Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sun, 10 May 2020 20:47 UTC
Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE623A0BAD for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ulVmp-1tDnc for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 13:47:22 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B0F3A0BAA for <mmusic@ietf.org>; Sun, 10 May 2020 13:47:21 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id C58052009C; Sun, 10 May 2020 22:47:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589143638; bh=gx+8Y/VD1JKeWFR8L3fXCXEpiMSyyr6qXSh0Y8GvC2U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aC+yIH2Qr1fD8e+yi7Uxg92uqFu3JASp3BT4uDnRFTOtX9in0QGSowEjjh6OJ52XN 2J8d1nrDYb1PcY1pmfG4oCGUzddAqzQn4CrGBOpjtK/dSu9fipxO5+gNcf/xu7ZFT1 +okG+8ZZnIhW5REaA8D2NECrk9z1zr8vRu/Y6QSI=
To: Christer Holmberg <christer.holmberg@ericsson.com>, Jose M Recio <jose@ch3m4.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <cb511151-af0d-a4d7-c82f-2191a7e88cd9@omnitor.se> <134665e3-0fba-f7c8-89d4-86951ed7fb29@ch3m4.com> <69f3e5d2-aba7-2bcd-0ed0-40ea9f5c121e@ghaccess.se> <AM7PR07MB701293DB525EE2BC6F7C953793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <7df68c5e-0597-9da5-3fdb-0bf632c75297@ghaccess.se>
Date: Sun, 10 May 2020 22:47:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <AM7PR07MB701293DB525EE2BC6F7C953793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------D1147BA50B218AA86A4058A1"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/AE1TJX8HzZd42WWpNx_S7uEWBxg>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2020 20:47:31 -0000
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 gunnar.hellstrom@ghaccess.se
- [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-dat… Bo Burman
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Bo Burman
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Keith Drage
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Gunnar Hellström
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Paul Kyzivat
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Jose M Recio
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Bo Burman
- Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage… Christer Holmberg