[Syslog] WGLC: protocol

"David Harrington" <ietfdbh@comcast.net> Wed, 16 August 2006 00:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9Bj-0006rR-Sc; Tue, 15 Aug 2006 20:23:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9Bi-0006rM-BI for syslog@ietf.org; Tue, 15 Aug 2006 20:23:14 -0400
Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD9Bh-0003FU-Sz for syslog@ietf.org; Tue, 15 Aug 2006 20:23:14 -0400
Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060816002312b1200se533e>; Wed, 16 Aug 2006 00:23:13 +0000
From: David Harrington <ietfdbh@comcast.net>
To: syslog@ietf.org
Date: Tue, 15 Aug 2006 20:21:35 -0400
Message-ID: <0b4e01c6c0c9$ef25f700$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcbAye5nX/6MyTgHSY2bGGKvmBcxKQ==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Cc:
Subject: [Syslog] WGLC: protocol
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

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 syslog@ietf.org 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
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog