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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 07 May 2020 19:52 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 8D2A13A0CF1 for <mmusic@ietfa.amsl.com>; Thu, 7 May 2020 12:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 prpczO1sc8Vq for <mmusic@ietfa.amsl.com>; Thu, 7 May 2020 12:52:49 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2087.outbound.protection.outlook.com [40.107.92.87]) (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 B11463A0CE7 for <mmusic@ietf.org>; Thu, 7 May 2020 12:52:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cLx20fuEa0VC/pl3asdW4Okiv7kNwyr9H/xWYtPGwLdnymOoeV63aIDW8wU91abI4i4jjL4KPNUAgSZLGZLb7EakFs9k6Rs0opOmE8Ncu5ZjQ1AlEi3gTb60A87a9JVEQusYakU6TO+YaKYvsbQ5f0q4bJ2i3pWbk9hs/0MO0NiUAcq9xDCDV3kYEWPRpFN/O1HFpX7aVwqOELYeqgR8gGf7C9zgu28Gm3ali5cbMl4keBC3bm70aOW9C4gWrkS4ZeAUx/j/EWA6RQPD31u6gzk5bmQ67oz7BhT/jmeNEHIB4ZHaorlLdFWIhHVzP85YjW2IVJMEVxcDt7KYvDDfEQ==
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=TepHHMtqwTz1J4raqB/1K0mYGeynsqhycJ9xBT/bQ5w=; b=laWHckUXJnqGK1jgKLtJ9C5apl26t9z3ZCThwj7Go9PXw2q69L6pXmE3r1cfEwzVKTD5uN9kjJaKC8eI4x5Yv8nHVqVra+4BGz35wLZ1VjHXt5YyiVEHdUU/TTwawFZ2dpCFf84kOT6D6fH78O+2rYE/9ZtQVIie/VxYN2IYmwCiWBs0SGBRzmavoNBvCPeJfu2W7Pr6KUzRbWiZo2AkNyh0aJwvN8DDQSq5GuFnE8ZZOmknChdseku95gz2nyCb2j8aQ++R8FZkgO8I3zoaKH9x96kBIpwrWXlApJV2i2BYnP/fE+jl8vc3tiB8aod7h0S9+7d6WsrNZ7LOeaYqHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TepHHMtqwTz1J4raqB/1K0mYGeynsqhycJ9xBT/bQ5w=; b=GndnO7gn0BhizV6/xcdJBTNq2YeuFjnXAJ15ChdBuSKb/BuNQhSRt+go1psO17JJnZS7ymzl6QHImbPT8sRmdpcINnn0xJ8hRjMkZfIWG9TBqcg8lEa6qraF9OfCZXD2WVY0oGhPmh+uc3UqrZYBsRW9bGl3/AVS3wGQKTxzFtM=
Received: from CY1PR07CA0024.namprd07.prod.outlook.com (2a01:111:e400:c60a::34) by DM6PR12MB4076.namprd12.prod.outlook.com (2603:10b6:5:213::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 7 May 2020 19:52:47 +0000
Received: from CY1NAM02FT004.eop-nam02.prod.protection.outlook.com (2a01:111:e400:c60a:cafe::98) by CY1PR07CA0024.outlook.office365.com (2a01:111:e400:c60a::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Thu, 7 May 2020 19:52:47 +0000
Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu;
Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism)
Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT004.mail.protection.outlook.com (10.152.74.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Thu, 7 May 2020 19:52:46 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 047JqhBO007488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Thu, 7 May 2020 15:52:45 -0400
To: mmusic@ietf.org
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <66bc33b6-8a66-1da3-93c0-e7ddc31cc605@alum.mit.edu> <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <a43c00d4-370f-415d-e93b-aca90d8d72c3@alum.mit.edu>
Date: Thu, 7 May 2020 15:52:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(376002)(346002)(396003)(39860400002)(136003)(46966005)(33430700001)(5660300002)(70206006)(70586007)(186003)(53546011)(26005)(336012)(786003)(75432002)(956004)(316002)(36906005)(2616005)(31686004)(356005)(2906002)(82310400002)(7596003)(86362001)(478600001)(6916009)(82740400003)(47076004)(8936002)(31696002)(966005)(8676002)(33440700001)(43740500002); DIR:OUT; SFP:1101;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5fc1fbf6-71bb-4188-3025-08d7f2c036dd
X-MS-TrafficTypeDiagnostic: DM6PR12MB4076:
X-Microsoft-Antispam-PRVS: <DM6PR12MB4076DEABE2B73BD990E13E18F9A50@DM6PR12MB4076.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 03965EFC76
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: f/BZ2OhmZeeW/JGSZndTakOxjk5NiV28epRo1RxlVxjkk7Z4bE2moGt+n/2SYJTZh/H0bKzK5KJaJmvXS6y8RlZIzsxgnkebw4CTWjHu21YeZBNf8z746g6f5LZwJK6GuyNEvnVLWstTm7t43+84i7EeIzKAHRr2W+rcNdPCIJCyPPImGq8vrq8VskinPoFBW2NpHPSN0tLQR9IQ1+xtktX1Ex0jPD6MjiTck8LYNHS5kSrsN0o6fMx9fHdAdB+N8fr3aqG18f4DdIOWwqe3NPhzJL57hbR4D+2HAq5Sp+ncHOECGy4z8+a46qXkWK/WEqHHwdXmVi5mDSBwyT2a5R8Ra/Ibpe/C/27GxRbcv97B+KpObUXp/Ayt1NPBhbJj0Nd1FyAdBOZthAWlErIPwOoyGFLUatB6iLVGtDnx6PNnHP89UGQNvPvkdoL0LNOSv1AR6GuA368FUq1AzcpbLjbMVWaHDWntQUn5pRnd19DD5lymDPEBGZULwgKQRdN6KwiEg3eqDXT9bvrJKceY9+8RzwPvP2cO0cpD1TS4O4LpQZ7ZIJtNjvxsivdLmp3plO3QmTZH377WYdXSjO7j+XzmHY1HDLYKj4Tc25yHaHtOwhGadaADqd5UYqiuXbLerNC6hkJVn+zZnRkGLk7FfD8HgM2wPEzwdv4oxEwsp+eMppC/W7pae3pvcC4mpbsn
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2020 19:52:46.1533 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5fc1fbf6-71bb-4188-3025-08d7f2c036dd
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4076
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/AxpQ6eHTZzmlwqs6LBn9xdwKixI>
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: Thu, 07 May 2020 19:52:51 -0000

On 5/7/20 3:33 PM, Christer Holmberg wrote:
> Hi Paul,
> 
> Thank You for the comments! Please see inline.

I'm fine with these.

	Thanks,
	Paul

> ---
>      
>>     1) NIT:
>>     
>>     In Section 3.1, in the table, the value for Label has a lot of white
>>     space between "See" and "Section 4.3". It would look better with a
>>     single space.
>    
> That's a bug. Will be fixed.
> 
> ---
> 
>>     2) MINOR ISSUE:
>>     
>>     In section 4.1, the abnf says:
>>     
>>         transport  /= "dc" / 1*ALPHANUM
>>     
>>     The /= means this is an added alternative to what is present in RFC4975.
>>     Hence it is equivalent to:
>>     
>>         transport = "tcp" / 1*ALPHANUM / "dc" / 1*ALPHANUM
>>     
>>     What you should really have is just:
>>     
>>         transport  /= "dc"
>   
> Will modify as suggested.
> 
> ---
> 
>>     3) NIT:
>>     
>>     Section 4.4 says:
>>     
>>         An offerer and answerer MUST include a dcsa attribute for the
>>         following MSRP-specific SDP attributes:
>>     
>>     I suggest: s/for the/for each of the/
> 
> Will modify as suggested.
>      
>>     Similarly, where it says:
>>     
>>         An offerer and answerer MAY include a dcsa attribute for the
>>     
>>     I suggest: s/for the/for any of the/
>    
> Will modify as suggested.
> 
> ---
>    
>>     4) QUESTION:
>>     
>>     Does section 4.6 this mean it is an error to use SDP to close the
>>     DTLS/SCTP association (via m=0) without all the added SDP attributes to
>>     close each data channel?
>>
>>     Could it not be implied that closing the association implicitly closes
>>     all the data channels?
>    
> The procedures follow what is defined in Section 6.6.1 of draft-ietf-mmusic-data-channel-sdpneg.
> 
> Whether closing the SCTP association, without explicitly closing the data channel(s) first, is an "error", or just "something one should not do",  I think should have been specified in draft-ietf-mmusic-data-channel-sdpneg.
> 
> ---
> 
>>     5) QUESTION:
>>     
>>     The example in section 4.8 includes use of the "path" attribute. How
>>     does that square with the following in section 4.4:
>>     
>>         The path attribute SHALL NOT be used for transport negotiation.
>>     
>>     I guess you mean that some usages of path are ok and others are not.
>>     Could you be more explicit about this?
> 
> I have got the same questions from others too, so I guess it needs to be clarified.
> 
> As the MSRP messages will be "routed" on the established data channel, the path attribute won't be used for routing.
> 
> Maybe something like this:
> 
> "When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. Because of that an MSRP endpoint
> can set the MSRP-URI authority value of the "path" attribute at its own discretion. However, when an MSRP endpoint receives an MSRP message on
> a data channel it MUST still check the MSRP-URI in the To-Path of the MSRP message, as described in [RFC4975]."
> 
> ---
> 
>>     6) ISSUE:
>>     
>>     Section 7.1 registers "MSRP" as if it was a totally new websocket
>>     protocol name, but it isn't. It is already registered as a websocket
>>     protocol referencing RFC7977.
> 
> True.
> 
> That shows for how long we have been working on this document, because when we started RFC 7977 didn't exist...
> 
>>     I think you instead need to specify that the existing registration be updated.
> 
> Something like:
> 
> 7.1.  Subprotocol Identifier MSRP
> 
>     NOTE to RFC Editor: Please replace "XXXX" with the number of this
>     RFC.
> 
>     This document adds a reference to RFC XXXX for the subprotocol identifier "msrp" in
>     the "WebSocket Subprotocol Name Registry".
> 
> ---
> 
> Regards,
> 
> Christer
> 
> 
>   
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>