Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 31 July 2017 16:03 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 70C19132555; Mon, 31 Jul 2017 09:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nznGehB_RvSw; Mon, 31 Jul 2017 09:03:16 -0700 (PDT)
Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E523131723; Mon, 31 Jul 2017 09:03:16 -0700 (PDT)
X-AuditID: 1207440c-c4bff70000000b4f-8c-597f54c3c7f2
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DA.0B.02895.3C45F795; Mon, 31 Jul 2017 12:03:15 -0400 (EDT)
Received: from [192.168.1.110] (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.13.8/8.12.4) with ESMTP id v6VG3CIZ031965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Jul 2017 12:03:13 -0400
To: Christer Holmberg <christer.holmberg@ericsson.com>, Ben Campbell <ben@nostrum.com>
Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>, General Area Review Team <gen-art@ietf.org>, IETF MMUSIC WG <mmusic@ietf.org>
References: <fb41df24-ffeb-2cdd-6233-858f886ee6ec@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <e0e715ef-322a-e060-2d1e-86ca9650df2a@alum.mit.edu> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <af3442ce-712d-4391-bf26-05a860211062@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <6cf88d1c-526a-ccf2-0103-7822d81a2690@alum.mit.edu>
Date: Mon, 31 Jul 2017 12:03:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixO6iqHs4pD7S4N0fdYv5nafZLS7MPMxo sePuDjaLq68+s1hMXf6YxYHV49fXq2weS5b8ZPKYtfMJSwBzFJdNSmpOZllqkb5dAldG38nH TAU3dCr2nv3G3MC4SqWLkZNDQsBE4nn7d8YuRi4OIYEdTBKNVx9DOVeZJL6dvcwKUiUsECRx 58gMdhBbRCBeYvn/7WBFzAK7GCWet6yD6ljHKtF/ZhFYB5uAlsScQ/9ZQGxeAXuJnceaGUFs FgFViR33roHZogJpEjO+X2eGqBGUODnzCVg9p4CfxKK3zWA2s4CZxLzND5khbHGJW0/mM0HY 8hLNW2czT2AUmIWkfRaSlllIWmYhaVnAyLKKUS4xpzRXNzcxM6c4NVm3ODkxLy+1SNdQLzez RC81pXQTIyTceXYwflsnc4hRgINRiYf3gXl9pBBrYllxZe4hRkkOJiVR3jNSQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivOsNgXK8KYmVValF+TApaQ4WJXFe1SXqfkIC6YklqdmpqQWpRTBZ GQ4OJQleoSCgRsGi1PTUirTMnBKENBMHJ8hwHqDhH4NBhhcXJOYWZ6ZD5E8x6nL8mrn1C5MQ S15+XqqUOO98kEECIEUZpXlwc2Bp6hWjONBbwrwFIKN4gCkObtIroCVMQEskS2tBlpQkIqSk Ghhdj1eaCew5KHj27Ym4cF3ZSUUtN2usN2qJ9HWc+flqcshBvstGe1o0/+yvT3gpoyV3+5Xo 3JkCSk97c7YLPirIfP42fsNu3dUCc1gv3pgn2up2pcX53tLwXuZG5gctj84dFa1Y+mdm86eH J7cFJ+1etumAi4cX+7EAk/V9upuDXLnMn98VNGdXYinOSDTUYi4qTgQACWuPei4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/rZG2HHwJNcd1KFQ9ueLjI23tkuk>
Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Jul 2017 16:03:19 -0000

On 7/31/17 4:05 AM, Christer Holmberg wrote:
> Hi Paul,
> 
>>> PR created:
>>>
>>> https://github.com/cdh4u/draft-dtls-sdp/pull/34
>>
>> This leaves RFC5763 in an inconsistent state:
>> - the reference to 8122 in section 5 isn't backed up with an entry in the references section
> 
> In the PR, I DO add 8122 to the reference section of 5763 :)

Oh, sorry.

>> - there is still a reference to 4572 in the introduction.
> 
> I could add a statement, saying that the reference in the Introduction is updated.

