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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 21 March 2019 14:28 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 C6080131154 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CnpIQm0Ggda8 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:28:33 -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 D69A5131150 for <mmusic@ietf.org>; Thu, 21 Mar 2019 07:28:32 -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 x2LESTbE014111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2019 10:28:30 -0400
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <2f297a3c-39d4-cb99-65f4-f0bcd072306a@alum.mit.edu> <CC5A264E-0D65-4D64-A558-3E5EDD22FBFE@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: mmusic@ietf.org
To: Ben Campbell <ben@nostrum.com>
Message-ID: <f4431bd1-7644-3bb1-d230-6ecb6c0166c9@alum.mit.edu>
Date: Thu, 21 Mar 2019 10:28:29 -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: <CC5A264E-0D65-4D64-A558-3E5EDD22FBFE@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/NxjAmW_wJ9afhWOtX0C0j2DeQP8>
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:28:35 -0000

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.

>>> §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?)

>>> §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.

>>> - "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".

	Thanks,
	Paul