Hi Zahed, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Zaheduzzaman Sarker via Datatracker <[email protected]> > Envoyé : jeudi 2 juin 2022 10:40 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > 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). 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. 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.," > > 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 would say, please go through the document and correctly > categorise all the > references. > > > > _________________________________________________________________________________________________________________________ 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
