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

On Sat, Apr 9, 2022 at 11:00 AM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Andy,
>
>
>
> My opinion remains the same that RFC 4001 got it right with types
> including the zone specification being the exception rather than the
> default. I know that when people think IP address, they think the dotted 4
> octet without “%ZZZZ” appended. I’d still like to know if there are
> products that actually make use of the zone?
>
>
>

I agree the YANG types should have been named differently,
but it was not flagged as a problem 12 years ago..

> See inline responses in the unsnipped email below.
>
>
>
> *From: *netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <
> andy@yumaworks.com>
> *Date: *Saturday, April 9, 2022 at 1:38 PM
> *To: *Randy Presuhn <randy_presuhn@alumni.stanford.edu>
> *Cc: *"lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
> *Subject: *Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>
>
>
>
>
>
>
> On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <
> randy_presuhn@alumni.stanford.edu> wrote:
>
> Hi -
>
> On 2022-04-09 4:36 AM, Christian Hopps wrote:
> ...
> > FWIW, I'm not arguing for this change; however, to be fair, isn't this
> > also about the existing published modules that are using the incorrect
> > type?
>
> No.  "Incorrect type" is a bit of a mischaracterization.  It's like
> saying using "int32" is incorrect if all that is needed is "uint16".
> One might say its a little sloppy or mutter "RTFM" under one's breath,
> but it's not "incorrect."
>
>
>
> You and Martin convinced me the ip-address type cannot be changed.
>
> There are other options.
>
>
>
> If a YANG module is using ip-address, and the WG intent was really to
>
> use ip-address-no-zone, then that module can be fixed with an Errata.
>
> The modules should not need to be updated just for this incorrect typedef
> usage.
>
>
>
> The type names are unfortunate but in the future this will not happen
> again.
>
>
>
> Well, these are probably some of the most ubiquitous types in the YANG and
> forcing everyone to use the -no-zone types is more a tragedy than merely
> unfortunate.
>

It must not be a real problem or it would not have taken 12 years to
surface.
The typedef is silent about ignoring an explicit zone index in an
ipv4-address value.
If that is allowed, then maybe existing modules do not need to change.
IMO they do not need to change anyway, since a server can just reject an
address with a zone index in it.

I don't think the YANG author or reader is that burdened if '-no-zone' is
added to the type name.

>
>
>
>
>
> Some modules have used a type that potentially can represent more
> values than are needed for the intended purpose.  Whether those
> implementations will ever accept or produce those values will
> depend on whether the code, whether library, generated, or hand-
> crafted, enforces the tighter constraints appropriate to the usage
> or only the looser constraints appropriate to the type's specification.
>
> But this is also true of every usage of any type where the use
> can only exhibit a subset of the possible values of the type,
> whether that subsetting is obvious from the description or not,
> so I find it really hard to get excited about it.  The more nuanced
> a repertoire of types becomes, the more likely developers won't
> use exactly the right one, though one would hope that these foibles
> are caught during the review process, at least until developers
> start reading the documentation for the libraries they employ.
>
>
>
> There are many examples where the pattern allows more strings
>
> than the intended usage.  Also, a server can reject any request for any
> reason.
>
>
>
> That does not address the conformance problem that Acee may be concerned
> about.
>
> What is a server required to support for a leaf with type ip-address?
>
> The text does not look like the zone index is optional for the server to
> accept.
>
>
>
>
>
> Even in these cases of "incorrect" usage, as Andy and others
> have pointed out, stuff still works, because those cases only
> require a subset of the values supported by the type.  If the
> proposed change is made, usages requiring the full value space of
> the original type definition will break, and those formerly
> "incorrect" usages will exhibit no change in their behavior.
>
>
>
>
>
> It works because clients are not sending addresses with a zone index.
>
> I agree with Martin that the NC/RC server is always obligated to reject a
> request
>
> it cannot fulfill, regardless of the typedef.
>
>
>
> I thought Martin said a server not supporting zone could accept the IP
> address and simply ignore the zone? This would seem to be a better options
> than using the -no-zone types.
>

Maybe. There is no text in the typedefs but descriptions in the leaf or
other
data node could specify this behavior, or it could be an implementation
decision.

>
>
>
> That is, the proposed change does not improve operation of
> anything, and it breaks some things.
>
>
>
> yes -- too many years out in the wild this way to switch type names around
> now.
>
>
>
> I know I may be being too pragmatic, but does anyone support zone via
> %zzzz?
>

 We cannot get the full picture on this mailing list, after so many years.

Maybe just a clarification in the typedef is needed

  - A server MAY ignore a zone index specified in an ip-address

IMO a module SHOULD use ip-address-no-zone going forward,
if the intent is to disallow a zone index. Some modules have already done
so.

>
>
> Thanks,
>
> Acee
>

Andy

>
>
>
>
> For me, it's more important for stuff to work (and to not break
> stuff) than it is to align perfectly with the underlying aesthetics
> of some naming system attributed post hoc to a set of types.
>
> Randy
>
>
>
> Andy
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>