Editorial pass for WGLC on -14 (Tommy)

[tfpauly]

During my read-through of the document, I had the following comments. These are generally editorial. This is for draft-ietf-quic-multipath-14.

Section 1

"4-tuple" is used without being directly defined, and I don't think that term is used in RFC 9000. Having a simple explanation of what tuple you mean would be good for people who aren't familiar. This is also used in section 5.2.

There are currently no IETF specifications for simultaneously (concurrently) using multiple paths.

I think this would be more clear to explain that "There are currently no IETF specifications that define scheduling algorithms for...". Without that clarification, it could sound like the IETF specifications prohibit simultaneous use (which isn't true) instead of just not specifying the algorithms for how to schedule them.

The intro defines the notion of "path ID" as part of the body of text, but it might be nice to have a separate sub-section that defines the normative aspects of the path ID. Right now, very crucial details about the path ID being an integer that monotonically increases, isn't reused, has special values for 0, etc, is mixed into the overview/conceptual text.

Section 2.1

When advertising the initial_max_path_id transport parameter, endpoints MUST use non-zero length Source and Destination Connection IDs.

The hyphens here feel a bit odd, like it should really be "non-zero-length". I suggest either one of these options:

• "endpoints MUST use Source and Destination Connection IDs with non-zero lengths."
• "endpoints MUST NOT use zero-length Source and Destination Connection IDs."

Section 2.3

The choice of three times the largest PTO is a trade-off.

It feels like this sentence should say "is a trade-off between ___ and ___.", for clarity.

Section 3

This is the first time that some of the new frame types are mentioned, such as PATH_ABANDON, PATH_NEW_CONNECTION_ID, PATH_RETIRE_CONNECTION_ID. These don't consistently provide references to the sections where they are defined below. Please either add the references on these first uses, or maybe have an overview at the top of section 3 that mentions all of the new frame types and provides references at that point; or just move the frame definitions up.

Section 4.3

I have a slight preference to change PATH_BACKUP -> PATH_IS_BACKUP or something similar. "BACKUP" alone sounds like a verb like "ABANDON", so initially I read it as "back this path up", which doesn't make much sense. A path being a backup, like it can be available, makes more sense.

Section 4.2.1

The error codes defined here seem specific to paths, but they go in the main error registry. Should their names have more clear path-related names?

APPLICATION_ABANDON -> APPLICATION_ABANDON_PATH
RESOURCE_LIMIT_REACHED -> PATH_RESOURCE_LIMIT_REACHED (although this one seems it could be more generic)
UNSTABLE_INTERFACE -> PATH_UNSTABLE_INTERFACE
NO_CID_AVAILABLE -> PATH_NO_CID_AVAILABLE / NO_CID_AVAILABLE_FOR_PATH

[mirjak]

There are currently no IETF specifications for simultaneously (concurrently) using multiple paths.

I think this would be more clear to explain that "There are currently no IETF specifications that define scheduling algorithms for...". Without that clarification, it could sound like the IETF specifications prohibit simultaneous use (which isn't true) instead of just not specifying the algorithms for how to schedule them.

@gorryfair would that wording be okay for you?

[mirjak]

I created PRs #570, #571, #572 to address most of your editorial comments, expect the question above for Gorry and the following two points:

The intro defines the notion of "path ID" as part of the body of text, but it might be nice to have a separate sub-section that defines the normative aspects of the path ID. Right now, very crucial details about the path ID being an integer that monotonically increases, isn't reused, has special values for 0, etc, is mixed into the overview/conceptual text.

The normative specification effectively is where the transport parameter is defined to be an integer and the max value. Btw 0 does not have a special meaning. We used to have an own subsection on path ID but it seemed redundant. So I'm not really sure if I would want to (re-)add it again.

Section 2.3

The choice of three times the largest PTO is a trade-off.

It feels like this sentence should say "is a trade-off between ___ and ___.", for clarity.

This is want the sentence after the next sentence already says:

"Longer delays reduce the probability of losing packets but keeping old keys longer can negatively impact the security of the protocol."

Isn't that sufficient. Trying to squeeze this into one sentence would just make it a really long sentence, no?

[mirjak]

I added the part of scheduling algorithm to PR #570 given Gorry provided a thumbs-up above.

[tfpauly]

For "is a trade-off between", if the trade-off is the next sentence, maybe the first should end in a colon, like:

"The choice of three times the largest PTO is a trade-off: longer delays reduce the probability of losing packets, but keeping old keys longer can negatively impact the security of the protocol."

[mirjak]

I created #584

[mirjak]

I believe we addressed all points with merged PRs now, so I'm closing this issue. Thanks again for the review!