RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part 1

["Sharon Chisholm" <schishol@nortel.com>]

hi

Here is part one of my response ....

<Rainer>
> 
> G2 - Not much is said about change control and backwards
> compatibility other
> than the discussion buried in  A.2 which seems to imply there 
> isn't any. I
> propose the following:
> 
> G.2.1. Make a statement to set expectations about change
> control within the
> body of the document.
> 
> G.2.2. Suggest two levels of expectations - one for the
> header, which is
> governed by the version number and one for the SD-PARAMs 
> which should be
> somewhat independent of it. I recommend that people try not 
> to break things
> in the SD area within a version and between versions. Same 
> name has same
> general semantics. If not a MUST, this needs to be a SHOULD. 
> I vote for
> MUST.

I added some descriptive text to 6.2.1 (VERSION). But I think it already
covered that no header modifications are allowed. So some folks on this list
might reject this as a duplicate.
</Rainer>

I think the only duplication in the text is in the way it was phrased.
Suggest the following replacement.

"The VERSION field denotes the version of the syslog protocol
   specification.  The version number MUST be incremented for any new
   syslog protocol specification that changes any part of the HEADER
   format.  Changes include addition or removal of fields or a change 
   syntax or semantics of existing fields. This document uses a VERSION
   value of "1".  The VERSION
   values are IANA-assigned (Section 10.1). "


<Rainer>
For STRUCTURED-DATA, I have added the following new section:

###
6.3.4  Change Control

   Once SD-IDs and PARAM-NAMEs are defined in a specification and their
   IANA assignment has been done, syntax and semantics of these objects
   MUST NOT be altered.  So they begin to exist with their initial
   definition and are never allowed to change.  Should a change to an
   existing object be needed, a new one MUST be created.  It is advised
   to use a name the reflects the close relationship between the two
objects.
   For example, if the semantics of the "tzKnown" PARAM-NAME were to be
   changed, a good name for the new element would be "tzKnown2". ###

</Rainer>

This behaviours should not be made so specific to the ones allocated by
IANA. And the bit about the naming does not seem necessary. 
Suggest the following replacement:

"  Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of these
objects
   MUST NOT be altered.  Should a change to an
   existing object be desired, a new one MUST be created and the old one
remain unchanged."

<Rainer>
> S1. In section 6, what is the relationship between Facility
> and MSG-ID? They
> seem to serve the same purpose. Is Facility just historical? 
> Is MSG-ID what
> we need to use moving forward? (see G3)

I added this text to the description of FACILITY:

####
It is RECOMMENDED that the facility
reflects a type of subsystem, something that a number of different messages
might be issued from. So it is a kind of corase group. ####

Does this clarify? Do we need to add similar text to MSGID (in that it
identifies a specific message)? To keep it short, I've not done this yet.

</Rainer>

Now I'm left wondering how this relates to a category. 

<Rainer>
> 
> S2. Is the length of SENDER-NAME and SENDER-INST sensible?
> SENDER-INST seems
> way too short. Consider needing to name something which is 
> the concatenation
> of two IP addresses. It does not fit. Remember this is the 
> encoding the
> string, not the integer. We will end up forcing people to 
> make up something
> which does fit instead of using something existing.

Actually, SENDER-NAME and -INST are not meant to be IP addresses. We have
HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should identify the type
of sender, most probably a process name or something similar (like
"postfix", "su" in current messages in TAG). I think the size is sufficient
for this purpose. Given the size limitation we have in UDP based syslog, I
would like to keep the HEADER size as small as possible. Obviously, we
should not sacrifice things for a short size, but I think we do not need the
longer sizes here.
</Rainer?

I think you misunderstood my example. This was not the IP address of the
originator, but a pair of IP addresses that indicated the instance of
something which is referenced using a set of (different) IP address. What
exactly is a 'process name' suppose to be in IETF land? While I appreciate
the need for backwards compatibility with deployed syslog, I think we need
to understand how this naming can be used in a router and how it maps to
traditional IETF naming. I think some of the more intuitive ways we have to
name things won't fit in the size indicated. Or is instance really not an
instance and that is the disconnect?

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec