Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt

Ben Campbell <ben@nostrum.com> Mon, 24 July 2017 21:52 UTC

Return-Path: <ben@nostrum.com>
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 26A34129B5E; Mon, 24 Jul 2017 14:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.871
X-Spam-Level:
X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 o9DXaB2xoCAI; Mon, 24 Jul 2017 14:52:40 -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 EDB691204DA; Mon, 24 Jul 2017 14:52:39 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6OLqUDV033023 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Jul 2017 16:52:31 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com>
Date: Mon, 24 Jul 2017 16:52:29 -0500
Cc: "avt@ietf.org" <avt@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com>
References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com>
To: Roni Even <roni.even@huawei.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Yxp3n5rb9PNedIYFEt6HFvnFnNM>
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Jul 2017 21:52:42 -0000

Hi Roni,

I agree this covers the IESG comments. However, I am confused about some of the new text in section 7 about an answerer marking an extension as “inactive”. I assume these are here in response to Alexey’s questions about why the SHOULDs are only SHOULDs.

In the first instance:

   "If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.  An answerer MAY want to respond that he supports the
   extension and may use it in the future will mark the extension as
   “inactive””

What does “willing to use it in the future” mean that is different than just being willing to receive it, which is already covered by marking it as “recvonly”? Do we contemplate that the offerer may at some point in the future send an updated offer or answer that changes this to “recvonly”?

Similarly in the second instance:

  If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer.  An answerer MAY want
   to respond that he support this extension and may send in the future
   or will be able to receive by marking the extension as "inactive"

… is the answer expected to mark the extension as “sendonly” at some point in the future?


  
If it turns out that the added text is roughly correct, the text is still confusing from a pure sentence structure perspective. I would suggest text, but we probably need to resolve the above questions first.

Thanks!

Ben.


> On Jul 23, 2017, at 1:26 AM, Roni Even <roni.even@huawei.com> wrote:
> 
> Hi,
> I submitted a version that I hope addresses all the comments from the IESG review.
> The major open issue was the category of allowed-mix in bundle and based on the WG preference it is now Identical.
> 
> Thanks
> Roni Even
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: יום א 23 יולי 2017 09:23
> To: Harikishan Desineni; HariKishan Desineni; Roni Even; avtcore-chairs@ietf.org; David Singer; Roni Even
> Subject: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt
> 
> 
> A new version of I-D, draft-ietf-avtcore-rfc5285-bis-13.txt
> has been successfully submitted by Roni Even and posted to the IETF repository.
> 
> Name:		draft-ietf-avtcore-rfc5285-bis
> Revision:	13
> Title:		A General Mechanism for RTP Header Extensions
> Document date:	2017-07-22
> Group:		avtcore
> Pages:		24
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5285-bis-13.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-13
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-13
> 
> Abstract:
>   This document provides a general mechanism to use the header
>   extension feature of RTP (the Real-Time Transport Protocol).  It
>   provides the option to use a small number of small extensions in each
>   RTP packet, where the universe of possible extensions is large and
>   registration is de-centralized.  The actual extensions in use in a
>   session are signaled in the setup information for that session.  This
>   document obsoletes RFC5285.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>