[art] Re: Artart last call review of draft-ietf-tsvwg-multipath-dccp-17

[[e-mail]]

Hi Russ,

thank you for your review. We will handle this in
https://github.com/tsvwg/ietf-multipath-dccp/issues/316.

Br

Markus 

> -----Ursprüngliche Nachricht-----
> Von: Russ Housley via Datatracker <[e-mail]>
> Gesendet: Freitag, 4. Oktober 2024 20:46
> An: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Betreff: Artart last call review of draft-ietf-tsvwg-multipath-dccp-17
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned ART-ART reviewer for this draft. Please treat these
> comments just like any other last call comments.
> 
> 
> Document: draft-ietf-tsvwg-multipath-dccp-17
> Reviewer: Russ Housley
> Review Date: 2024-10-04
> IETF LC End Date: 2024-10-17
> IESG Telechat date: Unknown
> 
> Summary: Almost Ready
> 
> The document is very well written.  Thanks for the significant effort.
> 
> 
> Major Concerns:
> 
> Section 3.2.4: I find the notation confusing: hostA d-key(A)=(key-a+key-b).
> Further, the use of "-" as part of the variable name is easy to confuse
> with a math operator.  I suggest that the paragraph be reworded to show
> how to compute key_d_a and key_d_b, which also avoids the key names
> looking like functions.  Maybe:
> 
>    Key Material is exchanged in plain text between hosts, and the key
>    parts (key_a, key_b) are used to generate the derived key (key_d)
>    by concatenating the two parts with the local key in front.
>    That is, key_d_a=key_a+key_b, and key_d_b=key_b+key_a.
> 
> If you accept this comment, then you might define the following:
>    *  HMAC(A) = HMAC-SHA256(key_d_a, message)
>    *  HMAC(B) = HMAC-SHA256(key_d_b, message)
> 
> Section 3.2.4: Is one of the Key Type mandatory-to-implement?  I realize
> that does not make that Key Type mandatory-to-use.
> 
> Section 3.2.6: The "Key" used for the HMAC computation is the derived
> key (d-key) described in Section 3.2.4.  This statement is ambiguous.
> In the proposed rewording of Section 3.2.4, the two keys values are
> key_d_a and key_d_b.  Which one is used here?  The answer appears in
> the bullets that follow, but it would be more clear to say it one time
> before the bullets.  Further, both Hast A and Host B need to "perform"
> the HMAC-SHA256 calculation.  One host is doing it to compute the value
> to include in the datagram, and the other is doing it to check the value
> that was received.
> 
> Section 3.2.6: The text says:
> 
>    ...  In the event that an
>    MP_HMAC cannot be associated with a suboption, unless it is an
>    MP_HMAC sent in DCCP-Ack in response to a DCCP-Response packet
>    containing an MP_JOIN option, this MP_HMAC MUST be ignored.
> 
> This text begs for an explanation of MP_HMAC sent in DCCP-Ack in
> response to a DCCP-Response packet containing an MP_JOIN option.
> If a sentence will not cover it, then please add a pointer to the
> part of the document that discusses this situation.
> 
> Section 3.6: The text says: " (if this is not possible it MUST be
> closed)."  Please reword.  Please do not burry the MUST statement in
> a parenthetical.
> 
> Section 4: Please add a paragraph that describes the consequences for
> choosing the Plain Text Key Type over ECDHE-C25519-SHA256 or
> ECDHE-C25519-SHA512.
> 
> 
> Minor Concerns:
> 
> The IANA registry indicates that Feature Number 10 was given a temporary
> assignment.  I expected to see a similar temporary assignment for Option
> Type 46.  Maybe this document will be published as an RFC before that
> can happen, but it seems prudent to make the assignment.
> 
> Section 3.1: The text says:
> 
>    Unlike the example in Figure 4, this document only allows the
>    negotiation of MP-DCCP version 0, which means that client and server
>    must support it.
> 
> I think it would be more clear to say:
> 
>    Unlike the example in Figure 4, this document only allows the
>    negotiation of MP-DCCP version 0.  Therefore, successful
>    negotiation of MP-DCCP as defined in this document, the client
>    and the server MUST both support MP-DCCP version 0.
> 
> Section 3.2.4: s/certificate authority/certification authority (CA)/
> Also, you may want to reference RFC 5280 for a definition of a CA.
> 
> Section 3.2.8:  The text says:
> 
>    ...  Note that an
>    implementation MAY discard incoming address advertisements - for
>    example, to avoid the required mapping state, or because advertised
>    addresses are of no use to it (for example, IPv6 addresses when it
>    has IPv4 only).  Therefore, a host MUST treat address advertisements
>    as soft state, and the sender MAY choose to refresh advertisements
>    periodically.
> 
> The nesting of examples makes this paragraph very difficult.  First,
> please separate the MUST statement and the MAY statement.  Then, offer
> examples to explain the reasons an implementation might choose to
> discard incoming address advertisements or refresh advertisements
> periodically.
> 
> Section 3.2.9: Different names are used for the inputs to compute the
> HMAC key in this section.  Please be consistent.
> 
> 
> Nits:
> 
> General: Some sections use "Host A" and others use "host A".  Please
> pick one capitalization convention and use it throughout the document.
> 
> General: Please use "bytes" (not "Bytes") when discussing the length of
> a field or message.
> 
> General: Please use "bytes" or "octets" when discussing the length of
> a field or message.  I have a mild preference for octets, but consistency
> is desired.
> 
> Section 1.2: Please consider adding a definition of 4-tuple.
> 
> Section 2: There is something odd with the line breaks in the two
> paragraphs.
> 
> Section 2.1: s/Hosts A and B, respectively./Hosts A and B./
> 
> Section 2.1: s/The two subflows continues/The two subflows continue/
> 
> Section 3.2.1: s/MP_SEQ Section 3.2.5/MP_SEQ; see Section 3.2.5/
> 
> Section 3.2.2: s/packet (See Section 3.2.6 for details)/
>                 /packet; see Section 3.2.6 for details/
> 
> Section 3.2.2: s/needing to know what the source address at the receiver is/
>                 /the need to know the source address at the receiver/
> 
> Section 3.2.7: s/down- and uplink/down-link and up-link/
> 
> Section 3.2.9: s/MP_SEQ Section 3.2.5/MP_SEQ (Section 3.2.5)/
> 
> Section 3.2.9: s/server, respectively on the affected subflow(s) (if possible)/
>                 /server on the affected subflow(s), if possible)/
> 
> Section 3.2.10: I expected a paragraph for each example since "Example
> use cases include:" is in a paragraph of its own.
> 
> Section 3.2.10: s/path values 3-15 depends/path values 3-15 depend/
> 
> Section 3.11.2: Please add white space between the adjacent paragraphs.
> 
> Section 5: s/Section 4/Section 4./
> 
>