Re: [AVTCORE] update to RFC5285

Colin Perkins <csp@csperkins.org> Fri, 02 October 2015 16:05 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE451B2C65 for <avt@ietfa.amsl.com>; Fri, 2 Oct 2015 09:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 I4gm75CgB3I8 for <avt@ietfa.amsl.com>; Fri, 2 Oct 2015 09:05:42 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969251B2A03 for <avt@ietf.org>; Fri, 2 Oct 2015 09:05:42 -0700 (PDT)
Received: from [86.169.24.23] (port=58870 helo=[192.168.1.143]) 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 1Zi2q2-0000J3-9S; Fri, 02 Oct 2015 17:05:40 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <02bc01d0fb85$8779e840$966db8c0$@gmail.com>
Date: Fri, 02 Oct 2015 17:05:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <56C026DA-7146-4DD1-83C4-9E997CB3BA93@csperkins.org>
References: <022f01d0faf1$2f4dbaf0$8de930d0$@gmail.com> <E93C2099-3579-4823-AAAE-54E04A70A2B5@csperkins.org> <02bc01d0fb85$8779e840$966db8c0$@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/i_gTd_v3N0XT3P9UzcFw5gI-J4A>
Cc: avt@ietf.org
Subject: Re: [AVTCORE] update to RFC5285
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 02 Oct 2015 16:05:44 -0000

Roni.

[inline]

> On 30 Sep 2015, at 14:40, Roni Even <ron.even.tlv@gmail.com> wrote:
> 
> Colin,
> Thanks, inline
> Roni
> 
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: Wednesday, September 30, 2015 1:31 PM
> To: Roni Even
> Cc: avt@ietf.org
> Subject: Re: [AVTCORE] update to RFC5285
> 
> Hi Roni,
> 
>> On 29 Sep 2015, at 20:58, Roni Even <ron.even.tlv@gmail.com> wrote:
>> 
>> Hi,
>> http://tools.ietf.org/id/draft-even-avtcore-rfc5285-bis-00.txt   updates RFC5285 allowing mixing one byte and two bytes RTP header extensions in the same RTP stream. This mode is negotiated using a new SDP attribute.
> 
> This looks good, but I had a couple of quick comments:
> 
> - Section 4.1 changes “MUST NOT be mixed” to “MAY be mixed”, but that’s inconsistent with Section 6. I think Section 4.1 ought to say “MUST NOT be mixed unless support for mixing one- and two-byte header extensions is signalled as in Section 6”. 
> 
> RE: OK, correct
> 
> - The draft needs to define the ABNF for the new “mix-headers” SDP attribute. I also suggest “a=extmap-allow-mixed” might be a more consistent name than “a=mixed-headers”.
> 
> RE: In this case there is no ABNF in  draft-ietf-avtcore-rtp-multi-stream-optimisation for "rtcp-rgrp". It is a similar attribute

Then we should add it to rtp-multi-stream-optimisation, too.

> - The draft removes the description of how IANA should manage the namespace, and the initial registrations. I don’t think this should be removed, but if it is, the IANA considerations needs an additional paragraph stating that the IANA registry for RTP Compact Header Extensions is to be managed in accordance with RFC 5285.
> 
> RE: I will look how to do it since this document does not define new registry, so I will just ask to update the reference to this document (does this make sense?)

No, that doesn’t make sense. Since this obsoletes the document that does define the registry, you either need to put definitions and policies matching the registry into this draft, or add something to explicitly state that the old definitions and policy remain in force.

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