Hi, Med, Thanks for resolving my comments, please also find my responses below inline.
Besides, if this draft is referenced somewhere by other documents because of, e.g., quotation of the tree diagram generation text in sec.3.4, use the Security Considerations Section template in sec.3.7.1, should this draft be listed as an informative or normative reference? Should this be stated in sec.3.4 and sec.3.7.1 where a reference exists (or somewhere else)? Best Regards, Qiufang From: [email protected] [mailto:[email protected]] Sent: Friday, September 27, 2024 3:49 PM To: maqiufang (A) <[email protected]>; [email protected] Cc: [email protected] Subject: RE: shepherd review for draft-ietf-netmod-rfc8407bis Hi Qiufang, Thank you for the careful review. The diff to track the changes can be found here: Diff: draft-ietf-netmod-rfc8407bis.txt - draft-ietf-netmod-rfc8407bis.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/quifang-review/draft-ietf-netmod-rfc8407bis.txt> Please see inline for more context. Cheers, Med De : maqiufang (A) <[email protected]<mailto:[email protected]>> Envoyé : vendredi 27 septembre 2024 08:07 À : [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> Objet : shepherd review for draft-ietf-netmod-rfc8407bis Hi, authors, WG, As part of my shepherd write-up for draft-ietf-netmod-rfc8407bis, I've reviewed the latest version of the draft and have got some editorial comments (most of which are nits), hopefully they could be fixed before progressing the document. The Idnits<https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-16.txt> complains of some errors and warnings, some of which I think are valid and need to be fixed before publication : · There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. The line where the when expression is located in sec.4..6.4: when 'derived-from-or-self(rt:address-family, "v4ur:ipv4-unicast")' { [Med] Fixed. Thanks. · Downref: Normative reference to an Informational RFC: RFC 8792 Could this be fixed as informative reference? [Med] This one is normative. Please note that 8792 is already listed in https://datatracker.ietf.org/doc/downref. Thanks for the information, well noted. · -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Better to fix the reference to RFC 7223 with 8343 (which also defines the identical example) in section 4.19.1? [Med] The citation of 7223 is intentional. See, e.g., = For example, the "ietf-interfaces" model in [RFC7223<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC7223>] has been restructured as an NMDA-compatible model in [RFC8343<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC8343>]. = The reference above is good for me, what I am referring to is another reference of 7223 in sec4.19.1(see below), which I think might be better to be replaced with RFC 8343 (RFC 8343 defines that example as well). Agreed? The following example from [RFC7223] shows how a conditional container called "ethernet" is added to the "interface" list only for entries of the type "ethernetCsmacd". augment "/if:interfaces/if:interface" { when "if:type = 'ianaift:ethernetCsmacd'"; container ethernet { leaf duplex { ... } } } Section 4.14 specifies a set of YANG statements that MUST have a description substatement, but I don't think anydata should be omitted here. Thoughts? [Med] This list is inherited from 8407, which in its turn was inherited from 6087. anydata wasn't in 6087 because it wasn't defined at the time in 6020. I don't have the context whether this was considered by the WG in the past, but I'm afraid that adding this mandatory will break existing models. For example, pyang does not make that check for anydata, while it is in place for anyxml. I suggest we leave the list as it is. That seems like a valid concern for this NBC update, I am okay with keeping this as it is, if there is no objections from others. Other nits: · Section 4.5 OLD: presence "When present, indicates type foo" NEW: presence "When present, indicates type foo"; (missing the semicolon) [Med] ACK. OLD: presence "When present, indicates type bar" NEW: presence "When present, indicates type bar"; (missing the semicolon) [Med] ACK. OLD: Section 8.1 of [RFC7950] includes a provision for defining a constraint on state data and specifies that the constraint must be true in a valid state data. NEW: Section 8.1 of [RFC7950] includes a provision for defining constraints on state data and specifies that the constraint must be true in a valid state data tree. [Med] OK, with s/ that the constraint/ that a constraint Note this as well: s/in a valid state data/in a valid state data tree/, agreed? · Section 4.20 OLD: max-elements 10; NEW: max-elements 10; Please consider indenting a space here. [Med] OK. · Section 4.24 s/ min-entries/min-elements s/max-entries/max-elements [Med] Good catch! This was inherited from 8470. · Section 5.1 OLD: Name: iana-template Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:iana-template Prefix: iana-foo Reference: RFC AAAA NEW: Name: iana-template Maintained by IANA? Y Namespace: urn:ietf:params:xml:ns:yang:iana-template Prefix: iana-foo Reference: RFC AAAA [Med] The OLD is OK. The template is not maintained by IANA. · Appendix A OLD: "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; NEW: "IETF NETMOD (Network Modeling) Working Group"; Or, "IETF your-wg-name (expansion) Working Group", to be consistent with the info in contact statement. [Med] Works for me. · Appendix C The IETF Trust Copyright statement for the iana-template module doesn't seem to be correct. s/Simplified/Revised/? [Med] ACK. Best Regards, Qiufang ____________________________________________________________________________________________________________ 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.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
