Hi, [speaking as co-chair]
Let's make this more concrete. What specific changes to which specific documents are you requesting? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 06, 2007 2:04 PM > To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED] > Subject: Re: [Syslog] Syslog Protocol doubts > > <inline> > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" <[EMAIL PROTECTED]> > To: "tom.petch" <[EMAIL PROTECTED]>; "Glenn M. Keeni" > <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Friday, January 05, 2007 9:12 PM > Subject: RE: [Syslog] Syslog Protocol doubts > > > Hi Tom, > > I think this is an extreme position. The reason is that if I take this > to its ultimate end, we would probably end up without any MUST in the > draft. For example, should we just say the date SHOULD be given in RFC > 3339 format ... But leave it open to any implementor what he > intends to > do? I think a MUST is justified here. But on the other hand, I can NOT > force ("MUST") an implementation to discard an otherwise > useful message > just because the date is in the wrong format. From the protocol > perspective, this might be the right thing to do (in trying to punish > the incompliant implementation), but from a usabulity point > of view, the > administrator needs to have this capability. In a closed-source > environment, that means marketing will force an implementor to support > it. In open-source, the administrator will simply modify the > implementation himself. In either way, the "MUST discard" will not > survive. So is it really smart to mandate something in a standard that > we can foresee to be ignored (and that for good reason)? However, we > need to set same baseline and these are the format-MUSTs. If we change > them all to SHOULD (to cover a myriad of real-world cases), we do not > have a standard... > > Rainer > > <tp> > I disagree:-) > > I am not suggesting we add or change anything in -protocol. > I think MUST is > well defined in RFC2119 and that the consequences are clear. > If the sender > demonstrably does not conform to -protocol in some regard (to > a MUST), then what > confidence can you have that they will conform in other > regards where that may > not be immediately apparent from the message itself? > > syslog may have more MUSTs than most but I think that what > makes syslog unusual > is that it is simplex; in other protocols, the receiver can > say 'what on earth > is this?'; here it cannot and so I am content that the > specification should be > stricter. > > Tom Petch > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 05, 2007 6:47 PM > > To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED] > > Subject: Re: [Syslog] Syslog Protocol doubts > > > > <inline> > > Tom Petch > > > > ----- Original Message ----- > > From: "Rainer Gerhards" <[EMAIL PROTECTED]> > > To: "Glenn M. Keeni" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Friday, January 05, 2007 2:46 PM > > Subject: RE: [Syslog] Syslog Protocol doubts > > > > > > Hi Glen, > > > > thanks for the message. Let me start on an overview level: > if you look > > at the evolution of the draft, you will see that earlier > versions were > > quite specific on what to do if the message was malformed. However, > > based on dicussion, one after another of these rules were > deleted. The > > reason was always that MUSTs here are not actually needed to ensure > > interoperability. > > > > <tp> > > > > I take a somewhat different view. To quote RFC2119, > > > > "Imperatives of the type defined in this memo must be used with care > > and sparingly. In particular, they MUST only be used where it is > > actually required for interoperation or to limit > behavior which has > > potential for causing harm (e.g., limiting retransmisssions)." > > > > So if you receive a packet that breaks a MUST, you MUST discard it. > > > > If it breaks a SHOULD, then you MAY accept it, in fact I > > would say you ought to > > on the principle of being liberal in what you accept. > > > > <tom Petch> > > > > <snip> > > > > You can get a glimpse of this discussion by looking at > > > > http://www.syslog.cc/ietf/why-indepth.html > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
