David Harrington (co-chair of the Syslog WG) specifically asked me 
for a review of documents in WG Last Call.

I am not subscribed to the SYSLOG WG mailing list, so pls copy
me explicitly on any reactions that you want me to see.

Bert
----- draft-ietf-syslog-protocol-17.txt

I see:

   4.1.  Example Deployment Scenarios

   Sample deployment scenarios are shown in Diagram 1.  Other
   arrangements of these examples are also acceptable.  As noted, in the
   following diagram, relays may pass along all or some of the messages
>> that they receive and also pass along messages that they generate
   internally.  The boxes represent syslog-enabled applications.

I would change "pass along" into "send".
The "pass along" to me sounds as if the message was received from
someone else to beging with.

table 1 on page 12 refers to "(note 1)" and "(note 2)"
I cannot find these notes. Is that just me?

Section 6.2.4 states, page 16, 2nd para:

   Senders SHOULD consistently use the same value in the HOSTNAME field
   for as long as possible.  If the sender is multihomed, this value
   SHOULD be one of its actual IP addresses.  If a sender is running on

So does that  mean that this "SHOULD" overwrites an earlier "SHOULD" in
the 2nd para of section 6.2.4 on page 15:

   The HOSTNAME field SHOULD contain the host name and the domain name
   of the originator in the format specified in STD 13 [3].  This format
   is called a Fully Qualified Domain Name (FQDN) in this document.

To me it is unclear what I SHOULD do in case I am a multihomed system
while I do have a FQDN available.

I see in the ABNF specification:

      APP-NAME        = NILVALUE / 1*48PRINTUSASCII

And I see in section 6.2.5:

   6.2.5.  APP-NAME

   The APP-NAME field SHOULD identify the device or application that
   generated the message.  It is a string without further semantics.  It
   is intended for filtering messages on the receiver.

I find the latter misleading. Because ABNF mandates PRINTUSASCII, and
applications these days very often may have internationalized names that
cannot easily be represented in PRINTUSASCII. What are implementers
supposed/expected to do in that case?

I see in the ABNF specification:

   PROCID          = NILVALUE / 1*128PRINTUSASCII

and in section 6.2.6 I see: 

   6.2.6.  PROCID

   The PROCID field SHOULD be used to provide the sender's process name
   or process ID.  The field does not have any specific syntax.

So that last sentence is not very accurate I think. To me it means that if
the process ID, that I must translate it to PRINTUSASCII. Merging the
ABNF and the last sentence that says it does not have any syntax, I guess
I can convert it to hexaxdecimal, or to decimal or some such as long as
I represent it in PRINTUSASCII.

I get confused by the 2nd para of section 6.4:


   The character set used in MSG SHOULD be UNICODE, encoded using UTF-8
   as specified in RFC 3629 [6].  If the sender can not encode the MSG
   in Unicode, it MAY use any other encoding.

What exactly does that mean for the on-the-wire data?

And in sect 64. in last para:

   If a receiver receives MSG not starting with a BOM, then the encoding
   of the content is implementation specific and it is RECOMMENDED that
   no assumption be made about the encoding of the content.

So what is a receiver expecter and/or allowed to do?
I guess a receiver MAY decide to discard the message?

I think that in section 7.2.2 I would point to
   http://www.iana.org/cgi-bin/mod_ent.pl
instead of just www.iana.org for the online form. It is not always
so easy to find (specifically for novices).

Further in section 7.2.2. I see:
   <http://www.iana.org/>.  Only that number and any-enterprise assigned
   ID below it MUST be specified in the "enterpriseId" parameter.  If
   sub-identifiers are used, they MUST be separated by periods and be
   represented as decimal numbers ("9.1.30" and "11.2.3.7.5.12").  The

I understand that the decimal numbers listed are examples. 
But I would still add a note/warning that these are indeed just examples
and should not be used as is, the enterprise-IDs 9 and 11 respectively
belong to PSI and HP respectively. And the actual numbers might even 
represent sometging totally different (maybe a MIB OID or an LDAP
OID or some such).

In sect 7.2.4 I see:

   The "software" parameter is a string.  It MUST NOT be longer than 48
   characters.

If I understand it correctly, then the value has to be in UTF-8.
And in that context, it is not clear if a "character" is one octet or
multiple octets. I think you mean that the length of the value can be
max 49 octets? If so, then I would use "octets" instead of "characters".
Pls do realize that in some languages, 48 Octets may be just 6 "characters".

Same for various other parameters

In sect 8.5 I see:

   It may also be desirable to include rate-limiting features in syslog
   senders.  This can reduce potential congestion problems when message
   bursts happen.

Mmm... I know that the transport area (TSV) is very keen on MANDATING
some sort of rate limiting on such UDP packet originators. So I would
not be surprised if this gets brought up when this doc comes to IETF
wide last call or to IESG review. Maybe we should say something about
a max sending rate for UDP.

I see a (normative) reference to ABNF RFC 2234, and note that 2234 has been
obsoleted by RFC 4234. So I'd think that referencing the newer RFC is 
probably the right thing to do.

Bert

----------- original review message:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt
> > > 
> > > Transmission of syslog messages over UDP
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07
> > > .txt
> > > 
> > > TLS Transport Mapping for SYSLOG
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03
> > > .txt
> > > 
> > > Syslog Management Information Base
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx
> > > t
> > > 
> > > Signed syslog Messages
> > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt
> > > (We expect this document to be updated this week.)
> > > 
> > > 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