From nobody Fri Nov 19 00:48:33 2021 Return-Path: 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 19F333A0CA4 for ; Fri, 19 Nov 2021 00:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOFslhjEhO8K for ; Fri, 19 Nov 2021 00:48:27 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 AABF23A0CA0 for ; Fri, 19 Nov 2021 00:48:26 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) (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 opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4HwVgX13szz4wVH; Fri, 19 Nov 2021 09:48:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1637311704; bh=i5v/rf1I8ZcivY73POatGQML3bQREUIQGb1sTkqbZtM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JAEh/bxcFO1ui2zClLfiJJUQdnet8+4fSNNbICXgRdUwlCY2Ak8ptv+MfbAfMCqR3 LoDHJ85XT3khQGm3a/spGqdcjRAEK3iPHBfAQkThSk08XhfCMQnIOcPu44m/i/B2AH a+NvqoO8R87sN7scjgKuR6LlwgdZrj8RMzOINW/E3XklIsbIy2SN5X8kt4vPgbZYGd D/shLWsTUoE0rHHRIEt3+djmpAetlsawLYIw1NSlkNz2tH6zhqTItLw5XmB8BD1WmX G08huYAT/jNiSf6Nm9GDQyFSydkOJ15EOxX9LGSaNFaRVS9WfqE26qL2mIaQhG7Ntu JAUdtoxLpyVLw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr06.francetelecom.fr (ESMTP service) with ESMTPS id 4HwVgX03Y5zDq7l; Fri, 19 Nov 2021 09:48:24 +0100 (CET) From: To: tom petch , "adrian@olddog.co.uk" , "opsawg@ietf.org" Thread-Topic: I-D Action: draft-ietf-opsawg-l2nm-09.txt Thread-Index: AQHXxY+BPrGf22xivUK/053Fr8a3lqvurcIIgAAG6gCACqd4gIAAVQzwgAATR9CAD4OmCYABcP3g Content-Class: Date: Fri, 19 Nov 2021 08:48:22 +0000 Message-ID: <4327_1637311704_619764D8_4327_490_1_787AE7BB302AE849A7480A190F8B9330354547F4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <163471885009.1635.1710953535762344047@ietfa.amsl.com> <15615_1634719796_616FD834_15615_95_1_787AE7BB302AE849A7480A190F8B93303542F007@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <142b01d7cf1f$ec3cc3a0$c4b64ae0$@olddog.co.uk> <9358_1636357114_6188D3FA_9358_491_1_787AE7BB302AE849A7480A190F8B93303544B31E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <22040_1636381142_618931D6_22040_274_1_787AE7BB302AE849A7480A190F8B93303544B9C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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=2021-11-19T08:47:49Z; 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=b447ff0f-6f1a-4e20-b1a6-a6c688c17355; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 08:48:32 -0000 Hi Tom,=20 Thank you for checking. Will fix as appropriate.=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: tom petch > Envoy=E9=A0: jeudi 18 novembre 2021 11:54 > =C0=A0: BOUCADAIR Mohamed INNOV/NET ; > adrian@olddog.co.uk; opsawg@ietf.org > Objet=A0: Re: I-D Action: draft-ietf-opsawg-l2nm-09.txt >=20 > From: mohamed.boucadair@orange.com > Sent: 08 November 2021 14:19 >=20 > Hi Tom, >=20 > > It looks like Figure 15 is out of line with the YANG in both -09 and -10 >=20 > Figure 15 has > leaf translate > leaf cvlan-id > leaf mode > where in the YANG it would appear to be > leaf translate > leaf cvlan-id > leaf direction >=20 > tom petch >=20 >=20 >=20 > I confirm that Figure 12 is correct. >=20 > What is authoritative is the YANG module. We provided the reader with > instructions to generate the full tree: >=20 > The full tree diagram of the module can be generated using the > "pyang" tool [PYANG]. >=20 > It is much more easier to include the full tree and update it once when > the module is touched but having a tree spanning dozens of pages is not > usable. This is why we are using subtrees: >=20 > That tree is not included here because it is > too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided > for the reader's convenience. >=20 > However, this approach has some cons as we need to check manually many > many figures. We are doing our best to maintain up-to-date subtrees ... > but bugs happen. >=20 > Thank you for helping identifying some of those. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : tom petch > > Envoy=E9 : lundi 8 novembre 2021 13:51 >=20 >=20 > > From: mohamed.boucadair@orange.com > > Sent: 08 November 2021 07:38 > > Hi Adrian, Tom, all, > > > > The comments raised by Tom are now addressed in -10. > > > > > In Figure 12 I see > > | +--rw saii? uint32 > > | +--rw remote-targets* [taii] > > | | +--rw taii uint32 > > | | +--rw peer-addr inet:ip-address > > while in Figure 13 I see > > | +--rw saii? uint32 > > | +--rw remote-target* [peer-addr taii] > > | | +--rw peer-addr inet:ip-address > > | | +--rw taii uint32 > > > > i.e. a change of identifier for the list, a change in keys, a change > > in leaf order. The YANG suggests that Figure 13 is wrong. More > > fundamentally, YANG tree diagrams are an aid to understanding and > > reviewing especially with a module as big as this. If they cannot be > > trusted, then what can? > > > > Tom Petch > > > > > > Two comments on idnits: > > > > (1) obsolete reference: > > > > -- Obsolete informational reference (is this intentional?): RFC 5143 > > (Obsoleted by RFC 4842) > > > > This is on purpose as we are following what is in: > > https://www.iana.org/assignments/pwe3-parameters/pwe3- > > parameters.xhtml#pwe3-parameters-2. > > > > (2) long lines: > > > > idnits is clean when I run it prior to submission: > > > > =3D=3D > > > > Checking nits according to https://www.ietf.org/id-info/checklist : > > > > ---------------------------------------------------------------------- > > -- > > ---- > > > > No issues found here. > > =3D=3D > > > > However, the datatracker displays the following after submission: > > > > =3D=3D > > Checking nits according to https://www.ietf.org/id-info/checklist : > > > > ---------------------------------------------------------------------- > > -- > > ---- > > > > ** There are 132 instances of too long lines in the document, the > > longest > > one being 3 characters in excess of 72. > > =3D=3D > > > > Will see how to fix this. > > > > Cheers, > > Med > > > > > > > -----Message d'origine----- > > > De : Adrian Farrel Envoy=E9 : lundi 1 novembre > > > 2021 13:57 =C0 : 'tom petch' ; BOUCADAIR Mohamed > > > > > > > Useful comments, thanks Tom. > > > > > > Authors, please run idnits and fix issues. Also address Tom's > comments. > > > > > > I'll be doing my shepherd review this week. Hopefully you can post a > > > new revision when the gates open next Monday. > > > > > > Cheers, > > > Adrian > > > > > > -----Original Message----- > > > From: tom petch > > > Sent: 01 November 2021 12:48 >=20 >=20 > > > From: OPSAWG on behalf of > > > mohamed.boucadair@orange.com > > > Sent: 20 October 2021 09:49 > > > Hi all, > > > > > > After discussing with Adrian, we are publishing this version that > > > addresses a recent comment from Julian. For more context, please > > > refer to https://github.com/IETF-OPSAWG-WG/lxnm/issues/350. > > > > > > > > > Some stray thoughts > > > > > > some lines are 90 characters long > > > > > > 802.1ah is referenced but not in I-D References 802.3ah ditto > > > 802.1ag Amendment 5 looks like a separate document warranting a > > > separate reference 802.1p is referenced implicitly 802.1Q likewise > > > > > > What is the difference between > > > identity bgp-l2encaps-type > > > Base BGP L2 encapsulation type > > > and > > > identity iana-pw-types > > > Base BGP L2 encapsulation type > > > > > > ccm-priority-type > > > what is high what low? > > > > > > Local Maintenance End Point (MEP) > > > This is not the expansion used by the ITU-T > > > > > > leaf split-horizon-filtering > > > what does true mean? > > > > > > leaf ccm-interval > > > no units > > > > > > leaf ccm-holdtime > > > no units > > > > > > leaf duplicate-ip-detection-interval no units > > > > > > leaf duplicate-ip-detection-interval no units > > > > > > > > > Tom Petch > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : I-D-Announce De la part de > > > > internet- drafts@ietf.org Envoy=E9 : mercredi 20 octobre 2021 10:34= =C0 > : > > > > i-d-announce@ietf.org Cc : opsawg@ietf.org Objet : I-D Action: ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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.