-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all,
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The primary purpose of the document is to extend supplemental information carried in ICMP responses to support diagnostics, notably by supporting interface naming information. The document describes one use of extended ICMP (RFC4884), which was developed for this purpose as well as to support MPLS diagnostics. This document would extend the information available to stateful transports (TCP, SCTP, and DCCP), notably for destination unreachable, time exceeded, and parameter problem ICMP messages. This document does describe a use of extended ICMPs that, if deployed widely, would provide additional information to transport protocols which could be useful diagnostically, but is not expected to impact the operation of these transport protocols. Issues of backward compatibility of legacy transports with extended ICMPs are discussed in Section 5.1 of RFC4884, and is not affected by the particular extension described in this document. This document does describe a use of extended ICMPs that would be expected to be seen by legacy transport protocols, however. For stateful transports, such as TCP, SCTP, and DCCP, the extended ICMP described by this document could provide useful diagnostic information, but should not affect protocol operation. UDP is not directly affected by this extension, but is anticipated to pass the extended information up to the application; revised traceroute applications would provide this information, if available (i.e., on stacks that support it), to the user. Note that there are potential issues of interaction of extended ICMP (RFC4884) with legacy transports, and which affect whether more than 128 bytes of header are available in the ICMP response, as well as whether full-packet inspection (e.g., checksum verification or other authentication) can even be performed. This further advocates for conservative approaches in parsing ICMP responses, especially requiring that new implementations support RFC4884 extensions and do not anticipate a full packet in the ICMP payload. This document does not alter that effect, but, as noted above, would be the first use of extended ICMP expected to widely interact with transport protocols. There is no need to modify this document to address these issues; the are sufficiently addressed in RFC4884. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknbhi8ACgkQE5f5cImnZrsnnwCg0fpTYixwNFkYsLDfNUtdVUXD xJAAoJPnhf5NrAkZH4kOmhPeTuAIeya2 =wSSa -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
