[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt



Hi,

After some other reading of syslog-protocol-11 I have encountered some
new problematic items.

Let me start with minor issues

--------------
6.2.8  PROCID

   The PROCID field MAY by used to provide the sender's process ID.
--------------

s/by/be/


--------------
       7.3.1   sequenceId
       7.2.2   enterpriseID
--------------

Should not we use a consistent PARAM-NAME naming scheme ? Id or ID for
both.


--------------
(from grammar)
      HOSTNAME        = 1*255PRINTUSASCII  ; a FQDN
--------------

According to "6.2.6 HOSTNAME", the HOSTNAME field does not always
contain a FQDN.



Now more important issues to my point of view

--------------
   In the case that truncation cannot result in a valid message then the
   message SHOULD be dropped.  As the MSG part of the message is free-
   form and receivers MUST be able to accept messages up to and
   including 480 octets in length, truncation according to 3) should
   always be possible and as such no dropping SHOULD actually occur.
--------------

Why put a requirement on an impossible situation ? A syslog message can
always be truncated, and the result is always a valid syslog message. I
can't understand why this SHOULD is in the draft.


--------------
     SD-ELEMENT      = "[" SD-ID 0*(1*SP SD-PARAM) "]"
--------------

I am seeing two problems in this line. The first one is trivial,
according to RFC 2234 "0*" is redundant, * is sufficient. By removing
the '0', notation is more homogeneous (think about *SD-ELEMENT for
example).

Secondly we can see that more than one SP is allowed between SD-PARAM.
In all other places of this draft, fields are delimited by one and only
one SP. Why are we allowed to put any number of SP character we want
here ? 

IMHO, to be consistent, one and only one SP character must be allowed.



That's all for today :-)
I am hopping that this post will be useful to improve syslog-protocol

Clément MATHIEU

_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec