I think that there are a number of places where the language is not quite English and could do with editing. There are also several places where I am unclear about the meaning. Taking the more significant ones and trying not to overlap with previous comments
It would be easier for the RFC Editor (and me) if the three references were to proposed RFC were to xxxx, yyyy, zzzz as opposed to all being xxxx 3 'it is imperative .. ' seem unnecessary when it is followed by 'MUST NOT' 'Signature Group' seems as much a special term as Signature Block or Certificate Block and so should be capitalised. I find the mix of byte, decimal and character confusing. As already commented, I think octet should replace byte and, in most places, character. For me, saying a field is decimal is imprecise; I would like you to specify that in ABNF as Rainer does. Also, I you should give guidance on leading zeroes (omit them!). 4.2.2 "between 0 and 9999999999" I assume that this is an inclusive range, ie 0 and 9999999999 are valid values. "If the value latches at 9999999999" I am unclear about this and other uses of 'latches'. I expect a specification to say whether or not a value latches at its maximum value (and so needs to be reset by special action eg manual intervention). Saying 'if it latches' confuses me; is this at the choice of the implementor?. 4.2.3 "how to divide up the processing //of/ syslog messages " "The ability to /to// associate" "with flexibility /to/in/ that regard." 4.2.4 "In the case in which the reboot session ID is in fact 0 and persisting of reboot session IDs is not supported, when the global block counter latches, it resumes at 0 also in this case but the reboot session ID MUST NOT be incremented and remains at 0." I struggle to parse this. Is it more like "When the reboot session ID is 0 ( ie persistent reboot session IDs are not supported) and the global block counter reaches its maximum value, then the global block counter is reset to 0 and the reboot session ID MUST remain at 0." 4.2.7 How is the message padded? 5.2 "each reboot session has only one Payload Block" I get confused in this section; my sense is, and I struggle for the right wording, that the contents of the Payload Block are fixed for a reboot session (regardless of whether or not persistent session IDs are supported) but that the Payload Block may appear as many times as the sender thinks fit. 5.3 "refe/re//rred to as a Certificate Block" Should a Certificate Block have a minimum length? is it valid to send a large number of such blocks with zero length (DOS attack)? 6 I would like to see suggested values for this customisation. Given the number of comments from Chris and Rainer, I would like to see a reissue and the chance to read it again before this goes to the IESG. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
