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.
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 understand that we wanted to tackle 1) in RFC8366bis, while 2) is under
discussion - maybe.
While PEN-based spaces works for 1), it doesn't address case 2).
For case 2 it would be sufficient to allocate 1 SID / 1 attribute in the
modules "voucher" / "voucher-request" with a value 'binary' (byte string) which
then contains something vendor-specific.
Esko
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: woensdag 12 maart 2025 01:14
To: Carsten Bormann <c...@tzi.org>
Cc: Esko Dijk <esko.d...@iotconsultancy.nl>; 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
Carsten Bormann <c...@tzi.org> wrote:
> Doing that gives you all you need to attach to the existing voucher
(e.g., using augment).
No, this does not work in practice, because you can't merge augments.
My slides explaining this are at some 2023 IETF.
I was looking at the RFC8520 extension example in Appendix B, and it uses
augment, and that most certainly does not work the way that they want.
> Having an undefined “here’s some bytes, but we won’t tell you what they
> mean” is probably a bit outside the way YANG people envision their
> ecosystem.
> (Note that there is an SID range for experimental use, if you promise
> to never use these in interchange; megaranges can also allow for
> private allocation.)
No, we are specifically aiming for the opposite :-)
> I’ll need to revise the PEN-Holder draft (by adding a 32-bit space per
> PEN-Holder to the 64-bit space already in there):
That's why I wanted PEN-based spaces too.
A sorta-public mega-range as suggested by Andy would also work for private
modules.
> https://www.ietf.org/archive/id/draft-bormann-core-yang-sid-pen-01.html
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
