Anton,
many thanks for your well thought-out mail. My apologies that I provide
a more general answer. I see a lot of truth in your thoughts. I support
some of them, on some I have a slightly different opinion. But I think
the big question is *when* to do all that.
The last thing this WG published was RFC 3195, in November 2001. Since
then, we have done
- 18 revisions of syslog-sign
- 7 revisions of syslog-mib
- 17 revisions of syslog-protocol
- 7 revisions of syslog-transport udp
- 2 revisions of syslog-transport tls
We have had big discussions, we also have been re-iterating some issues
ever and ever again. We have missed charter milestones repeatedly. We
are are also (rightfully, IMHO) threatend by the IESG announcement that
the WG will be concluded if we will miss our current milestones again.
So while I agree there is lot that could be changed, I also think we are
in the deperate need to finally publish.
The current approach documented in -protocol and -udp might not be
perfect, but I think it is a good-enough compromise. What I suggest is
that we do not touch any essentials of these documents, at least not
now. Let's look at finishing a secure transport, so that we actually can
publish. RFC 3195bis with the few alterations I described still looks
like a good candidate to me. One reason for this is that some companies
have made investment into RFC 3195. If we now do not do 3195bis, we will
actually render their investment useless(because unmodified 3195 will
not be able to be used with -protocol). It is minimal effort to update
3195. I suspect this helps preserve some considerable investment. So we
should do it - but without touching the basics, just adopting it. Much
of the same reasoning applies to syslog-tls, except that existing
investment (in terms of effort required) is much lower. -transport-ssh
might also be a good alternative. But I have some concerns to create it
with a too simplistic framing, just to get it finished. If it is
something being done from scratch, it would pay to do it right in the
first place.
I have also begun to very seriously look at the netconf documents and
watch the discussion that's going on there. NETCONF is talking much
about event notifications these days. I begin to like the NETCONF way of
doing things and think we can at least adopt some things from there. I
highly suggest people from this WG to watch what NETCONF is doing.
My proposed course of action is as follows:
We should do NOW:
1. minor edits to -protocol and -transport-udp as need arises
2.1 update 3195 to 3195bis [I volunteer to do that if the original
authors are not available]
2.2 (finish -transport-tls) [interest in this might be affected by IPR
claim)
PUBLISH
As soon as 2.1 or 2.2 is finshed, we should publish this work. Do not
wait for the non-finished 2.x part. My preferrence is to focus on
updating 3195 because there is existing investment to be preserved.
We should do THEN:
1. More transports
- think about a generic stream framing
[after thoughtful consideration, I am again
of the opinion that a -transport-stream is useful]
I volunteer to write this and already have some ideas.
- define syslog-transport-ssh via transport-stream
I already have written a rough proposal which I consider
to be a starting point.
- define/update syslog-transport-tls via transport-stream
- eventually update RFC 3195bis to support
-transport-stream semantics and the data model
in 2. below
2. think about a data model for syslog messages
[probably best done in the OPS and not the SEC
area of the IETF]
3. eventually update -protocol to cover XML STRUCTURED-DATA
[may be a side-effect of 2. above]
If you follow my proposal, you see that some work is done twice. For
example, I accept to publish -protocol as it is today but revisit it
some time in the not so distant future. One can argue that this leads to
implementation effort that would not necessarily be needed if we wait
for the "final" version. HOWEVER, experience tells me that there is
never something like a "final version". You even always can do things
better. But if you always wait for the best solution, you will never
have any solution in the first place. This is where I think this WG is
heading to.
I suggest that we accept our faith and publish the imperfect (but
well-discussed) drafts we currently have. We should try to do this ASAP.
I have a strong argument on my side: if we do not do that by the end of
the year (which quickly approaches), we will not publish anything - of
course that avoids publishing imperfect draft but at the price of never
publishing "perfect" ones. The current state of non-standardization is
by far worse than publishing what we have. We are also beginning to
hinder other standardization efforts (namely NETCONF) because they are
refering to I-Ds which we discuss eternally ;)
I hope this clarifies my position on the big picture. I would really
appreciate if we could concentrate on publishing. Again, I strongly
suggest to create 3195bis, satisfy the IETF secure transport criteria
with that, PUBLISH and then carry on with all the well thought-out ideas
we have.
Rainer
> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 26, 2006 11:50 PM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] IESG secure transport requirement can
> be quickly solved...
>
> 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
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
>
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
