Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-tsvwg-multipath-dccp-17 Reviewer: Robert Sparks Review Date: 2024-10-17 IETF LC End Date: 2024-10-17 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Issues I found this document mostly clear, but have a very large number of comments that sum to a single issue of "Needs clarification before proceeding". I did not carefully review the security mechanics added in this document. I read Kyle's review after I made my original notes - I'm not sure I agree with the details of some of his assertions, but I do think a more careful discussion of what the added mechanisms are trying to achieve and what a malicious observer of the messages could possibly do is warranted. (In my read, this became concerning in the first paragraph after Figure 10). The IPR declarations on the document are a little unusual. I don't think there's a process issue around them though. I understand the group's decision to leave how to use these extensions, particularly details of path management and scheduling beyond the priority hints out of scope, but I found evaluating whether what the document defines is _useful_ difficult without some other document doing those things as an existence proof that what's here is sufficient. That there is an exciting implementation is good, but still. It would help readers not already familiar with DCCP to provide or point to a small summary of its basic mechanics. In particular, a description of how it achieves what it intends in the presence of loss, and pointing out that "retransmit" means "send again with a new sequence number" would help readers with this document. Experience with other multi-path like protocols suggests that the design decision to wait until the first path finishes its connection to succeed before adding paths will be an impediment. I would guess discussions pointing to ICE-like techniques came up? I'm not suggesting change at this time, but I do think the decision will limit the utility for real-time applications. The discussion of requirements on "random" things, such as the nonces would benefit from more precision. Bare pointers to 4086 aren't helpful. Discuss _why_ the IDNS should be set randomly. The discussion of exhausting the sequence space at the end of section 3.2.5 is particularly confusing. Perhaps a few examples of how quickly the space would exhaust if the connection were carrying modern real-time stream data would help? Consider discussion what to do if a peer signals use of special addresses (broadcast for example) in MP_ADDADDR. In document order: At the definition of Connection Identifier, "locally unique" is not a sufficient description of what's required of the identifier. The first sentence on page 4 (staring "The discovery and setup") does not parse. Is "needs to be avoided" in the last sentence of that paragraph masking a normative requirement? At the first paragraph of section 3, the document claims it is updating section 6.4 of RFC4340. I don't believe this document is doing such a thing. It is, rather, adding an entry to an IANA registry, and the prose should say _that_ instead. Section 3.1 second paragraph, third sentence: This is a long run-on that does not parse, please rework it as two or more sentences. Why is the fragment ", which means that the client and server must support it" present at the end of last sentence on page 10? I think the fragment can just be deleted. At the first paragraph on page 11, SHOULD A or MUST B is an unclear construction. I think you mean "MUST either A (which is preferred) or B". Page 13: "confirmation of options is identified outdated" fails to parse. 2nd to last paragraph of 3.2.2 - more discussion of the properties of the nonce is needed. Be careful to say that each MP_JOIN gets its own distinct nonce. The current wording could be misread to imply every MP_JOIN use the same nonce. The document uses "tear down the connection" informally. Please consider removing all such language and say instead what that means (in most instances it's already been said). At the first paragraph on page 18. "The CI is a unique number that is configured per host" is imprecise and misleading. Avoid the word configured, and spell out the uniqueness requirements for CI carefully here. Page 19 at "not all hosts will have all key types" : suggest s/have/support/ The exception in the last sentence of 3.2.6 is not clear. Consider a restructure where you can make it clear what you are supposed to do with an MP_HMAC that cannot be associated with a suboption when it _is_ in a DCCP-Ack in response to a DCCP-Response packet containing an MP_JOIN option at this point in the text. Page 25, 3rd paragraph - why "SHOULD silently ignore". When would you do something else? Page 25, last paragraph of 3.2.8 - It's unclearly stated that receiving a resent MP_ADDADDR overrides the SHOULD NOT perform further connection attempts. Is it the intent that a host _SHOULD_ retry each time it receives such a resent message? First paragraph of page 26 has a bare SHOULD - why is it not a MUST? Consider moving the last paragraph of 3.2.9 close to the very beginning of the section. At 3.2.10, the use of a capitalized SHOULD is not appropriate. It would be better to say "The path priorities signaled with the MP_PRIO option are hints". In 3.2.10 you say "priority flag" exactly once. Suggest s/priority flag/priority value/. It's potentially misleading to mix normative statements and examples. The prose on page 33 says the following options MUST be included, but then put example values into the options. Top of page 36 - why is this SHOULD? What would happen otherwise. Is this another example of MUST either do A or B, where A is preferred and B is currently implicit? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
