Hi, A new revision of syslog-sign will be published soon. Here are some comments, mostly editorial, on the new draft.
Line 218: "with with" Line 229: "could be also be" Line 343: (section 3) eliminate the second sentence:"The syslog protocol therefore MUST be supported by implementations of this specification." This does not appear to be justified for use of RFC2119 keywords, if the sign protocol can also be used with non-syslog protocols. (and if not, then some text gives the impression you are advocating such a thing). Line 350 "described in RFC xxxx [11]. MAY make changes to a syslog packet. " eliminate the period after [11]. Line 376: s/the contents of the messages is/the content of the messages is/ Line 410: s/as such// Line 411: s/SD ELEMENT, as defined in RFC xxxx [11],/SD ELEMENT/ Section 4.2.1 Should we also define a hash algorithm value 2 to represent SHA-256? 4.2.4 - what extra considerations? 4.2.6 s/between 1 and 99/1 through 99/ 5.3 s/Note that// (remove this everywhere please) 5.3.1 s/per RFC xxxx [11] // (this is needed for the first reference, and not needed afterwards.) 5.3.1 s/as such// (remove this everywhere please) 5.3.1 s/, as defined in RFC xxx [1]],// (this is needed for the first reference, and not needed afterwards.) 5.3.1 s/In addition,// 5.3.1 s/to be compliant with RFC xxxx [11]// 5.3.1 s/for consistency reasons/for consistency/ 5.3.1 s/(but not required)// 5.3.1 s/Likewise,// 5.3.1 s/per the definitions that follow in the next section// 5.3.2 s/Like a Signature Block,// 5.3.2 s/per RFC xxx [11]// 5.3.2.1 s/as such,// 5.3.2.3 s/Also,// Section 5.3.1.x - if these are al;reday defined in section 4.2.x, why are we duplicating the information here? Can we eliminate the redundant text? 7.1 d. could use some wordsmithing. 8.2 s/as (per RFC xxxx [11])/since/ 8.2. s/to to/to/ 8.2 s/In this case, as in all others,// 8.2 s/Similarly// 8.2 s/Finally// 8.2 what does malfunction mean? Can we rephrase to what a receiver must do? 8.3 "That fact" - what fact? 8.3 "maintain doubt"? 8.3 - this section needs wordsmithing 8.4 s/may/might/ 8.4 s/However// 8.5 s/may/might/ 8.5 s/However// 8.4 and 8.5 would beneift from active voice rather than passive voice: "a reviewer can determine if ... by examining the information contained in Signature Blocks" 8.6 s/This document acknowledges that// 8.6 s/proper// 8.6 "allows a reviewer" would be better in active voice: A reviewer can determine .... By ..." 8.6 s/also// 8.7 s/Related to the above, syslog messages delivered over UDP not only may be lost, but they may also arrive out of sequence./Syslog messages delivered over UDP might be lost or delivered out of sequence./ 8.7 "allows a reviewer" => "A reviewer can determine ... By ..." 8.7 s/Beyond that,// 8.7 "... May help ..." => "A reviewer can determine the order of messages, and which messages were delivered out of order, by examining the information in the Signature Block, and any timestamp information in the message. Other sections - use "might" rather than "may"; MAY is a RFC2119 reserved word related to interoperability. 8.9 s/Generally this has had the benefit of allowing/This allows/ 8.10 s/It is conceivable that an attacker may/An attacker might/ 8.10 s/In that case,// 8.11 s/An attacker may be able to overwhelm a receiver by sending it invalid Signature Block messages. If the receiver is attempting to process these messages online, this attack may consume all available resources./An attacker might send invalid Signature Block messages to overwhelm the receiver's processing capability and consume all available resources./ 8.11 Do we want to make this implementation choice RECOMMENDED? Does this really belong in this document? s/As with any system,// s/may also just/might/ s/Nothing in this protocol attempts to eliminate/This protocol does not prevent/ s/Indeed,// s/In fact,// 8.12 do we really need this is this document? Couldn't this be done with almost any protocol? IANA Considerations should be succinct instruction to IANA about registries we want them to create, and values we want them to assign, and instructions about how values should be assigned in the future, that are specific to this document. This should NOT be the place where we describe in detail WHY we need these things; that should be in other sections. Eliminate the first paragraph. s/Specifically,// s/with regards to RFC xxx [11],// s/instructed/requested/ "appropriate registry" - you need to identify which is the apporpriate registry, if it already exists. If it does not exist, you need to request that IANA create a registry. It is the WG's responsibility to understand why we need these things, not IANA's; It is IANA's responsibility to create registries and add entries within the 2434-style guidance the WG decides should be applied. Please format these into table form, similar to existing registries found at www.iana.org so IANA can simply cut-and-paste the registries or registry entries you are requesting. "This document also upholds ..." Why are we asking to reserve the facilites and severities values, and doing so from this document? Is that something specific to syslog-sign? All the sections in IANA considerations should be reduced to tables that can be cut and pasted into the registry documents by IANA, without them needing to understand why we have each table or each value. For each new registry, identify how future extsnions are handled as per 2434. Authors' addresses are listed twice in the document. Can Informational documents be Normative? dbh > -----Original Message----- > From: Alexander Clemm (alex) [mailto:[EMAIL PROTECTED] > Sent: Monday, March 12, 2007 6:08 PM > To: David Harrington > Cc: Chris Lonvick (clonvick) > Subject: RE: syslog-sign > > Hello David, > > sure, here you go > > In case you have additional comments, I will hold off > submitting to the > ID Editor until I hear from you, or tomorrow noon (Pacific time), > whichever comes first - ok? > > Best regards > --- Alex > > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Monday, March 12, 2007 9:49 AM > To: Alexander Clemm (alex) > Subject: RE: syslog-sign > > Hi Alex, > > Can you send me a copy of the text file and the source? > > Thanks, > dbh > > > -----Original Message----- > > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 12, 2007 12:38 PM > > To: Alexander Clemm (alex) > > Cc: [EMAIL PROTECTED] > > Subject: RE: syslog-sign > > > > Hi Alex, > > > > Please submit it to the ID Editor. > > > > Many thanks, > > Chris > > > > On Sun, 11 Mar 2007, Alexander Clemm (alex) wrote: > > > > > Hello Chris, > > > > > > please find enclosed > > > > > > In summary: > > > - References to RFC 3164 and 3195 have been removed; syslog-sign > now > > > presupposes syslog-protocol. > > > - syslog-sign does not mandate values for the APP-NAME, > MSGID, and > > > PROCID fields. (It does suggest that whichever values > are chosen, > > > SHOULD be consistent.) Likewise, the vlaue for the PRI field is > now > > > merely a recommendation. > > > > > > Some minor updates beyond those, such as changing "bytes" > > to "octets". > > > I'll send a more detailed response with replies to your and > Rainer's > > > review messages (which are the superset of all the comments) > later. > > > > > > Please advise how to proceed from here. > > > > > > Thanks > > > --- Alex > > > > > > -----Original Message----- > > > From: Chris Lonvick (clonvick) > > > Sent: Wednesday, March 07, 2007 12:06 PM > > > To: Alexander Clemm (alex) > > > Subject: Re: syslog-sign > > > > > > Hi Alex, > > > > > > Any update? > > > > > > Thanks, > > > Chris > > > > > > On Mon, 19 Feb 2007, Alexander Clemm (alex) wrote: > > > > > >> Hi Chris, > > >> > > >> apologies for the delay and keeping quiet for so long. I > > am keeping > > >> extremely busy with GMI so didn't get to send you the > > revised writeup > > >> on syslog-sign yet, although it's been resting heavily on > > my mind as a > > > > > >> thing-I-must-do-if-I-can-figure-out-how-to-get-to-it. I > > have finally > > >> a weekend coming up that is free of commitments, so I am > > planning to > > >> get this to you by the morning of Monday (of next week - 2/26). > > >> Hopefully this will still work for you... > > >> > > >> Best regards > > >> --- Alex > > >> > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
