Ballot for draft-ietf-tsvwg-rfc4960-bis
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
Thanks to the authors and contributors for making the 4960-bis happen. This surely shows the dedication to this work. SCTP is important part of Radio Access Network (RAN) deployment. I found the changes between -15 and -17 are very good. I don't think I have additional comments or concerns for this specifications. On the question of obsoleting RFC 8540 brought up by my IESG colleagues, I know RFC 8540's role for 4960-bis and this bis refers (informative) to RFC 8540 for further details. I don't think obsoleting RFC 8540 will change the reference for details relation form 4960-bis. Then the question is -- is there anything in the RFC 8540 that has not been included in this 4960-bis and that need to leave of it's own? If the answer is NO then we might just obsolete RFC 8540.
[general; comment] * I suspect that my notion of {src,dst} transport address tracking doesn't align with the model under which this was developed. There are several places where parameters associated with a given destination address might be tracked on a {src,dst} basis, at least for implementations for which the accompanying complexity was deemed justified. Some observations are made in this context; I don't expect they need to be considered at this (bis) point in time. [S2.7; nit] * s/Describe ... more precise/Describe ... more precisely/ [S5.2; question] * In light of Path Verification discussion in 5.4 is one of the reasons that a (duplicate) COOKIE-ECHO chunk might arrive a consequence of path probing during connection setup? [S5.4, S7.3, S8.3; question] * Is the assumption here that there will be only be one source address selected for each proposed destination address? I would have thought that if the INIT and INIT-ACK each had multiple IP addresses that the probed paths (and thus paths along which PMTU discovery would be performed) could in fact be the union of the Cartesian cross product of all {INIT} x {INIT-ACK} addresses of matching address family. [S6; nit] * At first I thought "out of the blue" might be replaced with something less idiomatic for non-native English readers, but I see that S8.4 goes so far as to craft the OOTB acronym. Perhaps add this phrase and a one-sentence summary (and maybe a link to S8.4) to the list of key terms in Section 2.3. [S6.5; question] * Does this mean that the first unordered user message within a stream uses a Stream Sequence Number of previous+1 and that all subsequent unordered messages on that stream MUST use the same sequence number (of that first unordered message)? (The fact that unordered messages don't cause an increase in sequence numbers struck me as a bit odd/unnecessary.) [S8.2; nit] * s/user ought avoid/user ought to avoid/ [S11.1.5; comment] * It may be too late, but it seems like an optional [,source transport address] might be part of the API for platforms that might want to allow sending from more than one validated/active source address. [S11.1.7; comment] * It may be too late, but should there be an optional local transport address to indicate at which local address a message was sent? I get that packets might arrive at multiple local addresses, but given that (I think) they can be sent from multiple remote addresses and there is a parameter to return the sender's address, I just thought... [S11.1.9; comment] * It may be too late, but should there be an optional source transport address parameter as well? [S11.1.10; comment] * It may be too late, but should there be an optional source transport address parameter as well?
Thank you for the work on this document. Many thanks to Eliot Lear for his thoughtful review: https://mailarchive.ietf.org/arch/msg/art/j0zknGwfrVc4rIzEqD3tE2kmFgY/ , and thanks to the authors for addressing his comments, as well as incorporating changes that improved the text. Francesca
Thanks for your work on this. I noticed in the shepherd write up: “SCTP is implemented in endpoints either in the operating system or a user stack. Running code for SCTP exists in several TCP/IP stacks. All main STCP implementations are expected to comply with 4960.bis. **The document is expected to fulfill the requirements of an "Internet Standard"** according to RFC 2026 and RFC 7127.” (emphasis added) I wonder why that isn't the intended status, then?
I also relied largely on the diff to RFC 4960 for my review, and I only found a couple of things to mention. First, I'm also curious about the Internet Standard question raised by other ADs. Section 15.4, which is largely copied from RFC 4960's Section 14.3, defines a Specification Required registry. RFC 8126 says that advice for the designated expert reviewing these should be provided. I realize such was missing from the original; should we take this opportunity to add some? Section 15 as a whole is really big; the text in 15 (i.e., all the stuff before 15.1) could probably benefit from being broken into subsections.
Thank you to David Mandelberg for the SECDIR review. ** Section 2.5.3 Once a user message has been fragmented, this fragmentation cannot be changed anymore. This new text appears to have been added for clarity, but I don’t follow the intent. ** Section 3.3.5 When a HEARTBEAT chunk is being used for path verification purposes, it MUST hold a random nonce of length 64-bit or longer ([RFC4086] provides some information on randomness guidelines). As a carryover from RFC4960, the text makes clear that 64-bits is a minimum. Is there any guidance on the trade-space of why and when a larger nonce should be used? ** Section 5.1.3 Choosing a high performance MAC algorithm increases the resistance against cookie flooding attacks. A MAC with acceptable security properties SHOULD be used. Is “acceptable security properties” a use case specific decision and therefore out of scope? Taking the position of an implementer, I’m not sure how to act on this normative “SHOULD”. ** Section 12.2.4 or 12.3. These sections appear to be establishing the expectations for SCTP endpoints and middle-boxes. Section 12.2.* discusses denial of service attacks and associated mitigations via logging and statement management by the end-points. Would it be worth mentioning that middle-boxes can also play a role in filtering and rate limiting if needed?
Thank you all of the work on this, and to Linda Dunbar for the OpsDir review. I fully agree with Alvaro that this document should obsolete RFC 8540, and that it should be updated to say so. In addition, I had started writing up a slightly grumpy ballot about how long the Abstract was, but then realized that this is almost as long in the original :-) Thanks again, W
Thank you for the work put into this document. I am copying Rob Wilton's text as it also applies to my review: "Given my lack of familiarity with STCP, I have only quickly reviewed the diffs before this document and the base RFC, and do not have any significant comments that will improve this document." Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Gorry Fairhurst for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 10 -- I wonder what is the purpose of this section dedicated to ICMP handling, e.g., ICMP1-5 are pretty obvious. It is of course not harmful to keep this section but perhaps limit it to the important ones like ICMP6 and the rest ? ICMP7: please s/v4/IPv4/ and s/v6/IPv6/ (also applicable in other parts). I would also prefer s/an implementation MAY process/an implementation SHOULD process/ -- Section 12.2.4.1. -- Suggest to use "ESP" wording as in 12.2.3 About "IP Authentication Header", I am unsure whether it is still commonly used and adding a reference to RFC 4302 is probably required. -- Section 7.2.1 -- Just curious about why the "cwd" is computed differently for IPv4 and IPv6 (I do not understand the 60 bytes difference)
[This point doesn't reach the level of a DISCUSS, but I believe it is important and that it must be addressed before publication.] This document should Obsolete rfc8540, which was used to provide "a history of the changes that will be compiled into a bis document for [RFC4960]." With the publication of this document, it will have reached the end of its useful life. Note that rfc4460 was not declared Obsolete by rfc4960. So this document should take care of that too.
Many thanks for the extensive and very thoughtful discussion in response to my previous ballot comments; I'm happy to say that we reached resolution on all of them (for some of them, educating me on my misunderstandings).
Thanks for pulling these updates together - I think that it will make a helpful future reference. Given my lack of familiarity with STCP, I have only quickly reviewed the diffs before this document and the base RFC, and do not have any significant comments that will improve this document. I was slightly surprised to see that this wasn't going for Internet Standard rather than Proposed Standard, but I presume that this was considered and there was a good reason not to do so. Regards, Rob