Re: [MMUSIC] Draft new version: 8843bis-02

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 10 June 2021 19:39 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 E105F3A168E for <mmusic@ietfa.amsl.com>; Thu, 10 Jun 2021 12:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 3k0qmBu3M5uy for <mmusic@ietfa.amsl.com>; Thu, 10 Jun 2021 12:39:47 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2086.outbound.protection.outlook.com [40.107.243.86]) (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 4082F3A168A for <mmusic@ietf.org>; Thu, 10 Jun 2021 12:39:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSlyP8zhjeHLz1xAHxLPwci+leTq32rzN3Lr9/T4jBA7ozHvxhGIIe58kTTS4JKqNJP8MvzSameAUiIcvua1JwyDTl4Ztp4vhf2GaUDP5cDfn+aTkldN9u3Jtkp3LBQkpM+0d0BqJDlBGClTf6ODnW4DCoo5ln/TYt6QWKlnfk1ZormaWptDS7RJqo5B0zo6TeKsD/rhkaqt6TkAAR+WosnAW2ooh6CI/852O8Yp3I4foBMmleC0DgKOPXg0/1NjII/IwEzWEsLaA4WSTb50WVNSNcz130VILzjy6gm6IkdP/YSywcdTGkfL1luhnO6R/hoon1tmMko6d0BGkhUdwg==
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=OQbKfm2z1ZaM4i770z2zhtDupEAadAooGw0YdwCo0Us=; b=MQXPIByy3VZnPXrtdBg7yCQ5dj1o2C8YLehQNx2cyyccz8TEcLObZC4INt6q+HHlssqs7RBjd0VTYDZCCOJZiFBojHwp73r83bGhWn1DmuuNkE9allWhe8BhCMmu5K+beBQhYKKlu4mh97vkmkBm4DITZyuKbYSwInMooWX2nntSMGVsmngx6/WZsyLkGWYXsLyXgm5NmpPa2aH4vPbpWMKmXEcbIgVi6E7m13v/y5TxSQXbYlC3YZl87TUHexqcjzkqKwOEYi8sncxhQKMFZMWN1Mo/1smZp0kh087xc/IBcfpkx22NDvfVQySFdrjAceVqYPCk42UycR0txyEUsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=OQbKfm2z1ZaM4i770z2zhtDupEAadAooGw0YdwCo0Us=; b=PZSm8wOOLCbSefKq2l7xLwVRBhN+pGPqFycn1DbpFzUSK8+gx0aO4XS01lzjBAeGkfYk5znsJ0vzZdP+fFgp4D43ciZ5i3YCJ5qvXnzsvPS9Bb7Z95rBC34VKpU/vdaxLQT/pmmO+MwQ8hvSfmFZ7KtEmA7jXzInAlWyXk4ZrFk=
Received: from SN6PR2101CA0021.namprd21.prod.outlook.com (2603:10b6:805:106::31) by BY5PR12MB4161.namprd12.prod.outlook.com (2603:10b6:a03:209::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Thu, 10 Jun 2021 19:39:45 +0000
Received: from SN1NAM02FT0033.eop-nam02.prod.protection.outlook.com (2603:10b6:805:106:cafe::7b) by SN6PR2101CA0021.outlook.office365.com (2603:10b6:805:106::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.4 via Frontend Transport; Thu, 10 Jun 2021 19:39:45 +0000
X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0033.mail.protection.outlook.com (10.97.5.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21 via Frontend Transport; Thu, 10 Jun 2021 19:39:44 +0000
Received: from MacBook-Air.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 15AJdg3F008453 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <mmusic@ietf.org>; Thu, 10 Jun 2021 15:39:43 -0400
To: mmusic@ietf.org
References: <AM0PR07MB386041274C21D6D7DC023DFC93389@AM0PR07MB3860.eurprd07.prod.outlook.com> <AM0PR07MB386033BABBEF4E8FD52E428F93359@AM0PR07MB3860.eurprd07.prod.outlook.com> <3b288014-fcb3-90e7-1e66-4fbb92e09989@alum.mit.edu> <AM0PR07MB386099490505B7D072CCF34393359@AM0PR07MB3860.eurprd07.prod.outlook.com> <22ef52f9-fcac-f2ca-4b17-6649bbee3b85@alum.mit.edu> <AM0PR07MB38604791304D23D284B1EB9793359@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <c9c8a15c-2eb2-0636-3d01-b618b06ec937@alum.mit.edu>
Date: Thu, 10 Jun 2021 15:39:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <AM0PR07MB38604791304D23D284B1EB9793359@AM0PR07MB3860.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d08c3d12-6793-4ce8-1ce3-08d92c477fcf
X-MS-TrafficTypeDiagnostic: BY5PR12MB4161:
X-Microsoft-Antispam-PRVS: <BY5PR12MB41617589698FFACF93697BA7F9359@BY5PR12MB4161.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: F546RUUFVwiOmU+l4d0CpaTLyxZmJ7rQT5ez0fWJXpGWq6eiyEbKSh9S1cQcpR6PQ2qvUtncUhcU9Px4iHcW+ACoYid6XgaEyGWl0A9zu/JIiGPXG+xU2wxY6hGMV9NONJO4fOsUoZManKtEYyV2dQ9NfuWSaI/OxQR0jc84OUZYMqPTnFqITak/V6WriklA2C47nE4aBQ+UBydhGVGPNSGxEMxC1sBa5YmW3YAXnbtWB8CUwKlZGYQuVqiSy8+EM5oyclFGnwsfas1eUEqPQJ0kV37flRIEkLJ8aPpwaGlxFRey38t5sWb17anQ7TGgMZyz/XV3Pwftym6FEliHvsqqAtdNPjzw9QOaAvpWRaaGfJ/9mSfKyokKbpPd74NHbHvQMCnjqOvRvIztzUNLQG9Tk9JkI3gtlWmgSeaqgEV3xGjER8bCDGL/fxeJtvHeup8EhRq1RXzctgdB9Bx7D+FuJ7O3r/gVlUmgeqTSOut/9C9thrUlwXUXBURQKSKkVHe0g89HjY0zVpLfvD+8xoo2CzqKqc1w82XXN1tL466+EF2KA0YNbyJxMrnO6YgFp8cx7S5y4by5e/WWFTj++rPaj+pizdzcluBNKAxfBCHAX1r/H9hdgez9/QabfJ06PXvowMbi2OB7PzlSKz+uEzGDEaNtZ5Ni89WxxL0F+CkvXyWORCSL3+2Nu68hF/Mz
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; SFS:(136003)(396003)(376002)(346002)(39860400002)(46966006)(36840700001)(31696002)(7596003)(53546011)(26005)(356005)(36906005)(70586007)(786003)(6916009)(83380400001)(316002)(8676002)(2906002)(186003)(70206006)(86362001)(75432002)(336012)(82310400003)(31686004)(5660300002)(478600001)(36860700001)(8936002)(47076005)(82740400003)(956004)(2616005)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2021 19:39:44.6316 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d08c3d12-6793-4ce8-1ce3-08d92c477fcf
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-AuthSource: SN1NAM02FT0033.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4161
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/OxGZPBkY-r6i4j5LL8o_gG9RkV4>
Subject: Re: [MMUSIC] Draft new version: 8843bis-02
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, 10 Jun 2021 19:39:51 -0000

On 6/10/21 11:45 AM, Christer Holmberg wrote:
> Hi,
> 
>>>>> Paul, are you happy with the way your comments have been addressed?
>>>>
>>>> I have one remaining question:
>>>>
>>>> The new section 7.3.5 is addressing the case where the offerer only support RFC8843 while the answerer supports 8842bis. In this case, what sort of answer should the answerer generate?
>>>> Should it emulate RFC8843 behavior? Do we understand what the impact will be if not?
>>>
>>> That is a good question.
>>>
>>> Because, if we say that the endpoint shall generate an answer according to 8843, what about when the same endpoint later wants to generate a new offer itself? Should it then generate
>>> the offer according to 8843? I think we could easily go down a slippery slope, and eventually 8843bis endpoints would also have to fully implement 8843. I don't think we want that.
>>>
>>> Having said that, we probably do need to say something about what "accept such offer" really means when it comes to generating the answer. My suggestion would be to say that the answer SHOULD be generated according to 8843bis.
>>
>> I don't have an answer here. But it would be helpful for those impacted one way or the other to comment.
> 
> The ones impacted DID comment when we discussed what way to go, and the draft reflects the outcome.  There was never an agreement (or even suggested, AFAIR) that an 8843bis endpoint would also have to implement 8843 functionality, in order to backward compatible. The only requirement was to be backward compatible with non-BUNDLE endpoints (e.g., not include identical port numbers in the initial offer). This was also the reason we wanted to get the alignment published as far as possible, in order to minimize the backward compatibility issues.
> 
> So, if people think this causes confusion, perhaps we should just remove the "8843 Consideration" sections and leave it up to implementers to fix things, if needed.

I agree that these changes don't seem to have improved clarity.

Maybe it would be worth mentioning that the changes in this bis may 
break interoperation with RFC8843 implementations. And that actions to 
ease interoperation in such cases is out of scope for this document.

	Thanks,
	Paul