Subject: Re: [tsvwg] Document shepherd review questions on draft-ietf-tsvwg-sctp-ndata-07

From: Michael Tuexen <[email-masked]>
Date: Mon, 31 Oct 2016 09:56:44 +0100

> On 24 Sep 2016, at 11:38, G Fairhurst <[email-masked]> wrote:
> 
> 
> I have just completed a detailed read of draft-ietf-tsvwg-sctp-ndata-07, with a view to progressing this document to a WGLC.
> 
> It seems this document is now stable, and there has not been much discussion recently on the technical design of this specification, indicating this may be ready now for a detailed review of the text. If any people in the WG feels that some feature or mechanism needs to be changed, please speak-up on the tsvwg list.
Hi Gorry,

thank you very much for the review.
See my comments in-line.

Best regards
Michael
> 
> Gorry
> (TSVWG Co-Chair)
> 
> —
> I have 4 document questions:
> 
> (1) UPDATES
> 
> It appears to me that some sections of this spec may indeed be updates to RFC3758 and RFC6525?
> 
> I am therefore asking whether readers of these specs need to be aware of the changes in this spec, and my thoughts were that this may be important to ensure the implementations can in future support interleaved data. If you agree, then please add text to say this and indicate in the UPDATES header, if you do not think this is needed we should discuss this.
Someone implementing RFC3758 and RFC6525, but not this document, doesn't have to care
about this document. Only when this document is implemented in combination with
RFC3758 or RFC6525, the details given in this document have to be considered.
I think this means this document does NOT need to update RFC3758 and RFC6525.
But if I'm wrong, I'm happy to add the "Updates" stuff.
> 
> —
> (2) ABSTRACT
> 
> The abstract, or parts of it are often used on their own I wonder if it is worth re-phrasing the abstract, is it perhaps better to say:
> 
> “The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrary large user messages. This document adds a new data chunk to SCTP. This
> allows a sender to interleave different user messages that
> would otherwise result in head of line blocking at the sender.
> 
> Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving.”
OK. Taken.
> —
> (3) PLEASE CLARIFY REQUIREMENTS ON IMPLEMENTATIONS
> 
> I would prefer it to be very clear at the start of section 2 that there are requirements here that impact the SCTP stack.
> 
> Current text:
> /It should be noted, that an SCTP implementation needs to support the coexistence of associations using DATA chunks and associations using I-DATA chunks.
> /
> - This seems to me like a requirement. Can we use the REQUIRED keyword here to say what implementations need to implement? - e.g., can this be placed in section 2?
I added at the beginning of section 2:
<t>An SCTP implementation supporting user message interleaving is REQUIRED
to support the coexistence of associations using DATA chunks and associations
using I-DATA chunks.</t>
> 
> I think some statement pointing forward to section 2.3. is also an implementation requirement, and this clause could usefully also come at the start of the section, so it is read by people interested in SCTP in general and not just the details of this extension.
Added in section 2:
If an SCTP implementation supports user message interleaving and the extension
described in <xref target='RFC3758'/> or <xref target='RFC6525'/>,
it is REQUIRED to implement the corresponding changes specified in
<xref target='interactions'/>.</t>
> 
> 
> Base on this, I have this question: are all RFC-compliant SCTP implementations now REQUIRED to support the ability to have associations that use DATA Chunks and associations that have negotiated to use I-DATA chunks? — or is it more true that:
> all SCTP implementations that support I-Data are REQUIRED to support the ability to have associations that use DATA Chunks and associations that have negotiated to use I-DATA chunks?
Yes. Stated now as above.

But not every RFC 4960 compliant implementation is required to support user message
interleaving.
> —
> (4) LIST OF SCHEDULERS
> 
> Having read section 3, I think it “defines” a set of schedulers. This seems useful.
> 
> I’m not sure whether the list is informative or normative - as I read, it could be either. Although clearly a sender-side function, are the names defined here known to the protocol, endpoints? This is nor clear, although the names are referenced in the informative annexe.
> 
> I’d like to understand whether a registry needs to be created in IANA to hold the list of schedulers?
No IANA action required since this is a sender side only thing. The constants
defined are just used in the API.
> - these items are explicitly called-out in section 4 could be needed elsewhere?? (e.g., could other RFCs or documents define new scheduler mechanisms in future that should be uniquely identified?, a registry would probably be needed if a MIB was ever made to report the type of scheduler, there may be other future reasons to signal what scheduler is used for the recipient application?)
> —
>