I've reviewed this document as part of the transport directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum. Summary: This document could go into more detail with respect to transport behavior. In places the wording could be improved. Section 1 "The IPv4 version of this transport mapping is REQUIRED for all syslog protocol implementations on devices supporting IPv4. The IPv6 version of this transport mapping is REQUIRED for all syslog protocol implementations on IPv6-only devices." So we are saying that a syslog implementation on a dual-stack host isn't even recommended to support IPv6? This would imply that a dual-stack implementation may not be able to send syslog messages if it has IPv6 connectivity, but not IPv4. This doesn't make sense to me. Section 3.2 " IPv4 syslog receivers MUST be able to receive datagrams with message size up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message size up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with messages size of at least 2048 octets." If I read this literally, it seems to imply that IPv4 receivers must be able to receive datagrams with a message size of 0 to 480 octets, and should be able to receive messages greater than 2048 octets, and IPv6 receivers must be able to receive datagrams with a message size of 0 to 1180 octets, and should be able to receive messages greater than 2048 octets. What about IPv4 messages from 480 to 2047 octets, or IPv6 messages from 1181 to 2047 octets? Are we saying that reception of these messages sizes is optional?? " The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that fall within these limits have the greatest chance of being delivered because they do not require fragmentation." One could interpret this to mean that datagrams between 576 and 1280 octets have the greatest chance of delivery, which isn't what you mean. You might say "Datagrams that conform to these limits..." " When network MTU is not known in advance and cannot be reliably determined using path MTU discovery [7], the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6." There are issues with syslog usage of classical path MTU discovery, since ICMP Packet Too Big messages may not be delivered or processed for some reason. Since syslog doesn't support acknowledgement, it can't determine when packets are lost, making it difficult to implement alternatives such as draft-ietf-pmtud-method. You might talk a bit more about these implications. Section 4 "This section discusses reliability issues inherent in UDP that implementers and users MUST be aware of." What implementation obligations does the MUST imply? I'm unclear what an implementer is supposed to do. Section 4.1 " In some circumstances the sender can receive an ICMP error message or other indication of a transmission problem. If the sender receives a reasonable indication that a datagram has been lost, it MAY retransmit the datagram." This paragraph seems too vague. Are we suggesting that the implementer may retransmit in response to any ICMP error message? Also, are there any recommendations with respect to retransmission timers or failover behavior? Section 4.2 "However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message retransmission when a corrupt message is detected." It might be clearer to say that there is no acknowledgement mechanism, given the potential for retransmission described in Section 4.1. " A special case of corruption is corruption introduced by the UDP implementation itself. For example, several earlier UDP implementations defaulted to a buffer size of less than 65535 octets and truncated larger payloads upon receipt [8]. By following the message size recommendations specified in this document, application developers can significantly reduce the risk of this type of error." This probably would better fit in Section 3.2. Section 4.3 " The UDP does not provide for congestion control. Any network host or router can discard UDP packets when it is overloaded, and can optionally provide an ICMP error to indicate this." Are you referring to "Source Quench" here? I think you need to talk about syslog's response to potential congestion indications in more detail. Section 4.1 raises the possibility of retransmission, which without backoff doesn't seem like a great idea in situations where congestion is being experienced. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf