Rainer:
A few thoughts on 3195bis. Generally, I like the idea of app-layer ACKs.
1. I think the format would need to be changed a bit more than you suggested.
If you do XML, you should do it all the way -- not mix it with special
delimiters. Structured data, for example, should be encoded as normal XML
using separate tags instead of text separators as in syslog protocol. This
means it can't go as an attribute in entry tag. It needs separate tags.
Possibly something like:
<Message>
<Header>
<SourceIP>...</SourceIP>
<Date>...</Date>
<Path>
<PathEntry>...</PathEntry>
</Path>
<Tags>
<NamedTag>
<TagName>aaa</TagName>
<TagValue>bbb</TagValue>
</NamedTag>
</Tags>
</Header>
<Body>
...
</Body>
</Message>
Basically, you will need a new XSD. BTW, I can't find XSD for 3195.
2. XSD needs to be defined in a way that allows extensions in headers and body.
For example, XSD could support Body as anyType allowing the use of simple
strings or inserting XML there without escaping it. I am not clear if currently
XML in <entry> tag has to be escaped in 3195bis.
3. If you allow custom XML payload, people could use this as a transport for
events defined elsewhere, enabling syslog to become really more about
transport. For example, IBM contributed their extensive XML schema for events
to OASIS. See CBE format announcement:
http://xml.coverpages.org/xmlPapers200308.html#IBM-CBEvent
4. If one defined XSD and all, should we consider defining a standard WSDL
(same XSD as above) and switch to standard SOAP over HTTP mapping instead of
BEEP. You just need to define 4 messages:
ClientIdentity(ClientIdentity) - "iam" equivalent
ClientIdentityResponse(Status)
ReportEvent(Message) - "entry"
ReportEventResponse(Status)
(Client identity could be included in Message for simplicity - reduces this to
two RPCs.)
I think this would have greater chance of being adopted than XML over BEEP.
WS-I.org has developed a lot of interoperability and security profiles (TLS)
for SOAP already and a bunch of tools to validate it. As a result, you can use
any number of free high-quality interoperable libraries off the shelf.
I can generate sample WSDL if it helps people think about this. WSDL being a
formal specification of protocol messaging and with abundance of good quality
WS-I specs to reference the draft could be pretty streamlined. Given sufficient
interest in WG, I could throw some rough draft together pretty quickly.
Basically, I think if we do XML-based RPC mechanism, doing something other than
SOAP over HTTP is really not aiding interop. Sorry to stir the pot with further
alternatives. :(
Thoughts?
Thanks,
Anton.
> -----Original Message-----
> From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 20, 2006 9:44 AM
> To: [EMAIL PROTECTED]
> Subject: [Syslog] IESG secure transport requirement can be
> quickly solved...
>
> Hi all,
>
> I propose to update RFC 3195 in the spirit of syslog-protocol
> to satisfy
> the IESG secure transport requirement (I will call this
> derivative work
> RFC3195bis below). I sincerely believe that this option would
> enable us
> to submit syslog-protocol, -transport-UDP and RFC3195bis within a few
> weeks.
>
> My reasoning for this proposal is as follows:
>
> We all know that 3195 has limited acceptance in the community and very
> few implementations. However, it satisfies all IESG criteria
> we have in
> our charter. Also, it *is* something that can be used in practice and
> implementing it becomes easier as support libraries become visible. I
> know it is not an optimal choice. On the other hand, we have
> syslog-transport-tls, which has been encrumbered by a patent claim. As
> it looks, this will need months to solve. RFC3195bis can not be taken
> hostage by any patent claims, because there is well-defined
> prior art in
> RFC 3195. Focussing on RFC 3195bis would enable us to complete our
> mission and finsh work that is in the queue for many years
> now. I think
> this is urgently needed. We might even put the netconf WG with their
> syslog gateway on hold (because syslog-protocol can not be published
> without resolving the secure transport). Or netconf might
> choose to drop
> syslog-protocol in order to publish.
>
> And the good news is that 3195bis can definitely very quickly
> be done. I
> am saying this on the assumption that we do not revisit the basics of
> 3195 but just adopt it to syslog-protocol. I've gone through
> 3195 today
> and the changes are absolutely minimal:
>
> Section 2:
> Most of it simply needs to be removed because the entity roles are
> defined in syslog-protocol.
>
> Section 3:
> - the message samples must be upgraded to -protocol-format
> - syslog-framing in section 3.3 must be changed (could be
> octet-counting
> or disallow of multiple messages per ANS, what I recommend)
>
> Section 4:
> 4.4.2
> - needs to be updated with the new HEADER fields and STRUCTURED-DATA
> - some work on "deviceFQDN" and "deviceIP" needed
> - some transformation rules (page 15) need to be removed
> - handling of invalid message formatting must be removed (no longer a
> concern)
> - samples must be adjusted
>
> 4.4.3
> - sample on page 24 (top) must be checked and/or adjusted
>
> Section 7:
> - DTD needs to be adjusted
>
> Section 9:
> - new URIs for 3195bis (also in some other places)
> [we can reuse well-known port 601 for -protocol]
>
> Overall
> References to 3164 must be changed to -syslog-protocol. This
> seems quite
> trivial, because the references are easy to spot and do not touch any
> substance (except outlined above).
>
> Other than these minor things, there are *NO* other changes necessary.
> I'd expect that an initial version of 3195bis can be created within a
> single working day. Add some quick review and a very limited number of
> edits to change discovered nits - and we have something to publish by
> summer.
>
> I find this extremely tempting. It breaks the deadlock
> situation we are
> currently in. Especially as we have planned to do 3195bis some time
> later anyhow. I don't know if the authors of 3195 would
> volunteer to do
> the edit. But I hope so.
>
> I would appreciate if the chairs could try to reach consensus on my
> proposal.
>
> Comments are appreciated.
> Thanks,
> Rainer
>
> _______________________________________________
> 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
