> -----Original Message-----
> From: Eliot Lear [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 26, 2007 11:46 AM
> To: Chris Lonvick
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Syslog] 3195bis before syslog-sign
> 
> Chris & all,
> 
> As you mentioned, Darren, Marshall, and I will produce an internet-
> draft
> that revises RFC 3195 (rfc3195bis).  As part of that effort we
envision
> accomplishing the following:
> 
>     * Obsoleting RAW and COOKED profiles.  The RAW profile has a
length
>       limitation that we have been told is not appropriate for
>       syslog-signed.  The COOKED profile has seen no uptake.  This
>       dramatically simplifies the draft.
>     * A new profile that has taken on the name of TARTARE will
>       essentially be RAW rev 2.  Messages sent with the TARTARE
profile
>       will conform to draft-ietf-syslog-protocol's syntax, and have no
>       length limitation.

I agree with Bazsi, multiple messages inside a single beep block need a
different framing. The question is if we drop the multiple message per
block capability. Beep framing is not inefficient per se...

>     * We will review existing security considerations.  For instance,
>       RFC 3195 calls for use of 3DES for TLS.  We propose that the new
>       draft take on a more modern approach with regard to algorithm
>       agility and which algorithm SHOULD be the low bar.
> 
> In our early drafty draft, we were unable to eliminate all references
> to
> RFC 3164, due to reference of security considerations seemingly not
> covered in draft-ietf-syslog-protocol. However, those references that
> remain are NOT normative.  If a complete separation for 3164 is
desired
> we will need to incorporate a few of those remaining concerns, where
> IMHO the existing text in 3164 is sufficient.

syslog-protocol had carried over all security considerations from RFC
3164. Those now missing have been removed because it was WG consensus
that these are not valid security considerations. I suggest consulting
the mailing list archive before mandating any of them.

If we now find that something essential has been removed, we should add
this to -protocol during IETF last call. This would be the place where
it belongs.

> 
> Finally, do people desire any other changes that would be considered
> necessary either for draft-ietf-syslog-protocol or for the forthcoming
> syslog-signed work?

I will think about this, but out of my head I do not see any change I
would desire. One thing that would potentially be useful is the
transport path indication that was available with COOKED. However, I do
not know of a single implementation (including mine) that acutally
supports it - it was a very complicated beast. So it is probably not
desirable to have it.

Rainer
> 
> We predict this work to progress rapidly.
> 
> Thanks,
> 
> Eliot
> 
> Chris Lonvick wrote:
> > Hi Folks,
> >
> > David Harrington and I had a talk about syslog-sign and its
> > dependencies upon 3195bis.  As was noted in the email discussion it
> > would be messy to try to publish syslog-sign with dependencies upon
> > 3195, then update 3195, then revise syslog-sign.  We had a talk with
> > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to
> > eliminate unnecessary dependencies.
> >
> > David and I are pleased to announce that Darren New, Marshall Rose
> and
> > Eliot Lear have volunteered to produce a revision to RFC 3195.  We
> > expect that this will be a transport for syslog-protocol so that
> > syslog-sign, and any other, future applications, can make use of
> > syslog-protocol without having to worry about transport
dependencies.
> > Other goals of 3195bis will be to deal with the length limitation in
> a
> > manner consistent with the other transports, and to eliminate
> > references to RFC 3164.
> >
> > We've have had an initial explanation of how the authors will revise
> > 3195 which sounds reasonable.  I will let Darren, Marshall and Eliot
> > propose the changes to the list.  This should be a quick effort so
> > please pay attention and discuss this on the list so we can get it
> > moving.
> >
> > Thanks,
> > Chris & David
> >
> > _______________________________________________
> > 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

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to