Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Christer Holmberg <[e-mail]>]

Hi,

1. Should the draft say that it updates RFC 4975?

>>>>>The msrps scheme is also IANA-registered in RFC 4975 section 15.5.2. 
>>>>>Please check if that registration need update because of the reuse of the msrps scheme.
>>>>
>>>>Thanks for bringing this back. WG was asked for feedback about updating IANA registry or 
>>>>keeping as it is, with the argument that data channel uses DTLS so it would conform
>>>>original “msrps” requirement, that refers to TLS. There was no clear outcome.
>>>>
>>>>If there are no comments opposing this, I would follow your comment and add it to IANA updates section
>>>Good. 
>>>Would it also be suitable to say that the draft updates RFC 4975, because of this? 
>>
>> I agree that a reference to the document should be added to the IANA registry for the "msrps" scheme.
>>
>> And, if people think 4975 should be updated, I guess we could say something like:
>>
>> "This document RFC 4975, by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS."
>
> I assume you mean that the sentence starts: "This document updates RFC 4975 ...."

Correct.

---

2. Data reception is not mentioned.

>>>>Section 5.5 is about data sending and reporting. There is no section about data receiving.
>>>>It seems that as for sending, it would be sufficient to refer to RFC 4975. 
>>>>I suggest that data reception is included in section 5.5.
>>>
>>>I propose:
>>>"Data sending, receiving and reporting procedures SHALL conform to RFC4975"
>>
>>Fine.
>
> I am ok with that.
>
> On a more generic level, should be replace "SHALL" with "MUST" throughout the document? Currently we are using both "MUST" and "SHALL", and I think it would be good to be consistant.

---

3. Channel or association failure handling should be specified

>>>>>There is nothing said about channel failures or SCTP association failures. I assume 
>>>>>that transmission failures are handled under "reporting" in section 5.5, but that does
>>>>>not cover channel or association failures. 
>>>>>
>>>>>RFC 4975 has a section 5.4 "MSRP Connection Model" that includes connection failures, and
>>>>>considerations for retrying a failed connection. Please check if it can be sufficient to refer to
>>>>>that section for this issue. 
>>>>
>>>>I think RFC4975 should be enough, failures detected at transport (data channel) level should
>>>>trigger the actions specified in RFC4975. I will add a comment.
>>>>
>>>>> Sections 4.6 and 5.3 in the draft are about session closing, requiring SDP signaling for session closing.
>>>>> Consider adding some words about that nomal closing requires SDP signaling, while connection failure
>>>>> may result in session closing without sdp exchange.
>>>
>>>What about this:
>>>
>>>Changing "The closure of an MSRP session MUST be signaled via an SDP" -> "Normal closure of an MSRP session MUST be signaled via an SDP"
>>>
>>>Adding "Connection failure may result in session closing without SDP exchange. If the endpoint attempts to re-create the session, 
>>>procedures specified in RFC4975 SHALL be followed"
>>>
>> Actually, I would suggest some re-wording.
>>
>> Some details can be removed, since we are following the procedures in draft-mmusic-data-channel-sdpneg: we don't need to talk about
>> offer/answer, and we don't need to talk about which endpoint triggers the actual data channel closure procedure.
>>
>> Also, there is no need for a MUST, because we simply describe how the MSRP session is closed.
>>
>> OLD:
>>   The closure of an MSRP session MUST be signaled via an SDP offer/
>>   answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
>>   lines associated with the MSRP session from the associated DTLS/SCTP
>>   based media description.  This results in the associated data channel
>>   being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
>>   where the actual data channel closure procedure is typically
>>   initiated by the SDP answerer right after having accepted the SDP
>>   offer.
>>
>> NEW:
>>   An MSRP session is closed by closing the associated data channel,
>>   fllowing the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].
> Yes.
>
> But I think the draft lacks general requirements to apply procedures from RFC 4975 and just modify them by msrp channel specific procedures. 
> It may be felt as obvious, but I cannot find it stated anywhere. 
>
> Especially in the beginning of section 5. MSRP Considerations :
>
> Current text: "
> This section describes the MSRP considerations specific to a MSRP
>   data channel.
> "
> Proposed text:
> " The procedures specified in RFC 4975 apply except when specifications in the present document introduces other procedures.   
> This section describes the MSRP considerations specific to a MSRP data channel."

With some minor editorial changes I think that sounds good.

>>I think you are also obliged to do some actions to clean up from the lost channel or association. Please check the
>>data channel specs if anything more is needed. E.g. sdpneg section 6.6.1, but I am not sure that the channel close
>>that is specified there is close because of failure. 
>
> Per 4975, if the connection fails, endpoints MUST consider the MSRP session failed. There is no requirement to do any clean-up,
> or try to re-establish the connection.
>
> Yes, but I meant clean-up after the lost MSRP data channel, e.g. sdpneg section 6.6.1, and maybe something more if the closure is because of a connection failure. 

There is no requirement to do anything.

>> We could add something like:
>>
>> "If the SCTP association [RFC4960] used to realize the MSRP data channel fails and gets torn down, the endpoints MUST consider the MSRP session
>> failed. An MSRP endpoint MAY, based on local policy, try to re-establish the SCTP association, and negotiate a new MSRP data channel."
>> Yes, but I suggest adding  both sdpneg section 6.6.1 and RFC 4975 section 5.4 Connection model. 
>
> (I think there may be a general lack of specification in the RTCWeb and WebRTC and data channel documents about how to handle
> connection and association failures, but that is a topic for another discussion)
 
Yes __

Based on the feedback I have received, isolated SCTP association failures isn't a big problem. If the connectivity goes away then most likely your signaling won't work either. 

Regards,

Christer