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

[Alex Campbell]

Hi,

Perhaps not directly relevant, but the following sentence stuck out to me:

> Why not use the syslog/TLS specification, with the security features 
> administratively turned off within secure environments?

I was under the impression that the IETF tries to ensure that TLS security is 
not possible to turn off.
The assumption within the people working on TLS is that if you don't want 
security, you won't be using TLS.


I can think of two main reasons why syslog/TLS might not be desirable
- it adds administrative overhead - now you have to upload a certificate to 
every device that can send log messages (embedded devices don't use the Web's 
PKI).
- it adds runtime overhead - while general purpose devices these days are 
plenty fast to handle TLS, embedded devices may not be.


If TCP support is removed from the syslog model, then Aviat will most likely 
add it back as a vendor-specific extension, when we adopt this model.
I see the model is easily extensible with new transports so this will not be a 
problem - the only question is whether the extension should be standardized.
A quick Google search shows me that (at least some) Cisco and Juniper devices 
do support syslog/TCP, but it isn't widely used compared to UDP.


Alex


From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen 
<kwat...@juniper.net>
Sent: Saturday, 10 February 2018 5:42 a.m.
To: t.petch; Clyde Wildes (cwildes); netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Thank you, Tom.  That's an interesting bit of history there.  Of course, you 
would know, as I see you listed in the Acknowledgments section in RFC 6587.  
David Harrington's points are very compelling.

The chairs want to get this draft to Benoit before he steps down.  But looking 
at the draft right now, I can see that it is a very easy fix to remove the TCP 
transport layer support entirely, not much more than just moving the reference 
to Informative.

So, yes, let's bin it.

FWIW, I asked before if it were important to anyone, giving them a chance to 
speak up first.  But now, given how easy I see the fix is, that we should 
remove it without waiting for an answer.  If it is important to someone, let 
them speak up now.

Clyde, please let this be the update you plan to post today.

Thanks,
Kent // all hats


= original message =

Kent

The TCP syslog started out as Standards Track, after the syslog WG had
concluded, but David Harrington objected, as the extract below shows,
that it would never pass the IESG; and so it became Informational.

Further, the author, in 2013, described it as

"there is also historic RFC6587 on industry standard plain tcp, but this
is just for interoperating with legacy systems, not for new
implementation. It is strongly discouraged to use that in new systems.
"

Bin it IMHO.

Tom Petch
==


Many of the changes were made at my request.
I believe the document as written would not have made it through IESG
approval.

1) the IETF has defined a standard syslog; how to make your legacy
proprietary version work is not an IETF problem.

2) the syslog WG was created to develop a secure syslog solution with
secure transport and signing capability.
How to make your legacy proprietary version work over non-secure
transport is not an IETF problem.

3) Publishing this as a proposed standard seems to violate BCP 61.
syslog/tls already provides "strong security" over tcp, so syslog/tcp
is not needed to meet IETF goals. Under what
circumstances is it **desirable** to use this specification (with no
strong security available) in the Internet? Why not use the syslog/TLS

specification, with the security features administratively turned off
within secure environments?
You cannot justify implementing this by saying things like
"syslog/TLS is required and this is optional", and not explain WHY
this
additional non-bcp61-compliant specification is needed.

4) The aim of this IETF specification should be to document "how TCP
MAY be used as a
transport for standardized syslog", when the standard secure transport
may not apply.
(But I expect serious pushback from the IESG on this; see #3)
Because this might have to work with legacy deployments, we also
include as an appendix
"how to correlate the legacy and standard usages."

5) RFC3164 is just a survey, not a specification.

6) RFC2119 language needed to be cleaned up.

David Harrington
Director, IETF Transport Area
ietf...@comcast.net (preferred for ietf)
dbharring...@huaweisymantec.com
+1 603 828 1401 (cell)

> -Original Message-
> From: syslog-boun...@ietf.org
> [mailto:syslog-boun...@ietf.org] On Behalf Of t.petch
> Sent: Tuesday, November 02, 2010 1:02 AM
>
> Chris
>
> I had not noticed before but this seems to have changed
> direction during the
> summer; Informational not Standard

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

[Kent Watsen]

Thank you, Tom.  That's an interesting bit of history there.  Of course, you 
would know, as I see you listed in the Acknowledgments section in RFC 6587.  
David Harrington's points are very compelling.

The chairs want to get this draft to Benoit before he steps down.  But looking 
at the draft right now, I can see that it is a very easy fix to remove the TCP 
transport layer support entirely, not much more than just moving the reference 
to Informative.

So, yes, let's bin it.  

FWIW, I asked before if it were important to anyone, giving them a chance to 
speak up first.  But now, given how easy I see the fix is, that we should 
remove it without waiting for an answer.  If it is important to someone, let 
them speak up now.

Clyde, please let this be the update you plan to post today.

Thanks,
Kent // all hats


= original message =

Kent

The TCP syslog started out as Standards Track, after the syslog WG had
concluded, but David Harrington objected, as the extract below shows,
that it would never pass the IESG; and so it became Informational.

Further, the author, in 2013, described it as

