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" <clonv...@cisco.com>>
> Sent: Friday, October 01, 2010 9:16 PM
> > Hi Folks,
> >
> > While this is a non-WG item, there are some people interested.
I've
> > updated the syslog/tcp draft and I'll invite reviews and comments.
>
> > Chris
> >
> > ---------- Forwarded message ----------
>> > Filename: draft-gerhards-syslog-plain-tcp
> > Revision: 05
> > Title: Transmission of Syslog Messages over TCP
> > Creation_date: 2010-09-30
> >
> > Abstract:
> > There have been many implementations and deployments of
> legacy syslog
> > over TCP for many years.  That protocol has evolved without being
> > standardized and has proven to be quite interoperable in practice.
> >
> > The aim of this specification is to document three things: how to
> > transmit standardized syslog over TCP, how TCP has been used as a
> > transport for legacy syslog, and how to correlate these usages.
> >
[end of extract]
==============================================

----- Original Message -----
From: "Kent Watsen" <kwat...@juniper.net>
Sent: Wednesday, February 07, 2018 12:49 AM

> 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" <kwat...@juniper.net>
> To: <netmod@ietf.org>
> 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&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJ
UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuuHwmgn0
HIzePAk6Q&s=HHa4Kg7ZoXOz6uC9VkiT_-jMeGdW9Kbfo1CydiT4bM8&e=.
> 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_li
cense-2Dinfo&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9z
kP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBuu
Hwmgn0HIzePAk6Q&s=L95k8rDeNKaSZXkCpqx2hwzmGDw8trmzmYOT0SLU-fQ&e=):
>
  --------------------------------------------------------------------
> --------
> >
> >      No issues found here.
> >
> >   Checking nits according to
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Di
nfo_1id-2Dguidelines.txt&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDT
XcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7
lKz5mWWYCBuuHwmgn0HIzePAk6Q&s=wrmo4jVcBb7-_LFH7ty-TOpG80tfe3pWbfCSFZaT6e
Y&e=:
>
  --------------------------------------------------------------------
> --------
> >
> >      No issues found here.
> >
> >   Checking nits according to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Di
nfo_checklist&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9
zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=vB8Genu4I7nOu9B7lKz5mWWYCBu
uHwmgn0HIzePAk6Q&s=_seSaCKfzxYeb3b1tfX2RqUk7CKbOsRr3pRVJrQ8lEc&e= :
>
  --------------------------------------------------------------------
> --------
> >
> >   ** 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
> >
> >
> >
> >



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

Reply via email to