On 12. Mar 2025, at 11:23, Esko Dijk <[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. > 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 information flowing from one instance to the other * make sure that the security objectives and attributes are well understood; something may need to be standardized so the other components can handle the byte string * do we know that MASA and Pledge, beyond being programmed by the same entity, know which kind, revision, product line, etc. this byte string relates? There may or may not be a useful role for some identifying, versioning, etc. information together with the byte string. There may also be a desire to protect this beyond the protection the voucher offers on its own. Grüße, Carsten _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
