Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

["Ben Campbell" <[e-mail]>]

Thanks for the response. Replies inline.

Ben.

On 21 Jan 2017, at 14:23, Christer Holmberg wrote:

> Hi,
>
> Below are my replies to Ben's technical comments.
>
> ----------------
> Substantive Comments
>
>> -1, first paragraph: RFC 5572-update is currently in IETF LC. Is 
>> there a reason not to reference it instead?
>
> I assume you mean 4572-update :)

Yes :-)

>
> I agree that we should reference that spec instead, and I'll fix that.
>
> ----
>
>> -4.1, last paragraph:
>> I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP 
>> or TCP/DTLS/SCTP,
>> not fmt values in general.
>
> Correct.
>
>> It would help to be explicit about that.
>
> The first sentence in section 4.1 does say:
>
>    "This section defines the following new SDP Media Description (m-
>    line) protocol identifiers (proto values) for describing an SCTP
>    association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'."

I'm not sure all readers will see the connection between the first and 
last paragraph. I still think it would help to explicitly mention it. 
(Especially if it moves to 4.3)

An alternative, if it were to stay in 4.1 would be to have the opening 
paragraph in 4.1 explicitly mention that it includes the fmt values to 
be used in the context of these new proto values.

>
>> (Also, it seem like this paragraph belongs in section 4.3).
>
> I could move and combine it with the 4th paragraph of section 4.3:
>
>    "The m- line fmt value, identifying the application-layer protocol,
>    MUST be registered by IANA. Section 15.3 defines the IANA registry
>    for the media format namespace."
>
> ----

[...]


> ----
>
>> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, 
>> SPECIAL means you need to refer
>> to the rules in the protocol definition. But the text here basically 
>> say that the rules are undefined.
>
> I'm ok using CAUTION. I agree it might be more appropriate than 
> SPECIAL.

I'm glad we agree :-) This is probably a big enough change to make sure 
the workgroup also agrees, though.

>
> ----
>
>> -6.1: What is meant by saying an "endpoint MUST assume that larger 
>> ...
>> will be rejected"? Can that be stated in terms of actual procedure 
>> (e.g.
>> "endpoint MUST NOT send...larger"?
>
> I'd like Roman's input on this, in case he had some cases in mind 
> where endpoint will have to send larger messages.
>
> I guess we could say SHOULD NO send larger message, and explain that 
> one cannot assume that larger message (if sent for whatever reason) 
> will be accepted by the peer.

That would be reasonable if it is the right answer. I just want to avoid 
the vagueness of "MUST assume".
>

[...]

> ----
>
>> -9.1, 2nd paragraph: Don't the lower layers need to be established 
>> before the
>> upper layers? Won't removal of the TCP connection or DTLS association 
>> break
>> an existing SCTP association?
>
> Roman had lots of input on this, so I'll let him reply.

Okay

[...]