Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

Hi Clyde,

Trimming down to just the active discussion points.




>   12. S3, P8: I'm having trouble understanding the pseudocode.  What
>happens if S and/or F are not present?  Can S or F ever not be
>present? - looking at the tree diagram, it seems like they might
>always be set to something in the model.
>
> [clyde] S or F might not be present. 

In the YANG module, facility-list is keyed by [facility severity], which
means the values are always present, right?

[clyde] There are two paths specifying a facility-filter in which case S or F 
are present, or specifying a pattern-match in which case they might not be 
present if facility-filter is not specified.   

 if this is what you're trying to say, then your pseudocode isn't right.
Regardless if you agree with me or not, you need to somehow make this section 
clearer.



>14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
>'address' leaf?
>
> [clyde] not as far as I know
>

Looking at the tree-diagram, the 'tls' case doesn't seem to have the
address or port fields.  FWIW, the ietf-tls-client module doesn't 
provide these fields so that consuming modules can configure a normal
client versus a client listening for call-home connections...

   +--:(tcp)
   |  +--rw tcp
   | +--rw address?   inet:host
   | +--rw port?  inet:port-number
   +--:(udp)
  +--rw udp
 +--rw address?   inet:host
 +--rw port?  inet:port-number
  +--:(tls)
 +--rw tls
  
+--rw server-auth
 

[clyde] Here is what the tree looks like in the latest draft…

   |  +--:(tls)
   | +--rw tls
   |+--rw server-auth
   ||  +--rw trusted-ca-certs?   -> 
/ks:keystore/trusted-certificates/name
   ||  +--rw trusted-server-certs?   -> 
/ks:keystore/trusted-certificates/name
   |+--rw client-auth
   ||  +--rw (auth-type)?
   || +--:(certificate)
   ||+--rw certificate?   -> 
/ks:keystore/keys/key/certificates/certificate/name
   |+--rw hello-params {tls-client-hello-params-config}?
   ||  +--rw tls-versions
   ||  |  +--rw tls-version*   identityref
   ||  +--rw cipher-suites
   || +--rw cipher-suite*   identityref
   |+--rw address?inet:host
   |+--rw port?   inet:port-number

Address and port are there. Please clarify on what you think is missing.
  
This is what it looks like in the model:

case tls {
  container tls {
description
  "This container describes the TLS transport options.";
reference
  "RFC 5425: Transport Layer Security (TLS) Transport 
   Mapping for Syslog ";
uses tlsc:tls-client-grouping;
leaf address {
  type inet:host;
  description
"The leaf uniquely specifies the address of 
 the remote host. One of the following must be 
 specified: an ipv4 address, an ipv6 address, 
 or a host name.";
}
leaf port {
  type inet:port-number;
  default 6514;
  description
"TCP port 6514 has been allocated as the default 
 port for syslog over TLS.";
}
  }
}


 Sorry, it didn't see them way down at the bottom.  In all my drafts, I 
have these leafs before the tls-client-grouping.  Can you please switch the 
order around?




> 19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
>have values set for enums 'none' and 'all'?  When would these values
>be used, as opposed to the enum's name string?  If you do need values,
>then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
>and 'all' be -2147483648 (so everything is greater than it)?
>
> [clyde] ‘none’ and ‘all’ are set to values that are not defined in 
> RFC 5424. These values were previously suggested by Martin Björklund

Fine, but let's re-evaluate the values now.  Image having a variable x
and stepping through the selector list:

  if x >= facility-list/severity then foo.

Now imagine it read:

  if x >= 'all' then foo.

What integer value for 'all' would always ensure True?  MIN-INT
Likewise, you 

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 references

[t.petch]

Clyde

What  concerns me most is that AFAICT anything that is referenced in a
YANG module is a Normative Reference in the RFC that defines it and you
do not have those two I-D in the list of references.

Since they have not been published, then they would appear as I-Ds in
the references and the RFC Editor knows to on the one hand, hold up the
publication of the referring I-D until until the references become RFC,
and on the other hand insert the RFC number when they do.

I note that in other modules, I see no RFC for an import.  Strictly one
is not needed since the name should be unique and can be derefenced but
it is nice to have (SNMP usually has it).

But as I say, it is the lack of Normative Reference that worries me
most.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
To: "t.petch" ; "Kent Watsen"
; 
Sent: Wednesday, August 09, 2017 5:53 PM

> Tom,
>
> The agreement was that I should use “” until the two unapproved
RFCs that the model depends on are assigned numbers.
>
>  RFC : Keystore Management
>  RFC : Transport Layer Security (TLS) Client";
>
> Imported are:
>
>   import ietf-tls-client {
> prefix tlsc;
>   }
>
>   import ietf-keystore {
> prefix ks;
>   }
>
>
> Have numbers been assigned?
>
> Thanks,
>
> Clyde
>
> On 8/9/17, 4:32 AM, "t.petch"  wrote:
>
> Clyde
>
> You use  as a placeholder for three different RFC and two of
these
> do not appear AFAICT in the list of References.
>
> This might be a challenge for the RFC Editor.
>
> Tom Petch
>
>
> - Original Message -
> From: "Clyde Wildes (cwildes)" 
> Sent: Wednesday, July 19, 2017 6:48 PM
>
>
> > Hi Alex,
> >
> > Answers inline as [clyde]…
> >
> > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
> 
wrote:
> >
> > I am considering to implement the data model in this draft.
> (dependent on business priorities of course)
> > I have reviewed this draft and found the following issues.
> >
> > * I see pattern-match is specified to use POSIX 1003.2
regular
> expressions. This is presumably for compatibility with existing
> implementations; however it is inconsistent with most of YANG
(which is
> specified to use XPath regular expressions) - unless these are the
same.
> >
> > [clyde] I believe that my answer in the other thread explains
why we
> used Posix 1003.2 – it is commonly used.
> >
> > * pattern-match is inside the facility-filter container;
common
> sense says this is wrong as pattern-match has nothing to do with
> facilities.
> >
> > [clyde] I will move pattern-match up one level in the next
version of
> the draft. Thanks for catching this!
> >
> > * The advanced-compare container groups together two nodes
that
> share a common "when" and "if-feature" statement, but don't seem
to have
> any semantic relation to each other. Are there general guidelines
on
> when to use a container?
> >
> > [clyde] The confusion may come as a result of the when clause
> appearing before the if-feature clause which is set by the IETF
> statement order recommendation.
> >
> > The when construct was suggested by Martin Björklund as a way of
> solving the case that advanced-compare does not apply for the ‘all
’ and
> ‘none’ case.
> >
> > The if-feature applies to the entire container – it is either
> supported or not.
> >
> > * The advanced-compare container has a description starting
with
> "This leaf ..." even though it is not a leaf.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * The examples are missing  nodes.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * Perhaps there should be more consistent terminology for
> receivers of syslog messages; both "collectors" and "actions" are
used
> in the draft. RFC 5424 uses "collector" for the ultimate recipient
of a
> log message - which might not be applicable, because the sending
system
> has no idea whether the receiving system is a collector or a
relay.
> >
> > [clyde] The definition of “collector” in RFC 5424 is: A
"collector"
> gathers syslog content for further analysis.
> >
> > actions relate to the “further analysis” taken by the
 “collector”.
> >
> > “Collectors” appears in the model under the remote action and I
> believe the usage is correct:
> >   container remote {
> > if-feature remote-action;
> > description
> >   "This container describes the configuration parameters
for
> >forwarding syslog messages to remote relays or
> collectors.";

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Kent,

Comments inline as [clyde]…

On 8/14/17, 6:53 AM, "Kent Watsen"  wrote:



>5. S1 as a whole.  I'm a bit unclear what this section is doing.  It
>seems to be a general summary of Syslog (RFC5424).  Do we need this 
here?
>
> [clyde] Suggestions appreciated. I wanted to provide a high level overview
> of the syslog process. I cleaned it up a little.
 
Move Section 2 text to Section 1, replacing the text that's there?

[clyde] will do

>   12. S3, P8: I'm having trouble understanding the pseudocode.  What
>happens if S and/or F are not present?  Can S or F ever not be
>present? - looking at the tree diagram, it seems like they might
>always be set to something in the model.
>
> [clyde] S or F might not be present. 

In the YANG module, facility-list is keyed by [facility severity], which
means the values are always present, right?

[clyde] There are two paths specifying a facility-filter in which case S or F 
are present, or specifying a pattern-match in which case they might not be 
present if facility-filter is not specified.   

>14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
>'address' leaf?
>
> [clyde] not as far as I know
>

Looking at the tree-diagram, the 'tls' case doesn't seem to have the
address or port fields.  FWIW, the ietf-tls-client module doesn't 
provide these fields so that consuming modules can configure a normal
client versus a client listening for call-home connections...

   +--:(tcp)
   |  +--rw tcp
   | +--rw address?   inet:host
   | +--rw port?  inet:port-number
   +--:(udp)
  +--rw udp
 +--rw address?   inet:host
 +--rw port?  inet:port-number
  +--:(tls)
 +--rw tls
  
+--rw server-auth
 

[clyde] Here is what the tree looks like in the latest draft…

   |  +--:(tls)
   | +--rw tls
   |+--rw server-auth
   ||  +--rw trusted-ca-certs?   -> 
/ks:keystore/trusted-certificates/name
   ||  +--rw trusted-server-certs?   -> 
/ks:keystore/trusted-certificates/name
   |+--rw client-auth
   ||  +--rw (auth-type)?
   || +--:(certificate)
   ||+--rw certificate?   -> 
/ks:keystore/keys/key/certificates/certificate/name
   |+--rw hello-params {tls-client-hello-params-config}?
   ||  +--rw tls-versions
   ||  |  +--rw tls-version*   identityref
   ||  +--rw cipher-suites
   || +--rw cipher-suite*   identityref
   |+--rw address?inet:host
   |+--rw port?   inet:port-number

Address and port are there. Please clarify on what you think is missing.
  
This is what it looks like in the model:

case tls {
  container tls {
description
  "This container describes the TLS transport options.";
reference
  "RFC 5425: Transport Layer Security (TLS) Transport 
   Mapping for Syslog ";
uses tlsc:tls-client-grouping;
leaf address {
  type inet:host;
  description
"The leaf uniquely specifies the address of 
 the remote host. One of the following must be 
 specified: an ipv4 address, an ipv6 address, 
 or a host name.";
}
leaf port {
  type inet:port-number;
  default 6514;
  description
"TCP port 6514 has been allocated as the default 
 port for syslog over TLS.";
}
  }
}

   

> 19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
>have values set for enums 'none' and 'all'?  When would these values
>be used, as opposed to the enum's name string?  If you do need values,
>then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
>and 'all' be -2147483648 (so everything is greater than it)?
>
> [clyde] ‘none’ and ‘all’ are set to values that are not defined in 
> RFC 5424. These values were previously suggested by Martin Björklund

Fine, but let's re-evaluate the values now.  Image having a variable x
and stepping through the selector list:

  if x >= facility-list/severity then foo.

Now imagine 

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

>5. S1 as a whole.  I'm a bit unclear what this section is doing.  It
>seems to be a general summary of Syslog (RFC5424).  Do we need this here?
>
> [clyde] Suggestions appreciated. I wanted to provide a high level overview
> of the syslog process. I cleaned it up a little.
 
Move Section 2 text to Section 1, replacing the text that's there?



>   12. S3, P8: I'm having trouble understanding the pseudocode.  What
>happens if S and/or F are not present?  Can S or F ever not be
>present? - looking at the tree diagram, it seems like they might
>always be set to something in the model.
>
> [clyde] S or F might not be present. 

In the YANG module, facility-list is keyed by [facility severity], which
means the values are always present, right?



>14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
>'address' leaf?
>
> [clyde] not as far as I know
>

Looking at the tree-diagram, the 'tls' case doesn't seem to have the
address or port fields.  FWIW, the ietf-tls-client module doesn't 
provide these fields so that consuming modules can configure a normal
client versus a client listening for call-home connections...

   +--:(tcp)
   |  +--rw tcp
   | +--rw address?   inet:host
   | +--rw port?  inet:port-number
   +--:(udp)
  +--rw udp
 +--rw address?   inet:host
 +--rw port?  inet:port-number
  +--:(tls)
 +--rw tls
  
+--rw server-auth
 



> 19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
>have values set for enums 'none' and 'all'?  When would these values
>be used, as opposed to the enum's name string?  If you do need values,
>then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
>and 'all' be -2147483648 (so everything is greater than it)?
>
> [clyde] ‘none’ and ‘all’ are set to values that are not defined in 
> RFC 5424. These values were previously suggested by Martin Björklund

Fine, but let's re-evaluate the values now.  Image having a variable x
and stepping through the selector list:

  if x >= facility-list/severity then foo.

Now imagine it read:

  if x >= 'all' then foo.

What integer value for 'all' would always ensure True?  MIN-INT
Likewise, you can see that MAX-INT is the best value for 'none'.



>20. S7: can you indent the two blocks of details so the whole thing
>reads better?
>
> [clyde] I searched for an example that shows how to do this in XML
> and couldn’t find the keyword.

Assuming xml2rfc XML, then you could convert the contents to a figure,
or a list with style='empty'


  
Thanks,
Kent


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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Kent,

Thanks for your exhaustive review. I will be publishing the revised model 
momentarily.

Comments inline as [clyde].

On 7/12/17, 2:55 PM, "netmod on behalf of Kent Watsen"  wrote:

As shepherd, yang doctor, and individual contributor, following is 
my LC/YD review.

1. Because I know this draft will not be presented in Prague, I first
checked to see if it was NMDA-compatible.  The draft contains just
one module, and it only contains config true nodes (no config false
nodes).  There is no companion "-state" module in the Appendix.  As
far as I can tell, all this is accurate, as I don't believe this 
module needs to do anything special to be NMDA compatible.  Agreed?

[clyde] Agreed.

2. the abstract seems just a little bland.  Is there any way to beef
it up with a sentence or two?

[clyde] Done.

3. S1, P1, last sentence.  s/the messages/these messages/?

[clyde] Done.

4. S1, P3, 1st sentence: "and processes those"?  - rewrite sentence?

[clyde] Done.

5. S1 as a whole.  I'm a bit unclear what this section is doing.  It
seems to be a general summary of Syslog (RFC5424).  Do we need this here?

[clyde] Suggestions appreciated. I wanted to provide a high level overview of 
the syslog process. I cleaned it up a little.

6. S1.1: you should also reference RFC8174 here.

[clyde] Done

7. S1.2: three terms come from 5424, but only one has its definition
   provided.  This seems inconsistent...

[clyde] Done

8. S2: s/6020/7950/

[clyde] done

9. S3, P3: this paragraph is hard to read due to the previous paragraph
talking about proprietary features.  Maybe replace the beginning of the 
sentence to read "Some optional features are defined in this document
to specify"?

[clyde] done

10. S3, P4: The diagram appears to show multiple originators, not 
just one, so s/an originator/originators/?  Also, I don't think 
either of the commas are needed.

[clyde] done

11. S3, P6: This paragraph starts a new aspect of the design, right?
This is likely just a text-rendering issue, but the transition from
the diagram above (Figure 1) to this line is not visible.  Can you
provide a transition sentence?

[clyde] done

12. S3, P8: I'm having trouble understanding the pseudocode.  What
happens if S and/or F are not present?  Can S or F ever not be
present? - looking at the tree diagram, it seems like they might
always be set to something in the model.

[clyde] S or F might not be present. 

   The operative sentence in the pseudocode is: 
   There is an element of facility-list (F, S)…
   or the message text matches the regex pattern (if it is present)

13. S3.1, P1: RFC 6087 did not define tree diagram notation, and
rfc6087bis references the tree-diagram draft.  I don't think that
it is safe for this draft to reference the tree-diagram draft, as
that draft is unstable (the notation may change).  You should 
probably copy/paste the Tree Diagram Notation section found in
other drafts today (especially mine).

[clyde] I used to the Tree Diagram Notation embedded in the document and was
asked by another reviewer to use what is there now. I will change to your 
document’s 
notation.

14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
'address' leaf?

[clyde] not as far as I know

15. S4.1, P1: Doesn't the module import *groupings* from ietf-keystore
and ietf-tls-client?

[clyde] done

16. S4.1, though it's not in 6087bis, I think that it is best
practice for 'import' statements to include a 'reference'
substatement:

  import ietf-keystore {
prefix ks;
reference
  "RFC : Keystore Model";
  }

17. S4.1, imports that are used for groupings only should use a
revision statement:

  import ietf-tls-client {
prefix tlsc;
revision-date -MM-DD; // stable grouping definitions
reference
  "RFC : TLS Client and Server Models";
  }

[clyde] done

18. S4.1, can you put the beginning of the 'organization' (i.e. "IETF")
on the next line, s/NETCONF Data Modeling Language/Network Modeling/,
and put a blank line in after the 'organization' line?

[clyde] done

19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
have values set for enums 'none' and 'all'?  When would these values
be used, as opposed to the enum's name string?  If you do need values,
then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
and 'all' be -2147483648 (so everything is greater than it)?

[clyde] ‘none’ and ‘all’ are set to values that are not defined in RFC 5424. 
These values
were previously suggested by Martin Björklund

20. S7: can you indent the two 

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[t.petch]

Clyde

As Kent says, I would prefer to see only one  with others being 
or some such.

Further, I think that this RFC  to be should be in the list of
References.

Adding it there would then solve my additional problem of which I-D you
have in mind.  There are two relating to key management and neither are
titled Keystore Management:-(  I can guess which you mean but I do not
think that I should be guessing!

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "t.petch" <ie...@btconnect.com>; "Kent Watsen"
<kwat...@juniper.net>; <netmod@ietf.org>
Sent: Wednesday, August 09, 2017 5:53 PM
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15


> Tom,
>
> The agreement was that I should use “” until the two unapproved
RFCs that the model depends on are assigned numbers.
>
>  RFC : Keystore Management
>  RFC : Transport Layer Security (TLS) Client";
>
> Imported are:
>
>   import ietf-tls-client {
> prefix tlsc;
>   }
>
>   import ietf-keystore {
> prefix ks;
>   }
>
>
> Have numbers been assigned?
>
> Thanks,
>
> Clyde
>
> On 8/9/17, 4:32 AM, "t.petch" <ie...@btconnect.com> wrote:
>
> Clyde
>
> You use  as a placeholder for three different RFC and two of
these
> do not appear AFAICT in the list of References.
>
> This might be a challenge for the RFC Editor.
>
> Tom Petch
>
>
> - Original Message -
> From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
> Sent: Wednesday, July 19, 2017 6:48 PM
>
>
> > Hi Alex,
> >
> > Answers inline as [clyde]…
> >
> > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
> <netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com>
wrote:
> >
> > I am considering to implement the data model in this draft.
> (dependent on business priorities of course)
> > I have reviewed this draft and found the following issues.
> >
> > * I see pattern-match is specified to use POSIX 1003.2
regular
> expressions. This is presumably for compatibility with existing
> implementations; however it is inconsistent with most of YANG
(which is
> specified to use XPath regular expressions) - unless these are the
same.
> >
> > [clyde] I believe that my answer in the other thread explains
why we
> used Posix 1003.2 – it is commonly used.
> >
> > * pattern-match is inside the facility-filter container;
common
> sense says this is wrong as pattern-match has nothing to do with
> facilities.
> >
> > [clyde] I will move pattern-match up one level in the next
version of
> the draft. Thanks for catching this!
> >
> > * The advanced-compare container groups together two nodes
that
> share a common "when" and "if-feature" statement, but don't seem
to have
> any semantic relation to each other. Are there general guidelines
on
> when to use a container?
> >
> > [clyde] The confusion may come as a result of the when clause
> appearing before the if-feature clause which is set by the IETF
> statement order recommendation.
> >
> > The when construct was suggested by Martin Björklund as a way of
> solving the case that advanced-compare does not apply for the ‘all
’ and
> ‘none’ case.
> >
> > The if-feature applies to the entire container – it is either
> supported or not.
> >
> > * The advanced-compare container has a description starting
with
> "This leaf ..." even though it is not a leaf.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * The examples are missing  nodes.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * Perhaps there should be more consistent terminology for
> receivers of syslog messages; both "collectors" and "actions" are
used
> in the draft. RFC 5424 uses "collector" for the ultimate recipient
of a
> log message - which might not be applicable, because the sending
system
> has no idea whether the receiving system is a collector or a
relay.
> >
> > [clyde] The definition of “collector” in RFC 5424 is: A
"collector"
> gathers syslog content for further analysis.
> >
> > actions relate to the “further analysis” taken by the
 “collector”.
> >
>   

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

Today's activity on this thread necessitates another response as well:

The WG LC is closed.  Authors, please address any comments that have
been received, and let the WG know how the issues have been addressed,
and when a version is available that is ready to be submitted for 
publication.

Thanks,
Kent (and Lou)



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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

Hi Clyde,

In my drafts that depend on more than one work in progress, I typically assign 
each of them a value (e.g., , , ) and then have RFC Editor 
instructions mapping each to a specific value.

Kent // contributor

--

Tom,

The agreement was that I should use “” until the two unapproved RFCs that 
the model depends on are assigned numbers.

 RFC : Keystore Management
 RFC : Transport Layer Security (TLS) Client";

Imported are:

  import ietf-tls-client {
prefix tlsc;
  }

  import ietf-keystore {
prefix ks;
  }


Have numbers been assigned?

Thanks,

Clyde

On 8/9/17, 4:32 AM, "t.petch"  wrote:

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.





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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Tom,

The agreement was that I should use “” until the two unapproved RFCs that 
the model depends on are assigned numbers.

 RFC : Keystore Management
 RFC : Transport Layer Security (TLS) Client";

Imported are:

  import ietf-tls-client {
prefix tlsc;
  }

  import ietf-keystore {
prefix ks;
  }


Have numbers been assigned?

Thanks,

Clyde

On 8/9/17, 4:32 AM, "t.petch"  wrote:

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.



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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[t.petch]

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Hi Alex,

Answers inline as [clyde]…

On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell" 
<netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com> wrote:

I am considering to implement the data model in this draft. (dependent on 
business priorities of course)
I have reviewed this draft and found the following issues.

* I see pattern-match is specified to use POSIX 1003.2 regular expressions. 
This is presumably for compatibility with existing implementations; however it 
is inconsistent with most of YANG (which is specified to use XPath regular 
expressions) - unless these are the same.

[clyde] I believe that my answer in the other thread explains why we used Posix 
1003.2 – it is commonly used. 

* pattern-match is inside the facility-filter container; common sense says 
this is wrong as pattern-match has nothing to do with facilities.

[clyde] I will move pattern-match up one level in the next version of the 
draft. Thanks for catching this!

* The advanced-compare container groups together two nodes that share a 
common "when" and "if-feature" statement, but don't seem to have any semantic 
relation to each other. Are there general guidelines on when to use a container?

[clyde] The confusion may come as a result of the when clause appearing before 
the if-feature clause which is set by the IETF statement order recommendation.

The when construct was suggested by Martin Björklund as a way of solving the 
case that advanced-compare does not apply for the ‘all’ and ‘none’ case.

The if-feature applies to the entire container – it is either supported or not.

* The advanced-compare container has a description starting with "This leaf 
..." even though it is not a leaf.

[clyde] This will be fixed in the next draft.

* The examples are missing  nodes.

[clyde] This will be fixed in the next draft.

* Perhaps there should be more consistent terminology for receivers of 
syslog messages; both "collectors" and "actions" are used in the draft. RFC 
5424 uses "collector" for the ultimate recipient of a log message - which might 
not be applicable, because the sending system has no idea whether the receiving 
system is a collector or a relay.

[clyde] The definition of “collector” in RFC 5424 is: A "collector" gathers 
syslog content for further analysis.

actions relate to the “further analysis” taken by the “collector”. 

“Collectors” appears in the model under the remote action and I believe the 
usage is correct:
  container remote {
if-feature remote-action;
description
  "This container describes the configuration parameters for 
   forwarding syslog messages to remote relays or collectors.";

I will revise the description of these terms in the next draft.

Thanks,

Clyde  


From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen 
<kwat...@juniper.net>
    Sent: Saturday, 8 July 2017 6:34 a.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

This is a notice to start a three week NETMOD WG last call for the
document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15

Note: Three weeks is more than needed, especially given this
  draft has been through Last Call before, but we understand
  folks are busy these days.

Please indicate your support or concerns by Friday, July 28, 2017.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs




___
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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Juergen and Alex,

The choice of Posix 1003.2 regular expressions was because of multiple vendors 
who supported same and asked for model support:
http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/syslog-edit-system.html
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/command/esm-cr-book/esm-cr-a1.html#wp1888787448
https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0071-10-01/7750_SR_OS_System_Management_Guide/Logcli.html#1030840

Posix 1003.2 regular expressions support Unicode characters using the notation: 
\u or \x{}.

I will insert a normative reference to POSIX 1003.2 in the next revision of the 
draft.

Thanks,

Clyde

On 7/18/17, 1:26 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Mon, Jul 17, 2017 at 11:20:40PM +, Alex Campbell wrote:
> I am considering to implement the data model in this draft. (dependent on 
business priorities of course)
> I have reviewed this draft and found the following issues.
> 
> * I see pattern-match is specified to use POSIX 1003.2 regular 
expressions. This is presumably for compatibility with existing 
implementations; however it is inconsistent with most of YANG (which is 
specified to use XPath regular expressions) - unless these are the same.

The fact that the schema language uses a different regular expression
language than the data model is by itself not a problem I think. What
is potentially a problem is that RFC 5424 syslog messages are UTF-8
and hence the regular expression language adopted should be able to
match on unicode characters. Does POSIX 1003.2 do that? (There also
needs to be a normative reference to POSIX 1003.2 or whatever is
finally adopted.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

As shepherd, yang doctor, and individual contributor, following is 
my LC/YD review.

1. Because I know this draft will not be presented in Prague, I first
checked to see if it was NMDA-compatible.  The draft contains just
one module, and it only contains config true nodes (no config false
nodes).  There is no companion "-state" module in the Appendix.  As
far as I can tell, all this is accurate, as I don't believe this 
module needs to do anything special to be NMDA compatible.  Agreed?

2. the abstract seems just a little bland.  Is there any way to beef
it up with a sentence or two?

3. S1, P1, last sentence.  s/the messages/these messages/?

4. S1, P3, 1st sentence: "and processes those"?  - rewrite sentence?

5. S1 as a whole.  I'm a bit unclear what this section is doing.  It
seems to be a general summary of Syslog (RFC5424).  Do we need this here?

6. S1.1: you should also reference RFC8174 here.

7. S1.2: three terms come from 5424, but only one has its definition
   provided.  This seems inconsistent...

8. S2: s/6020/7950/

9. S3, P3: this paragraph is hard to read due to the previous paragraph
talking about proprietary features.  Maybe replace the beginning of the 
sentence to read "Some optional features are defined in this document
to specify"?

10. S3, P4: The diagram appears to show multiple originators, not 
just one, so s/an originator/originators/?  Also, I don't think 
either of the commas are needed.

11. S3, P6: This paragraph starts a new aspect of the design, right?
This is likely just a text-rendering issue, but the transition from
the diagram above (Figure 1) to this line is not visible.  Can you
provide a transition sentence?

12. S3, P8: I'm having trouble understanding the pseudocode.  What
happens if S and/or F are not present?  Can S or F ever not be
present? - looking at the tree diagram, it seems like they might
always be set to something in the model.

13. S3.1, P1: RFC 6087 did not define tree diagram notation, and
rfc6087bis references the tree-diagram draft.  I don't think that
it is safe for this draft to reference the tree-diagram draft, as
that draft is unstable (the notation may change).  You should 
probably copy/paste the Tree Diagram Notation section found in
other drafts today (especially mine).

14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
'address' leaf?

15. S4.1, P1: Doesn't the module import *groupings* from ietf-keystore
and ietf-tls-client?

16. S4.1, though it's not in 6087bis, I think that it is best
practice for 'import' statements to include a 'reference'
substatement:

  import ietf-keystore {
prefix ks;
reference
  "RFC : Keystore Model";
  }

17. S4.1, imports that are used for groupings only should use a
revision statement:

  import ietf-tls-client {
prefix tlsc;
revision-date -MM-DD; // stable grouping definitions
reference
  "RFC : TLS Client and Server Models";
  }

18. S4.1, can you put the beginning of the 'organization' (i.e. "IETF")
on the next line, s/NETCONF Data Modeling Language/Network Modeling/,
and put a blank line in after the 'organization' line?

19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
have values set for enums 'none' and 'all'?  When would these values
be used, as opposed to the enum's name string?  If you do need values,
then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
and 'all' be -2147483648 (so everything is greater than it)?

20. S7: can you indent the two blocks of details so the whole thing
reads better?

21. S8: please rework so this section so it matches the new template
at: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

22. S8.1: it would be better if the third paragraph was moved up to
become the first paragraph.


DISCLAIMER: I'm not a syslog expert, but have interacted with it,
including structured-syslog, over the years.

Kent



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

[netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen]

This is a notice to start a three week NETMOD WG last call for the
document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15

Note: Three weeks is more than needed, especially given this 
  draft has been through Last Call before, but we understand
  folks are busy these days.

Please indicate your support or concerns by Friday, July 28, 2017.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs




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