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 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 > <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> (see the note > in that page). 8466 is also in the normative reference. > > 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/ > <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. > > 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. > >> >> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
