Subject: [Syslog] RFC 3195bis?

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 22 Dec 2006 15:55:50 +0100

Hi all,

now that we obsolete RFC 3164 by -syslog-protocol, the only remaining
RFC that is not compatible to the "new syslog series" is RFC 3195. The
questions is now how to proceed here? I am raising this issue because it
has some effect on syslog-sign. I would love to see 2k as limit for
sign-generated messages, but that means we need to talk about 3195
(which not explicitely supports messages over 1k).

IMHO, we should do a 3195bis that updates 3195 to work as a transport
mapping with syslog-protocol. After we've done that, we have finally
unified all syslog RFCs and do not have any more issues with
incompatibilities between them. I think this is something we should do
soon.

Comments?

Rainer
PS: I, too, would like to express my seasons greetings to all folks on
the list! May you have a great and peaceful xmas time and a good start
into the new year.

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 22 Dec 2006 07:30:34 -0800 (PST)

Hi,

The Chairs have been discussing this already.  We have a candidate to 
write the update.  The length limit in RFC 3195 was constrained by RFC 
3164 and we have moved beyond that with the transport IDs which identify 
realistic maximum lengths.  Updating RFC 3195 to have a greater length 
should not be a problem.

HOWEVER...  We need to focus on syslog-sign and syslog-device-mib BEFORE 
doing this.  Once we get the shepherding documents for those IDs sent to 
the IESG _THEN_ we can discuss 3195bis.

Thanks,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 22 Dec 2006 17:11:59 +0100

> the IESG _THEN_ we can discuss 3195bis.

The problem is that -sign is related (even depending) on 3195. This is
why I brought up that issue.

Let me explain. syslog-sign recommends 2k for signature and payload
blocks. It does so, because it assumes (rightly for the new series) that
2k can be handled by almost every receiver, so there is no problem in
using that length. However, if we require that -sign works together with
3195, we must lower this limit to 1k. I would not like to see this
happen because 2k makes much sense and is much more efficient. 3195 does
not seem as important:

- it is due for update
- there has only been an extremely limited set of implementations
- none of the major vendors has implemented it
- there is no (not "virtually no"!) customer demand for it at the 
  time being (I know this because I have implemented RFC 3195)
- the only customer demand comes from IHE, but for IHE it is not
  usable because it still contains a too-rigid length constraint

In short: the current RFC 3195 is not really in use. An updated version
may. I think we should not sacrifice the 2k limit for something that is
not being used.

So my propsal is: we should remove RFC 3195 from syslog-sign as well. It
should simply reference -syslog-protocol and its transport mappings. RFC
3195bis will most likely be a transport mapping. Thus, -sign can cover
it without specifically mentioning it. This works exactly as the new
series is designed. Transports are below -protocol and sign is in the
layer above it. So there should be no dependencies between -sign and the
actual transports used.

If we take that route, we only lose the ability to use -sign *reliably*
with RFC 3195 as it is today. Given the fact that nobody is actually
using 3195, this is not a huge loss ;). It also finally de-couples -sign
from any other transport RFCs - and this was a major intention about the
whole effort of the new syslog series.

I suggest we all have a look at this slide from 2004:

http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html

Rainer

> > questions is now how to proceed here? I am raising this issue
because
> it

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 22 Dec 2006 08:22:45 -0800 (PST)

Hi,

I'm OK removing references to RFC 3195 from syslog-sign for the points you 
mention.  I'd welcome other opinions.

I agree that RFC 3195 is due for an update but I disagree with most of 
your other points.  A major vendor has found customers requesting it and 
has implemented it.
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html

Thanks,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 22 Dec 2006 17:37:39 +0100

Ah... interesting. I knew that Cisco had something brewing, but I never
heared that it was released. I still agree with you that 3195 should not
specifically be mentioned by -sign. I assume that implementing 3195bis
(when available) is probably not hard if you implemented 3195.

Rainer 

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Friday, December 22, 2006 5:23 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: RE: [Syslog] RFC 3195bis?
> 
> Hi,
> 
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a
> 00807883c3.html
> >> doing this.  Once we get the shepherding documents for those IDs
> sent
> >> to
> > So my propsal is: we should remove RFC 3195 from syslog-sign as
well.
> It
> >>> incompatibilities between them. I think this is something we
should
> >> do
> >>> soon.
> >>>
> >>> Comments?
> >>>
> >>> Rainer
> >>> PS: I, too, would like to express my seasons greetings to all
folks
> >> on

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Fri, 22 Dec 2006 12:21:52 -0500

Much of the reason 3195 is specified is because there is no good
alternative. Healthcare has been asking for a stable standard that gets
implemented for 4 years now. It is getting hard to justify this
allegiance to the syslog community. There are many in the healthcare
community that want to define their own transport for security audit
events using Web-Services. Please stop the over-analysis, get the
standards you have in the queue out, and please get them implemented.

John Moehrke
GE Healthcare
And major contributor to IHE-ATNA, DICOM-Supplement-95, RFC-3881, and BS
ISO 27789.
http://wiki.ihe.net/index.php?title=ATNA_Profile_FAQ

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, December 22, 2006 10:38 AM
> To: Chris Lonvick
> Cc: [email-masked]
> > I'm OK removing references to RFC 3195 from syslog-sign for 
> the points
> > you
> > >> The Chairs have been discussing this already.  We have a 
> candidate
> > to
> > >> write the update.  The length limit in RFC 3195 was 
> constrained by
> > RFC
> > > The problem is that -sign is related (even depending) on 
> 3195. This
> > is
> > > blocks. It does so, because it assumes (rightly for the 
> new series)
> > that
> > > using that length. However, if we require that -sign 
> works together
> > with
> > > happen because 2k makes much sense and is much more 
> efficient. 3195
> > does
> > > not seem as important:
> > >
> > > - it is due for update
> > > may. I think we should not sacrifice the 2k limit for 
> something that
> > is
> > > not being used.
> > >
> > > should simply reference -syslog-protocol and its 
> transport mappings.
> > RFC
> > > layer above it. So there should be no dependencies 
> between -sign and
> > the
> > > actual transports used.
> > >
> > > using 3195, this is not a huge loss ;). It also finally 
> de-couples -
> > sign
> > > from any other transport RFCs - and this was a major 
> intention about
> > the
> > >>> RFC that is not compatible to the "new syslog series" 
> is RFC 3195.
> > >> The