Hi Folks,
David provided a great review of -00 and we've updated it.
http://tools.ietf.org/html/draft-gerhards-syslog-plain-tcp-01
Just one more time, this is not a product of the syslog WG. If you have
some time, we would appreciate reviews.
Here are our replies to David's review.
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?
CML> I've changed the wording. 3164 describes the original syntax
that Eric Allman intended. It then backpeddles because there are so
many divergences from that.
2) In the intro, the last sentence mentions syslog transport receivers
and legacy syslog senders. Is this text consistent with the RFC5424
terminology?
CML> I've changed that wording and added a clarification.
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.
CML> New diagram 1.
4) Diagram 2 is labelled Diagram 1
CML> It's easier to reference when all diagrams are labelled the same.
....umm, OK, we removed the state diagrams as they were incomplete and
would require a lot of work to get a correct basic understanding.
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).
CML> Now described in the Intro.
6) the discussion of MUST/MAY and REQUIRED/RECOMMENDED is redundant.
You only need the sentence with REQUIRED/RECOMMENDED (which also
discusses why)
CML> OK
7) Is ABNF a figure? Do you need both diagrams and figures?
CML> No longer a figure.
8) I'm not an expert on ABNF. Will this ABNF parse in standard parsers
with APP-DEFINED not specified?
CML> It would parse but I've modified it to be more complete.
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."?
CML> Changed.
10) s/octect/octet/g
CML> My bad.
11) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. I would reverse
their order
CML> OK
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.
CML> Described later. It's so that the receiver can accept both
types of legacy formats.
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.
CML> OK
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.
CML> You misinterpreted that. It's saying that most legacy syslogs
are using the format described in 3164. Nonetheless, I don't see
that the paragraph is needed so it's been removed.
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?
CML> Yeah, not enough clarity there. I've reworked it to be consistent
with 5424.
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.
CML> Sounds good to me. :-)
17) Some people prefer that non-normative sections be handled as
appendices. Would it be good to move section for to an appendix?
CML> Yes - I've moved all of that to an appendix.
18) section 4 uses terms "encouraged" and "should". This is not
consistent with RFC2119.
CML> Revisions made.
19) section 4 - same coments as in 13)
CML> OK
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)
CML> I made changes throughout. Please take a look.
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.
CML> It was good enough for RFC 5426. Please look again to see if it's
cleared up with these edits.
26) "indeed" is seldom necessary
CML> Indeed.
27) 5.6 "cannot always know" - does it ever know?
The transport sender doesn't, and TCP won't either. If you fail to get
an ACK, does that mean that it was or wasn't delivered?
CML> Cleaned up.
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?)
CML> Cleaned up.
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?
CML> OK
30) You don't need to have section 6; xml2rfc automatically generates
a section (unnumbered per RFC editor rules) for Authors' Addresses.
CML> OK
===
Thanks,
Rainer & Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
