La implementación de las propiedades es bastante simple, basta con emplear un vector de definición de propiedades y extender cada uno de los shuttles con un vector de valores para cada una de las propiedades definidas. Cada shuttle mantiene (en un campo denominado pmask) una referencia al vector de valores para las propiedades definidas.
Dado que estas propiedades corresponden a elementos del contexto
gestionado por el 
kernel--el resto de elementos del contexto
correspondientes a abstracciones de usuario estarán gestionados por
completo en área de usuario--, no es necesario tener grandes vectores
de propiedades. Al contrario, en nuestra corta experiencia con el
prototipo implementado, la flexibilidad del modelo de shuttles ha
hecho innecesaria la definición de nuevas propiedades salvo en lo
referente a identidades de usuario y dominios de protección
(contenedores de recursos en área de usuario).
Las información sobre las propiedades definidas se mantiene en el vector de definición de propiedades que contiene una posición para cada propiedad definida. En cada entrada se mantienen los siguientes elementos:
Nótese como este modelo aisla por completo al sistema de shuttles de Off de las implementaciones particulares empleadas para suministrar recursos tradicionalmente mezclados con la gestión de procesos, tales como espacios de direcciones, espacios de E/S, identidades de usuario, privilegios, etc.
En la implementación actual, cada propiedad definida tiene un valor (posiblemente, el valor por defecto) para cada shuttle del sistema. Esto implica que la lista de valores de propiedades que cada shuttle posee corresponde a la lista de propiedades definidas en un momento dado. Una implementación más realista debiera permitir que cada shuttle sólo tuviese entradas para aquellas propiedades que utiliza. Esto es fácilmente implementable haciendo que en cada entrada del vector de valores de propiedades (pmask) esté contenido el identificador de propiedad. De este modo se aumentaría la escalabilidad en cuanto al número de propiedades se refiere.
Por último, y aunque en el diseño de Off las funciones de conmutación están invocadas mediante portales, en la implementación actual hemos utilizado llamadas a procedimiento en todos aquellos casos dónde el código de dichas funciones estaba contenido dentro del kernel. Creemos que esta implementación puede ser suficiente en la mayoría de los casos y esperamos cierta evolución del sistema en este aspecto.