Re: [AVTCORE] RFC5285bis open issues

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 27 February 2017 10:24 UTC

Return-Path: <magnus.westerlund@ericsson.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 3A681129D18 for <avt@ietfa.amsl.com>; Mon, 27 Feb 2017 02:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 QuOmB-rPKasV for <avt@ietfa.amsl.com>; Mon, 27 Feb 2017 02:24:43 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1974C12943D for <avt@ietf.org>; Mon, 27 Feb 2017 02:24:42 -0800 (PST)
X-AuditID: c1b4fb3a-ae2b298000007c1e-4b-58b3fe68bf9d
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 29.7A.31774.86EF3B85; Mon, 27 Feb 2017 11:24:41 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.319.2; Mon, 27 Feb 2017 11:24:38 +0100
To: Roni Even <roni.even@huawei.com>, "avt@ietf.org" <avt@ietf.org>
References: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <72bbcfb0-d9fa-3703-b100-82821973f2db@ericsson.com>
Date: Mon, 27 Feb 2017 11:24:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM2K7gW7mv80RBrMW81q87FnJbvHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx7N0P9oLZghWT3uxla2Bs5u1i5OSQEDCR uLJ+NXMXIxeHkMA6Rol/v5eyQzjLGSW+Tf7NCFIlLKArsWPJe6AqDg4RAWeJK6sjIGouM0ps aGtkBqlhE7CQuPmjkQ2khlfAXmLJ81yQMIuAqkTz71VgJaICMRJ7++8zgdi8AoISJ2c+YQGx OQVCJG5d/AlWwww0Zub884wQtrxE89bZYHEhAW2JhqYO1gmM/LOQtM9C0jILScsCRuZVjKLF qcXFuelGRnqpRZnJxcX5eXp5qSWbGIHhd3DLb6sdjAefOx5iFOBgVOLh/RC7OUKINbGsuDL3 EKMEB7OSCG/LN6AQb0piZVVqUX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwc nFINjH3ar8VTHycpCjNfLJGTb5Jx5uhvT1D1Uv088XWS78Ii58J6GQ2R2AO265d+PFl42+/y 0pXee+O+HXz9TETo+N7Q6qlboxoOMC7i2dYZ9yiijdX8Yrt87oeDHst9hQ16zy5oervk4e6/ U4yYu/1FNx6qqHV4fev1iWaRv6e0JfrWh9VxTJhpr8RSnJFoqMVcVJwIAEvGN1I7AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/qi4qHrrmNdekNmtfwaQDxovUe9w>
Subject: Re: [AVTCORE] RFC5285bis open issues
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: Mon, 27 Feb 2017 10:24:46 -0000

Den 2017-02-26 kl. 08:30, skrev Roni Even:
> Hi Magnus,
> Thanks,
> I will add the text about the id=0 len>0 using option b
>

Regarding this text:

    Each distinct extension MUST have a unique ID.
    The value 0 is reserved for padding and MUST NOT be used as a local
    identifier.

    an extension element with a value equal 0 MUST NOT have len greater
    than 0.  If such an extension element is encountered, its length
    field MUST be ignored, processing of the entire extension MUST
    terminate at that point, and only the extension elements present
    prior to the element with ID 0 and len greater than 0 SHOULD be
    considered.

I think it could be improved to make it clearer, thus I suggest the 
following changed:

    Each distinct extension MUST have a unique ID.
    The ID value 0 is reserved for padding and MUST NOT be used as a
        ^^
    local identifier.

    An extension element with an ID value equal 0 MUST NOT have len
    ^                          ^^^^
    greater
    than 0.  If such an extension element is encountered, its length
    field MUST be ignored, processing of the entire extension MUST
    terminate at that point, and only the extension elements present
    prior to the element with ID 0 and len greater than 0 SHOULD be
    considered.



> As for support for one-byte only I think that since section 4.1.2 says " the one-byte header form is preferred and MUST be supported by
>    all receivers" it provides guideline to use one-byte saying that one-byte will work but two-bytes may not. Do you have another proposed text to address this point?

No, I don't have any suggestion for improving that text.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------