Kent

You flag Std-1003.1-2008 as listed as a normative reference but not used
anywhere in the document.  In the Descriptions, but not in the s.4.1
references, I see

This leaf describes a Posix 1003.2 regular expression ...

twice, which may, or may not, relate to this issue.

Back in July, clyde said
"I will insert a normative reference to POSIX 1003.2 in the next
revision of the draft."

In a similar vein, RFC6991 appears in a reference statement but nowhere
else.

As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
should not be.

And in a slightly different vein,

   registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the

looks odd for plain text and for the repetition of 'the'..

Tom Petch

----- Original Message -----
From: "Kent Watsen" <kwat...@juniper.net>
To: <netmod@ietf.org>
Cc: <draft-ietf-netmod-syslog-mo...@ietf.org>
Sent: Tuesday, September 12, 2017 10:50 PM
Subject: [netmod] syslog-model-17 shepherd writeup issues


> Clyde, all,
>
> In reviewing the draft for Shepherd writeup, I found the following
issues that I think need to be addressed before the document can be sent
to Benoit for AD review:
>
>
> 1. Idnits found the following:
>
>   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
(--).
>
>     ** There are 2 instances of too long lines in the document, the
longest one
>          being 3 characters in excess of 72.
>
>     ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
>
>     ** Downref: Normative reference to an Historic RFC: RFC 6587
>
>     == Missing Reference: 'RFC5425' is mentioned on line 359, but not
defined
>          '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....'
>
>      == Unused Reference: 'RFC7895' is defined on line 1406, but no
explicit
>           reference was found in the text
>           '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG
Module L...'
>
>      == Unused Reference: 'RFC6242' is defined on line 1435, but no
explicit
>           reference was found in the text
>           '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
Secure Sh...'
>
>
> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
"@yyyy-mm-dd" in its name
>
> 3.  neither `pyang` nor `yanglint` found any errors with
ietf-syslog.yang.    pyang says
>       for vendor-syslog-types-example: statement "identity" must have
a "description"
>       substatement.
>
> 4. testing the examples in the draft against yanglint:
>       - for both examples: Missing element's "namespace". (/config)
>       - just removing the "<config>" element envelop resolves this
error.
>
> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
SHOULD be a
>      domain name (e.g., foo.example.com)
>
> 6. in the YANG module, anywhere you have an RFC listed in a
'description' statement,
>      there should be a 'reference' statement for that RFC.
>
> 7. in the tree diagram, the leafrefs no longer indicate what they
point at, they now all
>      just say "leafref".  Did you do this on purpose, or are you using
a different tree
>      output generator from -15?
>
> 8. RFC6536 is listed as a normative reference, but it probably should
be informative.
>
> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
used anywhere in the document.
>
> 10. RFC6242 is listed as an informative reference, but it is not used
anywhere in the document.
>
> 11. the document fails to declare its normative references to
ietf-keystore and ietf-tls-client-server.
>         Note: you manually entered the "[RFC yyyy], and [RFC xxxx]"
references…
>
> 12.  The IANA considerations section seems asymmetric.  Either put
both registry insertions into
>         subsections, or keep them both at the top-level…
>
> 13. reviewing the final document against my original YD review, I have
the following responses.  Let's be sure to close out these items as
well.  Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
s-0gOfCe8NSE
>
> 1. ok
> 2. better
> 3. should be: s/the message/these messages/  [RFC Editor might've
caught this]
> 4. better
> 5. still feel the same way, but no biggee
> 6. better, but from 8174, you should add the part "when, and only
when, they appear in all capitals, as shown here."
> 7. fixed
> 8. fixed
> 9. you did what I asked, but the result still isn't satisfying...
> 10. some improvements made in this area, but my ask wasn't among them
> 11. better
> 12. better, but I think the 4th line should be indented too, right?
> 13. better, but I wish you called S1.3 "Tree Diagram Notation"
> 14. fixed
> 15. fixed
> 16. fixed
> 17. fine
> 18. still a weird line brake here.  try putting the quoted string on
the next line.
> 19. fixed
> 20. fixed
> 21. not fixed (re: yang-security-guidelines)
> 22. fine
>
>
> PS: please also be sure to follow-up with Benoit on his AD review.
>
> Thanks,
> Kent  // shepherd & yang doctor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to