[Syslog] WGLC: protocol, part 2
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 specificati
[Syslog] WGLC: udp-07
Hi, I have reviewed http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt for WGLC. The xml2rfc will be submitted with the final draft, so this should be a "clean" xml2rfc source file. The xml2rfc-validator tools at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi shows the following warnings or errors, which should be fixed in the source file. Note that my copy of the XML source apparently does not match that used to generate the official draft. start validation output --- Validation results for D:\My Documents\IETF\syslog\draft-ietf-syslog-transport-udp-07.xml Processing... Validating document... 280: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author ) 279: 280: 281: The syslog Protocol ...validation failed Performing additional checks... 50: fyi: anchor intro not referenced 49: 50: 51: 68: fyi: anchor terms not referenced 67: 68: 69: 76: fyi: anchor Transport not referenced 75: 76: 77: 78: fyi: anchor Datagram not referenced 77: 78: 79: 84: fyi: anchor MessageSize not referenced 83: 84: 85: 104: fyi: anchor TargetPort not referenced 103: 104: 105: 110: fyi: anchor SourceIPAddress not referenced 109: 110: 111: 116: fyi: anchor UDPIPStructure not referenced 115: 116: 117: 122: fyi: anchor UDPChecksums not referenced 121: 122: 123: 137: fyi: anchor reliability not referenced 136: 137: 138: 143: fyi: anchor loss not referenced 142: 143: 144: 152: fyi: anchor corruption not referenced 151: 152: 153: 162: fyi: anchor overload not referenced 161: 162: 163: 168: fyi: anchor sequence not referenced 167: 168: 169: 177: fyi: anchor security not referenced 176: 177: 178: 182: fyi: anchor SenderAuthentication not referenced 181: 182: 183: 188: fyi: anchor SecForg not referenced 187: 188: 189: 200: fyi: anchor SecObs not referenced 199: 200: 201: 206: fyi: anchor SecReplay not referenced 205: 206: 207: 212: fyi: anchor SecRelDel not referenced 211: 212: 213: 218: fyi: anchor SecPri not referenced 217: 218: 219: 224: fyi: anchor SecDen not referenced 223: 224: 225: 231: fyi: anchor iana not referenced 230: 231: 232: 237: fyi: anchor rfc-editor not referenced 236: 237: 238: 244: fyi: anchor acks not referenced 243: 244: 245: 310: warning: anchor RFC1122 not referenced 309: 310: 311: ...done end xml2rfc validation output --- Idnits (using http://tools.ietf.org/tools/idnits/idnits.pyht) Boilerplates and formatting checks look good. spelling (using MS-Word on the xml2rfc-generated html file) The implementer/implementor debate rages on. Usage is inconsistenct within this document. It would be nice if we were consistent across our documents. My research shows implementer as the preferred spelling. The term "misconfigured" is used. This is apparently not a real English word, and that means that implementers and readers who rely on translation tools will probably have problems with this term. Can we use "inappropriately configured" instead? The draft acknowledges Mickael Graham; is this the correct spelling? --- grammar --- "The informational RFC 3164 [7] originally described the syslog" - eliminate "originally" The documentt talks about "RFC3164 described" - doesn't it still describe? Shouldn't this be "describes"? "The RFC-protocol specifies a layered architecture that provided for" - /provided/provides/ "This standards track RFC describes" should be "This document describes"; the IESG could always decide to publish this as a non-standards-track RFC, and it could be moved to "Historic" at a later date, so we should not specify standards-track in the body of the document; that status is external to the document. I don't feel very comfortable with use of the word protocol in "Network administrators and architects should be aware of the significant reliability and security issues of this protocol, which stem from the use of UDP." I think this document describes a transport mapping - how syslog should "interface to" the UDP protocol. We are not defining a syslog-udp message format. Part of the problem is that when the text says "this protocol", I need to think about whether "this protocol" means syslog (which is definitely a protocol), or the syslog-udp transport mapping. So "This protocol supports transmission of syslog messages up to 65535 octets in size" is ambiguous as to wehere the limit is defined, but "This transport mapping supports transmission of syslog messages up to 65535 octets in size" is not. In sexction 5.3, "This transport protocol" apparently refers to UDP. It woul dbe less ambiguous if each usage of "this ... Protocol" was replaced by "the UDP protocol" or "the syslog/udp transport mapping". "a well-known port 514" s/b "the we
[Syslog] Working Group Last Call: syslog-sign document
Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt The Working Group Last Call for this document will end September 11. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Working Group Last Calls
Hi, The WGLC for -protocol-17 and -udp-07 documents will end later today. Please review and comment on these documents today. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
