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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 11 May 2020 07:12 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 456D03A08AE for <mmusic@ietfa.amsl.com>; Mon, 11 May 2020 00:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=ericsson.com
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 LoDc7hBgR266 for <mmusic@ietfa.amsl.com>; Mon, 11 May 2020 00:12:53 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED473A08AD for <mmusic@ietf.org>; Mon, 11 May 2020 00:12:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HHKMl2m5JLVvjW2S0d0vfMfMvGQrA/d/Xd7xvYkNPVbfFvmrLtWM5vG4l/0+C8OEtYBkjfgN9Wy4V7unWViQvXwGgQE1KvWf7OZVDFmUmuH15uGOV3s0al2Ypzv52/Fz/6wCSVn2whhBtyudyb1srvzg6ExiT6fvkQVXCsENNzFgJd0LKctwkUkgSa+02U1VFPniX4eZ86Qda2101hOKuhZVC1g7zshQgOLorZ1uVxgyV8XX7nPU02LXFmoHQv6Lsqn2O2AmR64TD2lqmMchiFREvB/KyMBzfVd6tTa3IBvDR71zBuMQPwpaKm3Bl9fT+Q3z7yC2U1kP0/zn0mlbZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bg/flv4SIcz6U0iMutDnVhZcomo4AXvJP19+Twcl7Cs=; b=YRoz1mjzkNxC+hA+Kca0XHDWMadirC8HWqAqZzXflsdh3CaMHHjE+VEzX6NVdE+nMxwW30ZMhFrZCw6/aEN9OSCp7C09aOpv8X0SxmRoHwpI1sIPPP9phCaRNgog+Vl43bN+dmIT7H/fg8+GFRRXtvc4UcCJiKQdQIOd0SHq5k4CaswAFjyPa1I/lCX9Y80vgSsWsGS4ZcXGDDlmYHWlHrX2/nyswpqgUZtrOoUlQXdlVjEZ4xSD9MHSAVFn68o/xanZTD68MMz3tZlXX2KRYLMQj/PpZNt4YrxdPBXEGMjv88dDm3FRmRn8CWqC/wO6YQpSVoZIF4yRP7oZZqHV/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bg/flv4SIcz6U0iMutDnVhZcomo4AXvJP19+Twcl7Cs=; b=gr2jBL9LmCYNjxy1a8cOPm3xKenhFbt2kec8KPYTsNJjIjtFS2RmctG/1gI4rJvUpeHgfl2A4wU+7sSz80pLEsSWM3ZZpAD6KRY1FpKQNL/OekS0jhs3Nxx3tNvp30w1T2OkCkkqpSKJeuZYVe9W+suPJphH5gzyKnVl2FGzAWU=
Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6930.eurprd07.prod.outlook.com (2603:10a6:20b:1c3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.13; Mon, 11 May 2020 07:12:50 +0000
Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Mon, 11 May 2020 07:12:49 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@ghaccess.se>, Jose M Recio <jose@ch3m4.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
Thread-Index: AdYjuWxe8jgvP3HuS5indZrl5qmwswCdnrwAABnTpQAAE676AAACgJ8MAAcPVwAAHCGVgA==
Date: Mon, 11 May 2020 07:12:49 +0000
Message-ID: <DEE22CB6-4962-4070-92CF-DD77E6E2D6BE@ericsson.com>
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> <7df68c5e-0597-9da5-3fdb-0bf632c75297@ghaccess.se>
In-Reply-To: <7df68c5e-0597-9da5-3fdb-0bf632c75297@ghaccess.se>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: ghaccess.se; dkim=none (message not signed) header.d=none;ghaccess.se; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.127.223.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dbe5fb6e-37cd-403c-808d-08d7f57ab69c
x-ms-traffictypediagnostic: AM7PR07MB6930:
x-microsoft-antispam-prvs: <AM7PR07MB69306A80BECE94F3CB8C04D693A10@AM7PR07MB6930.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04004D94E2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2/hSbOfT/mMHuwlOdD7mrdbEp4N+oU7IHwLp5BQ7WJA5bEJ2G4CVVqO7XAvJL+Dqtf8qgJoqB1+lOwaV+ZZIs59scDvtApaWdIKzsCEEgepdpnzQejW1T/+QEtooPgvDoqJrB55M3Hqq7kswPduqpMyIzPIw83CGR7ATy2OddiId7yZ0SKsMClfbOpYO5Qg+elA6RoAcuGZFpQ3ZH4CKVq2Jg7QyG0+1J01qzUxIrjjZy2J43b5TdlBb/za6/gF5proCnKC6w3mVk1m6HLjSNwB9B0qiYuiJS5PZJV5NsNb6PGbqH5gTSl5Mh6wOa64v0IjwkIk3LJ1TrWYj0aGTY4axjdd7xrEh8U3ooYNgd8k82AROv7LgKlgCTpDATFTwSROe3Bpmkw+70iiq84diJZLRjv2WThRyj4bs40CLCE+Zw3gmbAHlVDdfpdDcHCqT2on4dfaHuwwPMlPw6W5bY4KQC6ybUo7DtNS3YJdtgUH4R9/LQQP6NqYK4YCj0L8j3uyaLVTySJ/0RSC6vwFxAA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(136003)(366004)(376002)(33430700001)(71200400001)(8936002)(2906002)(44832011)(186003)(2616005)(33656002)(6506007)(26005)(36756003)(66446008)(64756008)(66476007)(66946007)(66556008)(8676002)(316002)(91956017)(76116006)(110136005)(478600001)(6486002)(5660300002)(86362001)(6512007)(33440700001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LSyfXawCMJkpwOZ6qzQpRlMPfRFVg2CRecvMIi6CHCdLYCEcKfhiHb8pmd8zFQP0DmJnAkmVGIIJOACMuk5r+4XsNlH34f5MHsVfg1dhyQgmXv9SEB2oZu5eX1uaW/V5IzcBP1kS5UblOGON6roqV2gD7nYWcTjB/v6rQkuM0gjjDuqPQrLvnUjVIpPyG9FeCRGnS6nZuGjM5TGT+4EOikbx0pp0tOr9+Lvh0bWEZlo/NL5GtN/nPj7gM/nM07ZkS3Mkp6HQMOL/6S1yocJOE1ce8CcMJ46Zge+wCpITnQTG9gPKqdt8dt0EsjqPsfXru8KY0GQaeESLklHRk72rta9D8s5/85hX2zyIgbrwboF5LRK7AAaVJenHBogvZX+xshvSfiLwc776n0sBdQIKqNFdxpHgm77xSvyWCKVCUrwcokZpALDdtSZVo9RJUT1NU47Un55dCiuhlxN7dBwfQX05UNAdsfdaDK1VlsV4Y7sLPDHkCyR+DFeVFpTBfmYb
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <66F3F3D81C868F45969556E849866D1D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dbe5fb6e-37cd-403c-808d-08d7f57ab69c
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 07:12:49.4052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yv57SndEPK7gIRSB41vb4a1+T9I5PDaOwmzYU/kCycyewybtj6PnHLA/5+dsOYMsS063VjC5eqN3o3cr3mkhR6oNOFxopSEvXnLjg2hO0PA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6930
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/hpPUr1OzxK14jO-DFHHY0Vs9Bz0>
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: Mon, 11 May 2020 07:12:55 -0000

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