RE: I-D ACTION:draft-ietf-syslog-protocol-04.txt

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Anton,

I am on the road with bad connectivity, so it took some time to get to
this..

> From a quick glance, it seems the max length is not specified although
> somewhere there is a reference to section 4 for it.

I don't have access to the published draft right now, but at least it
was supposed to say "max of ~16MB". I'll check ASAP and eventually
re-adjust. It should also say "keep it below 499 bytes".

>
> Definitions & Architecture sections talks about senders and receivers,
> which is good, but still has the picture with various relay/collector
> stuff.  Are you planning on removing it?

Well, if there is strong objection, I can remove that. But I think it is
better to keep it in, because it defines names for several roles - this
may make it easier in the future to use the same name for the same
thing.

>
> Again, I have a problem with a term "machine can generate".  I think
> we need to refer to applications or processes.  Syslog is not a
> protocol for "machine-to-machine" (host-to-host) communication only.
> Like we said before, receiver and sender can be on the same machine.
> So, we have applications or processes interacting, not "machines".  I
> think we need to mention that multiple senders and multiple receivers
> can co-exist on the same host.  A particular transport protocol can
> impose restrictions on receivers. In my sec, I say that receiver MUST
> support listening on a standard syslog port and MAY listen on another
> port.

I basically agree - I've not re-worded this so far, because I am
focussing on the other things, first. I thought, however, that the
description of the relay with the original sender process already
covered at least some of this idea... But definitely not enough of it ;)

> Why do we default to IPv6 unknown IP?  It is longer.

I can change this, but I think/hope some time IPv6 will look more
natural - no other reasoning for this.

> I also don't
> understand the value of distinguishing the IPv4 unknown IP and IPv6
> address. It is still unknown.  It also creates ambiguity, what is the
> stack supports both.

I found this possibility while describing the scenarios. I can remove
it, if that is concensus.

> "The TAG is used to denote the process sending the message."  Should
> this be a MUST?

I pass this on to the list... It sounds good, but doesn't we need to
create a TAG value repository in this case?

>
> "The static ID SHOULD always remain the same for a given sender
> process."  I think you mean "application" here.  The process is a
> specific instance of an application which is identified with dynamic
> part, right? If you referred to process name, then it is the same for
> different process instances.

You are right, "application" is the right term here.

>
> "The full-dyn-id SHOULD change with each new instance of the sending
> process." SHOULD or MUST?

Strongly opt for SHOULD - else you need to make sure that the OS does
not accidently assing you the same PID as a previous process. And, yes,
I agree this is extremely unlikely, but it is a possibility...

>
> "Traditionally, the full-dyn-id should reflect the process ID of the
> new instance."  I think the word "traditionally" implies we are trying
> to follow some established standard, but there is no such thing.
> "Traditionally... Should..." does not sound right.

Agree, "traditionally" needs to be removed. SHOULD must be upper case.
The rest - I think - is right.

>
> I know you wanted to keep some resemblance of the old ad-hoc syslog
> format, but two separate fields for TAG would make life much easier
> then having to find the last [ and only if there is ] at the end.  If
> we make two fields, they would be APP-NAME (or PROCESS-NAME) and
> PROCESS-ID.  This is much more intuitive then describing it as static
> vs. dynamic. And this is what people are after in the end. We could
> allow for say "-" for unknown process ID. But I think requiring
> APP-NAME is a must. What do you think?

That sounds good - I actually did not have this good idea. If there is
no objection, I'll change it to this in the next draft.

Rainer