Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03

Colin Perkins <csp@csperkins.org> Wed, 02 November 2016 12:47 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD10F129623; Wed, 2 Nov 2016 05:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 W84IaKKY1D3n; Wed, 2 Nov 2016 05:47:17 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F60712961F; Wed, 2 Nov 2016 05:47:17 -0700 (PDT)
Received: from [130.209.247.112] (port=65448 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1c1uwh-0004bs-Ta; Wed, 02 Nov 2016 12:47:14 +0000
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <3f50e2bf-1877-9ac8-c94f-41af6cd95b5e@ericsson.com>
Date: Wed, 02 Nov 2016 12:47:08 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <A44578B2-9D31-4FF6-9422-91A2EE08684D@csperkins.org>
References: <e06fe3ab-7792-e53c-f0df-35702cfae10e@ericsson.com> <0eb001d2289a$ccf86070$66e92150$@gmail.com> <3f50e2bf-1877-9ac8-c94f-41af6cd95b5e@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/QH4Xv_Cb1y9-vkDrLMvQQk2iSp8>
Cc: draft-ietf-avtcore-rfc5285-bis@ietf.org, IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 12:47:19 -0000

Hi,

Following up, after reading the diff to -04.

> On 18 Oct 2016, at 09:53, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
…
>>> 12. Section 10.1:
>>> 
>>>       2.  that the extension complies with the requirements of RTP and
>>>           this specification, for extensions (notably, that the stream
>>>           is still decodable if the extension is ignored or not
>>>           recognized);
>>> 
>>> I believe there is need to tweak this bullet.
>> [Roni Even] This is the text from RFC5285, I believe it says that when
>> reviewing an extension the expert must verify that lack of support will not
>> prevent the decoding of the RTP stream. Any suggestion for text here?
> 
> So, based on the RTP header extensions recently defined or under definition, like RID and MID, they are not preventing RTP stack level processing, but in some cases failure to understand them prevents the application from working correctly. Even for middleboxes there exist a need to understand them to be able to route them correctly.
> 
> So the requirement was changed in Section 4.1 to say:
> 
>   To be specific, header extensions using this
>   specification SHOULD be used for data that can safely be ignored by
>   the recipient without affecting interoperability, there can be
>   essential header extensions for interoperability and intermediaries
>   SHOULD NOT remove such header extensions.
> 
> So my proposed text change is to remove the parenthesis.
> 
> I think the reviewer should be questioning the need for any header extension that modifies how the RTP stack processes the packet. The current situation is that we are going to have RTP header extension that are going to be critical for applications or at least certain functionalities in applications. I think we have to accept that, but we should I think ensure that the extensions are open and explicit in which way they may become required for interoperability or functionality. So the question is if we should rather add a requirement for documenting that need?

I accept that header extensions are being used more frequently now, but I think we’ve so far managed to avoid cases where critical information is only carried in RTP header extensions. We should try to keep it that way. Accordingly, I don’t think removing the parenthesised text is appropriate.

-- 
Colin Perkins
https://csperkins.org/