Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard

mohamed.boucadair@orange.com Fri, 13 May 2022 05:27 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C027C15E413; Thu, 12 May 2022 22:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Ja0SdWpCP3; Thu, 12 May 2022 22:27:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BF6C159A30; Thu, 12 May 2022 22:27:13 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4Kzxwb0ly5z1yBN; Fri, 13 May 2022 07:27:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1652419631; bh=quEXqjQbN4k7al1nNyUSa4MEJMdrPKUDf+pxEel1DcQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=eCU7zxbdDIqQI3FvFm3gNh8GHaXfo/Hr0JxJsTjvfHRtrcTsdWkBKfyzPpsO6BeVW 5gnF8edddtLa9ixTAzkUrR1p8p53+7DXwR/8zg7nOzm9C2Eg9XJmDuAhvtX18O6arg E3fdPwAcCIeesnzUUCTeCjID65SwSV7Vf5EDjs0dbzz1ZbNIyHFL62qPFlnBhQWESr 3P+7Ty3Evbgs4liSf9zku4/j1S+knbjQgubWlNwUI5Aw9fMpm2Mcgj7KhnQichXynv EXdd1Ks2Vi2BUIDqtFiBrDPkagluBq381vjCSC+PT/9npQT+DGmfafkSMyRWJJDVAs U7SmmbP1OxD/w==
From: mohamed.boucadair@orange.com
To: tom petch <daedulus@btconnect.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "opsawg@ietf.org" <opsawg@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "draft-ietf-opsawg-l2nm@ietf.org" <draft-ietf-opsawg-l2nm@ietf.org>
Thread-Topic: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard
Thread-Index: AQHYZhqJewcsY09B/k+4eda61LyZnK0cRA5Q
Content-Class:
Date: Fri, 13 May 2022 05:27:10 +0000
Message-ID: <30234_1652419630_627DEC2E_30234_156_1_d1797b0381904eae8f31541273964b8c@orange.com>
References: <165124323213.7379.13149514636739448316@ietfa.amsl.com> <627D30F4.6050101@btconnect.com>
In-Reply-To: <627D30F4.6050101@btconnect.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-05-13T05:13:15Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=cf818290-2079-42bb-a3f8-7c08b933e46f; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.50]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/zmivXfrlkPL450fsCKJf5ulyWCY>
Subject: Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 05:27:17 -0000

Hi Tom,

The use of the common module is provided early in the document. Section 1 includes the following:

   This document uses the common Virtual Private Network (VPN) YANG
   module defined in [RFC9181].

The description text is not "divergent" nor conflicting with what is in RFC9181. This text is provided for the reader's convenience. This is better compared to simply adding dry pointers to RFC9181.

It is the responsibility of each document making use of 9181 to find the appropriate description balance and also to ensure that it does not conflict with 9181. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <daedulus@btconnect.com>
> Envoyé : jeudi 12 mai 2022 18:08
> À : last-call@ietf.org
> Cc : adrian@olddog.co.uk; opsawg@ietf.org; opsawg-chairs@ietf.org;
> draft-ietf-opsawg-l2nm@ietf.org
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard
> 
> This I-D imports and uses a number of YANG grouping from RFC9181,
> ietf-vpn-common. This fact gets a mention in section 5 but you
> would not know this from the descriptive section, section 7, where
> imports and native YANG are seamlessly merged.
> 
> This I-D contains text on the meaning of the nodes, their usage
> and such like regardless of where they are defined.  Looking at
> RFC9181 it is rather short, or very short, on such text (e.g. in
> vpn-profile-cfg, vpn-description).  It would seem then that each
> document that imports
> RFC9181 will have to incorporate its own, potentially divergent,
> text on the meaning of the nodes and their usage while if ietf-
> vpn-common gets updated, the ripples may spread.
> 
> This seems unfortunate.
> 
> Tom Petch
> 
> On 29/04/2022 15:40, The IESG wrote:
> >
> > The IESG has received a request from the Operations and
> Management
> > Area Working Group WG (opsawg) to consider the following
> document: -
> > 'A YANG Network Data Model for Layer 2 VPNs'
> >    <draft-ietf-opsawg-l2nm-15.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action. Please send substantive comments
> to the
> > last-call@ietf.org mailing lists by 2022-05-13. Exceptionally,
> > comments may be sent to iesg@ietf.org instead. In either case,
> please
> > retain the beginning of the Subject line to allow automated
> sorting.
> >
> > Abstract
> >
> >
> >     This document defines an L2VPN Network YANG Model (L2NM)
> which can be
> >     used to manage the provisioning of Layer 2 Virtual Private
> Network
> >     services within a network (e.g., service provider network).
> The L2NM
> >     complements the Layer 2 Service Model (L2SM) by providing a
> network-
> >     centric view of the service that is internal to a service
> provider.
> >     The L2NM is particularly meant to be used by a network
> controller to
> >     derive the configuration information that will be sent to
> relevant
> >     network devices.
> >
> >     Also, this document defines a YANG module to manage Ethernet
> segments
> >     and the initial versions of two IANA-maintained modules that
> defines
> >     a set of identities of BGP Layer 2 encapsulation types and
> pseudowire
> >     types.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > IETF-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.