I meant to say something about the .1 vs .2 difference. My comment
assumes that it's supposed to be .1, but we of course should use
whatever is correct.
I also don't know much about that standards body.
K.
----- Original Message -----
From: "Kent Watsen" <[email protected]>
Sent: Wednesday, September 13, 2017 6:08 PM
Hi Tom,
Thanks. The fix I'm looking for is for the 'pattern-match' leaf
to have a 'reference' statement to Std-1003.1-2008, and for S4.1
to also list Std-1003.1-2008 as a draft-level reference.
and I am unfamiliar with that standards body so am looking for a little
more.
Is STD-nnnn always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?
Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant? You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.
You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.
The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.
I hope my confusion is sufficiently clear, at least to Clyde!
Tom Petch
I was going to point out the typo "the the" as well, but figured
that the RFC Editor would get it.
K. // shepherd
--
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" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
