Hi Med, Thanks for cross checking and addressing the comments.
I think it would be great if authors (and AD) go through the doc to check that the references are correct. I will clear my discuss as I got what I intended with the discuss. //Zahed ________________________________ From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Sent: Thursday, June 2, 2022 2:42 PM To: Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com> Cc: The IESG <i...@ietf.org>; draft-ietf-opsawg-l...@ietf.org <draft-ietf-opsawg-l...@ietf.org>; opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>; opsawg@ietf.org <opsawg@ietf.org>; adr...@olddog.co.uk <adr...@olddog.co.uk> Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with DISCUSS) Re-, Please see inline. Cheers, Med De : Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com> Envoyé : jeudi 2 juin 2022 12:13 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : The IESG <i...@ietf.org>; draft-ietf-opsawg-l...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk Objet : Re: Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with DISCUSS) Thanks Med for your prompt reply. Your clarifications were helpful. Please see inline below //Zahed On 2 Jun 2022, at 11:33, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Zahed, Thank you for the review. Please see inline. Cheers, Med -----Message d'origine----- De : Zaheduzzaman Sarker via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Envoyé : jeudi 2 juin 2022 10:40 À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc : draft-ietf-opsawg-l...@ietf.org<mailto:draft-ietf-opsawg-l...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk> Objet : Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm- 18: (with DISCUSS) Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-opsawg-l2nm-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot- positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ ------------------------------------------------------------------ ---- DISCUSS: ------------------------------------------------------------------ ---- Thanks for the effort to produce this YANG model, I always fascinate by the work done in creating the YANG models. I have found inconsistencies in the classification of normative references and informative references, hence, would like to discuss those. Some examples below- - in the terminology section while [RFC6241], [RFC7950], [RFC8466], [RFC4026], and [RFC8309] are normative references, [RFC8969] and [RFC8340] are not. [Med] Only 7950 and 6241 from that list are cited as normative. This is because this is implied by (RFC8407): https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines (see the note in that page). 8466 is also in the normative reference. [Med] Yes, you are right. I have the context recovered now for 8466. This was listed as normative as we don’t reiterate OAM and color type usage in the L2NM and point to 8466. == As shown in Figure 17, the L2NM inherits the same structure as in Section 5.3.2.2.6 of [RFC8466]<https://datatracker.ietf.org/doc/html/rfc8466#section-5.3.2.2.6> for OAM matters. == and == See also Section 5.10.2.1 of [RFC8466]<https://datatracker.ietf.org/doc/html/rfc8466#section-5.10.2.1> for more discussion of QoS classification including the use of color types. === For the other RFCs, we are trying to be consistent with previous usages. For ex Take the example of 8340, ** none ** of the very very long of RFCs that cites 8340 is categorizing it as normative: https://datatracker.ietf.org/doc/rfc8340/referencedby/. We can understand that if we look at RFC8407: If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. The majority of RFCs are citing RFC4026 as informative. I see your point. For this document while reviewing, I found it very important to understand the terminologies. This might be due to lack of experience with YANG models on my part. I felt like I can’t digest this doc without understanding those terms and that falls into normative definition to me. As you mentioned majority that doest not mean “all” so I don’t see we should be bothered to put them in the normative section it that helps. I will leave it up to you experts to decide. [Med] Noted, thanks. and so on. But clearly this document uses terms defined in those documents and I as a reader had to open those RFCs to understand what the terms are and without that I would not be possible to understand this document. - sometimes the this document is correctly referring to other documents as normative, as terms or processes are defines there but sometimes it is not. for example - 'signaling-option': Indicates a set of signaling options that are specific to a given VPN network access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote CE ID as discussed in Section 2.2.2 of [RFC6624]. [Med] This is because this is just an example: ", e.g.," May be a wrong example to illustrate the case - here is another one 'l2vpn-bgp': The service is a Multipoint VPLS that uses a BGP control plane as described in [RFC4761<https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC4761>] and [RFC6624<https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC6624>]. RFC4761 is normative and RFC6624 is not. It is very hard for me to see if there is other reasons to make 4761 normative and not 6624. [Med] For this one I think that what happened is that we trusted the classification made in RFC8466, which had the same wording as the one you quoted: == o Multipoint VPLSs that use a BGP control plane as described in [RFC4761] and [RFC6624]. == I moved this one to normative, especially after re-reading this part: == 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<https://datatracker.ietf.org/doc/html/rfc6624#section-2.2.3> [RFC6624]<https://datatracker.ietf.org/doc/html/rfc6624#section-2.2.3>. 'pw-encapsulation-type' is used to control the pseudowire encapsulation type (Section 3 of [RFC6624]<https://datatracker.ietf.org/doc/html/rfc6624#section-3>). == Now, without understanding what is discussed or defined in RFC6624 it was hard for me to understand the node/leaf mentioned in this document. Thus, I felt RFCC6624 should be a normative reference but it was not. - The reference modules from this document cannot be informative reference, can they? [Med] They can. We are using a classification that is aligned with rfc8407#section-3.9: For every normative reference statement that appears in a module contained in the specification that identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification. If the reference statement identifies an informative reference that identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section. For example in section 8.1 it says - This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC5086]. however, RFC4842 and RFC5086 is informative reference. [Med] Which is normal as per the clarification above. I see, I haven’t checked if all of the were imported or not. My mistake.
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg