Hi,
-- snip --
> >
> > identity hardware-reset {
> > base reset-type;
> > description
> > "Hardware reset";
> > }
>
> What other types of resets do you envision?
>
Possible other reset types: reset-with/without-selftest, software-reset-- snip -- > > > 3 Added a couple of common attributes for the manufacturer name and > > > model > > > module: bbf-entity-extension > > > augment /ent:entity/ent:physical-entity: > > > +--rw class? identityref > > > +--rw contained-in* -> ../../ent:physical-entity/name --rw > > > +parent-rel-pos? int32 > > > > These were discussed in the ML thread starting with > > https://www.ietf.org/mail-archive/web/netmod/current/msg16458.html. > > However, it was never clear (at least not to me) how this would > > actually work. > > > > [Bart Bogaert] Please find an example below (assuming physical entity > > 'thisNode' with class 'chassis' exists) using CLI notation: > > Ok; so the idea would be that a pre-configured component would be identified > by the (contained-in, class, parent-rel-pos). This makes sense. If the > system detects some configuration for this tuple when a component is > detected, it uses the additional config data (specifically the 'name') when > it instantiates the component in the physical-entity list? That's correct, system will link state to config data using those leafs Regards, Bart
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