That works for me.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
> 
> Otherwise looks right.
> 
> 	Thanks,
> 	Paul
> 
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> Sent: 29 July 2017 23:38
>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>; Ben Campbell
>> <ben@nostrum.com>
>> Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team
>> <gen-art@ietf.org>; IETF MMUSIC WG <mmusic@ietf.org>
>> Subject: RE: [Gen-art] Gen-ART Last Call review of
>> draft-ietf-mmusic-dtls-sdp-27
>>
>> Hi,
>>
>>>>>>> Regarding the reference to RFC 4572, the new text in section
>>>>>>> 10.2.1 references RFC 4572. We earlier agreed we were not going to update that text, and keep an informative reference to RFC 4572.
>>>>>>
>>>>>> OK, I guess I remember that now. Is it considered acceptable to
>>>>>> issue a new document with a reference to an obsolete document when it isn't to highlight a difference from the current document?
>>>>>>
>>>>>> Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide.
>>>>>
>>>>> As far as I know, there’s no hard and fast rule about this. It
>>>>> really depends on whether the difference between the new and
>>>>> obsolete dependencies are material to the draft. I do think we (i.e.
>>>>> the IESG) would favor referencing the new RFC, but would be open to
>>>>> arguments about why a WG chose to reference the obsolete version
>>>>>
>>>>> Does anyone recall the reasoning in this instance?
>>>>
>>>> Just to make sure we are on the same page, there are TWO references to RFC 4572 in the draft.
>>>>
>>>> The FIRST reference is in section 8, where it is used to reference
>>>> an example in RFC 4572. The same example exists in RFC 8122, so we can change that reference.
>>>>
>>>> The SECOND reference is in section 10.2.1, as part of the updated
>>>> text for RFC 5763. Now, RFC 5763 references RFC 4572 in 4 difference
>>>> places, so if we change the >reference to RFC 8122 in the text
>>>> updated by the draft we would also have to do it in every other place. That was the reason we decided not to do it (I have no problem doing it that's what IESG wants, though).
>>>
>>> Thanks for pointing that out. I just looked at that to size up the
>>> situation. Of those four references, three of them are in section 5
>>> and will all be replaced by the new text in this document. The remaining reference is simply a general one in the introduction. And then in addition there is the actual reference text in the normative references.
>>>
>>> ISTM that it would be sufficient to update the reference in the new
>>> text for section 5 and then add a general statement to update all references to 4572 to refer to 8122.
>>>
>>> But again, this is really an IESG issue at this point.
>>
>> Or, we could just go ahead and do it :)
>>
>> Regards,
>>
>> Christer
>>
>>>
>>>
>>>
>>>>> -----Original Message-----
>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>>>> Sent: 29 July 2017 01:07
>>>>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>;
>>>>> draft-ietf-mmusic-dtls-sdp.all@ietf.org
>>>>> Cc: General Area Review Team <gen-art@ietf.org>; IETF MMUSIC WG
>>>>> <mmusic@ietf.org>
>>>>> Subject: RE: [Gen-art] Gen-ART Last Call review of
>>>>> draft-ietf-mmusic-dtls-sdp-27 Hi Paul, Thanks for the review. I'll
>>>>> fix references.
>>>>> Regards,
>>>>> Christer
>>>>> -----Original Message-----
>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>> Sent: 28 July 2017 04:01
>>>>> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org
>>>>> Cc: General Area Review Team <gen-art@ietf.org>; IETF MMUSIC WG
>>>>> <mmusic@ietf.org>
>>>>> Subject: [Gen-art] Gen-ART Last Call review of
>>>>> draft-ietf-mmusic-dtls-sdp-27 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>> Document: draft-ietf-mmusic-dtls-sdp-27
>>>>> Reviewer: Paul Kyzivat
>>>>> Review Date: 2017-07-07
>>>>> IETF LC End Date: 2017-07-24
>>>>> IESG Telechat date: 2017-08-15
>>>>> Summary:
>>>>> This draft is basically ready for publication, but has nits that should be fixed before publication.
>>>>> (These nits were reported by IdNits. I apologize for not noticing
>>>>> these during my Last Call review.)
>>>>> Issues:
>>>>> Major: 0
>>>>> Minor: 0
>>>>> Nits:  2
>>>>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but
>>>>> no explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis.
>>>>> (2) NIT: Obsolete informational reference (is this intentional?):
>>>>> RFC
>>>>> 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that.
>>>>
>>>
>>
>