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

From: [email-masked]
Date: Fri, 12 Jan 2018 14:58:14 -0800

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-19.txt
	Pages           : 35
	Date            : 2018-01-12

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  "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft-
      ietf-netconf-keystore

   o  "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value
      for draft-ietf-netconf-tls-client-server

   o  "zzzz" --> 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-19
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-19

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

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/

---

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Jan 2018 16:59:04 +0000

Clyde,

This draft still isn't passing idnits.  I provided the link to idnits previously, but here it is again: https://www.ietf.org/tools/idnits.  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://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

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

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

  -- The document date (January 12, 2018) is 4 days in the past.  Is this
     intentional?

Kent: this is fine, it is intentional.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1386,
     but no explicit reference was found in the text

Kent: looking at the XML, I see that the entire paragraph uses '[' and ']' as opposed to <xref .../>.  Please fix this.

  == Unused Reference: 'RFC7895' is defined on line 1456, but no explicit
     reference was found in the text

Kent: looking at the XML, I see two instances of an unwanted "/&gt;" string.  For instance: <xref target="RFC7895"/>/&gt;  Please fix this.

  ** Downref: Normative reference to an Historic RFC: RFC 6587

Kent: hmmm, what's going on here?  This YANG module is providing an ability to configure the "tcp" transport, even though the IESG made that ability historic in 2012 (see IESG Note below).  Searching online, it looks like Cisco supports this, but Juniper does not.  What about other vendors, is it widely supported?  Was this discussed in the WG?  Answering my own question, searching my local mailbox, I don't see this ever being discussed before, other than Martin questioning if it was a good idea in Mar 2016 (no response).  Please start a thread on the list to get WG opinion if it's okay for the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:

   IESG Note

   The IESG does not recommend implementing or deploying syslog over
   plain tcp, which is described in this document, because it lacks the
   ability to enable strong security [RFC3365].

   Implementation of the TLS transport [RFC5425] is recommended so that
   appropriate security features are available to operators who want to
   deploy secure syslog.  Similarly, those security features can be
   turned off for those who do not want them.

     Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
===== END =====

Thanks,
Kent // shepherd

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Jan 2018 18:23:47 +0100

Hi,
>     turned off for those who do not want them.
Well, I believe it's clear plain TCP should not be in the YANG module.

Regards, Benoit

---

From: Alex Campbell <[email-masked]>
Date: Tue, 16 Jan 2018 21:46:20 +0000

By the same reasoning surely UDP should not be available either, because it also doesn't provide security.
________________________________________
From: netmod <[email-masked]> on behalf of Benoit Claise <[email-masked]>
Sent: Wednesday, 17 January 2018 6:23 a.m.
To: Kent Watsen; [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Hi,

Regards, Benoit

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

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 17 Jan 2018 02:07:18 +0000

IMHO, if this module is supposed to be useful in practice, without requiring immediately proprietary augmentations, UDP needs to be supported.  RFC 5424 also states that implementations SHOULD support a UDP transport per RFC 5426.  

Whether TCP support should be included is debatable because not a standard transport.  Perhaps it should not, however given that it has already been specified, I don't think it hurts to have it as a feature/option for implementations that require it.  
--- Alex

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Alex
> Campbell
> Sent: Tuesday, January 16, 2018 1:46 PM
> To: Benoit Claise <[email-masked]>; Kent Watsen
> <[email-masked]>; [email-masked]
> > Kent: hmmm, what's going on here?  This YANG module is providing an
> ability to configure the "tcp" transport, even though the IESG made that
> ability historic in 2012 (see IESG Note below).  Searching online, it looks like
> Cisco supports this, but Juniper does not.  What about other vendors, is it
> widely supported?  Was this discussed in the WG?  Answering my own
> question, searching my local mailbox, I don't see this ever being discussed
> before, other than Martin questioning if it was a good idea in Mar 2016 (no
> response).  Please start a thread on the list to get WG opinion if it's okay for
> the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:
> >
> >     IESG Note
> >

---

From: Kent Watsen <[email-masked]>
Date: Wed, 17 Jan 2018 16:35:12 +0000

Hi Clyde,

One quick follow-up, it seems that all drafts are moving over to reference the tree-diagrams draft these days.  As such, I think Section 1.3 (Tree Diagram Notation) should now be removed and Section 3.1 should change as follows:

  OLD
  Please see Section 1.3 for tree diagram notation.

  NEW
  Please see [I-D.ietf-netmod-yang-tree-diagrams] for tree diagram notation.
  (yes, that should be hyperlink)

and add I-D.ietf-netmod-yang-tree-diagrams as an Informative reference.

Thanks,
Kent

===== original message =====

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&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=FErz5G2HICKnT_lI6gedg7ni66XCMBrj756eh-lXdW0&e=.  Below is the idnits output for -19 with inlined comments.

Kent

===== START =====
idnits 2.15.00 

  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&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=X00_D6mS_CYdDDM_LABw-a_uhQziwjSvaaz8UHC6Nc0&e=):
  ----------------------------------------------------------------------------

     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&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=U9PqY8kpdbwz_sL4a1DhBJagSvEx9sv9zZquldhed7U&e=:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=K833IRzwN3sBZr2ApmQYRHjvSmKHOhNjY4JQ2mUEm18&e= :
  ----------------------------------------------------------------------------

  Miscellaneous warnings:

   IESG Note

Thanks,
Kent // shepherd

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo&s=etLxOIrgGaAD30-UmDGkrdfiVvY7AsD2GQ8szCkUChk&e=

---

From: Kent Watsen <[email-masked]>
Date: Wed, 17 Jan 2018 17:13:34 +0000

> IMHO, if this module is supposed to be useful in practice, without
> requiring immediately proprietary augmentations, UDP needs to be
> supported.  RFC 5424 also states that implementations SHOULD
> support a UDP transport per RFC 5426.  

Agreed.

> Whether TCP support should be included is debatable because not a
> standard transport.  Perhaps it should not, however given that it
> has already been specified, I don't think it hurts to have it as
> a feature/option for implementations that require it.  

Given the IESG statement (copied below) and the HISTORIC downref, I
think that this would be a hard sell.  But, if it turns out that
most vendors support RFC 6587, then a case could be made for it.

Kent

---

From: "t.petch" <[email-masked]>
Date: Wed, 24 Jan 2018 16:46:52 -0000

Kent

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

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: <[email-masked]>
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://www.ietf.org/tools/idnits.
Below is the idnits output for -19 with inlined comments.
>   Checking nits according to
https://www.ietf.org/id-info/1id-guidelines.txt:
> 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 ignore it.
> Kent: looking at the XML, I see that the entire paragraph uses '[' and
']' as opposed to <xref .../>.  Please fix this.
> Kent: looking at the XML, I see two instances of an unwanted "/&gt;"
string.  For instance: <xref target="RFC7895"/>/&gt;  Please fix this.
ability to configure the "tcp" transport, even though the IESG made that
ability historic in 2012 (see IESG Note below).  Searching online, it
looks like Cisco supports this, but Juniper does not.  What about other
vendors, is it widely supported?  Was this discussed in the WG?
Answering my own question, searching my local mailbox, I don't see this
ever being discussed before, other than Martin questioning if it was a
good idea in Mar 2016 (no response).  Please start a thread on the list
to get WG opinion if it's okay for the draft to proceed as is or not.