Subject: [Syslog] Reviews of syslog-sign before the Holidays

From: Chris Lonvick <[email-masked]>
Date: Thu, 18 Dec 2008 13:10:17 -0800 (PST)

Hi,

David and I will be awarding (virtual) GOLD STARS to each and every person 
who reviews draft-ietf-syslog-sign before going away for the Holidays.
   http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-24.txt
The diffs from previous versions may be found here:
   http://tools.ietf.org/wg/syslog/
The changes from the previous version to this version were to address 
Pasi's AD review and some additional comments.  We think that Alex has 
done this but more reviews would be appreciated.

All issues with RFCs-to-be 5424-5428 have been resolved and we are 
awaiting publication by the RFC Editor.  (Many thanks to our dedicated RFC 
Editor, btw :-)  The biggest holdup was getting the IANA to dedicate a 
Private Enterprise Number to be used for examples.  Pasi and David worked 
that out and have even produced an ID to document that. 
http://www.ietf.org/internet-drafts/draft-eronen-enterprise-number-documentation-00.txt

My best wishes for a Happy Holiday and a Prosperous New Year.
Best regards,
Chris
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Richard Graveman" <[email-masked]>
Date: Mon, 22 Dec 2008 12:54:54 -0500

Hi Chris,

I think this document is in excellent shape and encourage the WG to
move it out as quickly as possible.

Nits, all minor:

1. In 4.2.2, line 3 and 4.24, line 5:

Leading zeroes MUST be omitted.

-> except for a value of 0, which is encoded as "0"

2. In 4.2.4, line 8:

other than 0

-> other then 0 or 9999999999 (the latter case is covered above)

3. In 4.2.9, line 2, and in 5.3.2.9, line 2:

Tell the RFC Editor to change this to "RFC publication rules"

4. In 5.3.2.4 and 5.2.3.6:

Are leading ASCII zeros prohibited in these two cases also, or are
these two different?

5. In 7.1, case (b):

-> This should never happen, but I suppose there are pathological
cases, e.g., mis-configurations, where more than one different but
valid payload could be reconstructed. The software should at least
deal with this, and perhaps either (1) use other knowledge to choose
which to keep; or (2) retain all of them for later use.

6. Section 8.11:

IP is so full of covert channels, that it suffices to say that this
protocol doesn't really change that fact. The example is a very narrow
pipe; much wider ones exist.

7. References, [RFC5226]

Comma missing after T.

8. In general, I'm not sure why three or more author references are written:

"Jones, A., Smith, B., and C. Brown" rather than "Jones, A., B. Smith,
and C. Brown"

Regards, Rich Graveman