I hate when people selectively snip my Emails and respond out of context. Please don't do that in the future! I'll reply to the more constructive thread. Acee
On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn" <lsr-boun...@ietf.org on behalf of randy_pres...@alumni.stanford.edu> wrote: Hi - On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote: ... > If you look at the existing YANG RFCs rather than drafts that are confirming to the error, you'll notice that they don't use the no-zone types: > > https://datatracker.ietf.org/doc/rfc8344/ ... Huh? RFC 8344 *does* use inet:ipv4-address-no-zone and inet:ipv6-address-no-zone. > Also, if you look at the SNMP RFC 4001, you'll note that the base types do not include the zone index and RFC8344 references the MIB types using the base types (see snippet below). RFC 4001 addresses the limitation of the IpAddress SMIv2 base type, which is inherently unsuitable for IPv6 addresses. The new address types defined in RFC 4001 have OCTET STRING as their base type. The "base type" relationship you seem to be inferring reads too much into the labels, which are merely mnemonic. One might argue about the suitability of any particular (non)system of mnemonics, but the nature of these beasts is that we can't significantly change them once their published. > Clearly, it was wrong to make the IP addresses including the zone the default How is it a "default"? Both zonable and zoneless types are available to the model developer. Nothing makes one or the other a default. > and I'm not sure why there is all this effort not to just admit, fix the RFC 6991 BIS version, and be done with it. 30+ years of tradition (and BCP) not permitting types to be changed after they've been published, I suppose, motivated by our total lack of control over unpublished usage of these types after their definitions have been published. If there were actually something wrong with the semantics or syntax, I'm sure there would be more sympathy for the argument. But the heart of the argument is that the types label's mnemonicity is poor. That, coupled with the collateral damage resulting from a "fix", makes the whole argument terribly unpersuasive to me, particularly when the definition in question was been published, implemented, and deployed years ago. Randy _______________________________________________ Lsr mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod