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: <reference anchor='RFC-protocol'> 280: <front> 281: <title>The syslog Protocol</title> ...validation failed Performing additional checks... 50: fyi: anchor intro not referenced 49: <middle> 50: <section anchor="intro" title="Introduction"> 51: <t> 68: fyi: anchor terms not referenced 67: 68: <section anchor="terms" title="Conventions Used in This Document"> 69: 76: fyi: anchor Transport not referenced 75: 76: <section anchor="Transport" title="Transport Protocol"> 77: 78: fyi: anchor Datagram not referenced 77: 78: <section anchor="Datagram" title="One Message Per Datagram"> 79: <t> 84: fyi: anchor MessageSize not referenced 83: 84: <section anchor="MessageSize" title="Message Size"> 85: 104: fyi: anchor TargetPort not referenced 103: 104: <section anchor="TargetPort" title="Source and Target Ports"> 105: <t> 110: fyi: anchor SourceIPAddress not referenced 109: 110: <section anchor="SourceIPAddress" title="Source IP Address"> 111: <t> 116: fyi: anchor UDPIPStructure not referenced 115: 116: <section anchor="UDPIPStructure" title="UDP/IP Structure"> 117: <t> 122: fyi: anchor UDPChecksums not referenced 121: 122: <section anchor="UDPChecksums" title="UDP Checksums"> 123: <t> 137: fyi: anchor reliability not referenced 136: 137: <section anchor="reliability" title="Reliability Considerations"> 138: 143: fyi: anchor loss not referenced 142: 143: <section anchor="loss" title="Lost Datagrams"> 144: <t> 152: fyi: anchor corruption not referenced 151: 152: <section anchor="corruption" title="Message Corruption"> 153: <t> 162: fyi: anchor overload not referenced 161: 162: <section anchor="overload" title="Congestion Control"> 163: <t> 168: fyi: anchor sequence not referenced 167: 168: <section anchor="sequence" title="Sequenced Delivery"> 169: <t> 177: fyi: anchor security not referenced 176: 177: <section anchor="security" title="Security Considerations"> 178: <t> 182: fyi: anchor SenderAuthentication not referenced 181: 182: <section anchor="SenderAuthentication" title="Sender Authentication"> 183: <t> 188: fyi: anchor SecForg not referenced 187: 188: <section anchor="SecForg" title="Message Forgery"> 189: <t> 200: fyi: anchor SecObs not referenced 199: 200: <section anchor="SecObs" title="Message Observation"> 201: <t> 206: fyi: anchor SecReplay not referenced 205: 206: <section anchor="SecReplay" title="Replaying"> 207: <t> 212: fyi: anchor SecRelDel not referenced 211: 212: <section anchor="SecRelDel" title="Unreliable Delivery"> 213: <t> 218: fyi: anchor SecPri not referenced 217: 218: <section anchor="SecPri" title="Message Prioritization and Differentiation"> 219: <t> 224: fyi: anchor SecDen not referenced 223: 224: <section anchor="SecDen" title="Denial of Service"> 225: <t> 231: fyi: anchor iana not referenced 230: 231: <section anchor="iana" title="IANA Considerations"> 232: <t> 237: fyi: anchor rfc-editor not referenced 236: 237: <section anchor="rfc-editor" title="Notice to RFC Editor"> 238: <t> 244: fyi: anchor acks not referenced 243: 244: <section anchor="acks" title="Acknowledgements"> 245: <t> 310: warning: anchor RFC1122 not referenced 309: 310: <reference anchor='RFC1122'> 311: <front> ...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 well-known port 514" --- RFC2119 terminology --- Some of the keywrods are used in both lowercase and uppercase; I believe the preferred approach is to use uppercase consistently. Some authors use lowercase when th eterm is not used as an rfc2119 keyword, but uppercase when referring to an rfc2119 keyword. I recommend always using uppercase and avoiding the keywords when they are not meant to be used as an rfc2119 keyword to avoid ambiguity. The word "can" is used where MAY might be more appropriate. The document says that "this transport protocol" is required for interoperability. However, two transport protocols are referred to, and they are not necessarily interoperable. For a system that only supports IPv4, then the UDP/IPv4 protocol should be required for interoperability. For a system that only supports IPv6, then UDP/IPv6 should be supported for interoperability in an IPv6 environment. For a system that supports both IPv4 and IPv6, what is required - UDP/IPv4, UDP/IPv6, or both, for interoperability? If both, then by default, should operators have syslog messages sent over both (i.e. duplicate the messages) so they can be transmitted over IPv4 and IPv6 networks? In SNMPv3, we chose UDP/IPv4 as the required even if both IPv4 and IPv6 are available, and for IPv6-only devices, we require UDP/IPv6. --- general review --- "This limit stems from the maximum supported UDP payload of 65535 octets specified in the RFC 768 [1]." - I couldn't find such a limit specified in rfc768. In fact, rfc768 **assumes** this will run over the IP protocol. IP might define some limits that would lead to this syslog limit. If UDP had a limit, then saying UDP supported "payloads" of 65535 would probably be incorrect, since part of the 65535 limit would be used up by header fields, thus lessening the "payload" limit. "It is RECOMMENDED that application developers restrict message sizes" - shouldn't this be "It is RECOMMENDED that syslog senders restrict message sizes"? The receivers are also applications and we don't really want the receivers to restrict message sizes. I am a bit concerned that we are violating layer separation when we get too specific about the structure and checksums of the transport protocol; lower-layer details like checksums should not necessarily be made accessible to the syslog protocol, which operates at a higher layer. We should trust the underlying transport to do its job correctly, and operators to configure their devices correctly, so requiring syslog receivers to examine the UDP checksums seems wrong. In section 4.1, we go even further - "This protocol specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols." We have no business looking at layer 3 and layer 2 checksums. If a checksum is neede to validate the syslog mesdsage, then we should have a syslog checksum. Doesn't the last sentence of 5.1 mean basically the same thing as what is discussed in 5.2? Section 5.6 says "they will not get a higher priority". The standard will not mandate prioritization because that is an implementation decision and would not affect interoperability on-the-wire, but a sending implementation might provide such prioritization, so the document should not say they will not get a higher priority. It might even be a good idea to suggest that implementers of sending applications and relays consider support for prioritization based on the <PRI> label. Section 5.7 discusses DoS attacks. Should the MIB include the ability to restrict the nuber of messages sent per minute? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
