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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 14 March 2019 17:32 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 76524130F43 for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2019 10:32:31 -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 kM3wM3AmvTgn for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2019 10:32:29 -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 8C8C0130F1F for <mmusic@ietf.org>; Thu, 14 Mar 2019 10:32:29 -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 x2EHWPKV018552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Mar 2019 13:32:25 -0400
To: Ben Campbell <ben@nostrum.com>
Cc: Colin Perkins <csp@csperkins.org>, mmusic@ietf.org
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <2f297a3c-39d4-cb99-65f4-f0bcd072306a@alum.mit.edu> <C054EF10-FE82-4E9D-9ABA-5C2E6090F0C9@csperkins.org> <6f0d20c2-0397-2bbd-5671-8b7ea0d8c98d@alum.mit.edu> <0A5AD09E-8C94-4698-9418-EA0DE099FD07@csperkins.org> <57c8eb93-895a-9c7e-cdea-27237c67b2b0@alum.mit.edu> <F02E04D0-EEEA-4908-9035-85A321B890CC@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <f261920b-7f5a-cb75-1f4e-8bfe78952550@alum.mit.edu>
Date: Thu, 14 Mar 2019 13:32:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <F02E04D0-EEEA-4908-9035-85A321B890CC@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/ENcXJn2rA5N6iEUVEkU7XrH4I_M>
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, 14 Mar 2019 17:32:41 -0000

On 3/11/19 7:22 PM, Ben Campbell wrote:
> 
> 
> Sent from my iPhone
> 
>> On Mar 11, 2019, at 5:26 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> On 3/11/19 1:43 PM, Colin Perkins wrote:
>>
>>>>> §5 has several changes to normative language. Most are okay, but I think the change from “all MUST appear in exactly the order given here” to “all must appear” weakens it too much, and I’d prefer that to remain a MUST.
>>>>
>>>> The reason for changing that is because the *normative* specification of the ordering is from the ABNF. The text here is explanatory and non-normative. (Note that a couple of paragraphs prior to this is a new statement emphasizing that the ABNF is normative.)
>>> Sorry, but I think this change is problematic. The text needs to use normative language that is consistent with the ABNF.
>>
>> My thinking is that we don't like to have redundant normative specification, just in case they aren't consistent. The ABNF is normative. This section is of necessity an approximation.
>>
>> But I defer to Ben or whoever.
> 
> I agree with both of you. :-)
> 
> That is, we should avoid duplication normative requirements when possible, because it increases the chance of  spec errors. But we should still try to make sure the sections agree.

That is what I have tried to do. AFAIK they are consistent within the 
limits of the expressiveness of the informal syntax in the Section 5 figure.

The only divergence I am aware of is in the time description. The figure 
can't express that z= may only be used if it is preceded by an r=. It 
used to be that the abnf was consistent with the figure as written - 
permitting a z= without an r=. But that was nonsense because we have 
clarified that the z= only affects the immediately preceding r=.

IMO trying to indicate that subtlety in this figure would be 
counter-productive, by making the figure harder to follow.

	Thanks,
	Paul