Hi, There are several possible options to solve this issue:
1, Using a TLS alert to signal the inconsistent versions as the current draft does. The drawback is it violate the layer, using TLS alert to notify an application event seems ugly. 2, Saving the data (TLS app-data, not syslog message, different to UDP transport) no matter what the version is. This may mean a receiver should be able to save a stream without any knowledge about the structure of the stream. The data can not be stored in the same file/database to the one for syslog messages, because it has no way to delimit frames. 3, Change the simplex of syslog, add an application level notification from receiver to sender, this may increase the effort of implementation greatly, 4, Do nothing, the sender may keep connecting the receiver. But, we can recommend in that specification like "if connections are closed just after successful TLS handshake for three times with same transport mapping version, the sender SHOULD not connect the receiver again with the same transport version". Does it work? My preference is 4 > 1 > 2 > 3. Miao > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 21, 2006 2:55 AM > To: Miao Fuyou > Cc: 'David Harrington'; [EMAIL PROTECTED] > Subject: RE: syslog/tls - how to abort because of > inconsistent versions > > Hi Miao, > > We need this issue resolved in the WG. Please bring up the > discussion on the list with a proposal. I suggest that we > not use TLS to signal a failure in the upper level. > > Thanks, > Chris > > On Thu, 19 Oct 2006, Miao Fuyou wrote: > > > Hi, Eric, > > > > One clarification to version #: syslog/tls version is the one for > > "syslog/tls transport mapping", but syslog version # is the one for > > syslog-protocol, they are diffirent numbers. > > > > When a receiver gets a message with a **syslog version number** it > > does not understand, it could save the message in local storage or > > forward to other receiver because it know exact the boundary of the > > message (actually a receiver does not have to understand > the version > > of syslog protocol in most cases, because the only task for > receiver is to store or forward). > > > > But, this may not apply to syslog/tls transport mapping. Diffirent > > **syslog/tls version number** may mean diffirent APP-DATA format. A > > receiver with a diffrent version may not be able to parse > the stream > > or delimit syslog messages, the only thing that it can do > is to save > > the tls stream in local storage if it is linient. But, > saving stream > > seems ugly, maybe more ugly than making tls alert to serve > > application:-) > > > > Thanks! > > Miao > > > >> -----Original Message----- > >> From: EKR [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, October 19, 2006 10:02 AM > >> To: Miao Fuyou > >> Cc: 'David Harrington'; [EMAIL PROTECTED]; 'Chris Lonvick' > >> Subject: Re: syslog/tls - how to abort because of inconsistent > >> versions > >> > >> Miao Fuyou <[EMAIL PROTECTED]> wrote: > >>> Hi, Eric, > >>> > >>> The primary reason to use a TLS level notification to > >> notify an event > >>> for application level is to keep Syslog still simplex, > but it seem > >>> violative to clear layership. An application notification > >> will change > >>> that simplex of syslog, which is alien to syslog. The wg > is in the > >>> dilemma to process this issue. > >>> > >>> Your sugestion? > >> > >> Well, I see that draft-ietf-syslog-protocol-17.txt > contains a version > >> #. What do you do if that is something you don't understand? > >> > >> -Ekr > >> > > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
