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

Andy Bierman <andy@yumaworks.com> Tue, 05 April 2022 17:03 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 22A7B3A0CB3 for <netmod@ietfa.amsl.com>; Tue, 5 Apr 2022 10:03:43 -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 dg93-FN2qJwE for <netmod@ietfa.amsl.com>; Tue, 5 Apr 2022 10:03:37 -0700 (PDT)
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 71AA43A0C94 for <netmod@ietf.org>; Tue, 5 Apr 2022 10:03:37 -0700 (PDT)
Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-2eafabbc80aso142848387b3.11 for <netmod@ietf.org>; Tue, 05 Apr 2022 10:03:37 -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=JYLsPJZzRSgL4NYQQ6HX8VImv13D24EafjhtiPWNYik=; b=opKF5DZzZ5R3tOaD+55lRDKcwi+Sk6NiBee9NffeqXt6SQgW9oFgZJbNDwX4K2aurk Dj1X+0Cb1WmCa4uR0+AfdbkgsYc1UFZwrIarNy541L7l7friZqoH6nWrA35xNOxMTCvJ i5+0zeyCIpZ0bWTaSU07rMwDTHNZEhO4m6l0p0LU5Unisg9sKbmzlC4QCRG/Z4HoA/N7 kqiDs1cGM9z5u3srgis/QJLvbTtmplzonLdWehiyQM9iflzrA76CmQc7l5zdF21P4cpr yuHX5z1Jnvfi0CVf2XSrixtNIX4mIizd2yQqakOe6CFxEn3qUm3O8RRAH4k2DU6ObiZG rwYQ==
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=JYLsPJZzRSgL4NYQQ6HX8VImv13D24EafjhtiPWNYik=; b=glE+2ZPDTitJ/J2I8H3G4OotZdx8Y8biZYbHB0tXGuByXUjssE+Ge7eVe77YCMQQ1X ebiC0AiPYP53CCMfakgwoPkSYf1yovzH55N2ox6eMpHZiRx2ZxcfYVtCTdiL8JU1FF0P YsYY1oMMXt3jAeOX3LLNAZdrR8xyXlcrq+6YF6QfIInpd6P+S/IM9JmkU8t4Zv3RA6eN KMhUnc8/yzcphcX/hXld26+8KtiaNOniDo+tE8mI1wC5fSrT60sb0ynOxLk9DhxhLkQ3 7vk+U96kHz70gg/kLwhf3Bh54o7Gk+rPET6ACQaqiVgx6Qy0eHZOL7hTKHf/U2eI+tmq eIVA==
X-Gm-Message-State: AOAM5317tmq7iHkOGZ4dl1n4lFSEG+gBDYC9UO2RDO6GZuEqUHWD8dCP aG9TmcsZ9qBmHlh6W2tP0LLqFMxAaV1qyWB9p4DUTecddVo=
X-Google-Smtp-Source: ABdhPJxy+byMjR7CiPd3OhSGWGYuBlAx/TzrAljDDjBoGVoIE5x05HQi+qPVR8JHgnft7634a/MhphQChqwW5bjCHKc=
X-Received: by 2002:a81:5dd6:0:b0:2d6:3041:12e0 with SMTP id r205-20020a815dd6000000b002d6304112e0mr3641071ywb.331.1649178216072; Tue, 05 Apr 2022 10:03:36 -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> <20220405153644.w5faspao6qkbq337@anna> <B98C7C87-D7B6-4DB0-85C7-E8B61EDC66F6@cisco.com>
In-Reply-To: <B98C7C87-D7B6-4DB0-85C7-E8B61EDC66F6@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 05 Apr 2022 10:03:25 -0700
Message-ID: <CABCOCHTZC+HqgBWr=m_wvVdgbDFnR6kTTv-XB20Ujn8uhj6krQ@mail.gmail.com>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Cc: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd9b7605dbeb39ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/F6sbhYlWkMOL7IaW11H02deIe7A>
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: Tue, 05 Apr 2022 17:03:43 -0000

On Tue, Apr 5, 2022 at 8:45 AM Acee Lindem (acee) <acee=
40cisco.com@dmarc.ietf.org> wrote:

>
>
> On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" <
> lsr-bounces@ietf.org on behalf of j.schoenwaelder@jacobs-university.de>
> wrote:
>
>     On Tue, Apr 05, 2022 at 01:48:25PM +0000, Acee Lindem (acee) wrote:
>     > [wg-member]
>     >
>     > The thing is that most of the existing RFCs use inet:ip-address
> rather inet:ip-address-no-zone. It would be better to if we could fix
> inet:ip-address in RFC 6991 BIS to not include the zone similar to what was
> done in the MIB (RFC 4001). However, we're getting the passive aggressive
> treatment on this point.
>     >
>
>     You either assume that all existing uses of inet:ip-address (inside
>     the IETF and outside the IETF) are wrong or you are willing to break
>     all the existing correct uses of inet:ip-address so that the type
>     matches your expectations.
>
>     The existing YANG update rules are pretty clear that changing the
>     semantics of definitions is not allowed. Hence, all the WG could do
>     is to deprecate ip-address and to introduce ip-address-zone.
>
> The best outcome would be to fix ip-address to not include the zone,
> introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> the is that all the existing usages do not require zone and this would be a
> fix as opposed to a change.
>
>
I don't think this will harm our implementations.
The type is still string. The pattern will change but that is handled by a
library.
Whatever pattern is used will get handled the same way.

The same problem exists for 'date' and 'date-no-zone' types,
but they are not used very much.

But...

Since import-without-revision is used most of the time,
a module importing ietf-inet-types will get what?
Very implementation-specific, that's what.
Maybe both versions of ip-address present in the same server, maybe not.



Acee
>
>     /js
>


Andy


>
>     --
>     Jürgen Schönwälder              Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org
>     https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>