Hi,
Here are some additional coments on the protocol draft, as promised.
Section 5.1 - if a receiver implementation supports UDP/IPv4 and a
sender support UDP/IPv6, I believe these will not interoperate unless
there is a 6-to-4 proxy between them. Therefore, claiming
"interoperability between all systems" is incorrect.
Section 6.3 says "A receiver MAY ignore malformed STRUCTURED-DATA
elements." We do not actually standardize what a receiver does with
the messages it receives, since that is implementation dependent.
Isn't it true that a receiver can ignore any STRUCTURED-DATA elements,
whether malformed or not? So I think the question that needs to be
answered is what happens at a relay? If a relay can "ignore" malformed
structured data, does that mean it can discard that portion of the
message, even if it is in the middle of the message, and pass the
syslog message to a receiver without that portion of the content? Or
is the relay REQUIRED to pass the malformed SD in the forwarded
message? Wouldn't dropping the SD have an impact on syslog-sign? So we
need to define in a clear and unambiguous manner what ignore means.
Is the escape format defined in 6.3.3 a UTF-8 standard, or something
specific to syslog SD-PARAMS? The text should specify this.
"This is necessary to avoid parsing errors." - how is this necessary?
Which parser is being used? How does escaping ']' prevent parser
implementation errors as compared to not escaping this and
implementing the parser to not expect this to be escaped within a
PARAM-VALUE field?
If the escape format defined in 6.3.3. is not standard UTF-8, then why
are we making this non-standard UTF-8? Will UTF8-standard-compliant
parsers be able to parse this modified UTF-8 content correctly?
Doesn't this defeat the purpose of using a standard encoding?
How do these two statements co-exist? "It MAY modify messages
containing control characters (e.g. by escaping an octet with value
0 to "\0")." and "A backslash ('\') followed by none of the three
described characters is considered an invalid escape sequence...it MAY
[replace the sequence or] it MAY drop the message." Why don't we
either make all escaped characters except '"' and '\' and ']' invalid
- period and not permit them in a valid syslog message, or make them
valid and require receivers to process them in a standardized manner
so we have a MUST for interoperability rather than two
non-interoperable MAY clauses?
"They are wrapped on multiple lines for readability purposes only."
s/b "They are wrapped on multiple lines in this document for
readability purposes only."
"which has been left out for brevity" s/b
"which has been left out of this document for brevity"
In 6.5 example 1, aren't these contrsdictory statements - "The
encoding is defined by the BOM, and also advertised in
STRUCTURED-DATA. There is no STRUCTURED-DATA present in the message,
this is indicated by "-" in the STRUCTURED-DATA field." So should this
read ""and MAY be advertised"
7.3.3 Let's see. If BOM and enc are both specified, believe the BOM.
If BOM is not present and enc=UTF8 is present, then you should make no
assumptions about the encoding. If the BOM is not present and the
encoding is not UTF8 then enc MUST NOT be specified. So when is this
field actually useful? Why have it if the value of the field is always
either duplicative or not-to-be-trusted? Let's either make it useful
when the BOM is not specified and/or when the encoding is not UTF8, or
let's eliminate it.
Section 8.2 specifies why it is a security risk to send control
characters in the MSG or PARAM-VALUE content. We should simply say, if
you want to be a standard-compliant implementation, you MUST NOT send
control characters in these fields. Period. Strip them out and add a
section to your release notes tahat explains this decision was made by
the IETF for security reasons.
Section 8.5 "the underlying transport may be unreliable (e.g., UDP),
some messages may be lost." insert an "and" before "some".
8.8 "misconfiguration" is apparently not an English word recognized by
most dictionaries. Therefore, this term will eb difficult for
implementers and operators who use translation tools from English to
their native language. "Inappropriate configuration" is better
English.
Section A.1: RFC3164 is not a standard or a specification, it is an
informational document that describes existing practice. "In RFC 3164
[16] observed formats were specified." should be changed to "In RFC
3164 [16] describes observed formats."
It is inapprorpriate to refer to rfc3164 as being able to mandate or
specify behavior. That is the role of a standards-track specification,
not an informational document. So sentences like "RFC 3164 specifies
relay behavior" should be changed to "RFC 3164 describes observed
relay behavior."
"RFC 3164 mandates UDP as transport protocol for syslog." should be
changed to "Most existing implementations support UDP as the transport
protocol for syslog. This specification REQUIRES UDP support in
compliant implementations, and allows additional transport protocols
to be used."
Section A.2 "To further strengthen this point, it has
also been observed that some UDP implementations generally do not
support message sizes of more then 480 octets." Is this accurate? Is
it the UDP implementations that do not support more than 480 bytes, or
is it the syslog/udp implementations?
I am not sure I agree that the IPv6 MTU must be noted in this
document. It is more approrpiately mentioned in a transport mapping
that addresses transport over IPv6. I prefer to eliminate it here.
A.6 and A.8 are related; it would be good to have them next to each
other.
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
