Hi Tom, OK. Moved the text about the three other models to be positioned early in the intro: https://tinyurl.com/l2nm-latest. For experimental values, I'm having troubles to see how these can be used in contexts where interoperability is key (NETCONF/YANG). Cheers, Med > -----Message d'origine----- > De : tom petch <daedulus@xxxxxxxxxxxxx> > Envoyé : mercredi 18 mai 2022 13:12 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; > last-call@xxxxxxxx > Cc : adrian@xxxxxxxxxxxx; opsawg@xxxxxxxx; opsawg-chairs@xxxxxxxx; > draft-ietf-opsawg-l2nm@xxxxxxxx > Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG > Network Data Model for Layer 2 VPNs) to Proposed Standard BGP L2 > > On 13/05/2022 13:03, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Tom, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : tom petch <daedulus@xxxxxxxxxxxxx> Envoyé : vendredi 13 > mai 2022 > >> 11:23 > >> > >> I find some lack of clarity with regard of the BGP Layer 2 > >> Encapsulation Types module. > >> > >> I see no description of the module in the body of the document, > only > >> the module itself and the IANA Considerations (S.10.2). > > > > [Med] Hmm ... we do already have the following in Section 5: > > > > Also, the L2NM uses the IANA-maintained modules "iana-bgp- > l2-encaps" > > (Section 8.1) and "iana-pseudowire-types" (Section 8.2) to > identify a > > Layer 2 encapsulation type. > > > > and then in Section 7, you can read things such as: > > > > Remote CEs that are entitled to connect to the same VPN > should fit > > with the CE range ('ce-range') as discussed in Section 2.2.3 > of > > [RFC6624]. 'pw-encapsulation-type' is used to control the PW > > encapsulation type (Section 3 of [RFC6624]). The value of > the 'pw- > > encapsulation-type' are taken from the IANA-maintained > "iana-bgp- > > l2-encaps" module (Section 8.1). > > > > Is there anything else you think we should say? > > Yes. I think that the Introduction should say that this memo > defines four YANG modules, before going into so much detail of > just one of them. > You have got five paragraphs on l2vpn before the others get a > look in and, for me, that misses the big picture; some readers may > only care about the encapsulation module. > > And one point from below, Experimental Use values are in the > current registry which is why I think that they should be in the > YANG. > > Tom Petch > > > > >> > >> S.10.2 says ' add this note to both modules'. I only see one > module. > > > > [Med] This was fixed as per the genart review. Thanks for > catching this as well. > > > >> > >> It gives the name of the registry but not what Group it is part > of > >> i.e. > >> 'Border Gateway Protocol(BGP) Parameters'. Admittedly this is > one of > >> the better chosen Group names but it is always good practice > IMO to > >> specify Group name and Registry name when referencing IANA > entries. > > > > [Med] The note will be placed under the BGP parameters registry. > I don't think adding "under BGP parameters...registry" to the note > is useful. > > > >> > >> It also says that the name of the 'identity' is the lower case > of the > >> encapsulation name provided in the description. This is not > what > >> happens here, in the module, in many if not most cases. The > identity > >> name is based on the Description in the IANA Registry but > heavily > >> abbreviated. Who will decide on an acceptable abbreviation, > >> meaningful, unique, for future additions? > > > > [Med] I think this one was clarified as part of Dale's genart > review. Please check the diff shared in that thread. > > > >> > >> 'Unassigned or reserved values..' worth spelling out that those > are > >> the values in the BGP Layer 2 Encapsulation Types registry. > > > > [Med] Yes. > > > >> > >> And what about the Experimental Use values? They are not in the > IANA > >> module but why not? > > > > [Med] If such values appear in the re > > > >> > >> 'unique revision date' well yes but the current date would seem > more > >> useful. > >> > > > > [Med] This wording was agreed with Rob as there was a case where > IANA accidentally created two entries with the same revision date > when adding two types. > > > >> Section 8.1 describes the module as 'YANG data types defined by > IANA' > >> which seems odd. The underlying data types are defined by the > IDR > >> WG; perhaps 'maintained by'. > > > > [Med] Indeed. Changed to: > > > > "This module contains a collection of IANA-maintained YANG > > data types that are used for referring to BGP Layer 2 > > encapsulation types. .. > > > >> > >> I note that Section 8.2 which contains the other IANA module, > >> IANA-pseudowire-types, has a section title of 'IANA > Encapsulation > >> Types' > >> which seems odd in the absence of any explanation. > >> > > > > [Med] Good catch. Changed to "IANA-Maintained Module for > Pseudowire Types" > > > >> > >> 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@xxxxxxxx mailing lists by 2022-05-13. Exceptionally, > >> comments may > >>> be sent to iesg@xxxxxxxx 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@xxxxxxxx > >>> 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. > > > > . > > _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
