Subject: [Syslog] WGLC: protocol

From: "David Harrington" <[email-masked]>
Date: Tue, 15 Aug 2006 20:21:35 -0400

Hi,

Here is my review of the protocol-17 document. 

Let me apologize (slightly) for such a thorough review, late in the
process, but as co-chair I need to say I reviewed this thoroughly and
that I agree it is ready to be published as a standard. I am much
pickier about a document I will sign-off as co-chair than one I accept
as a casual WG participant.

For the most part, this review focuses on publication and
standardization requirements rather than on the technical design of
the protocol. I plan to do that review separately, and consider the WG
members more competent in syslog specifics than me.

>From the standpoint of what I reviewed, this document generally looks
good.

dbh

-- idnits --

The document has the correct IPR boilerplates, RFC2119 boilerplate,
and the document passes the automated idnits tool.

Idnits found two reference problems that should be addressed.

Reference [2] is never used in the text.
Reference [17] is never used in the text.

-- xml2rfc validation --

Since the source for this document is written in xml2rfc format, the
RFC editor will request that you submit a copy of the xml2rfc source
with the document to be published. It is a good thing if the sources
used to publish the final document are consisteent with the copy we
have for future update work, so it is a good thing to fix any known
problems in the xml2rfc source before submitting it to the RFC editor.
The rfc editor typically does not return their edited version to us.

The xml2rfc-validator tool at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified a
number of usages that are invalid according to the rfc2629.dtd, and
some usages that have been deprecated or obsoleted by the xml2rfc
tool. The xml2rfc tool will still accept these on the basis of being
liberal in what it accepts, but we should also be conservative in what
we send.

It would be good to fix all these errors and warnings. 

-- References --

The xml2rfc-validator tool at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified
some obsolete references:

RFC 2234 has been obsoleted by RFC4234
RFC 3513 has been obsoleted by RFC4291

6.2.1.1 says The Alarm MIB defines ITU perceived severities. Actually,
don't ITU M.3100 and X.733 define the severities, and the Alarm MIB
just uses them? I don't have a copy of M.3100 or X.733, so I cannot
check this; can somebody check this? I think we should reference the
original definition, and then we can point out that the Alarm MIB
references the ITU severities as well. According to RFC3877, the
references are 
"ITU Recommendation M.3100, 'Generic Network Information Model', 1995"
and
"ITU Recommendation X.733, 'Information Technology - Open Systems
Interconnection - System Management: Alarm Reporting Function', 1992"

-- RFC2119 language --

Section 5 states the UDP "transport is REQUIRED for interoperability
...". I think this might be better phrased as the UDP "transport is
mandatory to implement for compliance to the standard to support
interoperability ..." or remove the sentence since the next section
discusses the minimum required transport mapping.

In section 5.1, it says "This ensures interoperability ...". This
might be better stated as "This ensures at least a minimum
interoperability ..."

Section 6 is entitled "Required syslog format". I suggest making it
simply "Syslog Message Format".

Section 6.1: "After trucation, the message MAY contain invalid UTF-8
encoding or invalid STRUCTURED-DATA." 
Does this need an addendum to standardize subsequent behavior? If the
truncated message now contains invalid content, should the whole
message be discarded, or should the receiver try to process as much as
it can, even if it is incomplete, and the results of subsequent
processing could be misleading to an operator? 

6.2.1: "A receiver MUST NOT assume any specific semantics by default."
I think this fails the RFC2119 test - RFC2119 keywords MUST only be
used where it is actually required for interoperation or to limit
behavior which has potential for causing harm; this assumption would
happen after the message came off the wire, so should not impact
interoperability on-the-wire, and it should have no effect on behavior
such as retransmission. Obviously, a management application might
cause a configuration change based on a faulty assumption, but I don't
think that is a protocol issue. I think the maximum RFC2119 language
here would be a SHOULD NOT.

6.2.5 This section should mention that APP-NAME is an
operator-configured value, which justifies the use of SHOULD rather
than MUST here.

6.2.6 if operator-configured, then ditto. 

6.2.7 if operator-configured, then ditto.

6.3.2 "to be assigned by IETF CONSENSUS" should include a reference to
BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined
in the BCP.

6.3.4 "An exception is the addition of a new OPTIONAL PARAM-NAME to an
existing SD-ID, what MAY be done." This strikes me as incorrect
English grammar; I recommend rewording it. Here is some suggested
text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID."

7.2.1 Can it list an ip address in the "ip" parameter AND provide a
list of multiple "ip" parameters in an "origin" element? If not, why
not? Wouldn't it be useful to provide the "origin" list, but also to
identify its "preferred" address for syslog purposes in "ip"?

7.2.3 "It always contains the name of the generating software," -
should this one be MUST?

"whereas APP-NAME can contain anything else, including an
operator-configured value." Section 6.2.5 should mention that APP-NAME
is an operator-configured value.

If the software parameter contains UTF-8, then it is important to
specify the maximum length of strings in octets rather than
characters, since characters can be multi-byte.

7.2.4 If the swVersion parameter contains UTF-8, then it is important
to specify the maximum length of strings in octets rather than
characters, since characters can be multi-byte.

-- spelling --

/parsable/parseable/g
	neither MS-Word nor Merriam-Webster recognizes  either
spelling. Wikipedia supports parseable under parsing.
computing-dictionary.thefreedictionary.com supports parseable.
Apparently the Oxford dictionary supports parseable, based on a
discussion at apache.org, but I don't have a subscription to check it.
 
/trucation/truncation
/conceptionally/conceptually/
/mimimize/minimize/
/timezone/time zone/g
	according to MS-Word and Mirriam-Webster online
