I was first asking about the encoding ;-) Would be good to understand if this "empty" encoding would result in a - same of different degree of "backward compatibility" as an extended enum - same or different size of ascii and binary encoding ?
I am also not quite clear what difference it really makes to use empty instead of just creating a new revision of the voucher, as shown for module b in https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.5 Need to learn more YANG ;-) Wrt errata: I would bet that none of this will go through as errata to RFC8366. In all the instances i remember erratas being accepted as such, they where all about what i'd call real textual bugs where it was obvious that what was desired by the RFC is not what the text of the RFC says. I think choosing a better/different extensible encoding is purely a feature. Which is fine, it just means we need to find a different place to track this, maybe the trac wiki. Errata are just a very limited editorial tool, not really a generic help for an RFCbis ;-( Lets hear from yang doctors or yang friends. Right now i bet that if the only change for yang vouchers is this enum, then its probably easiest to do b), e.g.: make AE be a formal update. I think c) is appropriate if we have a larger critical mass of changes for rfc8366. Cheers Toerless On Fri, Jun 25, 2021 at 04:41:08PM -0400, Michael Richardson wrote: > > Toerless Eckert <t...@cs.fau.de> wrote: > tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty > tte> Is this the solution we are looking for ? > > > here it the relevant text: > > } The second situation is when you want to define an extensible enumeration, > } as an alternative to the type "enumeration", which is not extensible by > other > } modules. For example if an enumeration is used: > > } leaf protocol { > } type enumeration { > } enum smtp; > } enum pop3; > } } > } } > } and we want to add a new protocol 'imap4', it must be done by adding a new > } enum in the module. But if we use a choice of type empty instead: > > } container protocol { > } choice p { > } case smtp { leaf smtp { type empty; } } > } case pop3 { leaf pop3 { type empty; } } > } } > } } > } then another module can augment the first: > } > } augment /foo:protocol/p { > } case imap4 { leaf imap4 { type empty; } } > } } > > Well, this seems to be exactly what we want. > Do we get to put a description in there? > can we put a value in so that our SID process works? > (I imagine we'll have to hack pyang to make it cope, but...) > > proceedural options: > > 1) write this up as errata against 8366. That seems a bit much for errata, > but how much whisky does it cost to bribe an AD? > > 2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of > updates, and that's it. > > 3) do an entire RFC8366bis. > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- t...@cs.fau.de _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
