Hi Everyone, Overall this is looking good. :-) I've got some comments below and I would encourage everyone else to review the document as well.
1. Introduction I think this needs a blurb about the certificate block. Suggested: Insert this paragraph after the second paragraph in this section. ---- Additionally, a device will send a certificate block to provide key management information between the sender and the receiver. This certificate block has a field to denote the type of key material which may be such things as a PKIX certificate, and OpenPGP certificate, or even an indication that a key had been predistributed. In all cases, these messages will still utilize the syslog packet format. In the cases of certificates being sent, the certificates may have to be split across multiple packets. ---- 2. Specification This looks good. It addresses the comments made that the TAG field should be in the HEADER rather than in the CONTENT. 3. Signature Block Format and Fields What if we broke down the TAG into components that would indicate the version and the cookie? Perhaps something like: TAG = syslogsignL[pid]: The string "syslogsigL" would replace the cookie and would indicate that this is either a Signature Block or a Payload Block. L would be a letter. Values of [a-z] would indicate that it is a Certificate Block. Values of [A-Z] would indicate that it is a Signature Block. The first version of either is "a" and "A". "a" and "A" would be defined in this document and subsequent values could define other versions. "a" would mean: Hash Algorithm = SHA1 Signature Scheme = OpenPGP DSA "A" would mean: Signature Scheme = OpenPGP DSA The [pid]: is as we've always known it and could denote the current syslogsign or syslogd process. If we go with that, then we don't need the currently defined "Priority", "Cookie", or "Version" (pages 8-9) and sections 3.2, 3.3, and 3.4 may be removed as we had discussed earlier. 3.5 describes the "Reboot Session ID" and fits it into 8 bytes. Could we increase that to 10 bytes and SUGGEST the reuse of snmpEngineBoots value which is between 0 and 2147483647? [RFC 2574, Section 2.2.2, page 13] This could be kept in the integer format to be humanly readable without converting it to base64. Suggested text: ---- The reboot session ID is a 10 byte value, which is required to never repeat or decrease. The acceptable values for this are between 0 and 2147483647. If the value latches at 2147483647, then manual intervention may be required to reset it to 0. Implementors MAY wish to consider using the snmpEngineBoots value here. ---- Section 3.6 describes the Signature Group. Perhaps all of Section 4 could be placed into this Section since it is all of the details needed to explain this fully. I'd also like to see the value remain human readable on the wire rather than converting it to base 64. This would increase it to 3 bytes. Section 3.7 describes the Global Block Counter. Again, I'd like to see this in human readable format on the wire. Also, again taking the lead from the snmp stuff, perhaps it would be good to quantify this as a value between 0 and 2147483647? The text would have to say that if the value of 2147483647 is reached, then the reboot session ID would have to be increased by 1 and the Global Block Counter would be reset to 0. Section 3.8 describes the First Message Number. This could also be displayed in human readable format in 2 bytes. If we can get some consensus on these points, then we can make Section 5 consistent with this. Comments welcome. Thanks, Chris [Replying to this will go to the list.] [Please use [EMAIL PROTECTED] to ] [reply to me separately. ]
