Subject: [tsvwg] Benjamin Kaduk's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 04 Jul 2018 20:59:59 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-errata-06: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The reasons for my Abstain vs. No Objection are covered in the other Abstain
positions' descriptions. In particular, the "user-unfriendliness" aspect; e.g.,
in my notes, I was going to suggest switching the example CRC code to using
fixed-width types, and had to wait until basically the end of the document to
see that this was already done.

I did take some notes while reviewing the document, though:

Section 3.14.2 (new text)

 When its peer is multi-homed, an endpoint SHOULD send fast
 retransmissions to the same destination transport address where the
 original data was sent to. If the primary path has been changed and the
 original data was sent there before the fast retransmit, the
 implementation MAY send it to the new primary path.

What is "there"?

Section 3.35.2

There seem to be two instances of "Old Text" for the same outline of text;
presumably the second one is supposed to be "New Text".

Section 3.36.2

The ICMP3 change goes both from "MAY ignore" to "SHOULD ignore" and from
"code does not indicate" to "code indicates", which is qualitatively a
large change.  There are 13 code values that are not mentioned in either
old or new text, and the supporting problem/solution descriptions don't do
very much to explain the change for these 13 codes.

Section 3.40.2

Is ECN really still a "proposed extension to IP", or a realized extension?

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 6 Jul 2018 23:09:30 +0200

> On 5. Jul 2018, at 05:59, Benjamin Kaduk <[email-masked]> wrote:
> 
Hi Benjamin,

thanks for providing the notes. See my comments in-line.
> implementation MAY send it to the new primary path.
the old primary path... I changed the text to

When its peer is multi-homed, an endpoint SHOULD send fast
retransmissions to the same destination transport address where the
original data was sent to. If the primary path has been changed and the
original data was sent to the old primary path before the fast retransmit,
the implementation MAY send it to the new primary path.

> presumably the second one is supposed to be "New Text".
Yepp, that was a typo, which has already been fixed in the git repo:
https://github.com/sctplab/rfc4960bis/commit/650416a74049578aeea6c0e6098815f746ecc778
> very much to explain the change for these 13 codes.
The codes not mentioned may be ignored...

But you are right: The change for ICMP3) is missing IPv6 and is not covered
by the explanation in 3.36.1. This was a mistake in RFC 4960,
the text below the enumeration in RFC 4960 describes the intention:

   Note that these procedures differ from [RFC1122] and from its
   requirements for processing of port-unreachable messages and the
   requirements that an implementation MUST abort associations in
   response to a "protocol unreachable" message.  Port-unreachable
   messages are not processed, since an implementation will send an
   ABORT, not a port unreachable.  The stricter handling of the
   "protocol unreachable" message is due to security concerns for hosts
   that do NOT support SCTP.

The updated ICMP3 reflects this now.

I change the text of 3.36.1 to:

<t>Appendix C of <xref target="RFC4960"/> describes the handling of ICMPv4 and
ICMPv6 messages.
The handling of ICMP messages indicating that the port
number is unreachable described in the enumeration is not consistent with
the description given in <xref target="RFC4960"/> after the enumeration.
Furthermore, the text explicitly describes the handling of ICMPv6 packets
indicating reachability problems, but does not do the same for the
corresponding ICMPv4 packets.</t>

and the text of 3.36.3 to:

<t>The text has been changed to describe the intended handling of ICMP
messages indicating that the port number is unreachable by replacing the third rule.
Furthermore, remove the limitation to ICMPv6 in the ninth rule.</t>
> Is ECN really still a "proposed extension to IP", or a realized extension?
The issue was that the references needed an updated. But I removed the word
"proposed"...

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Jul 2018 16:35:18 -0500

Hi Michael,

> the implementation MAY send it to the new primary path.

Thanks!  If forced to guess, I would have guessed the old primary path, but
this is much clearer to me.

> Furthermore, remove the limitation to ICMPv6 in the ninth rule.</t>

Ah, this makes more sense -- as you can imagine, I was just looking at the
diff of the OLD/NEW chunks in this document, so I missed the broader
context in 4960 itself.

> The issue was that the references needed an updated. But I removed the word

Thanks.

And, more generally, thanks to all the authors for assembling the
information like this -- it's clear that a lot of energy and attention to
detail went into it, and I'm sure that will be reflected when we are
looking at 4960bis.

-Benjamin