Subject: [Syslog] RE: syslog-sign

From: David Harrington <[email-masked]>
Date: Tue, 13 Mar 2007 00:24:55 -0400

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-masked]] 
> 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-masked]] 
> 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-masked]]
> > Sent: Monday, March 12, 2007 12:38 PM
> > To: Alexander Clemm (alex)
> > Cc: [email-masked]
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "tom.petch" <[email-masked]>
Date: Thu, 15 Mar 2007 09:37:44 +0100

See RFC3967

Tom Petch

----- Original Message ----- 
From: "David Harrington" <[email-masked]>
To: "'Alexander Clemm (alex)'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 13, 2007 5:24 AM
Subject: [Syslog] RE: syslog-sign

> Hi,
<snip>
 
> Can Informational documents be Normative?
<snip>