We actually agree about 98%. My main beef is that the current syslog-auth stuff is not solving the whole problem by just doing hop-by-hop and private key. I strongly believe that a framework for cradle-to-grave message signing and confidentiality. I also believe that it is easier to add this to what's already in Syslog-Reliable than to what's in Syslog-Auth from what I know about both. So, the question remains whether Syslog-Auth is really needed as a seperate entity if this stuff is added to Syslog-Reliable. My feeling is that it is not needed, but I'm open to the opinion of others. As for formatting, I fully understand that the formatting stuff needs to be published seperately (though it's probably no use publishing it until syslog-reliable is done as it provides part of the framework that the formatting stuff will plug into). What's frustrating to me is that the original xml-log proposal of nine months ago handled not just formatting but also message reliability, confidentiality, and integrity and seeing how things are going now makes me keep slapping my head and saying 'how come we didn't just strip the formatting stuff out of the original proposal and use that nine months ago instead of spinning our wheels all this time?' In reality, I know the answer to this which is that it's taken the past nine months for the train to move this far aheaed (for all sorts of reasons of historical baggage), but it's still frustrating. To summarise.... 1. I believe the right thing to do is to add message confidentiality and integrity capabilities to Syslog-Reliable. Hop-by-hop 'received by' stuff is also a possibility. 2. Once this is done, then it will be reasonable to publish something discussing formatting of things not covered by syslog-reliable. 3. It's not clear to me whether syslog-auth is needed at all once Syslog-Reliable can do confidentiality and integrity. More discussion is needed on this topic. 4. The whole thing is a process and the train can take unexpected twists and turns. We shouldn't stick to any set idea of what ID's should cover what.
begin:vcard n:Calabrese;Chris tel;work:201-703-7218 x-mozilla-html:TRUE org:Merck-Medco Managed Care, L.L.C.;Internet Infrastructure and Security adr:;;1900 Pollitt Drive;Fair Lawn;NJ;07410;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Internet Security Administrator fn:Chris Calabrese end:vcard
