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

[Christer Holmberg <[e-mail]>]

​Hi,

>>>I have the following comments/questions:
>>>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."

---

>>>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].


>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.


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."


Regards,


Christer