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
