Re: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 29 September 2015 08:19 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 4ABBC1A21BC for <avt@ietfa.amsl.com>; Tue, 29 Sep 2015 01:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 k-Ij_nkVcKCi for <avt@ietfa.amsl.com>; Tue, 29 Sep 2015 01:19:03 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458FB1A21BE for <avt@ietf.org>; Tue, 29 Sep 2015 01:19:03 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-12-560a4975ecec
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.C1.27359.5794A065; Tue, 29 Sep 2015 10:19:01 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Tue, 29 Sep 2015 10:19:00 +0200
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Marc Petit-Huguenin <petithug@acm.org>, <avt@ietf.org>
References: <55894FE8.6080406@ericsson.com> <55FB1E25.7020702@acm.org> <55FC3935.6050605@alum.mit.edu> <560522EF.5000608@acm.org> <56055974.5060702@alum.mit.edu>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <560A4973.6030600@ericsson.com>
Date: Tue, 29 Sep 2015 10:18:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <56055974.5060702@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjW6pJ1eYQftDfouXPSvZLS6suctk sWLDAVYHZo/LV7w9/r7/wOSxZMlPpgDmKC6blNSczLLUIn27BK6MVx2X2AsOildM+7eFrYHx k1AXIyeHhICJRPPkO6wQtpjEhXvr2boYuTiEBI4ySmzauYYdwlnOKHH2+w1GkCphAQ+J89dm ANkcHCICSRK79xtA1CxllJj/tR9sEpuAhcTNH41sIDavgLbEhV3HmEFsFgFViRl/Z7CD2KIC MRI9vzZA1QhKnJz5hAXE5hTQkbi47i4LyHxmAXuJB1vLQMLMAvISzVtng40RAhrZ0NTBOoFR YBaS7lkIHbOQdCxgZF7FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERimB7f8NtjB+PK54yFG AQ5GJR7ehB2cYUKsiWXFlbmHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YOyRfbwzwfNZJUdxaI68wdUZyzJV550VS41b8LEjO1e1xcUz68akB4qCxcb9RpNDlDcm8W1x 75ZVPvKeu13CwD06zp1Tf3fc5Djvnvjzy3793rVGQs4lKOXuY5f/eZcuVH3nlTntreJkwRv8 XfNoysQtk1+IG137tPAB1zetz3XCVro7LZ8/UmIpzkg01GIuKk4EAOseq+c0AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/rYzHJPbIcpKlu5iN8ymhEW-UrZM>
Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02
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: Tue, 29 Sep 2015 08:19:05 -0000

Den 2015-09-25 kl. 16:25, skrev Paul Kyzivat:
> On 9/25/15 6:33 AM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi Paul,
>>
>> On 09/18/2015 10:17 AM, Paul Kyzivat wrote:
>>> On 9/17/15 4:10 PM, Marc Petit-Huguenin wrote:
>>>
>>>>> K. Section 3:
>>>>>
>>>>> When new values or ranges are added, they MUST be tested in
>>>>> ascending order.
>>>>>
>>>>
>>>> This text should not talk about adding new values/ranges. Changed
>>>> the text to:
>>>>
>>>> "The various range values for the first byte MUST be tested in
>>>> ascending order."
>>>
>>> I just reviewed this, and I have no idea what it means. I see nothing
>>> about Figure 3 that requires testing to be done in a particular
>>> order. The *text* suggests an if/then/else or switch statement
>>> implementation. But the code generated for a switch statement may
>>> well be a lookup table and so have no particular ordering.
>>>
>>> The only time ordering would matter would be if the ranges
>>> overlapped. And IIUC the goal here that the ranges *not* overlap.
>>
>> The reason we added this was to plan when a new overlapping range is
>> added (mostly because someone ignored the advices provided by this
>> draft).  If the algorithm says today that range must be checked in
>> ascending order, then *all* implementations will work (or, most
>> likely, fail) in a similar way.  That sentence is meant to explicitly
>> prevent using a lookup table or perfect hashing or whatever technique
>> that would prevent things to fail identically everywhere.
>>
>> That said the sentence can probably be improved.
>
> Yes.
>
> Do you consider overlapping ranges to be an error, and want the error to
> be handled deterministically? Or are you thinking that there may be
> overt changes that legally define overlapping ranges and want to make
> the meaning deterministic?
>
> If there is a deterministic choice when ranges overlap, then that seems
> to effectively update one of the ranges so that they don't overlap.
>

I think this discussion is going into the comment of my issue J. It 
really is to write down in the document why it would benefit to have a 
particular order of checking, and thus the implication of that for 
implementations. A reader in the future must have the chance of 
understanding why it should do what you suggest and why it matters. That 
was missing before. And as Paul comments what to actually do need to be 
more clearly described.

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
----------------------------------------------------------------------