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 <noreply@xxxxxxxx> > Gesendet: Freitag, 4. Oktober 2024 20:46 > An: art@xxxxxxxx > Cc: draft-ietf-tsvwg-multipath-dccp.all@xxxxxxxx; last-call@xxxxxxxx; > tsvwg@xxxxxxxx > 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./ > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
