Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Alexey,

I believe that I have addressed both of your concerns in the about to be 
published draft.

Thanks,

Clyde

On 3/9/18, 6:44 AM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote:

Hi Clyde,

On Thu, Mar 8, 2018, at 9:28 PM, Clyde Wildes (cwildes) wrote:
> Alexey,
> 
> Your minor comments are addressed below…
> 
> On 3/6/18, 12:06 PM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote:
> > 
> --
> COMMENT:
> --
> 
> Thank you for this document.
> 
> I also prefer for TCP to be documented, if used in real world.
> 
> Some minor comments:


> 2) On page 19:
> 
> Example: compare->equals and action->no-match means
> messages that have a severity that is not equal to the
> specified severity will be logged.";
> 
> Do you mean "action->block" instead of "action->no-match"?
> 
> [clw] An equals compare with action no-match means log the message, not 
> block it.

Your document only talks about "action->no-match" in one place in the 
example. Has terminology changes over years and you forgot to update the 
example?

It is possible I am confused here.

> 
> 3) When logging to file: how is the file name constructed from the 
> name file:
> URI if multiple files are preserved by the system? E.g. if the log 
> file is
> rotated daily and 5 last files are preserved, how does each 
> individual filename
> look? If I understood how this is used, this needs more 
> clarification.
> 
> [clw] We decided to leave this for the implementer as file systems may 
> be different for different implementations.

I think you should clarify in the document what is the purpose of filename 
and say something about the above. I appreciate that this might not be needed 
for interoperability, but what you have in the document doesn't provide enough 
details to implement this aspect. Even saying that implementations can derive 
log specific filenames from the base one instead of saying nothing would be 
better.

Thank you,
Alexey


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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Adam,

A new draft will be published soon that addresses your concern and I have used 
your wording.

Thanks,

Clyde



On 3/9/18, 6:09 AM, "Benoit Claise (bclaise)" <bcla...@cisco.com> wrote:

On 3/9/2018 2:27 AM, Adam Roach wrote:
> On 3/8/18 12:18 PM, Clyde Wildes (cwildes) wrote:
>> Adam,
>>
>> An earlier version of the model (draft-ietf-netmod-syslog-model-08 
>> and prior) included “terminal” as a syslog destination which 
>> addresses your requirement below:
>>
>>  +--rw terminal {terminal-action}?
>>  |  +--rw all-terminals!
>>  |  |  +--rw log-selector
>>  |  | +--rw (selector-facility)
>>  |  | |  +--:(no-log-facility)
>>  |  | |  |  +--rw no-facilities?   empty
>>  |  | |  +--:(log-facility)
>>  |  | | +--rw log-facility* [facility]
>>  |  | |+--rw facility union
>>  |  | |+--rw severity union
>>  |  | |+--rw severity-operator? enumeration 
>> {selector-sevop-config}?
>>  |  | +--rw pattern-match?   string 
>> {selector-match-config}?
>>  |  +--rw terminal* [name] 
>> {terminal-facility-user-logging-config}?
>>  | +--rw namestring
>>  | +--rw log-selector
>>  |+--rw (selector-facility)
>>  ||  +--:(no-log-facility)
>>  ||  |  +--rw no-facilities?   empty
>>  ||  +--:(log-facility)
>>  || +--rw log-facility* [facility]
>>  ||+--rw facility union
>>  ||+--rw severity union
>>  ||+--rw severity-operator? enumeration 
>> {selector-sevop-config}?
>>  |+--rw pattern-match?   string 
>> {selector-match-config}?
>>
>> A consensus of the group was that it was best to remove this 
>> destination in the model as a simplification, and that vendors that 
>> supported same could add it back through an augmentation.
>
> Thanks for the history -- that's useful to know. I don't have any 
> desire to re-open a settled issue, so please don't read my response as 
> a request to go back to the older, more complex model.
>
> My concern now is that the unstated assumption above isn't indicated 
> in the document; and absent such a treatment, I fear that some vendors 
> may do what you expect (extend the model), while some may do what I 
> mentioned (expect terminal syslog output to be provisioned via a 
> special filesystem node using the "file" subtree). This ambiguity 
> doesn't seem ideal.
>
> I would suggest that the document have text specifically indicating 
> that terminal output with requirements more complex than the console 
> subtree currently provides are expected to be supported via vendor 
> extensions rather than handled via the file subtree.
That makes sense.

Regards, B.
>
> /a
>
> .
>



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

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Alexey,

Your minor comments are addressed below…

On 3/6/18, 12:06 PM, "Alexey Melnikov"  wrote:

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/



--
COMMENT:
--

Thank you for this document.

I also prefer for TCP to be documented, if used in real world.

Some minor comments:

1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when 
you
mention it for the first time.

[clw] Accepted

2) On page 19:

Example: compare->equals and action->no-match means
messages that have a severity that is not equal to the
specified severity will be logged.";

Do you mean "action->block" instead of "action->no-match"?

[clw] An equals compare with action no-match means log the message, not block 
it.

3) When logging to file: how is the file name constructed from the name 
file:
URI if multiple files are preserved by the system? E.g. if the log file is
rotated daily and 5 last files are preserved, how does each individual 
filename
look? If I understood how this is used, this needs more clarification.

[clw] We decided to leave this for the implementer as file systems may be 
different for different implementations.

4) Nit: on page 18, typo in "spectify"

[clw] Accepted  

Thanks,

Clyde  


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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Adam,

An earlier version of the model (draft-ietf-netmod-syslog-model-08 and prior) 
included “terminal” as a syslog destination which addresses your requirement 
below:

+--rw terminal {terminal-action}?
|  +--rw all-terminals!
|  |  +--rw log-selector
|  | +--rw (selector-facility)
|  | |  +--:(no-log-facility)
|  | |  |  +--rw no-facilities?   empty
|  | |  +--:(log-facility)
|  | | +--rw log-facility* [facility]
|  | |+--rw facility union
|  | |+--rw severity union
|  | |+--rw severity-operator?   enumeration 
{selector-sevop-config}?
|  | +--rw pattern-match?   string {selector-match-config}?
|  +--rw terminal* [name] {terminal-facility-user-logging-config}?
| +--rw namestring
| +--rw log-selector
|+--rw (selector-facility)
||  +--:(no-log-facility)
||  |  +--rw no-facilities?   empty
||  +--:(log-facility)
|| +--rw log-facility* [facility]
||+--rw facility union
||+--rw severity union
||+--rw severity-operator?   enumeration 
{selector-sevop-config}?
|+--rw pattern-match?   string {selector-match-config}?

A consensus of the group was that it was best to remove this destination in the 
model as a simplification, and that vendors that supported same could add it 
back through an augmentation.

Thanks,

Clyde

On 3/8/18, 12:19 AM, "Adam Roach"  wrote:

Adam Roach has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/



--
COMMENT:
--

One quick comment on the model for the console:

+--rw console! {console-action}?
|  +--rw facility-filter
|  |  +--rw facility-list* [facility severity]
|  | +--rw facilityunion
|  | +--rw severityunion
|  | +--rw advanced-compare {select-adv-compare}?
|  |+--rw compare?   enumeration
|  |+--rw action?enumeration
|  +--rw pattern-match? string {select-match}?

Syslog can be (and frequently is) configured to log to "console" on a
non-default tty. It's not clear from this model how this would be 
configured or
indicated. Is the assumption here that all non-default-console tty logging
would be handled by the "file" portion of the tree? If so, it would be worth
indicating so explicitly, and noting that such an approach is limited to 
those
systems that present ttys as a part of the filesystem. Alternately, it might
make sense to add a tty field to the "console" subtree to report/configure 
this
value.




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

Re: [netmod] draft-ietf-netmod-syslog-model-23

[Clyde Wildes (cwildes)]

Bob,

I will add your wording in the next revision.

Thanks,

Clyde

From: Bob Harold <rharo...@umich.edu>
Date: Monday, March 5, 2018 at 11:06 AM
To: Clyde Wildes <cwil...@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-syslog-model-23


On Fri, Mar 2, 2018 at 5:13 PM, Clyde Wildes (cwildes) 
<cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
Bob,

Syslog message severity is set in RFC 5424 Table 2. The model in 
draft-ietf-netmod-syslog-model-23 conforms to that specification. A lower 
number means higher severity.


Thanks.  Can we add "A lower number means higher severity" to make it clear?

In Section 
"4.1<https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-23#section-4.1>.
 The ietf-syslog Module"
on page 11, cna we change:

