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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
