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

[Gunnar Hellström <[e-mail]>]

Hi,

Den 2020-05-10 kl. 19:57, skrev Christer Holmberg:
> ​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."
>
I assume you mean that the sentence starts: "This document updates RFC 
4975 ...."
>
> ---
>
> >>>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."




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

Thanks,


Gunnar

> Regards,
>
>
> Christer
>
-- 
Gunnar Hellström
GHAccess
[e-mail]