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

----- Original Message -----
From: "David Harrington" <ietfdbh@comcast.net>
To: <syslog@ietf.org>
Sent: Wednesday, August 16, 2006 2:21 AM
Subject: [Syslog] WGLC: protocol


> 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


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