Hi, I agree with Sam that the WG should review the large changes made since IETF last call.
I'll respond to these questions -- as a contributor. Let me start out by stating that I have no previous experience with syslog before becoming co-chair. My background has been SNMP-based NMS development. I came in as co-chair primarily to help get the documents finished and through the process, because the WG had stalled and Chris didn't have the time to spend on getting the WG through the process alone. my commnts inline. > -----Original Message----- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 13, 2007 9:16 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Syslog] Comments on draft-ietf-syslog-protocol-20 > > > > Hi. Thanks for the new draft. > > There are a lot of changes in this version; it will definitely require > a new ietf last call. I'd recommend that the WG evaluate the changes > and ask whether at this stage in the process they are actually > required. Perhaps they are. > If we are developing a standard, the documents should describe how the system works well enough for those with no previous experience in the protocol to be able to understand it from the documents. I have always used the rule "IETF documents should be clear and unambiguous" as various roles as chair and editor in the IETF. I found that protocol-17 failed that test. This became quite apparent when there were debates about terminology related to the -tls- draft and the -mib- draft. > > 1) You cannot use originator and sender in the same layering > diagram if they are going to mean different things. May I > suggest calling the entity a transport sender/transport receiver. > > 2) I question whether all three of sender/originator/formatter are > needed. I recommend dropping formatter and perser, folding their > behavior in somewhere else. As we tried to work on the docuemnts, especially the mib, it became clear that different people have different ideas of what each term means. In the mib it is necessary to model the abstract concepts of how the system works. The concepts of syslog seem to be that some entity, e.g. a device, request that a syslog message be created and logged/sent on its behalf. Implementation designs vary widely depending on a lot of factors, but all seem to accept that some process-or-whatever has an event occur that should be looged/sent and that some process-or-whatever creates a message, and some process-or-whatever sends the prepared message. Since the WG has been able to separate the protocl form the transport mappings, the process-or-whatever that craetes the message and th eprocess-or-whatever that sends the message are separate abstract concepts. Why is this important? because the mib contains counters for things like number-of-messages-sent; which portion of the system actually knows how many messages were sent? The requesting process-or-whatever knows ho wmany were requested; the message-formatting process-or-whatever knows ho wmessages were prepared for sending, but the transport sender is the only one that knows how many managed to get through all the intermediate error-checking and were actually sent. Only the transport-sender process has the information to make available to the mib. If different implementations count this counter from different points in the process, the results will not be interoperable - an NMS will not be able to accurately compare the values from two syslog daemons/processes/applications and be able to compare apples-to-apples rather than comparing apples-to-oranges. > > You are misusing the terms (as an example, the following diff suggests > that we care about the formatter's IP addresses not the originator's). > I can believe that the formatter chooses the IP address, but I don't > think it should choose one of its addresses if it is on a different > machine than the originator. Misuse of terms from those defining the > terms suggests that you have too many terms. >From the managed node perspective, it might make perfect sense to use the originator's IP address sometimes and the formatter's address sometimes, but from the point of an operator or NMS, it can make all the difference in the world what that value means vis-a-vis the network. We need consistency across implementations. If that value will be used for security purposes, I think it is even more important that it be consistent about what it represents. Maybe there should be two different places to represent IP address if it means two different things. Again, the terminology has been tremendously unclear and ambiguous. This WG should make the concepts and terminology clear and unambiguous. > > + Formatters SHOULD consistently use the same value in the HOSTNAME > + field for as long as possible. If the formatter uses IP addresses > + inside hostname, the following rules apply: If the formatter is > + multihomed, this value SHOULD be one of its actual IP > addresses. If > + a formatter is running on a machine that has both statically and > + dynamically assigned addresses, then that value SHOULD be from the > + statically assigned addresses. As an alternative, the > formatter MAY > + use the IP address of the interface that is used to send > the message. > > > If you keep formatter and parser, please for each use of originator, > formatter, parser and collector explain why that is the correct term. Apparently, we still have not gotten the abstract concepts and the terminology to be clear and unambiguous, since you could not understand it. > > > 3) Why does this obselete 3164? That document describes a ifferent > protocol. RFC3164 describes a variety of implementations, and during our work, we found that those descriptions only captured the tip of the iceberg. As a result, that informational document is inaccurate and misleading, and should be considered obsolete. We don't declare the implementations described obsolete, or the non-IETF defacto standard to be obsolete; we declare the informational RFC to be obsolete. Historic could also work, if the IESG prefers that choice. . > > > 4) Why was a.8 removed? a.8 and the section on PROCID used lots of words, but at the end of going through all those words, what was said was pretty straightforward - there was no agreement on the syntax or meaning of PROCID. The only agreement appeared to be that if the value changed, that was significant, and some implementations used these fields in a similar way. We summarized the discussion from a.8 (in -17-) and added it to 6.2.6 (in -20-). David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
