Hi Folks,
I've done a review of draft-ietf-syslog-protocol-13 and have the following
comments. I'd like to ask Rainer to incorporate them along with any other
final comments and publish a new version. Once this is in the ID
repository I will call for WG Last Call for two weeks. If we don't get
any major issues from that then I'll submit it to the IESG with the
recommendation that it be considered for publication. I'll be doing a
review of syslog-transport-udp as well.
References are not allowed in the Abstract. Suggest change:
This document has been written with the spirit of RFC 3164 [14] in
to:
This document has been written with the spirit of tradition syslog in
Keeping the reference in the Introduction is OK.
"Conventions Used in This Document" should be:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
(That's how it's written in RFC 2119.) In some cases the keyword
"optional" should be in uppercase in the document - like in several places
in Section 7.
Double dashes in Basic Pricipals are not to be used. Suggest change
o Relays may send all or some of the messages that they receive to a
subsequent relay or collector. They may also store -- or
otherwise locally process -- some or all messages without
forwarding. In those cases, they are acting as both a collector
and a relay.
to:
o Relays may send all or some of the messages that they receive to a
subsequent relay or collector. They may also store or otherwise
locally process some or all messages without forwarding. In those
cases, they are acting as both a collector and a relay.
Also, this is not entirely clear. Perhaps it should be changed to:
o Relays may send all or some of the messages that they receive to a
subsequent relay or collector. They may also store or otherwise
locally process some or all messages without forwarding. In the
case where a receiver stores some messages and relays some
messages, it is acting as both a collector and a relay.
Watch the contignuity of the diagram 1 and its title. Make sure that
they are not separated by a page break. The RFC editor will also
watch this.
In Section 6.1 "Message Length", the following paragraphs may be clearer
if they are reversed:
If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA
field MUST be changed to "-" to indicate empty STRUCTURED-DATA.
When a receiver or initial sender truncates a message, the TRUNCATE
(Section 6.2.4) field MUST be updated. In the case of a receiver,
please note that this will break eventually existing digital
signatures. This is irrelevant, as the truncation itself breaks the
signature. So no extra harm is done by updating the TRUNCATE field.
Also, the clause
please note that this will break eventually existing digital
signatures.
should be changed to:
please note that this will break message integrity checking
mechanisms such as digital signatures.
Would it be appropriate in Section 6.2.1 "VERSION" to describe that
the VERSION field can only be changed by STANDARDS ACTIONS as defined
in RFC 2434? Also, the VERSION needs to be registered with IANA and needs
to be stated in the instructions to the IANA.
In Section 6.2.2 "FACILITY", the value of the facility should not
have commas.
FACILITY is an integer in the range from 0 to 2,147,483,647. It can
change to:
FACILITY is an integer in the range from 0 to 2147483647. It can
If diagram 1 has a title, then so should the diagram (or table) in Section
6.2.3 "SEVERITY".
The list in Section 6.2.3.1 "Relation to Alarm MIB" may be better
represented in a table.
The table in Section 6.2.4 "TRUNCATE" should have a title.
Grammar in Section 6.3.3 "SD-PARAM":
MAY drop the message. It is RECOMMENDED that the receiver logs a
diagnostic on reception of invalid escape sequences.
should be changed to:
MAY drop the message. It is RECOMMENDED that the receiver log a
diagnostic message on receipt of a message with an invalid escape
sequence.
Section 6.3.4 "Change Control" should either be move to the IANA
Considerations or be duplicated there.
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.
A slight change may make it more readable:
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 SD-ID MUST be created and the old one remain
unchanged.
In Section 7.3.1 "sequenceId", commas should be removed from the number.
message up to a maximum value of 2,147,483,647. If that value is
should be changed to:
message up to a maximum value of 2147483647. If that value is
Grammar in Section 8.4
In case a sender includes user-supplied data within a syslog message,
it should limit the size of that data. Otherwise, an attacker may
provide large data in the hope to exploit this potential weakness.
should be changed to:
A sender should limit the size of any user-supplied data within a
syslog message. If it does not, an attacker may provide large data in
hopes of exploiting a potential weakness.
(Rainer may consider adding something about rate limiting here as well.)
In the Instructions to IANA, it should be noted how additional
SD-PARAM names are added. For example, how would one go about adding
a new SD-PARAM to describe the timezone on Mars to the timeQuality
SD-ID? In that case, the SD-ID is not being changed, only a new SD-PARAM
is being added.
The instructions to the IANA should give a table of SD-IDs and their
known SD-PARAMS.
SD-ID SD-PARAM
timeQuality OPTIONAL
tzKnown OPTIONAL
isSynced OPTIONAL
syncAccuracy OPTIONAL
origin OPTIONAL
ip OPTIONAL
enterpriseId OPTIONAL
software OPTIONAL
swVersion OPTIONAL
meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
The IANA seems to like maintaining tables better than just textual
registries.
Thanks,
Chris
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
