Hi,
Here are a few comments on this draft.
(As syslog co-chair I will point out this is NOT a syslog WG item
because it is not a secure transport, and out of scope of the syslog
WG charter. I have cross-posted since there may be interested parties
in the syslog WG who will not know it is being proposed in the OPSAWG
WG.)
Most of my comments are editorial.
1) Is there such a thing as an RFC3164 message? Isn't rfc3164 just a
description of a bunch of implementations, each of which has its own
message format?
2) In the intro, the last sentence mentions syslog transport receivers
and legacy syslog senders. Is this text consistent with the RFC5424
terminology?
3) I suggest a small diagram showing the stack-oriented approach of
rf5424 and its transport models, with an arrow showing that this
document discusses interactions between the sender and receiver
transport implementations.
4) Diagram 2 is labelled Diagram 1
5) octet-counting and octet-stuffing are not described before the
discussion of MUST/MAY is addressed. It would help to point to the
sections that define these (i.e. provide a forward reference).
6) the discussion of MUST/MAY and REQUIRED/RECOMMENDED is redundant.
You only need the sentence with REQUIRED/RECOMMENDED (which also
discusses why)
7) Is ABNF a figure? Do you need both diagrams and figures?
8) I'm not an expert on ABNF. Will this ABNF parse in standard parsers
with APP-DEFINED not specified?
9) " A transport receiver MUST accept that the TRAILER character is
a USASCII LF." sounds like the receiver is talking with a shrink ;-)
How about "A transport receiver MUST accept USASCII LF as a TRAILER
character."?
10) s/octect/octet/g
11) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. I would reverse
their order
12) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. But if I read 3.3,
they are MAY/MUST and RECOMMENDED/REQUIRED. There is inconsistency of
RECOMMENDED vs MAY vs NOT RECOMMENDED for stuffing, and of MUST vs
REQUIRED vs RECOMMENDED for counting.
13) " It is recommended and current practice that a transport
receiver assumes that octet counted framing is used if a syslog frame
starts with a digit." You are defining a standard; make this a MUST
for compliance to this standard.
14) " SYSLOG-MSG is defined in [RFC5424]. Most senders use the
format described in [RFC3164] as an alternate format." This sounds
like an implicit recommendation to use the rfc3164 format, since
that's what most senders use. Again, you are defining a standard; I
think you should at least RECOMMEND the rfc5424 format for compliance
with this TCP transport standard.
15) section 3.4 says to discard the TRAILER. How will this work with
syslog sign? Should the hash be calculated before the TRAILER is
added? And for octet counting, is the hash calculated before the count
is prepended?
16) section 3.5 says "It then initiates a TCP session closure." Not
being knowledgeable about TCP details, I thught this meant it would
start a closure conversation with the peer. Would this be clearer if
it said "It then initiates a local TCP session closure."? Obviously,
the text that follows clarifies this, but it was distracting.
17) Some people prefer that non-normative sections be handled as
appendices. Would it be good to move section for to an appendix?
18) section 4 uses terms "encouraged" and "should". This is not
consistent with RFC2119.
19) section 4 - same coments as in 13)
20) section 4.1 - is this advice consistent with earlier statements
about having to close and re-init the connection? If the difference is
that the earlier discussed requirements for compliance ("conservative
in what you send"), and this talks about "liberal in what you
receive", I recommend you discuss it in those terms. (Is that Postel's
law, or something like that?)
21) 4.2 and 4.3 mention what is REQUIRED; but section 4 is
non-normative and only informational. The REQUIRED seems out of place
here. I think a discussion of interoperability with legacy devices
(ala Postel) might be called for in both sections, rather than RFC2119
required/may discussions.
22) "In that" is unnecessary and makes the sentence harder to parse.
23) "In this legacy implementation" - should this be "In some legacy
implementations"? That whole paragragh could use cleanup.
24) octet-counting and octet-stuffing sections should be ordered
consistently with 11)
25) section 5.1 "representing itself as another machine" it is not
clear who is doing the misrepresenting in this sentence - the sender
or the receiver. Needs wordsmithing.
26) "indeed" is seldom necessary
27) 5.6 "cannot always know" - does it ever know?
28) You should have a "Note to the RFC Editor" to discuss replacing
the <TBD> in the text associated with the port assignment requested in
section 7. (Oh, I found it in secton 9; why not just put it into
section 7?)
29) I think the acknowledgement of xml2rfc is not needed.
Acknowledgements are for technical contributors. If you wrote the
draft using MS-Word or Notepad or Emacs, would you acknowledge them?
30) You don't need to have section 6; xml2rfc automatically generates
a section (unnumbered per RFC editor rules) for Authors' Addresses.
> -----Original Message-----
> From: Chris Lonvick [mailto:[email protected]]
> Sent: Monday, November 30, 2009 9:24 AM
> To: Dan Romascanu; [email protected]
> Cc: [email protected]; [email protected]
> Subject: New Version Notification for
> draft-gerhards-syslog-plain-tcp-00 (fwd)
>
> Hi Dan,
>
> A few weeks ago we were talking about documenting syslog/TCP
> and moving it
> into the OPSAWG - it no longer fits in the syslog WG charter.
> Rainer and
> I wrote up the initial draft for this.
>
> Would you please look it over and see if it is of sufficient
> quality and
> interest to become an OPSAWG product? If so, should I take
> this to the
> OPSAWG Chairs?
>
> Best regards,
> Chris
>
> ---------- Forwarded message ----------
> Date: Mon, 30 Nov 2009 06:02:36 -0800 (PST)
> From: IETF I-D Submission Tool <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: New Version Notification for
> draft-gerhards-syslog-plain-tcp-00
>
>
> A new version of I-D, draft-gerhards-syslog-plain-tcp-00.txt
> has been successfuly submitted by Rainer Gerhards and posted
> to the IETF repository.
>
> Filename: draft-gerhards-syslog-plain-tcp
> Revision: 00
> Title: Transmission of Syslog Messages over TCP
> Creation_date: 2009-11-30
> WG ID: Independent Submission
> Number_of_pages: 14
>
> Abstract:
> This document describes the transport for syslog messages over TCP/
> IPv4 or TCP/IPv6. The syslog protocol layered architecture provides
> for support of any number of transport mappings. However, for
> interoperability purposes, syslog protocol implementers are required
> to support this transport mapping.
>
> There have been many implementations and deployments of traditional
> 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 this has been done for
> traditional syslog, and how the new syslog architecture can
> interoperate with the traditional deployments.
>
> Status of this Memo
>
> This Internet-Draft is submitted to IETF in full conformance with
the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
> This Internet-Draft will expire on June 3, 2010.
>
> Copyright Notice
>
> Copyright (c) 2009 IETF Trust and the persons identified as the
> document authors. All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document. Please review these documents
> carefully, as they describe your rights and restrictions with
respect
> to this document. Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
>
>
>
> The IETF Secretariat.
>
>
>
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