/implementor/implementer/g  
	for consistency with rfc-editor boilerplate text.
/any-enterprise assigned/any enterprise-assigned/

enterpriseId or enterpriseID - inconsistent usage.

6.2.4 "described in RFC 3513" should this be ", as described in RFC
3513"?

7.2.2 "Only that number and any-enterprise assigned
   ID below it MUST be specified in the "enterpriseId" parameter."
seems awkward. 

Would this be better as "An enterprise is only authorized to assign
values within the iso.org.dod.internet.private.enterprise.<enterprise
ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST
contain only a value from the
iso.org.dod.internet.private.enterprise.<enterprise ID> subtree." 

7.3.2 /integer/INTEGER/

Note that the semantics in RFC3418 are
"The time (in hundredths of a second) since the               network
management portion of the system was last
re-initialized."
This of course relates to the SNMP-related management portion of the
system, which MAY be different than the syslog-related management
portion of the system.

-- security considerations

Good job describing the potential configuration issues.
Since the transport documents will describe the threat models, it is
probably acceptable that the threat model is not covered here in the
terminology recommended by rfc3552.

-- IANA considerations --

Good.

-- Authors --

We now have a [email-masked] mailing list adddress. That should be
used rather than the employees.org address.

You should identify that I work for Huawei Technologies USA.

-- Acknowledgment --

The funding acknowledgment for the RFC Editor function is out of date,
but the latest xml2rfc tool corrects it to acknowledge the IASA rather
than the Internet Society.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 16 Aug 2006 07:37:58 +0200

<inline>
Rainer

PS: I might be offline tomorrow...

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Tuesday, August 15, 2006 6:22 PM
> To: [email-masked]
> Subject: [Syslog] WGLC: protocol
> 
> Hi,
> 
> Let me apologize (slightly) for such a thorough review,

Nothing to apologize, I am glad it happened. I just feared it would
occur when I have the least ability to do serious work. Anyhow, I have
been able to edit it. Find comments inline...

> late in the

Removed

> It would be good to fix all these errors and warnings. 

I am working on that, but it is a pain with the low-bandwidth, instable
Internet I currently have ;)

> RFC 3513 has been obsoleted by RFC4291

I have changed the references, but have not (Yet) been able to check if
that means any material differences. A quick check tells me it does not.

> Interconnection - System Management: Alarm Reporting Function', 1992"

I have no references here, either. If someone could verify, I would
appreciate. Alternatively, Chris had recommended that we drop this
section. If there is no objection, we could also do that.

> discusses the minimum required transport mapping.

changed
> might be better stated as "This ensures at least a minimum
Changed 

> simply "Syslog Message Format".
Changed

> processing could be misleading to an operator? 

This was discussed on-list and the consensus at that time was that the
behaviour should be unspecified. The reasoning was to avoid any
complexity at the receiver. I have added the following sentence:

The
receiver MAY discard the message or MAY try to process as much 
as possible in this case.

> here would be a SHOULD NOT.

Agree, changed to SHOULD NOT
> 6.2.7 if operator-configured, then ditto.

These three fields must not necessarily be operator-assigned (I guess
most often the vendor-specific defaults be used). I have added the
following sentence to all three:

				This field MAY be operator-assigned.
				
> BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined
Added

> text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID."

changed
> identify its "preferred" address for syslog purposes in "ip"?

We could add a preferred address param, but would that actually be
useful? I am not sure, as we have the hostname (granted, a FQDN) for the
orginator. The (potential) list should help log analysers. It can list
all addresses it may send from there.

> is an operator-configured value.

Agreed, changed "... MUST always contain..."

> characters, since characters can be multi-byte.

changed
> characters, since characters can be multi-byte.

Changed

NOTE on both above: I left the size as is, as this was already a
compromise given the small guaranteed size of a message. I expect that
in the vast majority of cases these fields will be USASCII strings.

> /any-enterprise assigned/any enterprise-assigned/
Corrected

> enterpriseId or enterpriseID - inconsistent usage.

That stems back to the discussion that we should use camelcase on all
parameters. Thus I have change to enterpriseId whereever used.

> 6.2.4 "described in RFC 3513" should this be ", as described in RFC

Yes - corrected
> iso.org.dod.internet.private.enterprise.<enterprise ID> subtree." 

Excellent - thank you!
> system, which MAY be different than the syslog-related management

I have added this note to the text.
> terminology recommended by rfc3552.

I could merge this in from a transport document, if that would help.
Please advise.
> used rather than the employees.org address.
changed
> You should identify that I work for Huawei Technologies USA.

      David Harrington
      Huawei Technologies USA
      Email: [email-masked]

Ok?

---

From: "tom.petch" <[email-masked]>
Date: Thu, 17 Aug 2006 16:18:53 +0200

The only comments I would add are

- p.18 suggest replacing 'ABNF %D92' by 'ABNF %d92'

- 6.4 suggest ' a "meta" SD-ID'  for 'an "meta" SD-ID'

- 8.1 suggest replacing. 'security issues bound with UNICODE' by
  'security issues with UNICODE' or
  'security issues bound up with UNICODE'

 - On ITU perceived severity, I would stay with the Alam MIB reference.  I seem
to recall that the discussions in disman were complex and that what is there is
the best compromise.  M.3100 only talks of perceivedSeverity in a reference to
Q.821, it uses severity in several other contexts with different enumerations
for the same severity in different places.  I think that disman provided a good
interpretation of the complexity of the ITU Recommendations and that we cannot
better that in syslog.
Tom Petch