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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf