Subject: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Apr 2015 14:42:31 +0200 (CEST)

Hi,

I have reviewd this document and have some comments:        

o  typedef severity should have a reference to RFC 5424.

o  Given that the standard defines a fixed set of 24 facilities, it
   seems odd that the facilities are modelled as identities, and not
   as an enumeration.  Using identities gives the impression that this
   is an extensible set of values.

o  Why do we have these:

    feature file-logging-structured-data

    feature remote-logging-structured-data

  I would assume that if the device supports structured data, it would
  do so regardless of logging method?  I.e., a single feature
  "structured-data" would be enough?

  But is this (structured data) typically configurable in
  implementations, and if it is, it is configurable per "action" like
  this?

o  I do not understand what the global-logging-action does.  The
   description says:

         Global logging represents the ability to
         perform global log message suppression.

   Does this mean that the global level *suppresses* matching
   messages?

   The text talks about "group level suppression", but the model has
   "global logging action".  This is a bit confusing.

   So what does this configuration mean:

     <global-logging-action>
       <none/>
     </global-logging-action>

   Does it means that no messages are suppressed, or that all messages
   are suppressed?

o  The usage of the in-memory log buffer is a bit unclear.  I think the
   spec needs to explain how this log buffer is supposed to be used.
   Perhaps we should also provide a mechanism to read this buffer?
   I.e., provide a config false list of buffered messages?

o  It is important to remember that the names of choices and cases are
   not visible in the instantiated data.  Thus, when you have nice
   descriptive names for the choices and cases, and these names convey
   some meaning, this meaning is lost when you just look at instance
   data.  For example, this instance:

     <console-logging-action>
       <severity>warning</severity>
     </console-logging-action>

   does not convey the meaning of the chosen case, which is called
   "logging-facility-all".  I.e., from the instance data above you
   cannot tell that we're actually matching on all facilities.

   I think you said you are changing this grouping a bit, and if so I
   will have a look in the next revision.

o  For the remote logging, it seems only UDP is supported.  I think
   the data model should follow the recommendation in section 3 in
   draft-schoenw-netmod-yang-pattern-00 so that multiple transports
   can be supported.  Maybe this model should support the TLS and DTLS
   transports?

o  For remote logging, I think the "vrf-name" leaf should be removed.
   It is not clear how this maps to the routing work, and it can
   always be augmented later, or a vendor can do a proprietary
   augmentation.

o  For remote logging is it a good idea to have "source-interface"?
   If so, should we have this in all our models for outgoing
   connections?

o  leaf file-name is supposed to refer to a local file.  If inet:uri
   is supposed to be used, it should state that this MUST be with
   scheme "file"  (i.e., on the form "file:...").  But is inet:uri the
   correct type to use?

o  leaf file-number has a default of 1.  Isn't this a bit small for a
   file archive?

o  leaf file-size has a default of 262144.  Why this number?

o  leaf file-permission has the teo values "world-readable" and
   "no-world-readable".  This seems a bit restrictive for some kinds
   of systems, and it is also underspecified (what exactly does
   "no-world-readable" mean?).  Maybe it is better to leave this out?

o  I think some nodes can get better names.  Maybe:

     syslog / log-actions / global
                            console
                            buffer
                            file
                            remote
                            terminal

   This allows for future nodes (non-actions) directly underneath
   "syslog", and it removes the "-logging-action" suffix everywhere.

   I also suggest you remove the containers
   "logging-advanced-level-processing" and "logging-match-processing"
   and just move their leafs up one level:

      global / logging-level-scope /...
               select-message-severity
               pattern-match

   Some other suggestions:

     OLD: logging-files
     NEW: log-file   (note singluar)

     OLD: file-name
     NEW: name       (remove redundant prefix)

     OLD: file-logging-strucured-data
     NEW: structured-data (remove redundant prefix)

     OLD: file-logging-archive
     NEW: file-archive

     OLD: file-number
     NEW: number-of-files

     OLD: file-size
     NEW: max-file-size

     OLD: remote-logging-structured-data
     NEW: structured-data (remove redundant prefix)

o  I don't understand how the leaf "select-message-severity" is
   supposed to be used.

o  I think container syslog-sign should have:

     reference
       "RFC 5848: Signed Syslog Messages";

   (Yes I know this is also defined on the top-level, but it is nice
   to have the reference available when it is used.)

   BTW this is the style the RFC editor prefers, so you may want to
   change the current top-level reference to:

    reference
      "RFC 5424: The Syslog Protocol
       RFC 5848: Signed Syslog Messages";

o  I don't know anything about signed syslog messages, but are these
   config params all that are needed?

/martin

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Sat, 4 Apr 2015 03:45:46 +0000

A few comments below marked with [>>JTS]

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, April 02, 2015 8:43 AM
To: [email-masked]
Subject: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt

Hi,

[>>JTS] I'd prefer to see this stay as an extensible set of identities.  The RFC says "Facility and Severity values are not normative but often used.".  A number of implementations use both the facility names in the RFC as well as proprietary facility names.

o  Why do we have these:

     <global-logging-action>
       <none/>
     </global-logging-action>

     <console-logging-action>

[>>JTS] In my recent comments ("Some feedback on syslog-model-03") I recommended we remove the default from the model and let systems vary on that.

[>>JTS] I agree - leave this out.  Leave that to vendor specific augmentation. Authorization in network element file systems is too varied across implementations and I'm not sure that many actually configure it directly as part of the syslog config.

[>>JTS] I like this general idea although I don't think 'global' belongs with the other items. The other items could be in a container called "log-distributors" to match the figure in the draft or perhaps "log-destinations" (which I somewhat prefer personally).

   Some other suggestions:

     OLD: logging-files

     OLD: file-name

     OLD: file-number
     NEW: number-of-files

     OLD: file-size
     NEW: max-file-size

     reference

    reference

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Apr 2015 10:06:33 +0200

> [>>JTS] I'd prefer to see this stay as an extensible set of identities.  The RFC says "Facility and Severity values are not normative but often used.".  A number of implementations use both the fac…

My understanding of RFC 5424 section 6.2.1 is that the PRI field has a
fixed size and it is used to encode the faciltity and the priority.
Since both of them are fixed in size, I think it makes a lot of sense
to enumerate the possible values to achieve interoperability. I agree
with Martin that making them identities leads to wrong expectations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 6 Apr 2015 14:10:54 +0000

Hi guys,

I think we are mixing up the encoding of the syslog message format here (on the wire / external to the box) with configuration of filtering for the 'distributors'.  This syslog model isn't so much about trying to encode the syslog message formats (which is more the focus of the RFC) as it is about NE configuration of the filtering & distribution of log events in a network element (which isn't really the focus on the RFC).

Many systems have proprietary log event flows/streams that they have modeled as 'facilities' for internal NE configuration & filtering.  They then generally have configuration to remap or overwrite the internal proprietary facilities with one of the standard values before sending to a syslog collector (that is the "leaf destination-facility").

I've seen that approach in at least Alcatel-Lucent SR OS and in JUNOS.  I haven't looked at IOS or others but they may have it as well.

I really think the applicability of this model will be much better if we allow extensibility of the facilities (so they can be used in the selector/filter). 

Jason

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Saturday, April 04, 2015 4:07 AM
To: Sterne, Jason (Jason)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt

> [>>JTS] I'd prefer to see this stay as an extensible set of identities.  The RFC says "Facility and Severity values are not normative but often used.".  A number of implementations use both the fac…

My understanding of RFC 5424 section 6.2.1 is that the PRI field has a fixed size and it is used to encode the faciltity and the priority.
Since both of them are fixed in size, I think it makes a lot of sense to enumerate the possible values to achieve interoperability. I agree with Martin that making them identities leads to wrong expectations.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2015 17:24:21 +0200

If there are two levels and a mapping, then there are two levels and a
mapping. An opaque identity where I am not sure what it refers to does
not really help that much with interoperability I think. If this
two-level approach is common, perhaps it is then better to expose the
two levels and the mapping?

/js

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 7 Apr 2015 21:59:06 +0000

Martin,

Thanks for your review!

My responses are inline...

>o  typedef severity should have a reference to RFC 5424.

[clyde] Agreed - I will make the change.

>   is an extensible set of values.

[clyde] A number of vendors need to augment the list of facilities - some with several hundred additional facilities. Please suggest an alternative coding that can be used to add facilities through augmentation. Is it that we should have two separate facility fields: RFC 5424 (0-24) and Vendor Specific starting at 24?

>  implementations, and if it is, it is configurable per "action" like

[clyde] The history of this is that we agreed to support file-logging-structured-data as a feature (currently implemented by JUNOS) since it is called out in RFC 5424. Then someone (at the Hawaii meeting) asked, if we support structured data for files, why not support for remote logging too? Although I do not know of anyone who has implemented this, I agreed to support it for remote logging as a separate feature. We are talking about two different functionalities here. Perhaps the best solution is to remove remote-logging structured data and let it be supported through augmentation should anyone require it in the future.

>   Does it means that no messages are suppressed, or that all messages

[clyde] Global logging is a first level suppression filter. Please see the diagram in the RFC. Given that only a few NOS implement it we could remove it and leave it for augmentation for those vendors that implement it. <none/> means that no facilities participate in the filter and therefore the filter is turned off.

<none/> is useful when you want to turn off actions that default to on (such as the console). 

>   I.e., provide a config false list of buffered messages?

[clyde] In-memory log buffers are circular queues of log messages. Network elements that can experience log message event storms use in-memory buffers to avoid loss of syslog messages.

>   will have a look in the next revision.

[clyde] I will examine our use of choice/case with an eye to rewording for clarity.

>   can be supported.  Maybe this model should support the TLS and DTLS

[clyde] I agree to follow the recommendation in section 3 of draft-schoenw-netmod-yang-pattern-00.

>   always be augmented later, or a vendor can do a proprietary

[clyde} Multiple vendors add VRF name to the server connection specification so that the correct routing table can be used to provide access the server. I am surprised that VRF is not in your best practice Outbound Connection pattern.

>   If so, should we have this in all our models for outgoing

[clyde] source-interface is implemented by multiple vendors to force log messages to have the same source information in outgoing syslog packets. This makes it easier for the remote server to implement firewall protection.

>   scheme "file"  (i.e., on the form "file:...").  But is inet:uri the

[clyde] I will update the description to indicate that the file scheme should be used.

>o  leaf file-number has a default of 1.  Isn't this a bit small for a

[clyde] I chose 1 (perhaps naively) for those vendors that do not implement the file-number concept. I will be happy to change to a consensus number.

>o  leaf file-size has a default of 262144.  Why this number?

[clyde] There was a brief discussion on the list and this seemed like a good tradeoff.

>   "no-world-readable" mean?).  Maybe it is better to leave this out?

[clyde] Multiple vendors implement a binary switch for syslog world read protection: on for anyone; off for no. If we remove this almost every vendor will have to add it back through augmentation. It's not meant to be a general Unix file-permission mask value.

>   "syslog", and it removes the "-logging-action" suffix everywhere.

[clyde] I will make this change.

>      global / logging-level-scope /...

[clyde] Agreed.

>     NEW: structured-data (remove redundant prefix)

[clyde] I will make these changes.

>o  I don't understand how the leaf "select-message-severity" is

Juergen felt that it was important that this model support Linux syslog selector processing. Linux syslog adds "equals" and "not-equals" comparisons to the standard "equals-or-higher" severity comparison. This is a feature because not all implementations support this.

>       RFC 5848: Signed Syslog Messages";

[clyde] Agreed.

>   config params all that are needed?

[clyde] Yes, Alex Clemm provided the list from the RFC.

Thanks,

Clyde

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Apr 2015 12:12:09 +0200 (CEST)

Hi,

"Clyde Wildes (cwildes)" <[email-masked]> wrote:
> [clyde] A number of vendors need to augment the list of facilities -
> some with several hundred additional facilities.

How does this even work, given that the PRIVAL is encoded with 3
digits?  It seems to me that the maximum possible facility value is
124.

> Please suggest an
> alternative coding that can be used to add facilities through
> augmentation. Is it that we should have two separate facility fields:
> RFC 5424 (0-24) and Vendor Specific starting at 24?

One option could be to do:

  typedef facility {
    type union {
      type enumeration {
        enum kern   { value 0; }
        ...
        enum local8 { value 23; }
      }
      type uint16 {
        range "24..124";  // or 0..999
      }
    }
  }

It is not clear to me if this is allowed by RFC 5424.  It says that:

  Facility and Severity values are not normative but often used

But then it also says:

  Facility values MUST be in the range of 0 to 23 inclusive

So if we allow other facilities, shouldn't we also allow other
serverities?

Or should we allow them to configure prival 0..999?

> [clyde] The history of this is that we agreed to support
> file-logging-structured-data as a feature (currently implemented by
> JUNOS) since it is called out in RFC 5424. Then someone (at the Hawaii
> meeting) asked, if we support structured data for files, why not
> support for remote logging too? Although I do not know of anyone who
> has implemented this, I agreed to support it for remote logging as a
> separate feature. We are talking about two different functionalities
> here. Perhaps the best solution is to remove remote-logging structured
> data and let it be supported through augmentation should anyone
> require it in the future.

Let me take one step back.  What exactly does it mean to:

       log messages 
       to a file in structured-data format as per RFC 5424

RFC 5424 defines the format of a syslog message, with the rule
"SYSLOG-MSG".  This message format contains structured data.

So if you have not enabled structured data (with your model), what is
the expected format of the message?  Does it still contain the HEADER
as defined in 5424, or just some message format (maybe as exaplained
in RFC 3164)?

> [clyde] Global logging is a first level suppression filter. Please see
> the diagram in the RFC. Given that only a few NOS implement it we
> could remove it and leave it for augmentation for those vendors that
> implement it. <none/> means that no facilities participate in the
> filter and therefore the filter is turned off.

Ok.

My point is that the text is unclear.  But if you remove this that
problem goes aways ;-)

> [clyde] In-memory log buffers are circular queues of log
> messages. Network elements that can experience log message event
> storms use in-memory buffers to avoid loss of syslog messages.

This doesn't answer my question - how is the buffer supposed to be
used?

> [clyde} Multiple vendors add VRF name to the server connection
> specification so that the correct routing table can be used to provide
> access the server. I am surprised that VRF is not in your best
> practice Outbound Connection pattern.

The reason is that how to handle this is ongoing work in the routing
config.  When that work, we can/need to revisit this.  But if we add
something now, there's a risk that what we do do not fit into their
work.

> [clyde] I chose 1 (perhaps naively) for those vendors that do not
> implement the file-number concept. I will be happy to change to a
> consensus number.

What happens when all files are full?  I think the text needs to
specify this.

> Juergen felt that it was important that this model support Linux
> syslog selector processing. Linux syslog adds "equals" and
> "not-equals" comparisons to the standard "equals-or-higher" severity
> comparison. This is a feature because not all implementations support
> this.

Fine, but my point is that the text needs to better explain (more
specific) how it is supposed to work.  For example it says:

          enum equals {
            description
              "This leaf specifies all messages for the specified 
               severity.";
          }

It says "This leaf", but probably mean "This value".  What exactly is
"the specified severity".

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Apr 2015 13:34:29 +0200

> digits?  It seems to me that the maximum possible facility value is

RFC 5424 essentially says that PRI is limted to the range 0 .. 191
and that

   PRI = FACILITY * 8 + SEVERITY

This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations
have more facilities, then they need to map them to on of the 24
facility values the SYSLOG protocol supports (or they do not talk
SYSLOG).

> So if we allow other facilities, shouldn't we also allow other

Since there must be a mapping if this some other proprietary logging
protocol is shipped over SYSLOG, I think it would make sense to expose
the mapping of this prorietary protocol into the SYSLOG number space.
(The SYSLOG specification is rather clear about the the limits, not
only RFC 5424 but also RFC 3164.) Anyway, since we are talking of
mapping proprietary logging protocols to SYSLOG, perhaps it makes
sense to leave this mapping for vendor augmentations?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Apr 2015 13:51:48 +0200 (CEST)

> RFC 5424 essentially says that PRI is limted to the range 0 .. 191

Aha, I didn't see the comment about the range.

I think RFC 5424 is a bit unclear.  It says:

   Facility and Severity values are not normative but often used.  They
   are described in the following tables for purely informational
   purposes.  Facility values MUST be in the range of 0 to 23
   inclusive.

It says that the facility *values* are not normative, but then that
the *values* are 0..23.

Does it means that the *interpretation* of the values is
non-normative?

> facility values the SYSLOG protocol supports (or they do not talk

Right, I have seen implementations use other names for (some of) the
24 facilities.  But it was stated that some implementations have
several hundreds of facilities.  I do not understand how that works.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Apr 2015 14:05:06 +0200

> Does it means that the *interpretation* of the values is

Yes, this is how I understand it. The interpretation listed is a
common UNIX interpretation but there could be others. The numeric
value space is however clearly fixed.
 
> several hundreds of facilities.  I do not understand how that works.

It can only work by mapping the larget set to a smaller set. For
example, my local implementation might have a specific value for an
NTP daemon and a different specific value for a cron daemon but once I
send a SYSLOG message, both might map to the numeric code 3 commonly
interpreted as "system daemons".

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Apr 2015 14:26:58 +0200 (CEST)

> interpreted as "system daemons".

The question is if this is common enough so we should support it.

If it is common and we use an enum as facility, then this syslog model
is not as useful as it could be.  Suppose an implementation has "many"
(>>23) facilities.  In this case it seems it would be useful to be
able filter on the implementation-specific facility, rather than the
standard facility.

One way to handle this is actually to use identities, but let the
vendor-specific identities be derived from the standard ones, for
example:

  module my-module {
    ...

    identity ntp {
      base syslog:daemon;
    }

    identity cron {
      base syslog:daemon;
    }
  }

This way you can filter on the very specific identity (or the
standard), and the mapping to standard facilities is well defined.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Apr 2015 15:56:24 +0200

> standard), and the mapping to standard facilities is well defined.

This is a good proposal. This requires good text to encourage vendors
to actually derive identities this way - they might by default create
their own hierarchy of identifies...

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Apr 2015 16:06:02 +0200 (CEST)

> their own hierarchy of identifies...

Right; what we want to avoid is someone deriving directly from
syslog:syslog-facility.   We can probably simply say MUST NOT do
this.  So what happens if someone does it anyway?  I think it just
means that a 3rd party client will not understand what's going on...

/martin

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Wed, 8 Apr 2015 22:28:03 +0000

Hi Martin,

My responses inline...

>Or should we allow them to configure prival 0..999?

[clyde] I like your proposal to recommend that vendor-specific identities be derived from standard ones. But they will not want to be confined to the base set of 24. therefore your proposal using a union of the enum and uint16 above seems to be the best way forward.

>as defined in 5424, or just some message format (maybe as exaplained

[clyde] Please see RFC 5424 section 6.0 Syslog Message Format. STRUCTURED-DATA augments the syslog message. ;-)

If structured data is off, the STRUCTURED-DATA portion of the syslog message is not present and everything else is present.

>My point is that the text is unclear.  But if you remove this that

[clyde] I will remove global logging.

>This doesn't answer my question - how is the buffer supposed to be

[clyde] When a high volume of syslog messages is expected, say by turning on debug level messages or during event storms, buffered logging captures message reliably until the log buffer is full when it wraps. You access the buffered log using a "show log" command which displays the messages in the buffer.

>something now, there's a risk that what we do do not fit into their

[clyde] I will remove references to VRF.

>What happens when all files are full?  I think the text needs to

[clyde] I will clarify this behavior in the description.

>"the specified severity".

[clyde] Agreed that the text can be clearer.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2015 08:23:19 +0200 (CEST)

Hi,

"Clyde Wildes (cwildes)" <[email-masked]> wrote:
> [clyde] I like your proposal to recommend that vendor-specific
> identities be derived from standard ones. But they will not want to be
> confined to the base set of 24. therefore your proposal using a union
> of the enum and uint16 above seems to be the best way forward.

But this solution does not handle the case that Juergen described,
where other facility names are mapped to the standard value space
(0..23).

I assume you mean that these vendors do not implement RFC 5424 (which
limits the facilitiy numbers to 0..23)?  Can you describe in more
detail such an implementation, and what the messages look like in such
a case?

> [clyde] Please see RFC 5424 section 6.0 Syslog Message
> Format. STRUCTURED-DATA augments the syslog message. ;-)

Well, STRUCTURED-DATA is one part of SYSLOG-MSG.

> If structured data is off, the STRUCTURED-DATA portion of the syslog
> message is not present and everything else is present.

Do you mean that if structured data is off, you want the message to
NOT follow the format defined in 5424 (i.e., NOT follow SYSLOG-MSG),
or do you mean that if structured data is off, the message is
formatted with STRUCTURED-DATA = NILVALUE?

Whatever the answer is, it needs to be specified so that an
implementor knows what to do.

Some examples might help as well.

> [clyde] When a high volume of syslog messages is expected, say by
> turning on debug level messages or during event storms, buffered
> logging captures message reliably until the log buffer is full when it
> wraps. You access the buffered log using a "show log" command which
> displays the messages in the buffer.

This needs to be specified in the text.  And my original question
remains - should this data model provide a mechanism to read this
buffer?  I think we should - or remove the buffered-logging-action.

/martin

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Thu, 9 Apr 2015 18:03:08 +0000

Hi Martin,

Answers inline...

>detail such an implementation, and what the messages look like in such

[clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a new facility code for each major software component in the system and each component uses it's own facility when creating a syslog message. The message priority is the same except that the facility ranges from ( 0 to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The question is do we want to allow vendors to extend the facility and how? I would answer yes, we should create a model that allows vendors to extend the facility.

>Some examples might help as well.

[clyde] If structured data is off, the message is formatted with STRUCTURED-DATA = NILVALUE. I will include this in the description.

>buffer?  I think we should - or remove the buffered-logging-action.

[clyde] We created a config model and oper data is not included. Typically for those vendors that support in-memory log buffers the show command defaults to the in-memory buffer if configured.

Thanks,

Clyde

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2015 20:42:03 +0200 (CEST)

"Clyde Wildes (cwildes)" <[email-masked]> wrote:
> [clyde] Yes some vendors do not follow RFC 5424 exactly - the case
> that I am talking about is when a vendor supports 0..23 and adds
> additional facilities to the list above 23. The vendor creates a new
> facility code for each major software component in the system and each
> component uses it's own facility when creating a syslog message. The
> message priority is the same except that the facility ranges from ( 0
> to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The
> question is do we want to allow vendors to extend the facility and
> how? I would answer yes, we should create a model that allows vendors
> to extend the facility.

Ok.  In this case, the model with identities might work pretty well.

If a vendor follows 5424 strictly, no additional identities are
required.

If a vendor has different names (possibly > 24), but still follow the
protocol faithfully, additional identities that map to the 24
identities can be defined.

And if a vendor doesn't follow the syslog protocol (as you describe
above), identities that derive from syslog:syslog-facility can be
defined.

So the WG needs to decide if this last use case should be supported.

> [clyde] If structured data is off, the message is formatted with
> STRUCTURED-DATA = NILVALUE. I will include this in the description.

Ok, good!

> [clyde] We created a config model and oper data is not
> included. Typically for those vendors that support in-memory log
> buffers the show command defaults to the in-memory buffer if
> configured.

But is there value in having a standard config model for this but let
vendors define proprietary mechanisms for reading the buffer?  Why not
also define a way to read the buffer?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 22:01:04 +0200

> [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a…

In a nutshell, the vendor is violating a protocol MUST. Do we have to
support implementations that violate protocol MUSTs? This is a
difficult question to answer and I think this requires input from
people who were involved in the creation of the protocol MUST.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2015 22:05:05 +0200 (CEST)

> people who were involved in the creation of the protocol MUST.

One way to handle this is to do the identity solution we discussed,
maybe even with the "MUST NOT derive directly from
syslog:syslog-facility".  The vendors that break the protocol MUST can
then break our MUST NOT and add their own facilities.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Apr 2015 13:08:32 -0700

> people who were involved in the creation of the protocol MUST.

I know it is not possible in this case, but your comment is an excellent summary
of why protocol WGs should be writing their own YANG modules, and not NETMOD WG.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 22:19:31 +0200

On Thu, Apr 09, 2015 at 01:08:32PM -0700, Andy Bierman wrote:
> I know it is not possible in this case, but your comment is an
> excellent summary of why protocol WGs should be writing their own
> YANG modules, and not NETMOD WG.

The reason we do the SYSLOG model in NETMOD is because there is no
SYSLOG WG anymore. I would be really happy if people who actively
contributed to the SYSLOG WG would be involved in the data model work
as well. At the end, getting the right people involved matters, not so
much how the WG is called. I tried to reach out to some of those
people in order to get them involved but I do also understand why they
prefer not to follow the NETMOD mailing - where most of the messages
are not related to SYSLOG.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 22:21:38 +0200

> then break our MUST NOT and add their own facilities.

This is then at least formally consistent. Whatever the reason for the
protocol MUST has been...

/js

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 13 Apr 2015 13:57:56 +0000

Hi guys,

I think part of the confusion here is that:

1) the syslog RFC is mainly concerned with describing the external on-the-wire protocol/encoding of how to carry syslog messages
2) the syslog YANG model is mainly concerned with describing distributors and filtering within a node

Those are not the same things.

None of the "Message Producers", "Message Distributors" and syslog selector/filtering from the YANG model is covered in the RFC. The YANG model is trying to capture common implementations of internal node log event filtering and distribution.

Many implementations filter on their internal equivalent of "facility" (which may or may not be called facility).  We need to allow that in this YANG model - that is one of the main things this model is trying to normalize.

When a "remote" action/distributor is used that is really where RFC 5424 comes into play.  The messages that go to a remote syslog collector do need to conform to RFC 5424. Implementations use a variety of methods to map internal facility/severity to the external RFC 5424 format and values. For the facility field some implementations simply stamp every log event for a given remote destination with a fixed RFC 5424 facility value.  That is what the "leaf destination-facility" is for in the model.   Other implementations may map internal facilities to RFC 5424 facilities (or just use purely RFC 5424 facility values internally and externally with no mapping required).

I think we should just standardize the 0..23 RFC 5424 facility values as identities and let vendors augment and use those augmentations at minimum in the filtering/syslog-selector.  It can then be vendor-specific (with augmentation) if a vendor needs to add some more complex configurable mapping (besides the "leaf destination-facility" which is common enough to leave in).

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, April 09, 2015 4:22 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt

On Thu, Apr 09, 2015 at 10:05:05PM +0200, Martin Bjorklund wrote:
> > In a nutshell, the vendor is violating a protocol MUST. Do we have 
> > to support implementations that violate protocol MUSTs? This is a 

This is then at least formally consistent. Whatever the reason for the protocol MUST has been...

/js

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 13 Apr 2015 14:02:39 +0000

Hi guys,

A few comments below with [>>JTS].

Regards,
Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Clyde Wildes (cwildes)
Sent: Tuesday, April 07, 2015 5:59 PM
To: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt

Martin,

Thanks for your review!

[>>JTS] Agree - let's remove it especially if it is not prevalent. Current deployments likely use SNMP notifications if they need structured information and the industry longer term is probably more likely to focus on NETCONF based notifications rather than further evolution of syslog.

[>>JTS] This is a somewhat confusing mix of meaning for <none>.  In the global filter it means let everything through.  For console are we saying it means block everything ?  We need to also clarify (for global & distributors) what the absence of any selector means (vs <none>).

[>>JTS] I think these are just intended to be circular queues that an operator can request to view (in CLI and we should also make them viewable in NETCONF via <get>).  They don't feed any other distributor so I don't think they really have anything to do with mitigating event storms or event loss (if an operator doesn't look at them for a while then some of the older events will always be overwritten).  It is just a "pull" method for an operator to be able to access recent log events (without having them pop up on their terminal session - i.e. "push").

[>>JTS] Some implementations that support this do it globally rather than per distributor.  If we want to leave this in can we make it global (that can easily be supported by implementations that have either per distributor or global) ?  

[>>JTS] I really don't think this is done in a common enough way to put into the base standard model.

[clyde] Agreed.

[clyde] Agreed.

Thanks,

Clyde