Carsten Bormann <[email protected]> wrote: >> I see a need for multiple levels of extendibility of a voucher / >> voucher-request: >> >> 1) new attributes in a standardized way (e.g. defined by IETF or >> others, vendors themselves). We are looking for a method of extending >> that's easier than spinning a new RFC each time that includes all the >> combined changes in one YANG model. E.g. something using a registry. >> The extending party would have to know YANG a bit; but not be an >> expert on YANG or what "augment" means and can/cannot do.
> You don’t need an RFC to use YANG. Registration certainly is one way
> to do this. Just make sure that the registration template is clear, as
> well as what the other YANG components are supposed to do with it.
augment can not be stacked.
In particular, each time you augment, you create a new YANG namespace.
This actually means that you get new SID values each time.
So it's just a non-starter.
>> 2) vendor-specific data Created by MASA, consumed by Pledge. The data
>> is not complying to a YANG model. Vendor / implementer knows near
>> nothing about YANG/modules and wants to stay as far as possible from
>> that.
> I read this as:
> * MASA and Pledge run software from the same entity, so it does not
> need to be standardized * a byte string is the best way to package
Yes, exactly.
I don't know how much security considerations we need here.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
