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

Andy Bierman <andy@yumaworks.com> Sat, 09 April 2022 18:28 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41633A0D92 for <netmod@ietfa.amsl.com>; Sat, 9 Apr 2022 11:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-crKMhPhYgt for <netmod@ietfa.amsl.com>; Sat, 9 Apr 2022 11:28:38 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08CE3A0D98 for <netmod@ietf.org>; Sat, 9 Apr 2022 11:28:38 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id g34so621581ybj.1 for <netmod@ietf.org>; Sat, 09 Apr 2022 11:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FtNMHjYrWKswKBJlkEsyPjr4uIATLIpLh95e0OU+GjM=; b=n4Jd/qaAl3OMYQy7MAHTq7s7b3QWkgm9cWvBKmSOzAlcFO8Ml2tkeVlshle2Z1kRGa ywTu2TkrJLZCMtJ2mlV4bymDwrAt6bAhwr9QPc0otGRSNao6Y8OaVM/xdkY+p9t29PSB x9sxuWY0olbxx0ufhidAyX70CjtkwV2aCbzNSVGw2lb+zFph0wt/cKvUpGLs59g4+cdg hxsRRE656cISD24HJhbdVpLEsa/CdSAWVxwJeePeegKiuzqFyWodtS3BYti47e2zeXbH mSm09MOU2c/KNIzVQPQwpxcCWMxkuLFX8CHYVPm9HZIqy6Hy9yM8yZWtlwGMus3N3qw/ lQoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FtNMHjYrWKswKBJlkEsyPjr4uIATLIpLh95e0OU+GjM=; b=UIZVcTQQda0cb+RjZPiL1j6VQu0XpeA7YqOvGtx80fAx6/JQH710CrP2oIVIadxRI+ NVngp/LkBOvA8rbcGmjFLvhMh2S7eQl0kuUUORKEu2K2FhgD4qL0ezTwmqqi174B2A2C 3HN+KxN4n6w/t2EEASyvebvoNM5pbkSiJfZbUtnqabJAOQHHhVKoa8c/w7GPJEk4cs8Q wyww1fn+k/gcV6ttTIGfhpDorWHG5L8PPlgbYZo1VdSUZwWBjgGmJhD8MF9T5z+QbuEe qaPIMMCymOmNPtGlo715ZsveksdfWNcbty61KNpS0RWcubHwMDJvOWCdn74C2rgw/A8Z nXcw==
X-Gm-Message-State: AOAM532nKezb4iPmy/CMHvvQteRjIyqwaZVgyPFQyRxAWfmTCtSm2wqL NwtyZr9mDD2t+pvELmYnu3UiuqoBhE5vUbrmdy7IBw==
X-Google-Smtp-Source: ABdhPJxsfd2hqadizBL0Z3R0ql+8zuCIoK5HTSMdudHN0k3d5+QlWxX5Zr+uN5E1DNFsIoEsPwx4a2TKIpkw9vIoQds=
X-Received: by 2002:a5b:247:0:b0:624:4d24:94ee with SMTP id g7-20020a5b0247000000b006244d2494eemr17500888ybp.197.1649528917443; Sat, 09 Apr 2022 11:28:37 -0700 (PDT)
MIME-Version: 1.0
References: <164662287026.10186.17661147788695088858@ietfa.amsl.com> <AM7PR07MB62483353E387A0538EDA44C6A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB6248D0B4D19EF3168DEC4864A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <978D3500-5A9C-49FA-A259-B4E234CC9332@cisco.com> <AM7PR07MB6248CE4BDC0B27008D4F04BCA0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <2C00E058-F836-415E-A357-797E01FE77AD@cisco.com> <DB7E3112-3C2F-4040-81E1-F4625689DA62@chopps.org> <645FCC0B-8279-4070-B052-A553317B8474@cisco.com> <3F7DDA02-DEFA-4680-B048-1AB0A54C2FA1@chopps.org> <BB1D53D0-0D36-40DF-8B9D-4BD4EB6A35C1@cisco.com> <5b05a34d-41b6-7b65-ebe7-9dcaca80eeb2@alumni.stanford.edu> <m2wnfzydgz.fsf@ja.int.chopps.org> <530e30e1-9436-2123-7d03-eb4f876a9f90@alumni.stanford.edu> <72050246-8379-40CE-9171-110997FB0D5C@cisco.com> <28570b96-a7a0-1aee-9104-2402892a2089@alumni.stanford.edu> <m2fsmmfpn8.fsf@ja.int.chopps.org> <0a79b231-3be3-1765-bf32-abfb53b9076d@alumni.stanford.edu> <CABCOCHT-W9tRWV6jS_GbA9uwfkTY-E8=mDexCUGBbRy7HDgMfA@mail.gmail.com> <FCE6F5C4-D1EB-4DFE-9396-E97949E03178@cisco.com>
In-Reply-To: <FCE6F5C4-D1EB-4DFE-9396-E97949E03178@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 09 Apr 2022 11:28:26 -0700
Message-ID: <CABCOCHQh_3OQrAWp+CZnqD3Ap-PB_amrky+U4O_go_EQdhm4DA@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002bdaef05dc3ce1c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RIJf7HfpvihQPBbDYHjVI49NfBo>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2022 18:28:45 -0000

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
>
>