Re: [AVTCORE] Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT) - the use of "local"

Roni Even <roni.even@huawei.com> Thu, 22 June 2017 11:33 UTC

Return-Path: <roni.even@huawei.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 E7B421296B3; Thu, 22 Jun 2017 04:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 SEMx8GffNa50; Thu, 22 Jun 2017 04:32:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97439127735; Thu, 22 Jun 2017 04:32:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPQ06072; Thu, 22 Jun 2017 11:32:55 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 12:32:54 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 22 Jun 2017 19:32:32 +0800
From: Roni Even <roni.even@huawei.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-avtcore-rfc5285-bis@ietf.org" <draft-ietf-avtcore-rfc5285-bis@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT) - the use of "local"
Thread-Index: AdLrRkBZNpMiyrc3R9m+xLlDIkHl+A==
Date: Thu, 22 Jun 2017 11:32:31 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7DBAEC@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.594BAAE8.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2d4449d5b94ba4423104eba8272e4ba3
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/5J94ytPnajpqb8fi67fQgppeMWQ>
Subject: Re: [AVTCORE] Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT) - the use of "local"
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: Thu, 22 Jun 2017 11:33:01 -0000

Hi Adam,
You are right, the text in section 7

"Local identifiers in the valid range inclusive in an offer or answer  must not be used more than once per media section (including the session-level section).  "
Implies that local means in an RTP session , the text says that the identifier must be unique in the media section (m-line) taking into account that the identifier may be defined in the session level.  The rest of the text also implies that the same identifier must be used in the offer and answer.

I suggest adding an explicit sentence here.

"Local identifiers in the valid range inclusive in an offer or answer  must not be used more than once per media section (including the session-level section).  The local dentifiers MUST be unique in an RTP session and the same identifier MUST be used for the same offered  extension in the answer.
A session update MAY change the direction
   qualifiers of extensions under use.  A session update MAY add or
   remove extension(s).  Identifiers values in the valid range MUST NOT
   be altered (remapped).

   Note that, under this rule, the same local identifier cannot be used
   for two extensions for the same media, even when one is "sendonly"
   and the other "recvonly", as it would then be impossible to make
   either of them sendrecv (since re-numbering is not permitted either).
 "


Roni

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: יום ד 21 יוני 2017 02:16
> To: The IESG
> Cc: draft-ietf-avtcore-rfc5285-bis@ietf.org; Magnus Westerlund; avtcore-
> chairs@ietf.org; magnus.westerlund@ericsson.com; avt@ietf.org
> Subject: Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with
> COMMENT)
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-avtcore-rfc5285-bis-12: Yes
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The use of the term "local" in this document is implicit and therefore
> confusing. Section 5 refers to "local identifier (ID)", while section 7 refers to
> "Local identifiers". Neither indicates what the identifiers are local to, and
> some implementors have chosen to interpret this as meaning "local to the
> sender machine." See, for example,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1361206
> 
> I believe the intention here is for "local" to mean "local to this session."
> This meaning should be made explicit. And, for avoidance of doubt, the
> document should clarify that the negotiated identifiers use the same
> numeric value in both directions. This is implied by much of the text, but it
> never stated outright. Because so many other session attributes (e.g.,
> payload types) can be negotiated to be different in each direction, many
> implementors are likely to assume the same applies here. As the above bug
> demonstrates, this leads to real interop issues in the field.
> 
> Nits:
> 
>    element (no alignment is needed), and parsing stops at the earlier of
>    the end of the entire header extension, or in one-byte headers only
>    case, on encountering an identifier with the reserved value of 15.
> 
> Put quotation marks around "one byte headers only".
> ____
> 
>    Each extension element MUST starts with a byte containing an ID and a
>    length:
> 
> s/starts/start/
> ____
> 
> The attribute definition in section 6 says "Value:" instead of "Value: none."
> -- Fix or refer to the IANA section instead.
>