> You don’t need an RFC to use YANG. Yes, but we wanted to allow an RFC / draft to add a specific function to the voucher. Say, a new YANG attribute or multiple. The issue we hit there was that "augment" doesn't work for this if a voucher needs to be created that includes multiple independent add-on attributes. (Michael's slides.)
Instead, one can define an extension mechanism plus a registry of these extension attributes. Which can also be used by RFCs/drafts. Ideally (my viewpoint at least) is that a receiver can parse a voucher as valid YANG-based voucher, even if it would contain extension attributes that the receiver doesn't know about yet. MUD RFC 8520 had a mechanism to do this, for example. COSE also. > * MASA and Pledge run software from the same entity, so it does not need to > be standardized While the creator (MASA) and consumer (Pledge) would both understand the specific extensions, a middle party examining the voucher (Registrar) may not. Still, the Registrar might want to check that it's a valid voucher format. (For whatever reason.) > * 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 The Registrar is an example of an "other component". It may not understand what's inside the byte string, though. > * 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? The MASA in our use case knows the exact kind/revision/product that the Pledge is. So it can create the bytes such that the Pledge will understand it even without version info. > There may also be a desire to protect this beyond the protection the voucher > offers on its own. Good point, encryption/confidentiality comes to mind here. The signed voucher already provides the integrity. Esko -----Original Message----- From: Carsten Bormann <c...@tzi.org> Sent: woensdag 12 maart 2025 12:57 To: Esko Dijk <esko.d...@iotconsultancy.nl> Cc: Michael Richardson <mcr+i...@sandelman.ca>; Toerless Eckert <tte+i...@cs.fau.de>; anima@ietf.org; steffen.fr...@siemens.com Subject: Re: [Anima] Hierarchy in YANG structures, CBOR-YANG delta encoding and vendor extendibility On 12. Mar 2025, at 11:23, Esko Dijk <esko.d...@iotconsultancy.nl> 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 -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
