Rainer: I have read the draft. Some comments here. Lot of small ones in a separate email I will send you directly.
1. I don't think you specified maximum message size anywhere. Or did I miss it? 2. You talk a lot about server parsing the syslog message. Are we making an assumption that receiver must parse messages (for example 5th paragraph in 4.1.1)? Generally, there seems to be a lot of stuff dictating behavior for receiver. Why can't we just say: this is valid on the wire, this is not and leave it up to implementation to decide what it does with it. For example, we ask receivers to "log" diagnostic messages. What does "log" mean here? 3. You use enterprise ID of 0 (IETF) in examples. Is this valid? Should we say 0 is reserved and should never be used? What does 0 mean? 4. Section 4.1.3. "Any implementation MUST support free configuration of the FACILITY on the sender." I think by implementation you are always assuming a dedicated sender or receiver library product. I don't see why I can't just implement sending logic in my app directly and not have a fixed facility. I think at best, this is a SHOULD. 5. Section 4.1.6 - Hostname. So, we specify FQDN and if to present IP. Not sure if we had a discussion on this, but did we decide to bypass hostname? I think it will be a common case where hostname is present, but machine does not know its domain suffix. I would generally prefer IP unless it is dynamic (DHCP). 6. Section 4.2. Which version of Unicode do we support? UTF8 may support all, but I think we should limit it to some basic Unicode version. 7. Section 4.3. Why do we restrict sec-frac to 3 digits? If somebody has better precision why not allow it? 8. Section 6.2.3. I don't think you explain the purpose for allowing partcount to grow. I assume this is for streaming. Needs to be explained. I also think it is a strange scheme. Why don't you allow incrementing it by one every time? 9. Section 7.2. Can we use "yes" or "no" instead of "0" and "1"? 10. Section 8.1. If relay can't add structured data elements, it can't record source IP of the message. I think we should not lose such information. Also, need to allow for recording of time or original reception. 11. Section 8.3. You allow relay to break message into multiple parts. What happens with a message that is already multi-part? How do you distinguish first level of fragmentation from second? 12. The ID is now 45 pages long and growing with every revision. I think it would help if we shortened it whenever possible. After all it is just a syslog protocol. This is protocol used for troubleshooting. It can't be itself overly complicated or give such impression. Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Monday, February 16, 2004 12:15 PM > To: [EMAIL PROTECTED] > Subject: -protocol-03 > > > Hi WG, > > I have edited syslog-protocol so that we are now at > -protocol-03. I have submitted it to the IETF this morning, > but as the draft editor is probably very swamped with the > number of new IDs prior to the Seoul meeting, I have agreed > with Chris on publishing the not yet officially relased ID on > my site. I do so in the hope that this will allow us to work > out some of the issues before Seoul (and eventually identify > new ones). > > It was a rather complete edit, I have placed a full change > log on my comment's page at > > http://www.syslog.cc/ietf/drafts/comments-draft-ietf-syslog-pr > otocol-03. > html > > This page also links to the "unofficial" -protocol-03 > version. This version addresses many of the issues we > discussed the past days. Rather than individual replies, I'd > appreciate if you could have a look at the new ID. > > For those without time to access the web, my edit summary is > as follows: > > - general text-cleanup. Abstract and Intro modified. I > noticed some old text survived in the begininng of section 4, > removed that, some typos caught, probably twice as much added ;) > > - section 3, transport mappings clarified, section 3.1, UDP > transport required [see issue 10] > > - maximum syslog message size is now 1280 bytes (I assume > this *is* the minimum IPv6 MTU, had no time to check) [see > issue 11] ... oops, sorry folks, accidently I removed the > max size altogether ... shame on me for rushing. 1280 will be > back in in -protocol-04 ;) > > - section 4.2 - MSG - now specifies UTF-8 including including > all control characters [see issue 9] > > - section 4, TRAILER has been removed [see issue 6] > > - section 6, multi-part messages heavily changed. Name change > from fragmentation to "multi-part messaging", more > definitions, hopefully clearer description (some of the term > names are *really* lenghty - advise on better terms is taken > thankfully). > > - section 7, definition of structured data element IDs (and > semantics) added > > - section 7.1 - time - tries to solve issue 12 > > - section 7.2 - orgin - tries to provide a way to preserve > originator IP addresses inside the message. "origin" is also > a key element when relay RFC 3164 operations will be > described (I didn't manage to get this into the -03 version). > > - section 8, "relay operations" added, but so far it is more > or less empty. > > - section 9, "security considerations" cleaned up. > > - section 9.1 - diagnostic logging - added as a security > consideration. Comments on this are highly appreciated. This > was not previously discussed on the WG mailing list > > I am looking forward to all comments. > > Rainer > PS: I am unfortunately not able to attend the Seoul meeting > personally, but Chris has agreed to act as proxy (thanks, Chris!) > >
