As someone who followed the recent syslog-protocol series right from the beginning and as someone who has implemented RFC 3195, syslog-transport-tls, syslog-transport-udp and syslog-protocol, and as someone whose implementations of said drafts are being used in practice by actual people... I think we have reached a good-enough series of drafts to publish.
Sure, there are a number of imperfections and some things could be more precisely specified. HOWEVER, we can always do a second revision. What we have right now is good enough for most needs and flexible enough to be extended. There are also a lot of folks waiting on the completion of this work. I strongly propose that we do a -transport-tls-13 based on Joe's recent text proposal. I'd appreciate if that -13 would remove the MUST on ipAddress. But even if it does not, one can live with it. Once -13 is published, I suggest we continue to work on 3195bis, which is already posted, solves a lot of issues but needs a bit of polishing. Based on our desires, we may also do a lot of other things. PLEASE LET US FINISH THE CURRENT WORK *NOW*. I myself have already departed from the standards way by implementing my own proprietary protocol, and more and more people will follow the non-standards route if we do not deliver anything. Given the silence of almost all other implementers on this list, I think I am not the only one who did so. Remember that the first draft of the current series was published in 2003, which was five years ago. If we wait another five years, I think there will no longer be a need for what we specify, because everybody will use something else (just think of the widespread use of proprietary TLS protected plain tcp syslog because we did not manage to get a document out when there was demand for it...). Netconf notifications, for example, would probably not have been necessary if there would have been a decent syslog standard 2 years ago (and we could have been finished 3 (!) years ago if we hadn't blown the nearly finished doc set in a meeting for reasons I still find hard to understand). Rainer > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 05, 2008 7:49 AM > To: tom.petch; Rainer Gerhards > Cc: syslog > Subject: RE: [Syslog] -transport-tls references to "matching rules" > > Hi Tom, > > I think it would be useful to have recommendations for generic > application over TLS. I don't think all applications would be the same, > but I think there could be some common guidelines. I don't think we > should hold up the TLS syslog draft for this. > > Joe > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 02, 2008 1:15 AM > > To: Rainer Gerhards; Joseph Salowey (jsalowey) > > Cc: syslog > > Subject: Re: [Syslog] -transport-tls references to "matching rules" > > > > Replying to myself, and apologies to those who got my first, > > mangled attempt at this, > > > > I have just read > > > > draft-ietf-netconf-tls-02.txt > > > > which covers an almost identical territory to transport-tls > > but with server and client roles reversed; well worth a read. > > > > Where we used to refer to RFC2818, it refers to RFC4642 > > (which itself considers relays). > > > > It has a reference to RFC5280 and specifies section 6 for > > certificate paths. > > > > It does not consider fingerprinting. > > > > It does not consider alternatives to hostname. > > > > <rant> > > As I have said before, I see a crying need for a generic > > 'application over ...' I-D for others - like me - to draw > > on and reference, lest we keep inventing our (less than > > round?) wheels. > > </rant> > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
