Tom,
This does not satisfy the reference requirement?
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf describes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the SYSLOG-MSG field.";
reference
"RFC 5424: The Syslog Protocol
Std-1003.1-2008 Regular Expressions";
}
Please help me understand what more you want.
Thanks,
Clyde
On 12/14/17, 3:55 AM, "t.petch" <ie...@btconnect.com> wrote:
Clyde
A quick glance at -18 shows that there is now a Normative Reference for
Posix - good- but I do not see it referenced - not so good:-(
I think that there needs to be a reference in 4.1
Tom Petch
----- Original Message -----
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "Benoit Claise (bclaise)" <bcla...@cisco.com>; "Kent Watsen"
<kwat...@juniper.net>; "t.petch" <ie...@btconnect.com>;
<netmod@ietf.org>
Cc: <draft-ietf-netmod-syslog-mo...@ietf.org>
Sent: Wednesday, September 27, 2017 5:26 PM
Subject: Re: [netmod] syslog-model-17 shepherd writeup
issues -references
> Benoit,
>
> There were approximately 24 changes requested from you, Kent, Robert
Wilton, and Tom Petch. I have made approximately half of them and will
try to finish another revision of the draft by Friday.
>
> Thanks,
>
> Clyde
>
> On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)" <bcla...@cisco.com>
wrote:
>
> Clyde,
>
> Do you know your next step to progress this document?
>
> Regards, Benoit
> > 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" <kwat...@juniper.net>
> > 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" <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
>
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
