Hi Xufeng, FWIW, all the changes indicated in my reply are now implemented in https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/12/. Thanks again for your careful review. Cheers, Med > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : mardi 18 juin 2024 09:04 > À : 'Xufeng Liu' <xufeng.liu.ietf@xxxxxxxxx>; yang- > doctors@xxxxxxxx > Cc : draft-ietf-netmod-rfc8407bis.all@xxxxxxxx; last- > call@xxxxxxxx; netmod@xxxxxxxx > Objet : RE: Yangdoctors last call review of draft-ietf-netmod- > rfc8407bis-11 > > Hi Xufeng, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Xufeng Liu via Datatracker <noreply@xxxxxxxx> Envoyé : > mardi 18 > > juin 2024 05:33 À : yang-doctors@xxxxxxxx Cc : > > draft-ietf-netmod-rfc8407bis.all@xxxxxxxx; last- call@xxxxxxxx; > > netmod@xxxxxxxx Objet : Yangdoctors last call review of > > draft-ietf-netmod- > > rfc8407bis-11 > > > > > > Reviewer: Xufeng Liu > > Review result: Ready with Nits > > > > 3.2. Code Components > > The “file name” after the "<CODE BEGINS>" tag is something > described > > as “SHOULD” be included. If there is no such a “file name”, the > tool > > “rfcstrip” > > will not extract the correct file. Should we consider making > this > > “file name” a “MUST”? > > [Med] I tend to agree with you on this one. > > > > > 3.5.1. YANG Module Classification > > In the section “Network model”, the term "Network model” is > described > > as “relevant protocols operating at the link and network > layers”. Can > > a network model be designed for other layers, such as OTN or > MPLS? > > [Med] Yes as far as it "describes a network-level abstraction (or > a subset of aspects of a network infrastructure)". Please note > that the text you quoted starts with "including", which does not > exclude other network-level matters. > > > If so, such a description seems to > > be too narrow. RFC 8309 clarifies the “Service Model”, which > is the > > section before this one. Is there a definition of the “network > model” > > in RFC 8309? > > [Med] No. However, this maps to "network configuration model" > mentioned in the example illustrated in Figure 3 of RFC8309. This > is mentioned in the text: > > This model corresponds to > the network configuration model discussed in [RFC8309]. > > RFC8969 does not mention "configuration" because a network model > can be used for non-configuration purposes. > > > > > 3.8. IANA Considerations Section > > The “YANG Module Names” registry is defined in RFC 6020, but > not RFC > > 7950. Many YANG module writers mistakenly used RFC 7950. > > Should we consider bringing this up with special attention? > > [Med] We do already have the following: > > Section 3.8: > Each normative YANG module MUST be registered in both the > "IETF XML > Registry" [RFC3688] [IANA-XML] and the "YANG Module Names" > registry > [RFC6020] [IANA-MOD-NAMES]. > > Appendix A: > * IANA Considerations section -- this section must always be > present. For each module within the document, ensure that > the > IANA Considerations section contains entries for the > following > IANA registries: > > XML Namespace Registry: Register the YANG module > namespace. > > YANG Module Registry: Register the YANG module name, > prefix, > namespace, and RFC number, according to the rules > specified in > [RFC6020]. > > We might further emphasis on this point by adding a registration > template in Section 3.8. A PR to exercise this can be seen here: > https://github.com/netmod-wg/rfc8407bis/pull/56/files. > > > > > 4.5. Conditional Statements > > An example not preferred is given, but there is no preferred > fix. > > Would it be better to provide the proffered solution? > > > > [Med] Good point. Please see https://github.com/netmod- > wg/rfc8407bis/pull/57/files ____________________________________________________________________________________________________________ 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 To unsubscribe send an email to last-call-leave@xxxxxxxx
