Hi Clyde, One quick follow-up, it seems that all drafts are moving over to reference the tree-diagrams draft these days. As such, I think Section 1.3 (Tree Diagram Notation) should now be removed and Section 3.1 should change as follows:
OLD Please see Section 1.3 for tree diagram notation. NEW Please see [I-D.ietf-netmod-yang-tree-diagrams] for tree diagram notation. (yes, that should be hyperlink) and add I-D.ietf-netmod-yang-tree-diagrams as an Informative reference. Thanks, Kent ===== original message ===== Clyde, This draft still isn't passing idnits. I provided the link to idnits previously, but here it is again: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=FErz5G2HICKnT_lI6gedg7ni66XCMBrj756eh-lXdW0&e=. Below is the idnits output for -19 with inlined comments. PS: I didn't also checked the other issues we're tracking, but will when we get past these idnits issues. Kent ===== START ===== idnits 2.15.00 /tmp/draft-ietf-netmod-syslog-model-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=X00_D6mS_CYdDDM_LABw-a_uhQziwjSvaaz8UHC6Nc0&e=): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_1id-2Dguidelines.txt&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=U9PqY8kpdbwz_sL4a1DhBJagSvEx9sv9zZquldhed7U&e=: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=K833IRzwN3sBZr2ApmQYRHjvSmKHOhNjY4JQ2mUEm18&e= : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the RFC editor a step later on. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 352 has weird spacing: '...gorithm ide...' Kent: this is fine. it is in a tree diagram. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Kent: I can't find the error. Looking at the xml, it is verbatim what I have in the zerotouch draft. my guess is that this is a tooling error and we should ignore it. -- The document date (January 12, 2018) is 4 days in the past. Is this intentional? Kent: this is fine, it is intentional. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1386, but no explicit reference was found in the text Kent: looking at the XML, I see that the entire paragraph uses '[' and ']' as opposed to <xref .../>. Please fix this. == Unused Reference: 'RFC7895' is defined on line 1456, but no explicit reference was found in the text Kent: looking at the XML, I see two instances of an unwanted "/>" string. For instance: <xref target="RFC7895"/>/> Please fix this. ** Downref: Normative reference to an Historic RFC: RFC 6587 Kent: hmmm, what's going on here? This YANG module is providing an ability to configure the "tcp" transport, even though the IESG made that ability historic in 2012 (see IESG Note below). Searching online, it looks like Cisco supports this, but Juniper does not. What about other vendors, is it widely supported? Was this discussed in the WG? Answering my own question, searching my local mailbox, I don't see this ever being discussed before, other than Martin questioning if it was a good idea in Mar 2016 (no response). Please start a thread on the list to get WG opinion if it's okay for the draft to proceed as is or not. Here's the IESG Note from RFC 6587: IESG Note The IESG does not recommend implementing or deploying syslog over plain tcp, which is described in this document, because it lacks the ability to enable strong security [RFC3365]. Implementation of the TLS transport [RFC5425] is recommended so that appropriate security features are available to operators who want to deploy secure syslog. Similarly, those security features can be turned off for those who do not want them. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. ===== END ===== Thanks, Kent // shepherd _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=etLxOIrgGaAD30-UmDGkrdfiVvY7AsD2GQ8szCkUChk&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
