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

Ben Campbell <ben@nostrum.com> Thu, 21 March 2019 14:50 UTC

Return-Path: <ben@nostrum.com>
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 E696E1311D1 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 VYIZtizMV9ik for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2019 07:50:13 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929B91311CA for <mmusic@ietf.org>; Thu, 21 Mar 2019 07:50:13 -0700 (PDT)
Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2LEnddb074731 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Mar 2019 09:50:11 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553179811; bh=obR5/GEXes/gEgudcK6orBNuWaOWCdobF2fopB9/BF4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=MoXRJnDXob0XMVPGDjfICVLlB3rY3+Q+0r+d63IE+otvD8gpR5/XS3QF/ZByMm26o tdcfXGU5buljvqwvw3pNt+3zJMJDSKiWOIcF71ui5ybrv/hSpCYw8cV0Zs4FFmITzI b7dwTzo4tvbAJELpUcgC46UOliZzEOEzb8qcouR4=
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan
From: Ben Campbell <ben@nostrum.com>
Message-Id: <824DADE3-9C1A-4BFF-94A0-B439F4E7CA1C@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_BCF1800B-B77F-496F-A451-255DE8BA8458"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Mar 2019 09:50:10 -0500
In-Reply-To: <0089c1fe-9b50-c9c4-1daa-b133e4ed8f27@alum.mit.edu>
Cc: mmusic@ietf.org
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
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> <0089c1fe-9b50-c9c4-1daa-b133e4ed8f27@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/96LVytw6mPChRhUGJThOH-gilVg>
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:50:16 -0000

Send the draft to me and I will ask the secretariat to force publication.

Thanks!

Ben.

> On Mar 21, 2019, at 9:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>; wrote:
> 
> 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
>