[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] IETF 60 Meeting and WG Mailing List
David:
Thanks for the reply... I think for the most part we are on the same
page. Comment below.
> I have not reviewed the new drafts yet.
>
> I strongly dislike "standards" that say "do it however you
> want." A standard should standardize the behavior to be
> consistent and predictable. Therefore I would like to see us
> choose either application-layer-fragmentation or
> transport-layer-fragmentation, but not both.
I understand you point. Well, really, what I propose is not a bunch of
options. Either use small messages or... Use syslog implementations
which support fragmentation or... If you have good reasons not to the
use above, you are on your own, but nothing prevents you from doing
application-level fragmentation on client side, provided you know how
to deal with these messages on the other side. So, the last option is
possible, but is outside of our scope.
> If the transport-layer-fragmentation to which you refer
> requires the transport layer to understand syslog messages in
> any way, or even require the transport layer to know that a
> given payload *is* a syslog message, that would be a
> violation of the layering principle, and would seem to be a
> bad choice.
No, in current draft, current transport layer only needs to understand
transport header, and it treats syslog messages as generic payload.
Indeed, layer isolation is a key goal. This is also why I do not like
the idea of copying syslog message header in all transport fragments.
This would have allowed relay to make forwarding decision based on
this data without re-assembly, but would require the transport layer
to understand the payload (which has variable size fields).
> Short messages impose the least on both the sender and
> receiver implementations, and should be preferred unless
> short messages really cannot do the job adequately.
Transport layer recommends short messages.
> Application-layer-fragmentation would seem to require the
> user/developer to do more work to fragment messages, rather
> than "passing the buck" to the transport layer. This might
> lead vendors to use shorter messages, where adequate, to
> avoid having to do the fragmentation, which I would view as a
> good thing.
Yes, but by that logic, if we make syslog hard to use, this may also
encourage people to use something else altogether. I'd rather not
create deliberate obstacles.
> Using the 90/10 rule, I suggest making support for
> long/fragmented messages optional (despite my belief that
> standards shouldn't say "do what you want").
It is optional in the transport. It is only required for messages over
certain size and implementations are not required to support larger
messages. If some application needs to send large messages, the
administrators will have to ensure that it is deployed in an
environment with appropriate implementations. Same thing as with UDP.
Yeah, by protocol it supports 64k payload. But you better know that
your client, server and all networking devices in between support
these large messages. Until recently you have would have been hard
pressed to find many combinations that would.
> Most
> implementors will support short messages, and they will be
> adequate for 90% of users. For those 10% of device vendors
> who believe long messages are really important, and those 10%
> of receivers that believe supporting long messages is
> important, they can suffer the additional expense of
> supporting this at the application-layer, without forcing all
> implementations to support it.
I agree with 90-10 rule, but I have proposed a different way of
dealing with the 10%. Basically, fragmentation is in the transport,
but it is optional. I think this can ensure better interoperability
because people are not going to have to invent application-specific
fragmentation. Even if we standardize application-level
fragmentation, the log analyzers would then need to be able to
understand that. All of a sudden fragmentation creeps in deeper into
various applications instead of being shielded in a some lower layer.
> My $.02
Thanks!
Anton.
>
> dbh
>
> > -----Original Message-----
> > From: syslog-sec-bounces@www.employees.org
> > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > Anton Okmianski
> > Sent: Wednesday, June 16, 2004 10:56 AM
> > To: syslog-sec@employees.org
> > Subject: RE: [Syslog-sec] IETF 60 Meeting and WG Mailing List
> >
> > Here is my update on syslog-transport.
> >
> > After posting the last draft, I have not received any
> > substantive comments. But I had quite a few on the pre-draft
> > version. Seems like the draft satisfied all the concerns
> > raised against the earlier versions.
> >
> > Rainer & I talked about his concerns with doing fragmentation
> > the way we do it now in transport. He would prefer to do it
> > using structured content within syslog message like the
> > earlier proposals or some other scheme that pushes the
> > re-assembly on the log processor (analyzer) instead of every
> > party in transmission (potentially including syslog relays).
> >
> > I am not sure we reached complete consensus yet. But I think,
> > with fragmentation being optional now (only required for
> > messages over certain size), both approaches can co-exist.
> > People can use structured content as they please and break
> > messages, or they could use a syslog transport implementation
> > which supports fragmentation. Or just use small messages and
> > forget about all of this.
> >
> > Other than this, the syslog-transport draft is ready to go.
> >
> > Thanks,
> > Anton.
> >
> > > -----Original Message-----
> > > From: syslog-sec-bounces@willers.employees.org
> > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf
> > Of Rainer
> > > Gerhards
> > > Sent: Wednesday, June 16, 2004 5:44 AM
> > > To: syslog-sec@employees.org
> > > Subject: RE: [Syslog-sec] IETF 60 Meeting and WG Mailing List
> > >
> > >
> > > Hi Folks,
> > >
> > > a quick status update from my side. I've been out of office
> > for quite
> > > a while and I am now coming back to real work (after a pile
> > of email).
> > > I will create a new draft within the next 3 weeks or so.
> I'd really
> > > appreciate any more comments if there are. I will work
> through past
> > > comments soon.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: syslog-sec-bounces@www.employees.org
> > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
Chris
> > > > Lonvick
> > > > Sent: Monday, June 14, 2004 7:56 PM
> > > > To: syslog-sec@employees.org
> > > > Subject: [Syslog-sec] IETF 60 Meeting and WG Mailing List
> > > >
> > > > Hi Folks,
> > > >
> > > > I've been trying to get the IETF people to set up a WG
> > mailing list
> > > > for us to replace the one on employees.org. I believe that
I've
> > > > sent them all of the information but I havn't heard back
> > from them
> > > > in a few weeks.
> > > > However, it appears that employees.org has gotten a new lease
on
> > > > life and so I'll continue here until I get something
> going on the
> > > > IETF machines.
> > > >
> > > > I've had a discussion with Anton and Rainer. It looks
> > like both IDs
> > > > are getting close to being finished. I've asked them to
> > wrap up any
> > > > remaining issues and let's get this into WG Last Call.
> > We need to
> > > > do a nit check but I'm very hopeful that we can get them
> > to the IESG
> > > > in a few weeks. I think that our time will be better
> > spent in this
> > > > work rather than
> > in
> > > > preparing for the meeting in San Diego. As such, I'd like to
> > > > propose that we not have a meeting in San Diego. Please
> > watch for
> > > > the new IDs to be posted and please comment upon them.
> > > >
> > > > Thanks,
> > > > Chris
> > > > _______________________________________________
> > > > Syslog-sec mailing list
> > > > Syslog-sec@www.employees.org
> > > > http://www.employees.org/mailman/listinfo/syslog-sec
> > > >
> > > _______________________________________________
> > > Syslog-sec mailing list
> > > Syslog-sec@www.employees.org
> > > http://www.employees.org/mailman/listinfo/sysl> og-sec
> > >
> >
> > _______________________________________________
> > Syslog-sec mailing list
> > Syslog-sec@www.employees.org
> > http://www.employees.org/mailman/listinfo/syslog-sec
> >
>
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec