Re-, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Adrian Farrel <[email protected]> > Envoyé : vendredi 19 novembre 2021 11:57 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; draft- > [email protected] > Cc : [email protected] > Objet : RE: [OPSAWG] Shepherd review of draft-ietf-opsawg-l2nm > > Thanks for the speedy response, Med. > > Looks like you are completely on top of this. > > A few closures below. > > Cheers, > Adrian > > [significant snipping] > > >> I see "layer 2" and "Layer 2" etc. I think in the context of L2VPN, > >> L2NM, etc., "Layer 2" is fine. But others "like Layer 2 connection" > >> are used inconsistently. > > > > [Med] Thanks. I prefer to leave the current wording. > > OK. The RFC editor *will* raise the inconsistency. > > For example... > > Section 1 > Also, the document defines the initial versions of two IANA- > maintained modules that define a set of identities of BGP Layer 2 > encapsulation types (Section 8.1) > 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. > > >> Section 6 > >> > >> 'esi-redundancy-mode' Not sure, should you... > >> s/Single-Active/'single-active'/ > >> s/All-Active/'all-active/ > > > > [Med] The OLD one is OK because we are trying to be consistent with > > the > use in rfc7432. Thanks. > > I'm OK with this, but pointing out that evpn-redundancy-mode defines the > values for esi-redundancy-mode, and that uses lower case. > [Med] the identity labels use lower case, not the description. > > A merging of two issues, below... > > >> Section 8.1 > >> > >> Appendix B lists the > >> initial values included in the "iana-bgp-l2-encaps" YANG module. > >> > >> Initial values of what? > > > > [Med] ... of the registry. This is a living module if you will. It > > will > be automatically updated by IANA when new values are assigned. > > > >> I think you are saying that the YANG model is populated according to > >> the state of the registry at the time of publication of this document > >> (and that new entries to the registry should be matched with > >> additional nodes in this model). > >> > >> So, I would be inclined to leave this out. > >> > >> And actually, I'd omit Appendix B which doesn't add anything. > > > > [Med] A pointer to the IANA registry would be sufficient, but idnits > > won't > be happy as all reference statements have to be called outside the YANG > modules. These tables solves this issue. > > > >> > >> 8.1 and other subsections > >> > >> It is useful to help resolve references and import clauses by placing > some > >> text before the <CODE BEGINS> to say something like... > >> > >> This module makes imports from [RFCaaaa], and makes references to > >> [RFCbbbb] and [RFCcccc]. > > > > [Med] Agree. Unlike 8.3 and 8.4, we don't have such statements in > > 8.1/8.2 > because we don't have any imports. > > My first point was that if you say "This module references [RFCaaaa]" then > you don't need to use the Appendix to resolve the references. [Med] OK. Went for: == This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC5086]. == and == This module references [MFA], [RFC2507], [RFC2508], [RFC3032], [RFC3545], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4842], [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143], [RFC5795], and [RFC6307]. == > > I am not terribly worried by this issue: just that the two Appendixes > seemed to be a bit odd. In general, I don't like reproducing information > in multiple places because it is hard to see which is normative and how to > resolve discrepancies. > > >> Section 8.2 > >> > >> Why don't atm-aal5 and atm-vp-virtual-trunk have reference clauses? > > > > [Med] ... because we failed to find what is "[[ATM]]" in the IANA > > registry > (please see Appendix C). Please note that we have a reference statement in > 8.1 for atm-aal5. > > I believe it is per RFC 4446 (which is what populated the registry) > [ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed., > "Encapsulation Methods for Transport of ATM Over MPLS > Networks", Work in Progress. > I believe this became RFC 4717. (See Section 6.3.) I have sent mail to the > PALS chairs to ask them whether the registry should be updated. [Med] Thanks. Updated the module. it would be good if the registry is formally updated. > > >> Section 8.4 > >> > >> I don't find any explanation or reference for the color-type > >> identities > or > >> the color-type leaf. Maybe a description for Figure 20, or a > >> description clause for the leaf or the base identity. > > > > [Med] Joe raised a similar comment in the past. We added this general > pointer rather that redefining all the inherited item in the L2NM: > > > > See also Section 5.10.2.1 of [RFC8466]. > > Ah, good. > > Perhaps (but not absolutely necessary)... > > "See also Section 5.10.2.1 of [RFC8466] for more discussion of QoS > classification including the use of color types." > > That would close the loop for people searching through the document. Med] Deal! > > > As I expect this to pop-up in other reviews, I updated the yang > description with more text. > > So you may have closed this already > > > Section 9 > > > > The YANG modules specified in this document defines schema for data > > that is designed to be accessed via network management protocols such > > as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF > > layer > > > > s/defines schema/define schemas/ > > s/that is/that are/ > > s/] ./]./ > > > > [Med] Fixed. > > >> --- > >> > >> I think 10.2 and 10.3 should make it clearer that IANA is requested > >> to maintain the two YANG models. > > > > [Med] This is already mentioned in 10.1 > > Notwithstanding the text you quoted, you are not actually asking IANA to > do the thing (merely stated that it is done). [Med] We ask them to maintain the modules: This document requests IANA to register the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry: Please trust me, this is sufficient and the presence of "maintained by IANA:" will save us one usual question from IANA. > > The point here is that in satisfying 10.1, IANA just copies the text into > the registry. Nothing in the whole of Section 10, asks IANA to create and > maintain the modules. > Yes, they will probably work it out, but nothing beats being very, very > clear in an IANA considerations section. > > > >> A.4 > >> > >> In Figure 29 is it intentional that the left-hand end of the Emulated > >> Service is at the edge of the CE, but the right-hand end is in the > >> middle of the CE. > > > > [Med] Thanks for catching this. Fixed. > > > > This should be fixed in Figure 3 of RFC8214 as well. > > I'll raise an errata report. [Med] 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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
