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

Christian Hopps <chopps@chopps.org> Tue, 05 April 2022 13:33 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D253A0659; Tue, 5 Apr 2022 06:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 3z4gJOHC8lhQ; Tue, 5 Apr 2022 06:33:33 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7427D3A0658; Tue, 5 Apr 2022 06:32:48 -0700 (PDT)
Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 561567D03A; Tue, 5 Apr 2022 13:32:47 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <2C00E058-F836-415E-A357-797E01FE77AD@cisco.com>
Date: Tue, 05 Apr 2022 09:32:46 -0400
Cc: Christian Hopps <chopps@chopps.org>, tom petch <ietfc@btconnect.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB7E3112-3C2F-4040-81E1-F4625689DA62@chopps.org>
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>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/j0OzBNquFt07UtfJIcPv9FWI1bw>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2022 13:33:38 -0000

If they are new leaf values why not use the correct no-zone variant, what's the harm in doing it right? It has a nice side effect of basically restricting the base spec zone values to no-zone only. :)

Thanks,
Chris.
[wg member]

> On Apr 4, 2022, at 12:30, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> In the MIB,  the base types don't include the zone - https://www.ietf.org/rfc/rfc4001.txt
> 
> It was very unfortunate that the YANG IP addresses included the zone in the base types. 
> 
> Tom - I think it would be hard to find an author where including the zone was a conscious decision. 
> 
> Thanks,
> Acee
> 
> On 4/4/22, 11:55 AM, "tom petch" <ietfc@btconnect.com> wrote:
> 
>    From: Acee Lindem (acee) <acee@cisco.com>
>    Sent: 04 April 2022 15:58
> 
>    Hi Tom, +Juergen, netmod WG,
> 
>    I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone and the zone versions should be added as a separate YANG type.
> 
>    The RFC 6991 is under revision now:
> 
>    https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
> 
>    However, I'm not sure if the painful backward compatibility discussions could be overcome.  We'd also have to admit that it was a big mistake to include the zone in the base addresses. In any case, I don't think we just start using the no-zone types when the base addresses types are used everywhere.
> 
>    <tp>
> 
>    Well, there are plenty of uses of the no-zone types as well, so some authors, some YANG doctors, have made the conscious choice to use them.  I cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and there are others.
> 
>    Also, some authors want the zone information as part of their leaf.
> 
>    Tom Petch
> 
>    Thanks,
>    Acee
> 
> 
> 
>    On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" <lsr-bounces@ietf.org on behalf of ietfc@btconnect.com> wrote:
> 
>        I assume that this is a refresh while waiting for ospf.yang to wind its way through the system
> 
>        I wonder if the ip address should be the no-zone variant from RFC6991 - I never know the answer to that so keep asking.
> 
>        Some time the contact needs updating to https://datatracker and the TLP to 'Revised'
> 
>        Tom Petch
> 
>        ________________________________________
>        From: Lsr <lsr-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
>        Sent: 07 March 2022 03:14
>        To: i-d-announce@ietf.org
>        Cc: lsr@ietf.org
>        Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> 
> 
>        A New Internet-Draft is available from the on-line Internet-Drafts directories.
>        This draft is a work item of the Link State Routing WG of the IETF.
> 
>                Title           : YANG Model for OSPFv3 Extended LSAs
>                Authors         : Acee Lindem
>                                  Sharmila Palani
>                                  Yingzhen Qu
>                Filename        : draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>                Pages           : 29
>                Date            : 2022-03-06
> 
>        Abstract:
>           This document defines a YANG data model augmenting the IETF OSPF YANG
>           model to provide support for OSPFv3 Link State Advertisement (LSA)
>           Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
>           extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
> 
> 
>        The IETF datatracker status page for this draft is:
>        https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
>        There is also an htmlized version available at:
>        https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10
> 
>        A diff from the previous version is available at:
>        https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10
> 
> 
>        Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
>        _______________________________________________
>        Lsr mailing list
>        Lsr@ietf.org
>        https://www.ietf.org/mailman/listinfo/lsr
> 
>        _______________________________________________
>        Lsr mailing list
>        Lsr@ietf.org
>        https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr