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

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 14 Feb 2017 13:31:26 +0000

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&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff

Please review and comment.

Thanks,

Clyde

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman <[email-masked]>
Cc: Alex Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Any

My comments inline as [clyde2]…

From: Andy Bierman <[email-masked]>
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)" <[email-masked]>
Cc: Alex Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks for taking the time to review the model.

My comments are inline as [clyde]…

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell <[email-masked]>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-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.

The filter is based on an identityref, which is a module-qualified name,
e.g., acme:foo-facility and example:foo-facility are different entities.
In the syslog message, only the string foo-facility will be present.
The draft claims to provide extensible facilities,(see A.1)  but it only
seems to work if the identities do not contain any duplicates.

[clyde2] In my experience looking at multiple vendor implementations I did not see any duplicates. If you have a suggestion on another way to extend facilities, I am all ears.

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 support all the options.  Can't this be simplified
   and all the micro-behavior YANG features removed?

[clyde] This was designed by merging the requirements from several vendors. All of the variants specified are with if-feature so that the client does not have to support all options.

There seems to be some procedures implied by these YANG objects,
but it is not specified.

The 4 different methods (each with its own feature), are in a container.
Since container 'file-rotation' is in list 'log-file', the rotation variant
can be different for every file.  Is this really how implementations work?

[clyde2] We consolidated the requirements from multiple vendors.

Juniper log file archiving is available via a global setting or on an individual file – both number of files and file size are supported. See https://www.juniper.net/documentation/en_US/junos12.3/information-products/topic-collections/syslog-messages/index.html?jd0e921.html

Cisco log file archiving is specified for an individual file. File size and optionally a hard code maximum number of bytes set aside for logging or a percent of total disk space available for logging may be specified.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/command/esm-cr-book/esm-cr-a1.html#wp8708534740

Alcatel-Lucent log file archiving is specified for an individual file and supports rollover in minutes and retention in hours.
https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0071-10-01/7750_SR_OS_System_Management_Guide/Logcli.html#1038301

The server is free to support from none to all of the archiving features (note: they are specified as features).

Also, the different parameters in this container can interact if the server
supports more than 1 feature.  The draft does not say anything about
combining them.

E.g.:

           leaf number-of-files {

              if-feature file-limit-size;

              type uint32;

              description

                "This leaf specifies the maximum number of log

                 files retained. Specify 1 for implementations

                 that only support one log file.";

            }

How does the client know if the server only supports 1 file or not?
This should really be revisions, since these files are per log-file list entry.

[clyde2] Make the default 1?

If only 1 revision of the log-file is retained, then the meaning of the other
leafs is unclear. If there is only 1 log-file revision, then what happens
if the max-file-size # of megabytes, rollover # of minutes, or retention # of hours
is reached?  Does syslog monitoring stop for the log-file entry?

[clyde2] If one log-file is specified and max-file-size is specified, the single file is overwritten when max-file-size limit is encountered.

How does the client access different revisions of the log file? Or even list them?
How does the client know the current size of lifetime of the log-file
They do not have names. Is it assumed they will be the log-file/name field
appended with ".1", ".2", etc.?

[clyde2] There is no attempt to support oper data in this model.

Thanks,

Clyde
10) numeric limits: there is some odd usage of YANG types; some limits are uint64, some uint32,
some uint16.  Seems like uint32 is sufficient

[clyde]  The signing-options counts are as per the syslog-sign spec (RFC 5848) which is uint16. I will make all others uint32 except for the buffer size limit which I will leave at unit64.

Result:
<seven signing-options counters> uint16
buffer-limit-bytes uint64
buffer-limit-messages uint32 (was formally uint64)
number-of-files uint32
max-file-size uint32 (was formally uint64)
rollover unit32
retention unit32 (was formally uint16)

Thanks,

Clyde

Andy

Andy

On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <[email-masked]<mailto:[email-masked]>> 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.

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

* What is the behaviour of a selector if neither "no-facilities" nor "facility-list" is present?
* 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?
* Not all servers have a console; there should be a feature to indicate whether logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative.
* It's not clear to me why this needs to be split into two modules. Is it so that other modules can define logging parameters but still be usable on a device without syslog?
* "log-severity" defines a severity filter, not a severity, so its name is misleading.
* Perhaps the "severity" type and the facility identities should have "reference" statements referring to RFC 5424, rather than referring to it in the description.
* In section "8.2", "admisintrator" is a typo.

I assume that the means of accessing the memory buffer and log files are out of scope of this data model.

Alex

________________________________________
From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 14 December 2016 2:01 p.m.
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

This is a notice to start a two-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-11

Please indicate your support or concerns by Tuesday, December 27, 2016.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Feb 2017 21:28:57 +0000

Thanks for the update you Clyde!

Alex/Andy, since this update was made per comments you made during Last Call, can you please confirm that it does indeed address your concerns, and doesn't add any new ones?

Thanks,
Kent

On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks,

Clyde

Any

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Alex Campbell <[email-masked]>
Date: Tue, 21 Feb 2017 21:35:45 +0000

I can confirm that this new draft addresses my concerns and doesn't add any new ones.

________________________________
From: Kent Watsen <[email-masked]>
Sent: Wednesday, 22 February 2017 10:28 a.m.
To: Clyde Wildes (cwildes); [email-masked]
Cc: Andy Bierman; Alex Campbell
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Thanks,
Kent

Hi,

Thanks,

Clyde

Any

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Feb 2017 15:10:11 -0800

Hi,

Lots of improvement.
Just some minor details I noticed...

SYSLOG-MSG field:  RFC 5424 is mentioned in the 2nd usage, not the first.
Should be a citation --  SYSLOG-MSG field [RFC5424]

Page header says 'Abbreviated Title' (the template placeholder text).
I suggest 'Syslog Management' (consistent with RFC 8022)

p5:

The severity is one of syslogtypes:severity

perhaps:

The severity is one of: type "syslogtypes:severity"

Actions are to log

perhaps:

Actions are used to log

Andy

On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen <[email-masked]> wrote:

> Alex/Andy, since this update was made per comments you made during Last
> Call, can you please confirm that it does indeed address your concerns, and
> doesn't add any new ones?
>
>
>
> Thanks,
>
> Kent
>
>
>
> On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> 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.
>
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-
> model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff
>
>
>
> *From: *"Clyde Wildes (cwildes)" <[email-masked]>
> *Date: *Wednesday, January 11, 2017 at 2:54 PM
> *To: *Andy Bierman <[email-masked]>
> *Cc: *Alex Campbell <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
>
>
>
> Any
>
>
>
> *From: *Andy Bierman <[email-masked]>
> *Date: *Saturday, December 31, 2016 at 8:24 AM
> *To: *"Clyde Wildes (cwildes)" <[email-masked]>
> *Cc: *Alex Campbell <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *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) <
> [email-masked]> wrote:
>
> Hi Andy,
>
>
>
> *From: *netmod <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> *Date: *Tuesday, December 27, 2016 at 3:04 PM
> *To: *Alex Campbell <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
>
>
>
> Hi,
>
>
>
> [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.
>
>
>
> [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.
>
>
>
>
>
> [clyde2] I will remove the buffer and session actions in the next draft
> and will make the remaining three features.
>
>
>
>
>
> [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.
>
>
>
> [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
>
> [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.
>
>
>
>
>
>
>
> [clyde2] In my experience looking at multiple vendor implementations I did
> not see any duplicates. If you have a suggestion on another way to extend
> facilities, I am all ears.
>
>
>
> [clyde] This was designed by merging the requirements from several
> vendors. All of the variants specified are with if-feature so that the
> client does not have to support all options.
>
>
>
>
>
> Juniper log file archiving is available via a global setting or on an
> individual file – both number of files and file size are supported. See
> https://www.juniper.net/documentation/en_US/junos12.3/
> information-products/topic-collections/syslog-messages/
> index.html?jd0e921.html
>
>
>
> Cisco log file archiving is specified for an individual file. File size
> and optionally a hard code maximum number of bytes set aside for logging or
> a percent of total disk space available for logging may be specified.
>
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/
> command/esm-cr-book/esm-cr-a1.html#wp8708534740
>
>
>
> Alcatel-Lucent log file archiving is specified for an individual file and
> supports rollover in minutes and retention in hours.
>
> https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-
> 0071-10-01/7750_SR_OS_System_Management_Guide/Logcli.html#1038301
>
>
>
> [clyde2] If one log-file is specified and max-file-size is specified, the
> single file is overwritten when max-file-size limit is encountered.
>
>
>
> [clyde]  The signing-options counts are as per the syslog-sign spec (RFC
> 5848) which is uint16. I will make all others uint32 except for the buffer
> size limit which I will leave at unit64.
>
>
>
> Result:
>
> On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <[email-masked]>
> wrote:
>
> 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.
>
> * 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
>   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.
> * In the "selector" grouping it is not clear how the facility and pattern
> conditions are combined to decide whether a message is selected.
> * Not all servers have a console; there should be a feature to indicate
> whether logging to the console is supported.
> * It's not clear to me why this needs to be split into two modules. Is it
> so that other modules can define logging parameters but still be usable on
> a device without syslog?
> * Perhaps the "severity" type and the facility identities should have
> "reference" statements referring to RFC 5424, rather than referring to it
> in the description.
> From: netmod <[email-masked]> on behalf of Kent Watsen <
> [email-masked]>
> To: [email-masked]
> [email-masked]
> [email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Feb 2017 03:45:31 +0000

Authors,

I was asked to do another YANG Doctor review on this module (in addition to
Juergen's review back in 2015), and I'm also the shepherd for this draft, so I
decided to give the draft a fresh reading and had some preliminary questions
(i.e., this is neither a doctor-review or a shepherd-review).  I'm sending this to
you now, as I know that you plan to put out an update shortly to address Andy's
most recent comments.

S2, last paragraph, is "conceptual layer" a term in 5424?  If so, then make that
more obvious.  If not, then this sentence should be reworded to be more clear.

S3, P2: s/The base model/This base model/ or just "This model"?  Same issue
just below Figure 1 (aside: should 'actions' be in quotes here?)

S3, last paragraph, should "disable a facility" actually be "disable a filter", as it
says in the YANG description statement?

S4: Please remove the four "WG Chair" lines from the two modules.

S4:  Can you explain why there are two separate modules?  - does the
types module need to be imported by any future module?  I see, SA.1, but
this could be done as well with a single module.  If there really is a need,
then perhaps explain it in the draft?

S4:  Noticing the "signing-options" container.  My first question was why
isn’t something related to this in the security considerations section, but
then I noticed that this module doesn't configure certificates or configure
which signature blocks go to which collectors.  Is this really fleshed out
completely?  Perhaps we should remove the signing-options container
(and signed-messages feature)?

S8.1 and S8.2: as written, these don't seem like "security considerations", maybe
they should go into Appendix A (implementor [sic] guidelines)?

Kent // pick a hat

On 2/21/17, 6:10 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Lots of improvement.

p5:

perhaps:

Actions are to log

perhaps:

Actions are used to log

Andy

On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the update you Clyde!

Thanks,
Kent

Hi,

Thanks,

Clyde

From: "Clyde Wildes (cwildes)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: Alex Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Any

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)" <[email-masked]<mailto:[email-masked]>>
Cc: Alex Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 23 Feb 2017 19:10:50 +0000

Hi,

I am no an author, but I do have an opinion regarding the signed-messages feature.

IMHO, this is something that  needs to be definitely included as part of the draft.  Syslog signing is a part of the suite of IETF standards-track RFCs geared towards syslog.  Quite simply, I don’t think the YANG model would be complete without it.   In short, don’t remove this from the YANG data model draft.

RFC 5848 section 6.1 actually calls out the parameters that make sense for an implementation to make configurable, which are the ones supported in the model.  Now, it is certainly possible to introduce more.  It is conceivable for sign messages to go to a separate collector as you mention; however, in general they will go towards the same collector even although they will be used by a separate verification process used to verify and authenticate the other (non-sign) messages.  Section 7 in RFC 5848 describes all this in detail.

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, February 22, 2017 7:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Authors,

Kent // pick a hat

Hi,

Lots of improvement.

p5:

perhaps:

Actions are to log

perhaps:

Actions are used to log

Andy

Thanks,
Kent

Hi,

Thanks,

Clyde

Any

To: Alex Campbell <[email-masked]<mailto:[email-masked]>>

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Feb 2017 21:11:36 +0000

Thanks Alex, that was helpful.

So then:
- should the "signing-options" description statement mention "Section 6.1"?
- should the leafs not starting with "cert-" start with "sig-", to better match section 6.1?

Again, is there not a need to configure a private key to do the signing and/or the certificate to send?   Recall, we took out the TLS transport from this draft because the model didn't support being able to configure similar things...

Thanks,
Kent

On 2/23/17, 2:10 PM, "Alexander Clemm" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

--- Alex

Authors,

Kent // pick a hat

Hi,

Lots of improvement.

p5:

perhaps:

Actions are to log

perhaps:

Actions are used to log

Andy

Thanks,
Kent

Hi,

Thanks,

Clyde

Any

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 23 Feb 2017 22:09:34 +0000

Hi Kent,

Responses inline

Cheers
--- Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Thursday, February 23, 2017 1:12 PM
To: Alexander Clemm <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

So then:

<ALEX> RFC 5848 is mentioned already, so not sure if this is strictly speaking necessary, but if you want this to be as specific possible, sure.  </ALEX>

<ALEX> No, that would actually match less and be misleading.   The parameters mentioned in 6.1.1 refer to configuration parameters for certificate blocks, and are accordingly prefixed “cert”.  The parameters mentioned in 6.1.2 are related to Signature Blocks and are accordingly prefixed with “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount).  So, you might actually want to consider prefixing max-delay, number-resends, resend-delay, and resend-count with“sig-“. </ALEX>

<ALEX> I don’t really have an opinion on this one, but I don’t think this is needed.  I would not include it (but if you did, you would need to accommodate for the possibility of having not just one but possibly multiple signers on the same host, which is explicitly supported.)

The signer simply announces key blob and  key blob type being used ,  one of the following types:
Key Blob Type, a one-octet field containing one of five values:

       1.  'C' -- a PKIX certificate (per [RFC5280<https://tools.ietf.org/html/rfc5280>]).

       2.  'P' -- an OpenPGP KeyID and OpenPGP certificate (a
           Transferable Public Key as defined in [RFC4880<https://tools.ietf.org/html/rfc4880>], Section<https://tools.ietf.org/html/rfc5848#section-11.1>
           11.1<https://tools.ietf.org/html/rfc5848#section-11.1>).  The first 8 octets of the key blob field contain the
           OpenPGP KeyID (identifying which key or subkey inside the
           OpenPGP certificate is used), followed by the OpenPGP
           certificate itself.

       3.  'K' -- the public key whose corresponding private key is
           being used to sign these messages.  For the OpenPGP DSA
           signature scheme, the key blob field contains the DSA prime
           p, DSA group order q, DSA group generator g, and DSA public-
           key value y, encoded as 4 multiprecision integers (see
           [RFC4880<https://tools.ietf.org/html/rfc4880>], Sections 5.5.2<https://tools.ietf.org/html/rfc5848#section-5.5.2> and 3.2<https://tools.ietf.org/html/rfc5848#section-3.2>).

       4.  'N' -- no key information sent; key is pre-distributed.

       5.  'U' -- installation-specific key exchange information.

Syslog-sign does not specify how these types got there and what key material they used.  Now, if you wanted to manage that as well, sure, but now you would be getting into TLS territory as you mention and I would think this should be kept outside the scope.

HTH
</ALEX>

Thanks,
Kent

Hi,

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, February 22, 2017 7:46 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Authors,

Kent // pick a hat

Hi,

Lots of improvement.

p5:

perhaps:

Actions are to log

perhaps:

Actions are used to log

Andy

Thanks,
Kent

Hi,

Thanks,

Clyde

Any

Hi,

Some detailed comments:

  /console
  /file
  /remote

    container selector {

      description

         for syslog.";

      list facility-list {

        key facility;

        description

        leaf facility {

          type union {

            type identityref {

            }

            type enumeration {

              enum all {

                description

              }

            }

          }

          description

        }

        uses log-severity;

      }

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

5) pattern-match:

      leaf pattern-match {

        if-feature select-match;

        type string;

        description

           SYSLOG-MSG field.";

      }

E.g.:

           leaf number-of-files {

              type uint32;

              description

            }

Thanks,

Clyde

Result:

Thanks,

Clyde

Andy

Andy

     description

Alex

As well as:

Thank you,
NETMOD WG Chairs

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Feb 2017 22:51:48 +0000

> <ALEX> No, that would actually match less and be misleading.   The parameters mentioned in 6.1.1
> refer to configuration parameters for certificate blocks, and are accordingly prefixed “cert”.  The
> parameters mentioned in 6.1.2 are related to Signature Blocks and are accordingly prefixed with
> “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount).  So, you might
> actually want to consider prefixing max-delay, number-resends, resend-delay, and resend-count
> with“sig-“. </ALEX>

Exactly, we agree.   These were the leafs I meant by "not starting with 'cert-' ".

> Syslog-sign does not specify how these types got there and what key material they
> used.  Now, if you wanted to manage that as well, sure, but now you would be getting
> into TLS territory as you mention and I would think this should be kept outside the
> scope.

That Syslog-sign doesn't specify this is a good response as well.  But answer
me honestly, isn't it something that a device would have to have configured
and, if so, wouldn't it make most sense for that configuration to be in this
module?

FWIW, I don't think that it's TLS-territory so much as keystore-territory.

Thanks,
Kent        // shepherd

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 23 Feb 2017 23:36:16 +0000

Hi Kent

More responses, <ALEX>

--- Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Thursday, February 23, 2017 2:52 PM
To: Alexander Clemm <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

<ALEX>
Ah, okay.  Yes, we agree; I misunderstood your earlier sentence.
</ALEX>

<ALEX>
True, this is keystore territory, and I don’t think this should venture in that direction – the can be considered clearly out of scope.
However, what would actually make sense would be to offer a configuration option that clearly states which of the signature options (and signing material) should be used.    Clearly the ability to configure this will be needed.

If you want to accommodate this, you probably need to consider another modification to the model:  It is conceivable that there could be multiple signers, and different signers might each use a different option.  Therefore, to allow for differentiation by signer, you might want to consider introducing a corresponding parameter under a list of signers.  (You could even move the configuration parameters into this list, although frankly I would opt to keep those parameters global (and the use of the model simple), not per-signer.)
</ALEX>

Thanks,
Kent        // shepherd

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Feb 2017 00:13:22 +0000

> <ALEX>
> True, this is keystore territory, and I don’t think this should venture in that direction – the [sic]
> can be considered clearly out of scope.

Why would it be out of scope?  Seems like this is actually what you might want given what you
wrote below...

> However, what would actually make sense would be to offer a configuration option that
> clearly states which of the signature options (and signing material) should be used.
> Clearly the ability to configure this will be needed.

I think I agree here but, if I understand you correctly, wouldn't this be best accomplished
via references to keystore keys/certificates?

> If you want to accommodate this,

Actually, I'm just probing the issue.  I was hoping the response was going to be "this was discussed
by the working group here: <link to email-thread>" and we could move on.   But since that does
not seem to be the case, it would be good for the WG (not me) to decide if we want/need to
accommodate this.  What do people think?

Options:
  a) leave as is (and document the shortcoming)
  b) remove signing-options (add back later when ready)
  c) address the issue now

> you probably need to consider another modification to the model:  It is conceivable that there
> could be multiple signers, and different signers might each use a different option.  Therefore, to
> allow for differentiation by signer, you might want to consider introducing a corresponding
> parameter under a list of signers.  (You could even move the configuration parameters into this
> list, although frankly I would opt to keep those parameters global (and the use of the model
> simple), not per-signer.)

True, and potentially a reason to not go with (a) as, with that option, it may not
be easy to add in this kind of flexibility later in a backwards-compatible manner.

Thanks,
Kent        // shepherd

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 24 Feb 2017 00:25:22 +0000

Hi Kent,

I would think option c is the preferable option.  And I agree with your implied suggestion to accomplish this via references to the keystore.

Option a could be a less-preferred-still-acceptable alternative.  The case with multiple signers is a true corner case.

I don’t think b is acceptable, frankly.
--- Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Thursday, February 23, 2017 4:13 PM
To: Alexander Clemm <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Options:

Thanks,
Kent        // shepherd