Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 07 August 2019 14:50 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 3CE371202ED for <mmusic@ietfa.amsl.com>; Wed, 7 Aug 2019 07:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oZZ3PMnQt8lB for <mmusic@ietfa.amsl.com>; Wed, 7 Aug 2019 07:50:01 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 244381200B4 for <mmusic@ietf.org>; Wed, 7 Aug 2019 07:50:01 -0700 (PDT)
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 x77Enxui031870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Wed, 7 Aug 2019 10:49:59 -0400
To: mmusic@ietf.org
References: <156502552845.24515.11157901358870690278.idtracker@ietfa.amsl.com> <HE1PR07MB31613F486F6B67B1A1F0453093DA0@HE1PR07MB3161.eurprd07.prod.outlook.com> <747b0dc1-5a12-3751-c82b-20a03d14015a@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <ca3c81af-efe6-6d16-d8ad-3b0f67088d90@alum.mit.edu>
Date: Wed, 07 Aug 2019 10:49:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <747b0dc1-5a12-3751-c82b-20a03d14015a@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/HfQuZC2kJot8RLetlJLBiYkcasw>
Subject: Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)
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: Wed, 07 Aug 2019 14:50:03 -0000

On 8/7/19 8:48 AM, Flemming Andreasen wrote:
> 
> 
> On 8/5/19 2:44 PM, Christer Holmberg wrote:
>> Hi Mirja,
>>
>> Thank You for the review! Please see inline.
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>> 1) First I have a processing question for the IESG (and maybe the RFC editor) but it might be just me not knowing this:
>>> As I understand it, RFC5245 was spilt up into RFC8445 and this document, however, I find it a bot odd that both documenst
>>> obsolete RFC5245. Is that what we usually do? Did we have this case before? Is that the right thing to do?
>> That's a good question. I hope the chairs and/or the AD can give some guidance.
>>
> I'm not sure either. Maybe Adam knows ?

I'm not Adam. Nevertheless...

This is just about clarity and use of terminology, right?

Some parts of 5245 have been replaced by 8445, and other parts by this 
document. And this document has a normative dependency on 8445, and not 
on 5245. RFC8445 also makes normative changes (enumerated in section 21) 
to the parts of 5245 that it covers. That seems to justify it obsoleting 
5245.

But 8445 doesn't address the parts of 5245 that are covered by this 
document. For that you also need this document.

Consider somebody who has an implementation of ICE is SIP that currently 
references 5245. Somebody tells him that 5245 is now obsolete. So he 
checks the tracker and finds that it has been obsoleted by 8445. When he 
checks the changes from 5245 he finds a reference to this document.

That seems good enough to me. This document is just a supplement to the 
one that obsoletes 5245, and so it doesn't itself need to obsolete 5245.

BUT:

RFC8445 has section 21 that highlights what is new since 5245. That is 
good as far as it goes. But that doesn't cover changes to the parts of 
5245 that covered sip & sdp.

ISTM that this document also needs a section on changes from 5245.

	Thanks,
	Paul