Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

["Acee Lindem (acee)" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr