Carsten Bormann <c...@tzi.org> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
