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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 14 March 2019 16:24 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 15A40124B0C for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2019 09:24:01 -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 fgHjes9FyCTG for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2019 09:23:59 -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 AE98812958B for <mmusic@ietf.org>; Thu, 14 Mar 2019 09:23:56 -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 x2EGNhKf014030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Mar 2019 12:23:44 -0400
To: Colin Perkins <csp@csperkins.org>
Cc: Ben Campbell <ben@nostrum.com>, 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> <8ECE1C75-95E1-47C4-B642-AE4F8061F563@csperkins.org> <2432bf01-64de-2132-b4bc-ab5d51d1773d@alum.mit.edu> <AEB1F98C-F562-4810-9892-14F7C5526CED@csperkins.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <4ecf7883-87d5-c853-3f9a-f943232b5530@alum.mit.edu>
Date: Thu, 14 Mar 2019 12:23:43 -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: <AEB1F98C-F562-4810-9892-14F7C5526CED@csperkins.org>
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/6gPP0ZjQlTMtMkvMaiPFglxagUw>
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 16:24:01 -0000

On 3/14/19 11:02 AM, Colin Perkins wrote:
>> On 12 Mar 2019, at 15:41, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> On 3/12/19 7:08 AM, Colin Perkins wrote:
>>>>>>>> This is a normative requirement of RTP, however. If we want to avoid normative examples, which I’d agree makes sense, then this needs to be rewritten as just “An RTP-based system in recvonly mode SHOULD…”.
>>>>>>>
>>>>>>> That is the way it was. The change from "SHOULD" to "should" was to make it non-normative.
>>>>>>>
>>>>>>> Or were you requesting to remove “e.g."?
>>>>>> Remove the “e.g.”, yes, but also change “should” back to “SHOULD”.
>>>>>
>>>>> I thought the point was that the RTP specs are normative and this is only an example, and so shouldn't be normative.
>>>>
>>>> I do not have the text in front of me, but I agree that examples should not be stated normatively.
>>> This is documenting a perhaps unexpected interaction between SDP and RTP. That is, when set to recvonly in SDP, an RTP endpoint SHOULD send RTCP. I do think that it’s important that we spell this out clearly here, with normative language.
>>
>> I'm neutral here whether its normative or not. If it is to be a normative SHOULD, can we please include some "unless" text indicating the conditions when it may be omitted? Better yet, turn it into an "if NOT x then MUST ..." form.
> 
> I don’t think I can summarise the rules around when RTCP is, or is not, to be sent as a simple condition. If more detail is needed, I suggest “An RTP-based system in recvonly mode SHOULD still send RTCP packets as described in [RFC3550] Section 6”.

I'll put this in if it is the consensus. But this appears to give 
license to someone to ignore RFC3550. (I have talked to people who have 
said "SHOULD isnt a firm requirement so I don't need to do it.)

If that SHOULD is changed to MUST, then it will still mean that RTCP can 
be avoided in whatever cases RFC3550 allows. Specifically:

"An RTP-based system in recvonly mode MUST still send RTCP packets as 
described in [RFC3550] Section 6.”

	Thanks,
	Paul