Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 21 March 2019 14:43 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 3B259130FF3 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 veitDw83MV2P for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:43:36 -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 A289712795E for <mmusic@ietf.org>; Thu, 21 Mar 2019 07:43:36 -0700 (PDT)
Received: from PaulKyzivatsMBP.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 x2LEhX5S015249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2019 10:43:34 -0400
To: Ben Campbell <ben@nostrum.com>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <2f297a3c-39d4-cb99-65f4-f0bcd072306a@alum.mit.edu> <CC5A264E-0D65-4D64-A558-3E5EDD22FBFE@nostrum.com> <f4431bd1-7644-3bb1-d230-6ecb6c0166c9@alum.mit.edu> <75A4DF27-8A12-4C5E-80B7-F90EC6896297@nostrum.com>
Cc: mmusic@ietf.org
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <0089c1fe-9b50-c9c4-1daa-b133e4ed8f27@alum.mit.edu>
Date: Thu, 21 Mar 2019 10:43:33 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <75A4DF27-8A12-4C5E-80B7-F90EC6896297@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/vaHDrfIWdC2_H9kXdB6bn11S1pY>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32
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, 21 Mar 2019 14:43:39 -0000

Ben,

Based on your comments, I need to change the "Changes" section to 
mention the removal of private sessions, and remove the offending comma. 
I think that is all.

Given the freeze, what is the process to submit an update?

	Thanks,
	Paul

On 3/21/19 10:36 AM, Ben Campbell wrote:
> 
> 
>> On Mar 21, 2019, at 9:28 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>; wrote:
>>
>> Ben,
>>
>> On 3/20/19 11:21 PM, Ben Campbell wrote:
>>
>> I've trimmed this to just the points that seem to call for a reply.
>>
>>>>> - Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.
>>>>
>>>> I posted a query about this. The consensus was that the removal here is right, but that more discussion is needed in the Security Considerations section. But I don't know what to write. I need some help on that
>>> Would it make sense to say that “private sessions” have been superseded by the use of things like DTLS-SRTP and RFC 8224
>>
>> The section on private sessions appears to have made sense in the distant past when the primary (or only) use of SDP was SAP. Then most sessions were public. Now almost all use of SDP is in establishing private sessions.
>>
>> I'm not convinced it is necessary to say anything about this, but I could reinstate a §4.3 on private sessions, with text saying what I just said above.
> 
> In that case, a mention in the “changes” section should be good enough. Would that fall under the “removed references to SAP” comment? It might be worth mentioning that this removal included private sessions.
>>
>>>>> §5.8: "Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
>>>>> prefix) <bwtype> names SHOULD be defined, and then MUST be registered
>>>>> with IANA in the standard namespace.”
>>>>> “SHOULD be defined” seems to be in tension with “MUST be registered”.
>>>>
>>>> I twiddled with this. Does it work for you now?
>>> All I see in 33 is a punctuation change. Did I miss something?
>>
>> There is also a small change in the prior paragraph. I changed it to indicate that this is a legacy of 4566.
>>
>> Re SHOULD vs MUST: IIRC the intent was to leave a little wiggle room for X-, while saying that non-X- names MUST be registered.
>>
>> Can we agree on what we mean to say here? Then I can try to reword to say that more clearly.
>>
>> ISTM that we want to say that *new* uses of X- are forbidden while existing ones may continue. And non-X- names MUST be registered. (What about existing non-X- and unregistered names?)
>>
> 
> Okay, on re-reading, I think I am okay with it. I just wanted to make sure we were looking at the same text.
> 
>>>>> §7, last paragraph:
>>>>> What is the impact of this on RFC 4568 (security descriptions)? That RFC seems to allow the use of “k=“ lines at a MAY level. Does this draft need to update that? But more importantly, is it worth distinguishing the case of E@E protection of keying material vs the HBH protection offered by security descriptions?
>>>>
>>>> This text is unchanged since 4566.
>>>>
>>>> I need help with this from a security person
>>> I’m willing to accept this as legacy text. (But I guess we will see what the SEC ADs have to say.)
>>
>> OK. Then *they* can supply the text.
> 
> We can worry about that when it happens :-) (i.e. IESG evaluation)
> 
>>
>>>>> - "media-, or session-specific basis” : Incorrect comma usage.
>>>>
>>>> IIUC this is an "Oxford comma", and the use of it is controversial. Does IETF have a policy on its use?
>>>>
>>> <channeling-Adam>
>>> Well, yes. The RFC Editor follows the Chicago Manual of Style, which IIUC calls for use of the Oxford comma. However, this isn’t one. The Oxford comma is for a serial conjunction list, e.g. “a, b, and c”. This instance is just a normal conjunction, e.g. “a or b”. “a, or b” is generally incorrect unless there’s some other reason for the comma.
>>> </channeling-Adam>
>>
>> Oh duh! Agree. If I need to make more changes then I will include this one.
>>
>>>>> §5.9: "A "t=" line (time-field) initiates a time description that specifies
>>>>> the start and stop times for a session.”
>>>>> I don't understand what it means to "intitiate" a time description. The text from 4566 seemed more clear.
>>>>
>>>> I changed "initiate" to "begins".
>>>>
>>>> There has been a lot of confusion and questions raised bout how t=/r=/z= work together. I revised the ABNF to clarify that, and then reworked this text to be consistent with and coordinate with the ABNF.
>>> Okay. (Wow, that’s a lot of work for an editorial comment :-) )
>>
>> No. All the ABNF changes were done long ago. This time I simply changed "initiate" to "begins”.
> 
> Ah, okay.
> 
>>
>> 	Thanks,
>> 	Paul
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>