[MMUSIC] Draft new version: draft-sctp-sdp-22 [was: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments]

[Christer Holmberg <[e-mail]>]

Hi,

Version -22 has now been submitted.

Thanks! :)

Regards,

Christer


On 24/01/17 22:16, "Christer Holmberg" <[e-mail]>
wrote:

>
>>All looks good to me. Please submit a revision when you are ready, and I
>>will request >the IETF Last call.
>
>I'll do it tomorrow. The other changes are on a local branch on my office
>computer.
>
>Thanks!
>
>Regards,
>
>Christer
>
>
>
>
>On 24 Jan 2017, at 14:04, Christer Holmberg wrote:
>
>> Hi,
>>
>>>>>>>>> -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."
>>>>>>>>
>>>>>>>>
>>>>>> Ok, so my suggestion is to:
>>>>>>
>>>>>> 1) Move the paragraph to section 4.3, as described above
>>>>>> 2) Modify the first paragraph in section 4.1:
>>>>>>
>>>>>> "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'.  The section
>>>>>>    also describes how an m- line, associated with the proto
>>>>>> values, is
>>>>>>    created, and how the the media format (Œfmt¹) values are used."
>>>>>
>>>>> The change helps, but does it still make sense if the last
>>>>> paragraph of 4.1 moves to 4.3?
>>>>
>>>> So, you suggest to not move the last paragraph to 4.3?
>>>
>>> No, my suggestion is to either (put the additional sentence in the
>>> first paragraph of 4.1 and keep last paragraph in 4.1) _OR_ (move the
>>> paragraph to 4.3 and put the clarification in _that_ paragraph.)
>>
>> Ok, so:
>>
>> 1) Don't modify the 1st paragraph in 4.1
>> 2) Move the last paragraph to 4.3
>> 3) Modify the paragraph in 4.3:
>>
>>       "When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values,
>>         the m- line fmt value, identifying the application-layer
>>         rotocol, MUST be registered by IANA. Section 15.3 defines the
>>         IANA registry for the media format namespace."
>>
>> ----
>>
>>>>>>>>> -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".
>>>>>>
>>>>>> I suggest the following modified text:
>>>>>>
>>>>>> "An SCTP endpoint SHOULD NOT send a SCTP user message with a
>>>>>> message size that is larger than the maximum size indicated by the
>>>>>> peer.
>>>>>> If
>>>>>> the SCTP endpoint needs (for whatever reason) to send a larger
>>>>>> message, it cannot be assumed that the message will be accepted by
>>>>>> the peer."
>>>>>
>>>>> I'm okay with that, but don't be surprised if we get questions
>>>>> about whether it ever would ever make sense to send a message that
>>>>> you can't assume the peer will accept.
>>>>> (I wonder if it's more a matter
>>>>> of "probably not accept", given the peer has already stated its
>>>>> preference.
>>>>
>>>> If nobody objects, I am ok saying "MUST NOT send".
>>>>
>>>> Because, if there is a case where it would be needed, the peers
>>>> simply need to support and negotiate a larger value.
>>>
>>> Okay with me. If someone comes up with a plausible reason one might
>>> need to send larger messages, please speak up before the IETF LC
>>> completes. :-)
>>
>> Suggested modified paragraph:
>>
>>          "An SCTP endpoint MUST NOT send a SCTP user message with a
>> message
>>           size that is larger than the maximum size indicated by the
>> peer, as it
>>           cannot be assumed that the peer would accept such message."
>>
>> Regards,
>>
>> Christer