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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sun, 10 May 2020 16:13 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 1AEA93A0A87 for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 09:13:52 -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 WHJZ_5EUE0wv for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 09:13:43 -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 F33EF3A0909 for <mmusic@ietf.org>; Sun, 10 May 2020 09:13:36 -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 D0A1A20097; Sun, 10 May 2020 18:13:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589127213; bh=mr5zqo+15KzYVqvcXHXk7birSt3/1VysCUXoht14PAM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rKiUDZyAQV+vvtBsWmgX6oyDB4r8B/lqbnFpxDT1IP6lDxcgfSd3m1BE8n5uxy6jN gsY840M3WK9ejfqPkzsiH29zcBlPo7o9btGr0Cq9x0RrX6rgV6qCbHfQwG5DA+aT5a DTlCJGcAahIPcvsg6MTfVbLlFZl/LnxJXjVxL+UQ=
To: Jose M Recio <jose@ch3m4.com>, mmusic@ietf.org
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <cb511151-af0d-a4d7-c82f-2191a7e88cd9@omnitor.se> <134665e3-0fba-f7c8-89d4-86951ed7fb29@ch3m4.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <69f3e5d2-aba7-2bcd-0ed0-40ea9f5c121e@ghaccess.se>
Date: Sun, 10 May 2020 18:13:30 +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: <134665e3-0fba-f7c8-89d4-86951ed7fb29@ch3m4.com>
Content-Type: multipart/alternative; boundary="------------EC51906DE9D10B015A2C5AF1"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Me1SEqnWIp0teNFMGlqFpCSod5Y>
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 16:13:53 -0000

Hi Jose

Den 2020-05-10 kl. 08:49, skrev Jose M Recio:
>
> Thanks for your comments, Gunnar,
>
>
> On 10/05/20 02:30, Gunnar Hellström wrote:
>>
>> Hi,
>>
>> I agree that the draft seems to be in good shape.
>>
>> 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?

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


Regards

Gunnar

>> Regards
>>
>> Gunnar
>>
>> Den 2020-05-06 kl. 17:20, skrev Bo Burman:
>>>
>>> Greetings MMUSIC ,
>>>
>>> This is to announce a 2 week WGLC on the draft:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-16 
>>>
>>>
>>> as Proposed Standard. Please review and provide any comments you may 
>>> have on the document by
>>>
>>> Wednesday, May 20, 2020.
>>>
>>> Comments should be sent to the document authors and the MMUSIC WG list.
>>>
>>> If you review the document but do not have any comments, please send 
>>> a note to that effect as well.
>>>
>>> Thanks,
>>>
>>> /Bo
>>>
>>> (MMUSIC co-chair)
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> -- 
>>
>> + + + + + + + + + + + + + +
>>
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se