"there is also historic RFC6587 on industry standard plain tcp, but this
is just for interoperating with legacy systems, not for new
implementation. It is strongly discouraged to use that in new systems.
"

Bin it IMHO.

Tom Petch
==


Many of the changes were made at my request.
I believe the document as written would not have made it through IESG
approval.

1) the IETF has defined a standard syslog; how to make your legacy
proprietary version work is not an IETF problem.

2) the syslog WG was created to develop a secure syslog solution with
secure transport and signing capability.
How to make your legacy proprietary version work over non-secure
transport is not an IETF problem.

3) Publishing this as a proposed standard seems to violate BCP 61.
syslog/tls already provides "strong security" over tcp, so syslog/tcp
is not needed to meet IETF goals. Under what
circumstances is it **desirable** to use this specification (with no
strong security available) in the Internet? Why not use the syslog/TLS

specification, with the security features administratively turned off
within secure environments?
You cannot justify implementing this by saying things like
"syslog/TLS is required and this is optional", and not explain WHY
this
additional non-bcp61-compliant specification is needed.

4) The aim of this IETF specification should be to document "how TCP
MAY be used as a
transport for standardized syslog", when the standard secure transport
may not apply.
(But I expect serious pushback from the IESG on this; see #3)
Because this might have to work with legacy deployments, we also
include as an appendix
"how to correlate the legacy and standard usages."

5) RFC3164 is just a survey, not a specification.

6) RFC2119 language needed to be cleaned up.

David Harrington
Director, IETF Transport Area
ietf...@comcast.net (preferred for ietf)
dbharring...@huaweisymantec.com
+1 603 828 1401 (cell)

> -Original Message-
> From: syslog-boun...@ietf.org
> [mailto:syslog-boun...@ietf.org] On Behalf Of t.petch
> Sent: Tuesday, November 02, 2010 1:02 AM
>
> Chris
>
> I had not noticed before but this seems to have changed
> direction during the
> summer; Informational not Standards Track, and stressing
> byte-counting more,
> byte-stuffing less.
>
> I do find it less clear.  I think that the Introduction needs
> more work in the
> light of the changes to the rest of the document. I read
> "This specification includes descriptions of both
>format options in an attempt to ensure that standardized syslog
>transport receivers can receive and properly interpret
> messages sent
>from legacy syslog senders."
> got to the end of the document and thought 'oh no it does
> not!' and then
> realised that this is now an Appendix whereas before it was
> in the main body.
> Of course, if you never knew it was in the body, you might
> not be as confused as
> I.
>
> But really, the emphasis on standardised and legacy syslog
> seems misplaced.  The
> carriage over TCP is the same whether the carried is
> SYSLOG-3164 or SYSLOG-MSG
> so the distinction seems spurious.  And SYSLOG-3164 does not
> appear in any RFC
> or I-D I can find.
>
> Rather, you have two forms of adaptation to carry a message,
> and what that
> message is is mostly academic.
>
> Separately, I think that more is needed on Security.  It is
> easier to sabotage
> TCP than it is UDP; spurious FIN, RST etc.
>
> And I think more is needed on closing the session.  The
> transport receiver
> detects a format error (well, the transport sender is not
> going to) sends FIN,
> gets FIN-ACK and   the transport sender carries merrily
> on.  I think that
> there should be a recommendation that the transport sender
> closes the connection
> and reopens it if it wants to.
>
> Tom Petch
> - Original Message -
> From: "Chris Lonvick" 

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

[Kent Watsen]

Hi Clyde.


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

We'd have to ask the WG, since it's not a chair or shepherd decision.  If 
you're okay leaving it in, and dealing with the fallout later, and no one 
objects, then I'm fine leaving TLS in.


> RFC 6587 can be made Informational.

Okay, but you have never mentioned if you know if anyone (Cisco?) is using it?  
Juniper doesn't.   My first preference is to remove TCP support altogether.


> Working with an editor might help to avoid additional revisions.

Actually, it would be more like replacing you as the Editor.  You could stay on 
as an Author.  The point is, we need to have more timely responses...


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

You can make those changes, but most importantly, you need to make sure it 
passes idnits.  BTW, I was wrong before, there is an error in the 2119 
boilerplate (idnits verbose output shows it)


> Thanks,
> Clyde

Kent

== original message =

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

Hi Clyde,

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

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

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

Kent // shepherd


= original message =

Kent

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

Tom Petch

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

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8=.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> = START =
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   
https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ=):
>   

>
>  No issues found here.
>
>   Checking nits according to

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_1id-2Dguidelines.txt=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=wrmo4jVcBb7-_LFH7ty-TOpG80tfe3pWbfCSFZaT6eY=:
>   

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

>
>   ** There is 1 instance of too long lines in the document, the
longest one
>  being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   

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

[Clyde Wildes (cwildes)]

Kent,

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

RFC 6587 can be made Informational.

Working with an editor might help to avoid additional revisions.

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

Thanks,

Clyde


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

Hi Clyde,

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

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

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

Kent // shepherd


= original message =

Kent

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

Tom Petch

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

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8=.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> = START =
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   
https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ=):
>   

>
>  No issues found here.
>
>   Checking nits according to

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_1id-2Dguidelines.txt=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=wrmo4jVcBb7-_LFH7ty-TOpG80tfe3pWbfCSFZaT6eY=:
>   

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

>
>   ** There is 1 instance of too long lines in the document, the
longest one
>  being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   

>
>   == Line 352 has weird spacing: '...gorithmide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>  it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>  a matching beginning. Boilerplate error?
>
>  (The document does seem to have the reference to RFC 2119 which
the
>  ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should 

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

[Kent Watsen]

Hi Clyde,

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

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

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

Kent // shepherd


= original message =

Kent

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

Tom Petch

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

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8=.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> = START =
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo=DwICAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0HIzePAk6Q=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ=):
>   

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

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

>
>   ** There is 1 instance of too long lines in the document, the
longest one
>  being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   

>
>   == Line 352 has weird spacing: '...gorithmide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>  it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>  a matching beginning. Boilerplate error?
>
>  (The document does seem to have the reference to RFC 2119 which
the
>  ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should 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 .  Please fix this.
>
>
>   == Unused Reference: 'RFC7895' is defined on line 1456, but no
explicit
>  reference was 

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

[t.petch]

Kent

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

Tom Petch

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

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: https://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: '...gorithmide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>  it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>  a matching beginning. Boilerplate error?
>
>  (The document does seem to have the reference to RFC 2119 which
the
>  ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should 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 .  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 "/"
string.  For instance: /  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
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

> 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


> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Alex
> Campbell
> Sent: Tuesday, January 16, 2018 1:46 PM
> To: Benoit Claise <bcla...@cisco.com>; Kent Watsen
> <kwat...@juniper.net>; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> By the same reasoning surely UDP should not be available either, because it
> also doesn't provide security.
> 
> From: netmod <netmod-boun...@ietf.org> on behalf of Benoit Claise
> <bcla...@cisco.com>
> Sent: Wednesday, 17 January 2018 6:23 a.m.
> To: Kent Watsen; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> Hi,
> >
> >** 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.
> >
> >
> >
> Well, I believe it's clear plain TCP should not be in the YANG module.
> 
> Regards, Benoit
> 


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

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

[Kent Watsen]

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

PS: I didn't also checked the other issues we're tracking, but will when we get 
past these idnits issues.

Kent


= START =
idnits 2.15.00 

/tmp/draft-ietf-netmod-syslog-model-19.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=X00_D6mS_CYdDDM_LABw-a_uhQziwjSvaaz8UHC6Nc0=):
  

 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=A2x1CyvFGV7zPzunzNLz__Ce2NswyYOw0iQVI-cNwTo=U9PqY8kpdbwz_sL4a1DhBJagSvEx9sv9zZquldhed7U=:
  

 No issues found here.

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

  ** There is 1 instance of too long lines in the document, the longest one
 being 1 character in excess of 72.

Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the RFC 
editor a step later on.


  Miscellaneous warnings:
  

  == Line 352 has weird spacing: '...gorithmide...'

Kent: this is fine.  it is in a tree diagram.


  == The document seems to lack the recommended RFC 2119 boilerplate, even if
 it appears to use RFC 2119 keywords -- however, there's a paragraph with
 a matching beginning. Boilerplate error?

 (The document does seem to have the reference to RFC 2119 which the
 ID-Checklist requires).

Kent: I can't find the error.  Looking at the xml, it is verbatim what I have 
in the zerotouch draft.  my guess is that this is a tooling error and we should 
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 .  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 "/" string.  
For instance: /  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 

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

[Alexander Clemm]

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:netmod-boun...@ietf.org] On Behalf Of Alex
> Campbell
> Sent: Tuesday, January 16, 2018 1:46 PM
> To: Benoit Claise <bcla...@cisco.com>; Kent Watsen
> <kwat...@juniper.net>; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> By the same reasoning surely UDP should not be available either, because it
> also doesn't provide security.
> 
> From: netmod <netmod-boun...@ietf.org> on behalf of Benoit Claise
> <bcla...@cisco.com>
> Sent: Wednesday, 17 January 2018 6:23 a.m.
> To: Kent Watsen; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt
> 
> Hi,
> >
> >** 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.
> >
> >
> >
> Well, I believe it's clear plain TCP should not be in the YANG module.
> 
> Regards, Benoit
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[Benoit Claise]

Hi,


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




Well, I believe it's clear plain TCP should not be in the YANG module.

Regards, Benoit

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

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

[Kent Watsen]

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

Kent: this is fine.  it is in a tree diagram.


  == The document seems to lack the recommended RFC 2119 boilerplate, even if
 it appears to use RFC 2119 keywords -- however, there's a paragraph with
 a matching beginning. Boilerplate error?

 (The document does seem to have the reference to RFC 2119 which the
 ID-Checklist requires).

Kent: I can't find the error.  Looking at the xml, it is verbatim what I have 
in the zerotouch draft.  my guess is that this is a tooling error and we should 
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 .  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 "/" string.  
For instance: /  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



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

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

[internet-drafts]

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  "" --> 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/

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