Hi Tom,
The credit goes to Rainer who put in the time and effort. :-)
I have found these minor nits as well:
===
A.2
Implementers should note the message size limitations outlined in
Section 6.1 and try to keep the most important data early in the
message (within the minimum guaranteed length). This ensures the
data will be seen by the collector or relay even if the receiver at a
relay on the message path truncates the message.
...even if the reciever _as_ a relay on the message path...
s/confusability/confusion/
s/dcument/document/g
===
These can be corrected in AUTH48.
draft-ietf-syslog-protocol and draft-ietf-transport-tls are back in Sam's
hands. I expect an upcoming telechat will move them forward. They don't
need to wait for transport-tls to be sent to the RFC Editor, but the RFC
Editor won't publish them until all normative references are in good
standing.
I have the latest draft-ietf-syslog-transport-tls and just finished my
review of it last night. I believe that it addresses all of Sam's
concerns. I'm going to ask Miao and Yuzhi to submit it to the ID editor
so we can review in the WG.
I appreciate your review.
Thanks,
Chris
On Fri, 11 May 2007, tom.petch wrote:
Chris
I looked some more and am happy with it; the changes are thorough and
comprehensive. I did wonder about the use of "device" which used to have a
technical meaning in early versions of the I-D and now I take not to have.
'Machine' is I think used in the same sense, of the box/stack in general without
any more specific meaning and that seems fine.
One minor nit grabbed me, an extra comma in s.1 in
" reliable, and secure syslog extensions suffer from the lack of a"
where the comma is absent in the same sentence in the Abstract.
I take it we are still awaiting a further -tls for review before the three of
them go to the rfc-editor.
Tom Petch
----- Original Message -----
From: "tom.petch" <[EMAIL PROTECTED]>
To: "Chris Lonvick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2007 4:37 PM
Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol
Chris
I have looked at this and will look at it again in more depth next week. Some
of the new terminology in s.3 is unfamiliar to me and, while the end result
is
not as complex as say RFC3411, it is still going to take a while for me to
grasp
(by inference) the role of eg parser and formatter, the (redefined) sender and
receiver, and to work out which is responsible for which bits on the wire and
see if the usage hangs together. The changes are more extensive than I
anticipated. Probably, they much improve the precision but, at first sight, I
am less certain about the increase in clarity.
Tom Petch
----- Original Message -----
From: "Chris Lonvick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 02, 2007 10:45 PM
Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol
Hi Folks,
David and I would like to hand off this final version to Sam for
publication by Friday. I have performed an initial review and feel that
the changes address the IETF Last Call items.
The changes requested from the IETF Last Call were:
Item 1) Severity Range - The range of the Severity is not bound. The WG
decided that it needs to be bound in the range of 0 to 7 inclusive.
Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language
tags. The document needs to be compliant with this standard. Section
7.3.3 specifies the use of ISO 639 (which was the only reference available
at the time we discussed languages in the mailing list.) Sam asked that
we need to change the language tags to BCP47 to justify our decision. I've
found no compelling reason to continue to use the ISO 639 tags. We need
to change that paragraph to state that BCP47 language tags will be used.
The current "MAY" in Section 7.3.3 should still be used.
Item 3 - Deadlocks - There was a lengthy discussion about using a reliable
delivery mechanism for syslog and how certain circumstances could cause
the loss of messages. (I personally felt it was not addressing any
normative text in the document.) A note about "deadlocks" in Section 8.5
has been requested by Sam. This will need to be short.
Item 4 - IANA - We should review the document to see if there are any IANA
registry values that may be revised by IETF Consensus rather than
Standards Actions. I'll make a review and let you know if I find
anything.
Item 5 - Definitions - The definitions of "sender" "receiver" "relay",
"originator" and "collector" need to be tightened up. They are somewhat
inconsistent now and are required by the -device-mib document.
You may view the differences between -19 and -20 here:
http://tools.ietf.org/wg/syslog/
Click on "draft-ietf-syslog-protocol" and select your method of seeing the
diffs from -19.
Please submit any comments you have to the WG that concern how Rainer
addressed these issues in this document.
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
