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

From: G Fairhurst <[email-masked]>
Date: Sat, 24 Sep 2016 10:38:22 +0100

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.

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.

—
(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.”
—
(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 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.

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?
—
(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?
- 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?)
—