From:


 typedef syslog-severity {

   type enumeration {

 enum "emergency" {

   value 0;

   description



Change to:



 typedef syslog-severity {

   description

 "Note that a lower value is a higher severity.

  Comparisons of equal-or-higher security mean equal or lower numeric 
value"

   type enumeration {

 enum "emergency" {

   value 0;

   description

--
Bob Harold


The severity-filter specifies that “all messages of the specified severity and 
greater match” and therefore will be selected. This conforms to the way that 
many vendors that we evaluated perform syslog message severity match selection.

Juniper Example:
https://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/syslog-single-chassis-facility-severity-messages-specifying.html

“Messages from the facility that are rated at that level or higher are logged 
to the destination”

Linux rsyslogd Example:
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html#selectors

“The behavior of the original BSD syslogd is that all messages of the specified 
priority and higher are logged according to the given action. Rsyslogd behaves 
the same…”

Changing the table to match higher severity to higher number means that we 
would not conform the RFC 5424.

Note: I do see a typo in the description for severity-filter (the word “use” is 
missing):

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, the advance-compare
  rule.

should be:

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, use the advance-compare
  rule.

Thanks,

Clyde

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Bob Harold <rharo...@umich.edu<mailto:rharo...@umich.edu>>
Date: Friday, March 2, 2018 at 12:33 PM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] draft-ietf-netmod-syslog-model-23

Sorry for being late to the discussion - just joined this group.

Can we have "higher severity" match "higher number" in the enumerated values, 
to avoid confusion?

In section 4.1.  The ietf-syslog Module
on Page 11

typedef syslog-severity {

-- should be in the order:
debug=0
emergency=7

because "severity-filter" uses "equals-or-higher" which means "higher severity" 
but should also mean "higher number" to avoid confusion.
--
Bob Harold

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

Re: [netmod] draft-ietf-netmod-syslog-model-23

[Clyde Wildes (cwildes)]

Bob,

Syslog message severity is set in RFC 5424 Table 2. The model in 
draft-ietf-netmod-syslog-model-23 conforms to that specification. A lower 
number means higher severity.

The severity-filter specifies that “all messages of the specified severity and 
greater match” and therefore will be selected. This conforms to the way that 
many vendors that we evaluated perform syslog message severity match selection.

Juniper Example:
https://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/syslog-single-chassis-facility-severity-messages-specifying.html

“Messages from the facility that are rated at that level or higher are logged 
to the destination”

Linux rsyslogd Example:
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html#selectors

“The behavior of the original BSD syslogd is that all messages of the specified 
priority and higher are logged according to the given action. Rsyslogd behaves 
the same…”

Changing the table to match higher severity to higher number means that we 
would not conform the RFC 5424.

Note: I do see a typo in the description for severity-filter (the word “use” is 
missing):

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, the advance-compare
  rule.

should be:

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, use the advance-compare
  rule.

Thanks,

Clyde

From: netmod  on behalf of Bob Harold 

Date: Friday, March 2, 2018 at 12:33 PM
To: "netmod@ietf.org" 
Subject: [netmod] draft-ietf-netmod-syslog-model-23

Sorry for being late to the discussion - just joined this group.

Can we have "higher severity" match "higher number" in the enumerated values, 
to avoid confusion?

In section 4.1.  The ietf-syslog Module
on Page 11

typedef syslog-severity {

-- should be in the order:
debug=0
emergency=7

because "severity-filter" uses "equals-or-higher" which means "higher severity" 
but should also mean "higher number" to avoid confusion.
--
Bob Harold
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Clyde Wildes (cwildes)]

Kent,

I published a new draft that fixes the last two points.

Thanks,

Clyde

From: Kent Watsen 
Date: Wednesday, February 28, 2018 at 10:11 AM
To: Mahesh Jethanandani 
Cc: Clyde Wildes , "t.petch" , Yaron 
Sheffer , Ron Bonica , NETMOD 
Working Group , "Benoit Claise (bclaise)" 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[+benoit]

Mahesh,

That's fine, if we want to put the RFC Editor note into the Introduction, I see 
that you did the same in the ACL draft.  But there still remains the use of IP 
addresses (not hostnames) in examples and, if we're fixing that, let's please 
also fix the typo in the title of Section 1.4.

Clyde, can you please post a v23 that fixes these last two points?

Thanks,
Kent  // shepherd


On 2/23/18, 1:05 PM, "Mahesh Jethanandani" 
> wrote:

Kent,



On Feb 23, 2018, at 8:02 AM, Kent Watsen 
> wrote:

Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before). Please also either fix the typo or, better, 
move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.




Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
 on behalf of 
kwat...@juniper.net> wrote:











Kent







You illustrate beautifully the problem I would like a solution to.







The current thinking AFAICT is that tree-diagrams



should be an Informative Reference.







Therefore, the RFC Editor will not hold publication until an RFC number



is assigned.







Therefore, a note asking the I-D reference to be updated to reflect the



assigned RFC number is null - the RFC can be published with the



reference as an i-d and not as an RFC which is what I expect the RFC



Editor to do.







QED





   Except I know that this draft will be stuck in MISREF state and tree-diagrams

   will in fact be assigned an RFC number by the time this draft is published.



   K.







Note that this is not the case of a Normative i-d reference being buried



in the YANG module and not being.noticed by the RFC Editor; that problem



I am content with.











Tom Petch























Please also address these issues when posting -21 to address Benoit's

   issues.  Please post -21 ASAP as Benoit has already placed this draft on

   the IESG telechat in a couple weeks.







Thanks,



Kent // shepherd











On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

   

 on behalf of

   bcla...@cisco.com> wrote:







Dear all,







- the draft is NMDA compliant, right? It should be mentioned.



Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro







  The YANG model in this document conforms to the Network Management







  Datastore Architecture defined in

   I-D.ietf-netmod-revised-datastores.











- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]

   should be an informative reference, not normative.







- Editorial:



OLD:



This draft addresses the common leafs



NEW:



This document addresses the common leafs







Please publish a new version asap.



In the mean time, I'm sending this draft to IETF LC.







Regards, Benoit

















  

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Clyde Wildes (cwildes)]

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,

Clyde

On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"  wrote:




> Kent
> 
> You illustrate beautifully the problem I would like a solution to.
>
> The current thinking AFAICT is that tree-diagrams
> should be an Informative Reference.
>
> Therefore, the RFC Editor will not hold publication until an RFC number
> is assigned.
> 
> Therefore, a note asking the I-D reference to be updated to reflect the
> assigned RFC number is null - the RFC can be published with the
> reference as an i-d and not as an RFC which is what I expect the RFC
> Editor to do.
> 
> QED


Except I know that this draft will be stuck in MISREF state and 
tree-diagrams
will in fact be assigned an RFC number by the time this draft is published.

K.


> Note that this is not the case of a Normative i-d reference being buried
> in the YANG module and not being.noticed by the RFC Editor; that problem
> I am content with.
>
>
>Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> netmod mailing list
> netmod@ietf.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
>



___
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] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Clyde Wildes (cwildes)]

Yaron,

Thanks for your review. My answers are inline as [clw1].

On 2/18/18, 6:31 AM, "Yaron Sheffer"  wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

General Comments

* The semantics of pattern matching is not clear: "and/or the message text" 
-
are there cases where you only match the text but not the 
facility/severity? *

[clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on 
the regex pattern; 3. Match on both facility/severity and the regex pattern.

It's very confusing to specify rollover in minutes, but retention in hours.
People are bound to get this one wrong.

[clw1] I will change the retention to minutes unless others object.

* Interface selection: the feature
makes sense, but I think the description is incorrect. "This leaf sets the
source interface to be used to send messages to the remote syslog server. If
not set, messages sent to a remote syslog server will contain the IP 
address of
the interface the syslog message uses to exit the network element". AFAIK 
the
source IP will always correspond to the interface, but this feature allows 
you
to select a particular one.

[clw1] You are correct. I will modify the description to make this clearer. How 
about:

"This leaf sets the source interface to be used to send messages to the remote 
syslog server. If
not set, messages can be sent on any interface."

* Usage examples: the second example lists a
specific IPv6 address, but the Yang snippet shows a domain name. 

[clw1] Thanks for catching this error. I will fix this in the next revision.

* A generic
question (I am new to the Yang ecosystem): I understand most implementers 
will
use this module from

https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
- is this the expectation? If so, why not add a link from the RFC into the
repo, to make it easier for people to find?

[clw1] It is standard practice to include the model in the RFC AFAIK. I have 
not seen github links published in any other RFCs.

Security Comments

* I think almost all writable data nodes here are sensitive, because a 
network
attacker's first move is to block any logging on the host, and many of the 
data
nodes here can be used for this purpose.

[clw1] I will reword the security section to include all writeable nodes as 
sensitive.

* Re: readable data nodes, I'm not
sure which are sensitive, and the document should give an example or two 
rather
than just say "some". Otherwise the security advice is not actionable. One
example: "remote" sections leak information about other hosts in the 
network.

[clw1] This text was lifted from another model. I will review the readable 
nodes and update.

* Write operations... can have a negative effect on network operations. - I 
would
add "and on network security", because logs are often used to detect 
security
breaches. 

[clw1] I will add this phrase.

* Also add an advice, similar to the one on "pattern match", that the
private key used for signing log messages MUST NOT be used for any other
purpose, and that the implementation of this data node must ensure this
property (I'm not sure how). The rationale: if the TLS private key is used, 
for
example, this could result in a signing oracle for TLS and eventually a MITM
attack.

[clw1] I will add this advice.

Thanks,

Clyde


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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[Clyde Wildes (cwildes)]

Kent,

I will remove TLS if that is the preference of the chair and the working group.

RFC 6587 can be made Informational.

Working with an editor might help to avoid additional revisions.

Unless I hear otherwise I will post another update on Friday with TLS, and its 
references, removed as well as the change to make RFC 6587 informational.

Thanks,

Clyde


On 2/6/18, 4:49 PM, "Kent Watsen"  wrote:

Hi Clyde,

The chairs were discussing the HISTORIC reference to RFC 6587.   As we 
understand it, RFC 6587 was actually originally published as a HISTORIC 
document to accommodate Security area concerns.  Apparently, Benoit was AD at 
the time, so he may recall.  The IETF took special effort to publish RFC 6587 
anyway, likely due to TCP being in common use.  Anyway, we're wondering, must 
this document have a normative reference to RFC 6587?  - could it be made 
Informational instead?  Is understanding RFC 6587 necessary to implement the 
syslog draft?

We also discussed the normative references to the keystore-and-friends 
drafts.   As it stands, my shepherd write-up is going to have to call these out 
as unstable dependencies.   I know that it was discussed before, but would you 
have any appetite to revisit having TLS in the first version of this module?  
Perhaps it could be picked it up in a bis?

When can you post an update?  Would you rather us appoint an Editor to help 
get it done sooner?  I think that we've been in this post-LC phase for nearly 
four months now...

Kent // shepherd


= original message =

Kent

My request for a reference for Posix hs been fixed in -19.

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Sent: Tuesday, January 16, 2018 4:59 PM

> 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=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8=.
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=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ=):
>   

>
>  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=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=wrmo4jVcBb7-_LFH7ty-TOpG80tfe3pWbfCSFZaT6eY=:
>   

>
>  No issues found here.
>
>   Checking nits according to 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=_seSaCKfzxYeb3b1tfX2RqUk7CKbOsRr3pRVJrQ8lEc=
 :
>   

>
>   ** 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: '...gorithmide...'
>
> 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 

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[Clyde Wildes (cwildes)]

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- 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.

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[Clyde Wildes (cwildes)]

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)"  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" 
> 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- 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" 
>> To: 
>> Cc: 
>> 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
>> "@-mm-dd" in its name
>>> 3.  neither 

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt

[Clyde Wildes (cwildes)]

Tom,

I am working with Mahesh to fix the Normative References.

Regarding line length: I am using pyang 1.7.3 which is not complaining about 
line length in the model. But when I look at the draft I see that both the tree 
and the model exceed 80 characters. I will make a pass to shorten lines.

Thanks,

Clyde

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

Clyde

I like the introduction of  and ;  but I still hanker after
Normative References to I-Ds,  draft-ietf-netconf-keystore and
draft-ietf-netconf-tls-client-server.  I think that they are required.

Also, in -15  and in -16, the line length seems to have gone wrong and
is now too long; I notice it in the Description clauses.  It was ok
in -13.

"   Each line must be limited to 72 characters followed by the
   character sequence that denotes an end-of-line (EOL).  This
   limit includes any left-side indentation.
"

Tom Petch


 Original Message -
From: 
To: 
Cc: 
Sent: Saturday, August 12, 2017 3:17 AM

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Network Modeling WG of the IETF.
>
> Title   : A YANG Data Model for Syslog Configuration
> Authors : Clyde Wildes
>   Kiran Koushik
> Filename: draft-ietf-netmod-syslog-model-16.txt
> Pages   : 30
> Date: 2017-08-11
>
> Abstract:
>This document defines a YANG data model for the configuration of a
>syslog process.  It is intended this model be used by vendors who
>implement syslog in their systems.
>
> Editorial Note (To be removed by RFC Editor)
>
>This draft contains many placeholder values that need to be
replaced
>with finalized values at the time of publication.  This note
>summarizes all of the substitutions that are needed.  No other RFC
>Editor instructions are specified elsewhere in this document.
>
>Artwork in this document contains shorthand references to drafts in
>progress.  Please apply the following replacements:
>
>o  "" --> the assigned RFC value for
draft-ietf-netconf-keystore
>
>o  "" --> the assigned RFC value for draft-ietf-netconf-tls-
>   client-server
>
>o  "" --> the assigned RFC value for this draft
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-16
>
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-16
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-16
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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)]

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

[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

[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" <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”.
>
> “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.



___
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" 
 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.
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] Some questions about "draft-ietf-netmod-syslog-model-13"

[Clyde Wildes (cwildes)]

Hi Zhangjun, Walker,

Please note that the most recent version of the draft is revision 15.

We have strived to provide a model that meets the minimum requirements for 
successful implementation by multiple vendors with the caveat that a feature 
that is only implemented by a single vendor can best be handled through model 
augmentation by that vendor. Destination VRF is an example that could be added 
through model augmentation.

Regarding your question about DNS: are you asking if the address leaf which is 
defined as “type inet:host” be a hostname that can be translated through DNS to 
an IP address? If so, the answer is yes.

TLS was added as a destination transport choice in revision 14 of the draft.

Regards,

Clyde

From: "Zhengguangying (Walker)" <zhengguangy...@huawei.com>
Date: Tuesday, June 27, 2017 at 11:25 PM
To: "Clyde Wildes (cwildes)" <cwil...@cisco.com>, 
"kirankoushik.agraharasreeniv...@verizonwireless.com" 
<kirankoushik.agraharasreeniv...@verizonwireless.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "Zhangjun (Echo, CSD)" 
<olive.zhang...@huawei.com>
Subject: Some questions about "draft-ietf-netmod-syslog-model-13"

Hi all,


I have read the “draft-ietf-netmod-syslog-model-13”,  we have some comments 
want to discuss with you all,

https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-13


  1.  Because the destination may be in VRF, in the definition of list 
destination, there should add the vrf attribute
  2.  Whether “DNS “ should be one case of transport?
  3.  The tls case should be concerned

Please help to confirm these comments, thanks

Regards
Zhangjun, Walker

[cid:image001.png@01D2F00B.F3D31850]
[cid:image002.png@01D2F00B.F3D31850]
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-15.txt

[Clyde Wildes (cwildes)]

Hi,

The latest draft-ietf-netmod-syslog-model-15 contains updates to the 
signing-options container as a result of a review by Kent Watsen and Alex Clemm.

Diffs can be seen at:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-14=draft-ietf-netmod-syslog-model-15

Thanks,

Clyde 

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

Re: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options

[Clyde Wildes (cwildes)]

Kent,

Yes! Sorry for the delay.

Clyde

On 6/7/17, 11:13 AM, "Kent Watsen"  wrote:

Hi Clyde,

Since no concerns have been raised, should we be expecting an updated 
syslog draft shortly?

Kent // as shepherd

--

Hi,

As part of the last few steps before again calling for last call for 
draft-ietf-netmod-syslog-model-14, we are adding certificate support to the 
signing-options container. RFC 5848: Signed Syslog Messages is the RFC that 
governs this section.

The signing-options container resides within the remote action destination 
list section of the model. This means signing-options will be configurable for 
each remote destination.

RFC 5848 supports four signature groups as defined in section 4.2.3 
Signature Group and Signature Priority of the RFC:
https://tools.ietf.org/html/rfc5848#section-4.2.3

We are proposing to limit our support to Signature Group 0 which covers the 
case for administrators who want all messages of a syslog stream to be signed 
and Signature Blocks to be sent to a single destination.  We believe this case 
covers all deployment scenarios that are commonly encountered.  

Support for Signature Groups 1 (each PRI value is associated with its own 
Signature Group), 2 (each Signature Group contains a range of PRI values), and 
3 (Signature Groups are negotiated through a private arrangement) could be 
added to the model later through augmentation.

Please let us know if you have any concerns about this.

Thanks,

Clyde


___
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] draft-ietf-netmod-syslog-model-14 Signing Options

[Clyde Wildes (cwildes)]

Hi,

As part of the last few steps before again calling for last call for 
draft-ietf-netmod-syslog-model-14, we are adding certificate support to the 
signing-options container. RFC 5848: Signed Syslog Messages is the RFC that 
governs this section.

The signing-options container resides within the remote action destination list 
section of the model. This means signing-options will be configurable for each 
remote destination.

RFC 5848 supports four signature groups as defined in section 4.2.3 Signature 
Group and Signature Priority of the RFC:
https://tools.ietf.org/html/rfc5848#section-4.2.3

We are proposing to limit our support to Signature Group 0 which covers the 
case for administrators who want all messages of a syslog stream to be signed 
and Signature Blocks to be sent to a single destination.  We believe this case 
covers all deployment scenarios that are commonly encountered.  

Support for Signature Groups 1 (each PRI value is associated with its own 
Signature Group), 2 (each Signature Group contains a range of PRI values), and 
3 (Signature Groups are negotiated through a private arrangement) could be 
added to the model later through augmentation.

Please let us know if you have any concerns about this.

Thanks,

Clyde


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

Re: [netmod] draft-ietf-netmod-syslog-model-12

[Clyde Wildes (cwildes)]

Tom,

Inline…

On 3/16/17, 10:04 AM, "t.petch" <ie...@btconnect.com> wrote:

- Original Message -
    From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
Sent: Monday, March 13, 2017 6:11 PM

> Tom,
>
> The next revision of the draft-ietf-netmod-syslog-model includes a
change to the Yang tree diagram explanation to include the text from
RFC6087bis.
>
> RFC5426 is referenced in the model where "Transmission of Syslog
Messages over UDP” occurs:
>
>   case udp {
>  container udp {
>description
>  "This container describes the UDP transport
>   options.";
>reference
>  "RFC 5426: Transmission of Syslog Messages over
UDP";
>
> This is a correct reference.

Indeed but I don't think that [RFC5426]  is going to work as part of
leaf sig-number-resends
while

   leaf structured-data {
...
   as per RFC5424

is not the usual style.

[clyde] I was urged to use the descriptions directly from RFC5848 – in this 
case from section 6.1.2. Configuration Parameters for Signature Blocks (page 25)

sigNumberResends = number of times a Signature Block is resent.
  (It is recommended to select a value of greater than "0" in
  particular when the UDP transport [RFC5426] is used.)

[clyde] Please suggest a new name for the selector that you think should be 
changed. I could not find a reference to this in my notes.

On another tack, I thought that you agreed to change one of the
identifiers in

 grouping selector {
   description

   container selector {

Thanks,

Clyde 

   
Tom Petch

> Thanks,
>
> Clyde
>
> On 3/1/17, 4:20 AM, "netmod on behalf of t.petch"
<netmod-boun...@ietf.org on behalf of ie...@btconnect.com> wrote:
>
> The explanation of the YANG tree diagram is not that in RFC6087; I
think
> that it should be (or else explain why not)
>
> I am confused by the variation in the references to RFC in the
modules.
>
> I see
> RFC 5424
> [RFC5426]
> RFC5424
>
> I think the first correct
>
> Tom Petch
>
> - Original Message -
> From: "Alexander Clemm" <alexander.cl...@huawei.com>
> To: "Kent Watsen" <kwat...@juniper.net>;
> <draft-ietf-netmod-syslog-mo...@ietf.org>
> Cc: <netmod@ietf.org>
> Sent: Friday, February 24, 2017 12:25 AM
> Subject: Re: [netmod] WG Last Call for
draft-ietf-netmod-syslog-model-11
>
> ___
> 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-11

[Clyde Wildes (cwildes)]

Dale,

Thanks for the simplification. I have incorporated this in the next 
draft-ietf-netmod-syslog-model revision.

Regards,

Clyde


On 3/6/17, 12:53 PM, "Dale R. Worley"  wrote:

(We seem to be well beyond the original LC date, but this is only an
editorial comment...)

The algorithm in section 3 isn't clear to me (possibly because I'm not
very familiar with syslog in practice):

   Selector processing (input is syslog message):

   1. Loop through facility-list
  a. Facility match processing - continue to the next entry in
 the list if no match
  b. Severity compare processing - continue to the next list
 entry if no match
  c. Match - proceed with the action and exit further processing
   2. Process pattern match if specified and if a match proceed with
  the action

If I understand correctly, a message is processed if it matches any one
element of facility-list OR the regexp.  In that case, I think you could
it clearer by writing the pseudocode in a style that is more functional
than imperative:

   A syslog message is processed if
   there is an element of facility-list (F, S) where
   the message facility matches F (if it is present)
   and the message severity matches S (if it is present)
   or the message text matches the pattern (if it is present)

Dale


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

Re: [netmod] draft-ietf-netmod-syslog-model-12

[Clyde Wildes (cwildes)]

Tom,

The next revision of the draft-ietf-netmod-syslog-model includes a change to 
the Yang tree diagram explanation to include the text from RFC6087bis.

RFC5426 is referenced in the model where "Transmission of Syslog Messages over 
UDP” occurs:

  case udp {
 container udp {
   description
 "This container describes the UDP transport
  options.";
   reference
 "RFC 5426: Transmission of Syslog Messages over UDP";

This is a correct reference.
  
Thanks,

Clyde

On 3/1/17, 4:20 AM, "netmod on behalf of t.petch"  wrote:

The explanation of the YANG tree diagram is not that in RFC6087; I think
that it should be (or else explain why not)

I am confused by the variation in the references to RFC in the modules.

I see
RFC 5424
[RFC5426]
RFC5424

I think the first correct

Tom Petch

- Original Message -
From: "Alexander Clemm" 
To: "Kent Watsen" ;

Cc: 
Sent: Friday, February 24, 2017 12:25 AM
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

___
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-11

[Clyde Wildes (cwildes)]

Hi,

I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns 
that Alex and Andy raised in their review of draft 11.

Changes from draft 11 to draft 12 can be seen at this link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11=draft-ietf-netmod-syslog-model-12=--hwdiff

Please review and comment.

Thanks,

Clyde

From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman <a...@yumaworks.com>
Cc: Alex Campbell <alex.campb...@aviatnet.com>, "netmod@ietf.org" 
<netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Any

My comments inline as [clyde2]…

From: Andy Bierman <a...@yumaworks.com>
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
Cc: Alex Campbell <alex.campb...@aviatnet.com>, "netmod@ietf.org" 
<netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11



On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) 
<cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
Hi Andy,

Thanks for taking the time to review the model.

My comments are inline as [clyde]…

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell <alex.campb...@aviatnet.com>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi,

I am also considering an implementation.
I share the same concerns that Alex has brought up.

Some detailed comments:

1) /syslog/actions: seems like everything is in this container.
 Why is it needed?  Seems like it could be removed as it serves no purpose

[clyde] Although this model is currently designated as config only, we could 
add operational data and rpc leaves in the future. The actions container is to 
future-proof the model.

2) 8 features: the granularity seems wrong.  The main container for each section
 should have its own if-feature
  /console
  /buffer
  /file
  /remote

[clyde] We have gone back and forth on this…some have complained that there are 
too many features. I will be happy to add a feature for each action. Note that 
we studied the implementation of each action by six vendors including Linux and 
opted to not add features for actions implemented by at least 3 vendors. 
Vendors not implementing an action could create a deviation.


I prefer 1 mandatory-to-implement and a minimal number of additional options.

  /console
  /file
  /remote

These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.

[clyde2] I will remove the buffer and session actions in the next draft and 
will make the remaining three features.


3) What is the 'buffer' container for?
  How is the internal memory accessed by the client?

[clyde] buffer is implemented by vendors typically for routers capable of 
generating many syslog messages in event-storm bursts. Logging to memory (aka 
buffer) allows the preservation of syslog messages which might otherwise be 
lost.



IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring.  Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.

There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.

[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current 
designed as a configuration only model, there is no operational leaves for show 
log, or rpc leaves for clear log.

4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the 
facility-list

[clyde] This was changed as a result of Alex’s feedback – please see my 
response to him. The model will be changed to the following:


container selector {

  description

"This container describes the log selector parameters

 for syslog.";

  list facility-list {

key facility;

description

  "This list describes a collection of syslog

   facilities and severities.";

leaf facility {

  type union {

type identityref {

  base syslogtypes:syslog-facility;

}

type enumeration {

  enum all {

description

  "This enum describes th

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

[Clyde Wildes (cwildes)]

Any

My comments inline as [clyde2]…

From: Andy Bierman <a...@yumaworks.com>
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
Cc: Alex Campbell <alex.campb...@aviatnet.com>, "netmod@ietf.org" 
<netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11



On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) 
<cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
Hi Andy,

Thanks for taking the time to review the model.

My comments are inline as [clyde]…

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell <alex.campb...@aviatnet.com>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi,

I am also considering an implementation.
I share the same concerns that Alex has brought up.

Some detailed comments:

1) /syslog/actions: seems like everything is in this container.
 Why is it needed?  Seems like it could be removed as it serves no purpose

[clyde] Although this model is currently designated as config only, we could 
add operational data and rpc leaves in the future. The actions container is to 
future-proof the model.

2) 8 features: the granularity seems wrong.  The main container for each section
 should have its own if-feature
  /console
  /buffer
  /file
  /remote

[clyde] We have gone back and forth on this…some have complained that there are 
too many features. I will be happy to add a feature for each action. Note that 
we studied the implementation of each action by six vendors including Linux and 
opted to not add features for actions implemented by at least 3 vendors. 
Vendors not implementing an action could create a deviation.


I prefer 1 mandatory-to-implement and a minimal number of additional options.

  /console
  /file
  /remote

These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.

[clyde2] I will remove the buffer and session actions in the next draft and 
will make the remaining three features.


3) What is the 'buffer' container for?
  How is the internal memory accessed by the client?

[clyde] buffer is implemented by vendors typically for routers capable of 
generating many syslog messages in event-storm bursts. Logging to memory (aka 
buffer) allows the preservation of syslog messages which might otherwise be 
lost.



IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring.  Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.

There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.

[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current 
designed as a configuration only model, there is no operational leaves for show 
log, or rpc leaves for clear log.

4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the 
facility-list

[clyde] This was changed as a result of Alex’s feedback – please see my 
response to him. The model will be changed to the following:


container selector {

  description

"This container describes the log selector parameters

 for syslog.";

  list facility-list {

key facility;

description

  "This list describes a collection of syslog

   facilities and severities.";

leaf facility {

  type union {

type identityref {

  base syslogtypes:syslog-facility;

}

type enumeration {

  enum all {

description

  "This enum describes the case where all

   facilities are requested.";

  }

}

  }

  description

"The leaf uniquely identifies a syslog facility.";

}

uses log-severity;

  }

  leaf pattern-match {

if-feature select-match;

type string;

description

  "This leaf desribes a Posix 1003.2 regular expression

   string that can be used to select a syslog message for

   logging. The match is performed on the RFC 5424

   SYSLOG-MSG field.";

  }


5) pattern-match:


  leaf pattern-match {

if-feature select-mat

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

[Clyde Wildes (cwildes)]

Kent,

I will respond to Andy’s comments this morning and publish a new draft ASAP. It 
would be very helpful if Andy and Alex could work with me on the new draft.

Thanks,

Clyde

On 1/10/17, 11:34 AM, "Kent Watsen"  wrote:

Hi Clyde,

The LC period has ended.  While we only received two reviews, I think both 
were quite good and thorough and, as far as I can tell, entail needing a 
non-trivial update to the draft.

My thoughts are that you should continue working with Alex and Andy to 
ensure their issues are resolved, and then post an updated draft that we can 
run another LC on with the hope of getting a larger response.  Makes sense?

Kent // as shepherd






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

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

[Clyde Wildes (cwildes)]

Hi Andy,

Thanks for taking the time to review the model.

My comments are inline as [clyde]…

From: netmod  on behalf of Andy Bierman 

Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi,

I am also considering an implementation.
I share the same concerns that Alex has brought up.

Some detailed comments:

1) /syslog/actions: seems like everything is in this container.
 Why is it needed?  Seems like it could be removed as it serves no purpose

[clyde] Although this model is currently designated as config only, we could 
add operational data and rpc leaves in the future. The actions container is to 
future-proof the model.

2) 8 features: the granularity seems wrong.  The main container for each section
 should have its own if-feature
  /console
  /buffer
  /file
  /remote

[clyde] We have gone back and forth on this…some have complained that there are 
too many features. I will be happy to add a feature for each action. Note that 
we studied the implementation of each action by six vendors including Linux and 
opted to not add features for actions implemented by at least 3 vendors. 
Vendors not implementing an action could create a deviation.

3) What is the 'buffer' container for?
  How is the internal memory accessed by the client?

[clyde] buffer is implemented by vendors typically for routers capable of 
generating many syslog messages in event-storm bursts. Logging to memory (aka 
buffer) allows the preservation of syslog messages which might otherwise be 
lost.

A “show log” command is used to access the buffers. As this model is current 
designed as a configuration only model, there is no operational leaves for show 
log, or rpc leaves for clear log.

4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the 
facility-list

[clyde] This was changed as a result of Alex’s feedback – please see my 
response to him. The model will be changed to the following:


container selector {

  description

"This container describes the log selector parameters

 for syslog.";

  list facility-list {

key facility;

description

  "This list describes a collection of syslog

   facilities and severities.";

leaf facility {

  type union {

type identityref {

  base syslogtypes:syslog-facility;

}

type enumeration {

  enum all {

description

  "This enum describes the case where all

   facilities are requested.";

  }

}

  }

  description

"The leaf uniquely identifies a syslog facility.";

}

uses log-severity;

  }

  leaf pattern-match {

if-feature select-match;

type string;

description

  "This leaf desribes a Posix 1003.2 regular expression

   string that can be used to select a syslog message for

   logging. The match is performed on the RFC 5424

   SYSLOG-MSG field.";

  }


5) pattern-match:


  leaf pattern-match {

if-feature select-match;

type string;

description

  "This leaf desribes a Posix 1003.2 regular expression

   string that can be used to select a syslog message for

   logging. The match is performed on the RFC 5424

   SYSLOG-MSG field.";

  }


The field SYSLOG-MSG is referenced but never defined or listed in
the terminology section.

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

6) how are the syslog-facility identities mapped to SYSLOG messages?
6a) how to distinguish acme:foo-facility from example:foo-facility in a SYSLOG 
message?

[clyde] I do not understand your question. The current implementation of 
facilities was designed with the help of several Yang Doctors. The requirement 
is to support the facilities as called out in RFC 5424 as well as vendor 
specific facilities that can be added through augmentation. Vendor specific 
facilities are not meant to be used across multiple vendor implementations.

7) source-interface: what if the server does not let a source interface be used 
and instead
normal routing determines the source interface (this leaf is very 
router-centric)

[clyde] source-interface is optional. If not specified normal routing flow 
would be used.

8) signing-options: are these widely deployed on all routers and Linux hosts?

[clyde] Alex Clemm asked that we include syslog signing-options. This is 
implemented by at least Linux rsyslog.

9) logrotate: there are several features related to log file cleanup allowing 
lots of
server variability and forces the client to 

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

[Clyde Wildes (cwildes)]

Hi Alex,

Thanks for your review. My comments are inline as [clyde]…

On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" 
 wrote:

I am considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately 
decreasing order of severity:

* In the "selector-facility" choice statement the cases have misleading 
names - the case where no facility is matched is named "facility", and the case 
where specific facilities are matched is named "name". I suggest 
"no-facilities" and "specified-facilities", or similar.

[clyde] I understand your concern and agree. Please see the next answer where I 
have removed the no-facilities case from the model.


* I disagree with the premise of the "no-facilities" case, which is that it 
can be used to disable a log action, according to the description:

 description
"This case specifies no facilities will match when
 comparing the syslog message facility. This is a
 method that can be used to effectively disable a
 particular log-action (buffer, file, etc).";

  If an administrator wants to disable a log action they should do it by 
either removing it from the configuration, or by setting an "enabled" leaf to 
false.
  With that in mind, there is no reason for the "no-facilities" case to 
exist.

[clyde] I agree with your suggestion to simplify by removing the no-facilities 
case. Please see the revised selector grouping which will appear in the next 
draft:

  grouping selector {
description
  "This grouping defines a syslog selector which is used to 
   select log messages for the log-action (console, file, 
   remote, etc.). Choose one or both of the following:
 facility [ ...]
 pattern-match regular-expression-match-string
   If both facility and pattern-match are specified, both must 
   match in order for a log message to be selected.";
container selector {
  description
"This container describes the log selector parameters 
 for syslog.";
  list facility-list {
key facility;
description
  "This list describes a collection of syslog 
   facilities and severities.";
leaf facility {
  type union {
type identityref {
  base syslogtypes:syslog-facility;
}
type enumeration {
  enum all {
description
  "This enum describes the case where all 
   facilities are requested.";
  }
}
  }
  description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
  }
  leaf pattern-match {
if-feature select-match;
type string;
description
  "This leaf desribes a Posix 1003.2 regular expression 
   string that can be used to select a syslog message for 
   logging. The match is performed on the RFC 5424 
   SYSLOG-MSG field.";
  }
}
  }


* What is the behaviour of a selector if neither "no-facilities" nor 
"facility-list" is present?

[clyde] At least one or both of the following must be specified: facility; 
pattern-match (if supported).

I have updated the description at the beginning of the selector – please see 
above.


* In the "selector" grouping it is not clear how the facility and pattern 
conditions are combined to decide whether a message is selected.

  Must they both match the message, or is it sufficient for either one to 
match the message?

[clyde] If both are specified they must both match the message. This is 
consistent with the syslog implementations by Cisco and Juniper.


* Not all servers have a console; there should be a feature to indicate 
whether logging to the console is supported.

[clyde] I have received comments in earlier reviews that we should implement 
the minimum set of functionality that is contained in at least three vendor 
implementations.

Console is supported by Alcatel/Lucent, Brocade, Cisco (XE, XR, and NXOS), 
Juniper, and Linux-rsyslog. Removal of the console action for your case could 
be done through a vendor specific deviation statement.


* Likewise, not all servers may support logging to user sessions.

[clyde] User sessions are supported by Alcatel/Lucent, and Juniper. I will make 
this a feature in the next revision of the draft since only two vendors 
implement it.


* Likewise, not all servers may support a user-accessible filesystem.

[clyde] Files are supported by Alcatel/Lucent, Cisco (XE, XR, and NXOS), 
Juniper, and Linux-rsyslog. Removal of the file action for your case could be 
done through a vendor specific deviation statement.


* RFC 5424 states that the severity and 

Re: [netmod] Regarding IPR on draft-ietf-netmod-syslog-model-11

[Clyde Wildes (cwildes)]

Kent,

No, I'm not aware of any IPR that applies to this draft

Thanks,

Clyde

On 12/13/16, 4:15 PM, "Kent Watsen"  wrote:


Authors, Contributors, WG,
 
This IPR disclosure requests is being made as part of the preparation
for WG Last Call of draft-ietf-netmod-syslog-model-11.

Are you aware of any IPR that applies to draft identified above? 

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"
 
 
If you answer no, please provide any additional details you think
appropriate.
 
If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware
of IPR of others on an IETF contribution, or to refrain from participating
in any contribution or discussion related to your undisclosed IPR. For
more information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 
Thank you,
NETMOD WG Chairs
 
PS Please include all listed in the headers of this message in your 
response.
 




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

Re: [netmod] syslog-model-11 single buffer vs list

[Clyde Wildes (cwildes)]

Hi Jason,

I presented the latest draft ietf-syslog model last night in the Netmod session 
and mentioned that you had requested that I restore buffers to a list. No one 
raised any objections so I will do that in the next model update.

Thanks,

Clyde

From: "Sterne, Jason (Nokia - CA)" <jason.ste...@nokia.com>
Date: Monday, November 14, 2016 at 7:58 PM
To: "Clyde Wildes (cwildes)" <cwil...@cisco.com>, "netmod@ietf.org" 
<netmod@ietf.org>
Subject: RE: syslog-model-11 single buffer vs list

Hi Clyde,

Most implementations probably have limits in the # of files, remote 
destinations, etc they will support.  If vendors decide to augment the model to 
add max-elements then they'd do it for a number of the lists here.  That 
doesn't seem like a big deal.  But trying to fit into a model with 1 buffer 
would require complete augmentation of the entire buffer destination.  So if we 
do keep buffer I really think it should be a list.

On the other hand I'm fine with removing both buffer and user sessions (similar 
reasoning for both -> they are supported by 2 vendors and each does it 
differently). Then vendors can just augment for those types of destinations.  
The other types have broader support/applicability.

Here is how we left off with the table (view this with fixed width font):

>Feature  Nokia   Brocade  Ciena  Cisco IOS/XE  Cisco 
> IOS/XR  Cisco NXOS  Juniper JunOS  Linux Rsyslog  Comments
>log-input-transports   
>   x
>log-action console xx x  x 
>  xx   x
>log-action buffer  x  x  x
>log-action filex  x  x 
>  xx   x
>log-action remote  xx   x x  x 
>  xx   x
>log-action terminal   x  x 
>  xx
>log-action session x   
>   x
>feature buffer-limit-bytes   x  x
>feature buffer-limit-messages  x
>feature file-limit-size   x  x 
>   x
>feature file-limit-durationx  x
>   x
>feature
> terminal-facility-device-logging
>feature
> session-facility-user-logging 
>x
>feature select-sev-compare x  x
>   x
>feature select-match   x  x
>   x   x
>feature structured-data
>   x   x Required because of RFC 5424
>feature signed-messages            
>   x Required because of RFC 5848
>

Regards,
Jason

-Original Message-
From: Clyde Wildes (cwildes) [mailto:cwil...@cisco.com]
Sent: Tuesday, November 15, 2016 1:43
To: Sterne, Jason (Nokia - CA) <jason.ste...@nokia.com>; netmod@ietf.org
Subject: Re: syslog-model-11 single buffer vs list

Hi Jason,

Buffer was a subject of discussion on the netmod list most recently by Tom 
Petch who raised some questions. In an e-mail on 2016/5/6 Tom said:

“The description of log-buffer confuses me.  The buffer is circular in nature 
so there is only one of them; but it is a list keyed on 'name' so there are 
lots of them.  This leaf configures the amount number of log messages that can 
be stored in the local memory logging buffer, so there is only one of them. 
Or?”

In the same e-mail Tom also commented on the complexity of the current model:

“My comment was more on the complexity that results from having so many 
options. Other models are worse - some of the routing ones I find 
unintelligible as a result - but I raised the issue on this model because it is 
being discussed on this list where (almost) all the expertise in these matters 
resides to see if anyone else would bite.”

In a reaction to Tom’s comments, I tried to simplify by changing the buffers 
list back to a leaf in draft 09. In retrospect this was a mistake. Note that 
AFAIK buffer is currently implemented by only two vendors: Cisco and 
Alcatel-Lucent-Nokia.

The Cisco implementation has one buffer and specifies the limit as the total 
buffer size in bytes.

The Alcatel-Lucent-Nokia implementation has multiple buffers and specifies the 
limit in to

Re: [netmod] syslog-model-11 single buffer vs list

[Clyde Wildes (cwildes)]

Hi Jason,

Buffer was a subject of discussion on the netmod list most recently by Tom 
Petch who raised some questions. In an e-mail on 2016/5/6 Tom said:

“The description of log-buffer confuses me.  The buffer is circular in nature 
so there is only one of them; but it is a list keyed on 'name' so there are 
lots of them.  This leaf configures the amount number of log messages that can 
be stored in the local memory logging buffer, so there is only one of them. 
Or?”

In the same e-mail Tom also commented on the complexity of the current model:

“My comment was more on the complexity that results from having so many 
options. Other models are worse - some of the routing ones I find 
unintelligible as a result - but I raised the issue on this model because it is 
being discussed on this list where (almost) all the expertise in these matters 
resides to see if anyone else would bite.”

In a reaction to Tom’s comments, I tried to simplify by changing the buffers 
list back to a leaf in draft 09. In retrospect this was a mistake. Note that 
AFAIK buffer is currently implemented by only two vendors: Cisco and 
Alcatel-Lucent-Nokia.

The Cisco implementation has one buffer and specifies the limit as the total 
buffer size in bytes.

The Alcatel-Lucent-Nokia implementation has multiple buffers and specifies the 
limit in total messages.

If we make buffers a list, we still have three features in the model and the 
necessity for implementations that support only one buffer to augment the model 
to specify a max-elements statement. The three features are:

  feature buffer-action {
description
  "This feature indicates that the local memory logging buffer
   action is supported.";
  }

  feature buffer-limit-bytes {
description
  "This feature indicates that the local memory logging buffer
   is limited in size using a limit expressed in bytes.";
  }

  feature buffer-limit-messages {
description
  "This feature indicates that the local memory logging buffer
   is limited in size using a limit expressed in number of log
   messages.";
  }

Does it make sense to simplify the model by removing the buffer action along 
with the three features required and have vendors who implement buffer add it 
to the model through augmentation? 

A Netmod group consensus would be helpful here.

Thanks,

Clyde


On 11/13/16, 9:54 PM, "Sterne, Jason (Nokia - CA)" <jason.ste...@nokia.com> 
wrote:

Hi Clyde,

Somewhere in the past couple of revisions we dropped multiple memory 
buffers.  Version 8 (and a number of versions before that) had a list of 
buffers in the YANG (but it wasn't in the pyang tree).  But then version 9 
onwards seem to have a single buffer.

Can we put that back to a list ? Implementations that only support a single 
buffer can easily fit into a model that supports multiple buffers, but the 
other way around doesn't work very well.   I think it was accidently dropped 
due to some confusion over some "if-feature" comments from Tom P at one point.

(note - also add (s) to buffer to make it buffer(s) in a couple of places 
in section 3).

Regards,
Jason

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Clyde Wildes 
(cwildes)
Sent: Monday, November 14, 2016 8:52
To: internet-dra...@ietf.org; i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-11.txt

Hi,

This draft addresses Phil Shafer’s comments and also removes references to 
TLS for now.

Thanks,

Clyde

On 11/13/16, 3:47 PM, "netmod on behalf of internet-dra...@ietf.org" 
<netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the NETCONF Data Modeling Language of the 
IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-11.txt
Pages   : 33
Date: 2016-11-13

Abstract:
   This document describes a data model for the configuration of syslog.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-11


Please note that it may take a couple of

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-11.txt

[Clyde Wildes (cwildes)]

Hi,

This draft addresses Phil Shafer’s comments and also removes references to TLS 
for now.

Thanks,

Clyde

On 11/13/16, 3:47 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-11.txt
Pages   : 33
Date: 2016-11-13

Abstract:
   This document describes a data model for the configuration of syslog.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-netmod-syslog-model-10.txt

[Clyde Wildes (cwildes)]

Hi Phil,

Thanks for your review. My comments inline as [clyde].

On 10/31/16, 5:45 PM, "netmod on behalf of Phil Shafer" 
 wrote:

>Title   : A YANG Data Model for Syslog Configuration

I've a few questions:

- The description says that the "facility/no-facility" case/leaf
is used "to effectively disable a particular log-action".  Why not
make an explicit "disable" leaf instead?  Using no-facilities like
this is confusing.

- Why use an explicit/mandatory selector node instead of making
this implicit, with the lack of a selector meaning match all?

- compare-op: we've always tried to use full words; would this be
better as "compare-operation" or just "compare"?

- equals-or-higher: you might want to explain that this is the
default even in the absence of the "select-sev-compare" feature.
(I'm assuming this is true.)

- You use "facility" as both a case and a list under selector-facility.
This seems confusing and misleading.

[clyde] There have been numerous iterations of the filter specification to make 
it clearer, to simplify, and to include the requirements put forward by the 
vendors that we have worked with. I welcome your input to make it even better. 
We have reached agreement on the intent of the filter specification. Here it is 
in words:

A selector consists of two parts: one or more facility-severity matches, and if 
supported via the select-match feature, an optional regular expression pattern 
match that is performed on the SYSLOG-MSG field.

The facility is one of a specific syslogtypes:syslog-facility, none, or all 
facilities. None is a special case that can be used to turn off an action.

The severity is one of syslogtypes:severity, all severities, or none. None is a 
special case that can be used to turn off a facility. When filtering severity, 
the default comparison is that all messages of the specified severity and 
higher are logged. This is shown in the model as “default equals-or-higher”. 
This behavior can be altered if the select-sev-compare feature is enabled to 
specify: “equals” to specify only this single severity; “not-equals” to ignore 
that severity; “equals-or-higher” to specify all messages of the specified 
severity and higher.

[clyde] I agree that “compare-op” can be simplified to “compare”.

- "structured-data": says "describes how log messages are written
to the log file" but it applies to more than log files.

[clyde] I will reword this to “This leaf describes how log messages are 
written.”

- Consider making "syslog-sign" into "signing-options" or something
similar, to be more clear.  The "syslog-" prefix is not needed,
since the reader knows we are talking about syslog, and the "sign"
is not clear.  Then you can remove the "sig-" prefix on the child
nodes.

[clyde] I will change “syslog-sign” leaf to “signing-options” if no one 
objects, and remove the “sig-“ prefix.

- The "session" name is not clear, since there are many sort of
sessions; would "local-users" be better?

[clyde] An earlier version of the model supported a “user” action. 
Alcatel/Lucent requested that we rename the user action into a session action 
that could be augmented if needed to handle more than user sessions.

- What purpose for the "actions" container serve?  Can it be removed?

[clyde] “actions” serve a purpose should a vendor wish to extend the model to 
support operational data ie “show log” or an RPC such as “clear log”.

- "buffer" should be a feature, since many platforms do not implement it.

[clyde] I will make “buffer” a feature since it is only implemented by Cisco 
and Alcatel/Lucent. 

- How does an implementation specify the set of valid characters usable
for user names?

[clyde] Would a pattern statement like ‘pattern "[0-9a-fA-F]*";’ solve this 
issue? 

- Many networking devices have special tags at the front of their
messages, indicating the specific message.  For example "%ASA-1-104001"
in IOS, or "BGP_CEASE_PREFIX_LIMIT_EXCEEDED" in JUNOS.  We carry
these are specific SD-PARAMS when SD is used.  Is there a way to
filter using theses tags, or more generic SD-PARAMS?

[clyde] We added the ability to filter anything in the SYSLOG-MSG field 
including structured data using a regular expression with the pattern-match 
leaf. That should cover this.

Thanks,

Clyde


Thanks,
 Phil

___
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] partial review of draft-ietf-netmod-syslog-model-08.txt

[Clyde Wildes (cwildes)]

Juergen,

Thanks very much for your detailed review. I have updated the document with 
your feedback and have provided responses for every item, inline below.


On 8/5/16, 3:36 AM, "Juergen Schoenwaelder" 
<j.schoenwael...@jacobs-university.de> wrote:

On Fri, Jul 08, 2016 at 10:37:06PM +0000, Clyde Wildes (cwildes) wrote:
> Juergen,
> 
> Thanks for your detailed review!
> 
> I addressed all of your comments in the latest draft.

Thanks for the update. As my role as a YANG doctoc and someone
generally interested, I took another look at the syslog model.  I
think it has much improved and is close to be done. But of course, I
always find stuff to comment on...

* Document

  Should the title be changed to

A YANG Data Model for Syslog Configuration

  to match existing YANG RFC names and to indicate that the scope
  is configuration (as stated in the abstract)?

[clyde] Adopted.

  Why is the term message originator needed? The definition says:

 The term "message originator" is derived from the term "originator"
 as defined in [RFC5424]: an "originator" generates syslog content to
 be carried in a message.

  This does not explain why 'originator' is not good enough and why a
  new term is needed. What the figure in section 3 shows looks pretty
  much as originators as well. (BTW, it might be nice to give figures
  a number and a caption - makes it easier to refer to them.)

[clyde] I have changed the term to ‘originator’ and have added labels to the 
figures.

  I am also not sure why the term "message distributor" is needed; is
  this not just a 'relay' in the RFC 5424 sense? Or is your message
  distributor a combination of a 'relay' and a 'collector'? I think at
  least some explanation should be given how these terms fit together.
  I also note that the terms "message distributor" and "message
  originator" are never used in the YANG model definition itself; so
  if we can simply use RFC 5424 terms in the introductory part I would
  find that simpler. (I am also not clear whether I would call a Log
  File a Message Distributor as the figure in section 3 suggests; for
  me these are actually what RFC 5424 calls collectors.)

[clyde] I have simplified this to collector.

  You wrote "to configure one or more syslog processes" and I wonder
  what you mean with 'syslog processes' here and why you stress
  'multiple'. Is there anything in the data model that was designed
  specifically to support _multiple_ syslog processes? Is syslog
  process here the same as 'message distributor'? If so, use a single
  term; if not, please explain the difference.

[clyde] I have changed the wording to “to configure the syslog feature”.

  You wrote:

This module can be used to configure the syslog application
conceptual layer [RFC5424].

  Is this statement correct? How do I use the data model to configure
  the list of originators shown in section 3?

[clyde] The list of originators is fixed for each syslog implementation. A 
better
wording might be “This module can be used to configure the syslog application 
conceptual layers as implemented on the target system [RFC5424].”

  You wrote:

The leaves in the base syslog model log-input-transports container
correspond to remote message originators or remote message relays.

The leaves in the base syslog model log-actions container correspond
to each message distributor:

  I could not find log-input-transports and log-actions anywhere, I
  think renaming has not been reflected in the text yet.

[clyde] log-input-transports was removed in a previous edit. This paragraph has
been removed from the draft.

  I would prefer if the examples would be trimmed down to show just
  the XML config and not an entire NETCONF RPC exchange in order to
  reduce noise. Also reduce the number of namespace definitions to the
  minimum needed.

  I am not sure the namespace used in Appendix A.1 is a good idea.
  Perhaps use "http://example.com/ethernet; and in general use
  example.com for example domain names (and not vendor.com)

[clyde] Adopted.

* ietf-syslog-types

  Instead of just 'Alert Level Msg' in the description, perhaps write
  full sentence that is more descriptive, e.g.,

"The severity level 'Alert' indicating that an action must be
taken immediately."

  Note that Table 2 in RFC 5424 provides phrases describing syslog
  message severities.

[clyde] Adopted.

* ietf-syslog

  The commented out reference to ietf-tls-client needs to be resolved.

Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt

[Clyde Wildes (cwildes)]

Juergen,

Thanks for your detailed review!

I addressed all of your comments in the latest draft.

Regards,

Clyde



On 6/15/16, 8:29 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

>Hi,
>
>Dan Romascanu encouraged me to look at this I-D as part of his efforts
>to organize YANG document reviews. Since the YANG definitions are not
>consistent with the tree diagram, I have not really looked at the YANG
>definitions yet. So the comments below are essentially about the
>surrounding document structure, terminology, etc.
>
>- Abstract: The 'which is used to convey event notification messages'
>  may relate to 'the Syslog protocol' or 'a data model' and hence the
>  sentence is I think potentially confusing. Perhaps simply remove the
>  phrase altogether? Readers who do not know what SYSLOG is should
>  stop reading here anyway. Or break the sentence into two to make the
>  structure clearer. Perhaps add one more sentence describing what the
>  scope of the data model is.
>
>- The text uses Syslog, syslog, and SYSLOG. It is not clear what the
>  difference is (if any). If there is no semantic difference, I
>  suggest to pick one writing style (and 5424 seems to prefer all
>  lowercase except in cases where a sentence starts etc).
>
>- Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2
>  to 'The ietf-syslog Module' or something similar and consider
>  changing the title of section 4 to "Syslog YANG Modules" since
>  it contains the definitions of the modules themselves.
>
>- In section 2, should 'monitor and control' be 'configure and
>  monitor' in section 2? Are there actually definitions that support
>  monitoring? Perhaps the scope is just configuration?  Otherwise, I
>  would have expected to see a bunch of basic counters (messages
>  received, forwarded, dropped, the usual monitoring stuff).
>
>- In section 2, s/network management agents such as NETCONF/network
>  management protocols such as NETCONF/
>
>- In section 2, the phrase 'This module' is a hanging reference. There
>  is no prior text talking about a module. Perhaps replace with 'The
>  data model'
>
>- I did not find the term 'message distributor' in RFC 5424. The
>  figure first made me assume that only a console, log buffers, or log
>  files are message distributors but later it was stated that relays
>  and collectors (RFC 5424 defined terms) are also 'message
>  distributors'. Perhaps it helps to clearly spell out terms imported
>  from RFC 5424 and to clearly define any additional terms that go
>  beyond what is defined in RFC 5424.
>
>- Is it possible to shorten 'log-input-transports' to simply
>  'log-inputs' (en par with log-actions)? And since both containers
>  are under syslog, perhaps even the 'log-' prefix is not needed and
>  all we have are /syslog/inputs and /syslog/actions? (I generally
>  find it useful to look at the resulting paths and whether they are
>  'engineer friendly'.
>
>- I guess I have to define multiple /syslog/input/receiver in order to
>  listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and
>  [::]:514? This may be just find - just checking that this is the
>  idea.
>
>- I actually do not find the definition of log-input-transports in the
>  YANG model. It seems the tree diagram is not consistent with the
>  YANG model. So I can't judge what the structured-data boolean flag
>  is doing or what the syslog-sign presence container would do for
>  inputs.
>
>- The security considerations are quite generic; I think the template
>  asks for a more specific discussion.
>
>- I am not sure why RFC 6020 is an informative reference and why all
>  the normative references are actually normative. It might be useful
>  to go over the list to make sure we get the normative / informative
>  distinction right.
>
>- My understanding is that RFC 5424 numbers facilities and there is a
>  hard limit on the number of facilities that the protocol can
>  distinguish. RFC 5424 says:
>
>Facility values MUST be in the range of 0 to 23 inclusive.
>
>  Given this, the 'extending facilities' appendix does not make much
>  sense to me. And given the fact that the number of facilities is
>  fixed (which is due to the way things are encoded in RFC 5424), I am
>  not even sure that using an identity instead of an enumeration is
>  useful (except if we expect a future version of SYSLOG to use a very
>  different encoding of facilities). I mean, to stay within the bounds
>  of RFC 5424, all one can do is to add an identity that maps to an
>  already allocated code point.
>
>- Do not use 1.1.1.1 as an example IP address, consider using an IPv6
>  address from the IPv6 example address space.
>
>- Section 4.3 should not be in Section 4 and the title 'A Syslog
>  Example' is kind of misleading since the text shows NETCONF messages
>  operating on the SYSLOG YANG data model. I suggest to move 4.3 to
>  a new top-level section 5 "Usage 

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt

[Clyde Wildes (cwildes)]

Tom,

In the latest draft I have removed an action, some features and shortened more 
names.

I think that we are close to the minimum functionality that should be specified.

Thanks,

Clyde




On 5/28/16, 4:36 AM, "t.petch" <ie...@btconnect.com> wrote:

>
>Tom Petch
>
>
>- Original Message -
>From: "Sterne, Jason (Nokia - CA)" <jason.ste...@nokia.com>
>Sent: Friday, May 27, 2016 8:30 PM
>
>> Hi Clyde,
>>
>> I was a bit surprised to see the receiver/server side config in here
>(log-input-transports).  That seems to be a somewhat significant change
>in scope.  I thought the focus of this was more on the generation &
>distribution.  Do many implementations have functionality that maps to
>this log-input-transports ?   In any case the pyang tree has
>log-input-transports but it doesn't seem to be down in the actual model
>itself.  But I'd be inclined to just remove this from the model.  Maybe
>Mahesh has some thoughts here (I didn't see a posting about this in the
>mailing list).
>>
>> I agree there are multiple implementations of console, buffer and
>session logs.  But maybe 'terminal' should be removed or an if-feature ?
>I'm not sure that one is so widespread (not in JUNOS, not in SR OS).
>>
>> Buffer-limit-messages and having multiple log buffers are both
>supported by Nokia SR OS. I would think that both of those would have
>support in other logging implementations as well.  I'm not sure if Tom
>P. was really concluding that there are no implementations of these in
>his email.  Do we have multiple examples of implementations that limit
>log buffers using bytes ?
>>
>
>My comment was more on the complexity that results from having so many
>options.  Other models are worse - some of the routing ones I find
>unintelligible as a result - but I raised the issue on this model
>because it is being discussed on this list where (almost) all the
>expertise in these matters resides to see if anyone else would bite.
>
>I believe we will regret this complexity some years down the line but
>see no way of forestalling this:-(
>
>I don't have direct knowledge of whether or not this feature is
>widespread.
>
>Tom Petch
>
>> Buffer-limit-messages would be easy to do as an augmentation but
>making the log-buffer a list is probably something we should just do
>from the start.  That is also consistent with all the other types of
>actions (except console of course). The use case for multiple log
>buffers is that you might sort/filter different types of log events into
>different circular buffers (i.e. have one for really critical log
>events, etc) for viewing on the node.
>>
>> Regards,
>> Jason
>>
>> -Original Message-
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT Clyde
>Wildes (cwildes)
>> Sent: Tuesday, May 10, 2016 17:23
>> To: netmod@ietf.org
>> Subject: Re: [netmod] I-D Action:
>draft-ietf-netmod-syslog-model-08.txt
>>
>> Hi,
>>
>> This update to the draft-ietf-netmod-syslog-model-08 incorporates the
>changes listed below based on feedback received.
>>
>> An additional revision to this draft will be necessary to finalize TLS
>configuration leaves once the ietf-tls-client-server-model that the
>NETCONF WG plans to spin out of the netconf-server-model draft is
>available.
>>
>> Changes from feedback from Mahesh J:
>> - added support for configuring a syslog server
>>
>> Changes from feedback from Tom P.:
>> - removed four features for log action leaves console, buffer,
>terminal and session since they are implemented by multiple vendors.
>Lack of support for these actions can be indicated using a deviation.
>> - removed feature buffer-limit-messages since implementation by any
>vendor is unknown
>> - renamed feature terminal-facility-user-logging-config to
>terminal-facility-device-logging to shorten the name and to clarify
>> - renamed feature session-facility-user-logging-config to
>session-facility-user-logging to shorten the name
>> - renamed feature selector-sevop-config to feature select-sev-compare
>to shorten the name
>> - renamed feature selector-match-config to feature select-match to
>shorten the name
>> - renamed feature structured-data-config to feature structured-data to
>shorten the name
>> - renamed feature signed-messages-config to feature signed-messages to
>shorten the name
>> - removed the log-buffer list and name from log-action buffer since im
>plementation by any vendor is unknown
>> - removed the word draft from section 1
>> - updated the copyright dates and the revision dates in the models
>> - moved the

Re: [netmod] NETMOD SYSLOG YANG Model / additional attributes

[Clyde Wildes (cwildes)]

Dmytro,

RFC 5424 The Syslog Protocol, defines the message format for syslog messages 
and the proposed ietf-syslog.yang model supports both free form and structured 
data format Syslog messages as specified by RFC 5424.

TIMESTAMP is described in section 6.2.3 of the RFC. Sequence number could be 
implemented as free form text in the MSG field (section 6.4), or it could be an 
SD-ELEMENT (section 6.3.1) if structured data format is used. Section 7.3.1 – 
sequenceId shows an example of a structured data sequence number implementation.

Thanks,

Clyde

From: netmod  on behalf of Dmytro Gassanov 

Date: Friday, June 24, 2016 at 8:38 AM
To: "netmod@ietf.org" 
Cc: Andrew Veitch 
Subject: [netmod] NETMOD SYSLOG YANG Model / additional attributes

Hello Everybody,

I also read the latest revision of “SYSLOG YANG Model” and did not found 
attributes regarding “Timestamp format” and “Sequence number”.

From my understanding these attributes are important.

What do you think about adding these attributes?

Thank you.

Best regards,

Dmytro Gassanov,
Netcracker Technology

+380 44 238-8727 | ext. 6825 | office
+380 67 441-5834 | mobile

We are Netcracker, and we are focused forward





The information transmitted herein is intended only for the person or entity to 
which it is addressed and may contain confidential, proprietary and/or 
privileged material. Any review, retransmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and delete the material from any computer.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt

[Clyde Wildes (cwildes)]

the start.  
>That is also consistent with all the other types of actions (except console of 
>course). The use case for multiple log buffers is that you might sort/filter 
>different types of log events into different circular buffers (i.e. have one 
>for really critical log events, etc) for viewing on the node.
>
>Regards,
>Jason
>
>-Original Message-
>From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT Clyde Wildes 
>(cwildes)
>Sent: Tuesday, May 10, 2016 17:23
>To: netmod@ietf.org
>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
>
>Hi,
>
>This update to the draft-ietf-netmod-syslog-model-08 incorporates the changes 
>listed below based on feedback received.
>
>An additional revision to this draft will be necessary to finalize TLS 
>configuration leaves once the ietf-tls-client-server-model that the NETCONF WG 
>plans to spin out of the netconf-server-model draft is available.
>
>Changes from feedback from Mahesh J:
>- added support for configuring a syslog server
>
>Changes from feedback from Tom P.:
>- removed four features for log action leaves console, buffer, terminal and 
>session since they are implemented by multiple vendors. Lack of support for 
>these actions can be indicated using a deviation.
>- removed feature buffer-limit-messages since implementation by any vendor is 
>unknown
>- renamed feature terminal-facility-user-logging-config to 
>terminal-facility-device-logging to shorten the name and to clarify
>- renamed feature session-facility-user-logging-config to 
>session-facility-user-logging to shorten the name
>- renamed feature selector-sevop-config to feature select-sev-compare to 
>shorten the name
>- renamed feature selector-match-config to feature select-match to shorten the 
>name
>- renamed feature structured-data-config to feature structured-data to shorten 
>the name
>- renamed feature signed-messages-config to feature signed-messages to shorten 
>the name
>- removed the log-buffer list and name from log-action buffer since 
>implementation by any vendor is unknown
>- removed the word draft from section 1
>- updated the copyright dates and the revision dates in the models
>- moved the example to an Appendix
>- removed e-mail addresses from the acknowledgement section
>
>Changes from feedback from Benoit:
>- rename module vendor-syslog-types to module vendor-syslog-types-example
>
>
>Thanks,
>
>Kiran and Clyde
>
>
>
>
>On 5/10/16, 2:14 PM, "netmod on behalf of internet-dra...@ietf.org" 
><netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the NETCONF Data Modeling Language of the IETF.
>>
>>Title   : SYSLOG YANG Model
>>Authors : Clyde Wildes
>>  Kiran Koushik
>>  Filename: draft-ietf-netmod-syslog-model-08.txt
>>  Pages   : 35
>>  Date: 2016-05-10
>>
>>Abstract:
>>   This document describes a data model for the Syslog protocol which is
>>   used to convey event notification messages.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-08
>>
>>
>>Please note that it may take a couple of minutes from the time of 
>>submission until the htmlized version and diff are available at 
>>tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>___
>>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] I-D Action: draft-ietf-netmod-syslog-model-07.txt

[Clyde Wildes (cwildes)]

Tom,

I understand your concern with the complexity of the model. That said, as we 
progressed we encountered some vendors and some IETF RFC authors who requested 
that a particular feature of interest be included. We felt that we had to make 
features that were not implemented by two or more vendors a YANG feature to 
gain acceptance. Which is preferred in this case: augmentation to add features; 
deviation not-supported statements to remove features; or the use of feature 
statements? During early model development our YANG doctor advisor advocated 
using feature.

I read your post on "features - a Cartesian explosion" post. Note that in the 
case of the latest ietf-syslog model four of the features are nested such that 
they are not encountered unless a higher level feature is enabled. 

What would your preference be:
- remove the feature statements and ask vendors to supply deviation statements 
for those leaves not implemented
- remove all leaves conditioned by feature and ask vendors to supply annotated 
models with augmentation
- leave things as they are

It sounds like B would be your preference?

Thanks,

Clyde





On 3/28/16, 10:09 AM, "t.petch" <ie...@btconnect.com> wrote:

>
>- Original Message -----
>From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
>To: <netmod@ietf.org>
>Cc: "Martin Bjorklund" <m...@tail-f.com>; "t.petch"
><ie...@btconnect.com>; "Kiran Koushik Agrahara Sreenivasa (kkoushik)"
><kkous...@cisco.com>
>Sent: Sunday, March 20, 2016 7:53 PM
>
>> Hi,
>>
>> This revision incorporates feedback from Martin Bjorklunk (19
>comments) and Tom Petch (10 comments). Thanks to both of you for your
>valuable feedback!
>>
>> Regarding Tom's comment - "4.1 What a lot of features?  Again, makes
>things more complex, more error prone - are they all really needed?": We
>started the draft two years ago and it has evolved from feedback
>received from all of the folks that appear in the Acknowledgements
>section. Please review the current draft where I believe that I address
>all of your comments except possibly this one. The tradeoff is to leave
>the feature specific functionality out of the draft and leave it to the
>implementations to add back through augmentation. That said most of the
>features that are called out have been implemented by at least two
>vendors, but not all, leading to the feature designation.
>
>Clyde
>
>Ys; I did a separate post on the topic thinking that an implementor
>might share my concerns about the large number of possible variations in
>an implementation when there were a large number of features, that
>perhaps there should be guidelines about it, but it did not get any
>traction.  It is one those issues where I think, in a year or two's
>time, others might share my concern, but not yet:-(.
>
>I don't doubt that the variation exists and needs modelling, just that
>such use of 'features' may have unfortunate consequences - but I have no
>alternative suggestion.
>
>Tom Petch
>
>> Thanks,
>>
>> Clyde
>>
>>
>>
>> On 3/20/16, 8:10 AM, "netmod on behalf of internet-dra...@ietf.org"
><netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>
>> >
>> >A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>> >This draft is a work item of the NETCONF Data Modeling Language of
>the IETF.
>> >
>> >Title   : SYSLOG YANG Model
>> >Authors : Clyde Wildes
>> >  Kiran Koushik
>> > Filename: draft-ietf-netmod-syslog-model-07.txt
>> > Pages   : 34
>> > Date: 2016-03-20
>> >
>> >Abstract:
>> >   This document describes a data model for the Syslog protocol which
>is
>> >   used to convey event notification messages.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>> >
>> >There's also a htmlized version available at:
>> >https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-07
>> >
>> >A diff from the previous version is available at:
>> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-07
>> >
>> >
>> >Please note that it may take a couple of minutes from the time of
>submission
>> >until the htmlized version and diff are available at tools.ietf.org.
>> >
>> >Internet-Drafts are also available by anonymous FTP at:
>> >ftp://ftp.ietf.org/internet-drafts/
>> >
>> >___
>> >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: draft-ietf-netmod-syslog-model-06

[Clyde Wildes (cwildes)]

Lou,

We are working on a revision to the document to address the concerns that 
Martin and Tom raised.

There is one issue that I need to raise to the Netmod chairs for advice: all 
our drafts since the original draft have "Intended status: Informational" at 
the top of the draft. Martin indicated that this should be "Intended status: 
Standards Track" and that the WG will have to authorize this change in status. 
Please advise.

Thanks,

Clyde



On 3/10/16, 1:57 PM, "Lou Berger"  wrote:

>All,
>It looks like we've already received sufficient comments that
>indicate that the document isn't ready for publication.  Given the
>comments, we're looking to the authors to address comments received and
>any more that may be forthcoming.  We're ending a little early to give
>the authors extra time before the meeting cut-off to address comments in
>a draft update that, hopefully, can be discussed in BA. 
>
>Thank you,
>
>Lou (and Kent)
>
>On 2/29/2016 3:50 PM, Lou Berger wrote:
>> All,
>> This starts a two-week working group last call on
>> draft-ietf-netmod-syslog-model-06.
>>
>> The working group last call ends on March 14. Please send your comments
>> to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document and
>> believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Thank you,
>> Netmod Chairs
>>
>>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-syslog-model

[Clyde Wildes (cwildes)]

Patrick,

Thanks for your review.

Regarding the severity leaf: multiple severities are already covered when 
severity is specified because the default severity comparison is all messages 
of the specified severity and greater. You can use of the optional 
pattern-match string to select a message with a specific priority (includes 
severity and facility). If you need further filtering capability, you could add 
this through augmentation of the log-selector container.

Regarding the specification for the remote destination: in an earlier review it 
was required that the model conform to the recommendation in Section 3 of 
draft-schoenw-netmod-yang-pattern-00. Your proposal does not follow that 
pattern.

Regarding the leaf nodes to be added request:

- The presence or absence of a leaf in the log-actions container indicates 
whether the intended action is enabled/disabled. This pattern is used for all 
log actions.
- The proposed ietf-syslog model does not include operational state or 
notifications. Operational state in the model's config section would have to be 
flagged as such. Please refer to the "State Data" statement from RFC 6020 
section 4.2.3.
- A custom-prefix leaf to prepend a custom signature for each log message could 
be added though augmentation. If there is a consensus that this should be added 
for all implementations I will gladly add it.

Thanks,

Clyde

From: "Hinshaw, Patrick" >
Date: Tuesday, March 1, 2016 at 11:22 PM
To: 
"draft-ietf-netmod-syslog-mo...@tools.ietf.org"
 
>
Subject: draft-ietf-netmod-syslog-model
Resent-From: 

Re: [netmod] draft-ietf-netmod-syslog-model-06

[Clyde Wildes (cwildes)]

No, I'm not aware of any IPR that applies to this draft


Clyde





On 2/22/16, 5:22 PM, "Lou Berger"  wrote:

>Authors, Contributors, WG,
>
>As part of the preparation for WG Last Call
>
>Are you aware of any IPR that applies to draft identified above?
>
>Please state either:
>
>"No, I'm not aware of any IPR that applies to this draft"
>or
>"Yes, I'm aware of IPR that applies to this draft"
>
>If so, has this IPR been disclosed in compliance with IETF IPR rules
>(see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>If yes to the above, please state either:
>
>"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>or
>"No, the IPR has not been disclosed"
>
>If you answer no, please provide any additional details you think
>appropriate.
>
>If you are listed as a document author or contributor please answer the
>above by responding to this email regardless of whether or not you are
>aware of any relevant IPR. This document will not advance to the next
>stage until a response has been received from each author and listed
>contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
>TO LINES.
>
>If you are on the WG email list or attend WG meetings but are not listed
>as an author or contributor, we remind you of your obligations under
>the IETF IPR rules which encourages you to notify the IETF if you are
>aware of IPR of others on an IETF contribution, or to refrain from
>participating in any contribution or discussion related to your
>undisclosed IPR. For more information, please see the RFCs listed above
>and
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>NETMOD WG Chairs
>
>PS Please include all listed in the headers of this message in your
>response.
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] syslog-model-05: terminal logging vs session logging

[Clyde Wildes (cwildes)]

Jason,

We are about to publish draft-ietf-netmod-syslog-06 which separates terminal 
logging from session logging. We appreciate your feedback.

Thanks,

Clyde

From: netmod > on 
behalf of "Sterne, Jason (Jason)" 
>
Date: Wednesday, October 28, 2015 at 11:50 AM
To: "netmod@ietf.org" 
>
Subject: [netmod] syslog-model-05: terminal logging vs session logging

Hi all,

One of the syslog destinations in the model is the “terminal” (for all users or 
specific users).

Isn’t logging to a terminal more typically enabled on a CLI *session* basis 
rather than configured against a particular user ?

I believe it is also typical for session logging to stop/disappear when that 
session is ended (i.e. it is not persistent config).

I’m not sure it is typical to have configuration in a device that basically 
instructs the device to enable logging to the terminal for “user x” whenever 
that user later logs in (and if they had multiple login sessions then 
presumably log events would be delivered to each session).

I think session logging is something that is really purely CLI (i.e. 
interactive sessions with human users) and maybe not even applicable to 
configuration via NETCONF (since we’d never want to send a stream of syslog 
events as text to the NETCONF client/session like we do to the terminal for a 
CLI user).

In section 5 of the draft it mentions that syslog:log-actions/terminal maps to 
Cisco NXOS “logging monitor 2”.  I believe that is intended to enable logs to a 
particular *session* (not user).   IOS-XR behavior is similar.  The ALU SR OS 
logging config has the concept of sending (enabling) log events to a particular 
session (but not configured against a user).

Jason



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

Re: [netmod] syslog-model-05: minor editorial comments

[Clyde Wildes (cwildes)]

Jason,

We are about to publish draft-ietf-netmod-syslog-model-06 which incorporates 
your feedback below.

Thanks,

Clyde

From: netmod > on 
behalf of "Sterne, Jason (Jason)" 
>
Date: Wednesday, October 28, 2015 at 11:50 AM
To: "netmod@ietf.org" 
>
Subject: [netmod] syslog-model-05: minor editorial comments

A few minor editorial comments on syslog-model-05:

- The introduction says "We are using definitions of Syslog protocol from 
[RFC3164] in this draft." but the YANG model mostly references 5424.
- In section 3 maybe use the term "Remote Collector(s)" instead of Server(s) ? 
Collector seems more in line with RFC5424 (or "Remote Receiver" if others 
prefer that).
- In the Section 3 figure make all the Distributors have a common syntax for 
plural vs singular "Log Buffer(s)", "Log File(s)", "Remote Collector(s)", “User 
Terminal(s)”
- Document is missing the standard legend for the PYANG tree

Jason

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

[netmod] draft-ietf-netmod-syslog-model-05 Draft Status

[Clyde Wildes (cwildes)]

Hi,

This e-mail summarizes the changes that have been made to the proposed 
ietf-syslog.yang model since the July meeting when the previous 04 draft was 
published. The changes are based on feedback received after the last meeting 
from Martin Bjorklund, Lada Lhotka, Jason Sterne, and Mahesh Jethanandani.

Changes to ietf-syslog-types.yang:
- updated WG Chair to Kent Watson
- updated the revision date to 2015-10-14.

Changes to ietf-syslog.yang:
- updated WG Chair to Kent Watson
- updated the revision date to 2015-10-14
- modified numerous description fields to more accurately reflect field contents

- simplified the log-selector container leaves by using leaf names that more 
accurately describe the intent and using a union to add an option for all 
facilities
- modified the severity field to include an enum value for "none" instead of 
depending on none being implied if the leaf was not specified
- added "mandatory true" to the selector-facility choice and the severity leaf
- moved the "severity-operator" leaf into the syslog-severity grouping
- added "presence..." for the syslog/console container
- renamed the "remote-logging-destination" leaf to "destination" in the 
syslog/remote container
- replaced "default all-users" with "mandatory true" for the 
syslog/terminal/user-scope choice.

Please let me know if your have questions or concerns.

Thanks,

Clyde


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

[netmod] draft-ietf-netmod-syslog-model-04.txt Implementations

[Clyde Wildes (cwildes)]

Carl,

Thanks for your question in the Netmod meeting during the review of the 
ietf-syslog model.

Regarding the model implementation: the model has been implemented in ODL and 
internally in Cisco's NXOS.

Thanks,

Clyde

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

Re: [netmod] example in draft-ietf-netmod-syslog-model-04

[Clyde Wildes (cwildes)]

Lada,

Thanks for your review.

All was not added to the syslogtypes:severity because that would alter the 
definition of severity as specified by RFC 5424 in Table 2 on page 10. I agree 
that it will simplify the model to do so.

Please advise.

Thanks,

Clyde



On 7/14/15, 6:57 AM, netmod on behalf of Ladislav Lhotka 
netmod-boun...@ietf.org on behalf of lho...@nic.cz wrote:

Hi,

the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
invalid: the value of severity should be critical rather than
syslogtypes:critical. Enums are simple strings, not QNames.

Also, I wonder why the type of severity is defined (in multiple
places) like so:

  type union {
type syslogtypes:severity;
type enumeration {
  enum all {
value -1;
description
  This enum describes the case where all severities 
   are requested.;
  }
}

I think the all enum can be simply added to the syslogtypes:severity
enumeration.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
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] example in draft-ietf-netmod-syslog-model-04

[Clyde Wildes (cwildes)]

Lada,

I would prefer a specification that declares the all intent instead of 
relying on debug meaning all messages. A number syslog implementations 
specify a severity of all. Example: rsyslog - 
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html.

I used the union approach because, in an earlier review, Jan Lindblad suggested 
it as a simple method to add all without compromising the RFC definition of 
Severity. His point was that adding a choice is a complication.

Thanks,

Clyde




On 7/14/15, 9:03 AM, Ladislav Lhotka lho...@nic.cz wrote:


 On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes) cwil...@cisco.com wrote:
 
 Lada,
 
 Thanks for your review.
 
 All was not added to the syslogtypes:severity because that would alter the 
 definition of severity as specified by RFC 5424 in Table 2 on page 10. I 
 agree that it will simplify the model to do so.

The description of the “severity” leaf says:

When severity is specified the default severity comparison is all messages of 
the specified severity and greater are logged unless all is specified which 
means all severities are requested.

Isn’t then “debug” equivalent to “all”, i.e. is the “all” option really needed?

 
 Please advise.

I would do a similar thing that you did for facilities: choice between 
“severity” (with the type “syslogtypes:severity”) and an empty leaf 
all-severities”.

Lada

 
 Thanks,
 
 Clyde
 
 
 
 On 7/14/15, 6:57 AM, netmod on behalf of Ladislav Lhotka 
 netmod-boun...@ietf.org on behalf of lho...@nic.cz wrote:
 
 Hi,
 
 the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
 invalid: the value of severity should be critical rather than
 syslogtypes:critical. Enums are simple strings, not QNames.
 
 Also, I wonder why the type of severity is defined (in multiple
 places) like so:
 
 type union {
   type syslogtypes:severity;
   type enumeration {
 enum all {
   value -1;
   description
 This enum describes the case where all severities 
  are requested.;
 }
   }
 
 I think the all enum can be simply added to the syslogtypes:severity
 enumeration.
 
 Lada
 
 -- 
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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