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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 25 September 2015 14:25 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 AA12C1A1B17 for <avt@ietfa.amsl.com>; Fri, 25 Sep 2015 07:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Ea8s2sjCuGkK for <avt@ietfa.amsl.com>; Fri, 25 Sep 2015 07:25:58 -0700 (PDT)
Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A5B1A1B18 for <avt@ietf.org>; Fri, 25 Sep 2015 07:25:58 -0700 (PDT)
Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-02v.sys.comcast.net with comcast id MSR11r0065BUCh401SRyGx; Fri, 25 Sep 2015 14:25:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id MSRx1r00C3Ge9ey01SRxtW; Fri, 25 Sep 2015 14:25:58 +0000
To: 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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56055974.5060702@alum.mit.edu>
Date: Fri, 25 Sep 2015 10:25:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <560522EF.5000608@acm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1443191158; bh=GJju8WKfbRK+/+pKP+euENYraCGLkLQ/f/ufWvSiKRk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=lqZ1WNLfXt5f8ijFrQYetYF5tPoOXdSNjb0eWGaKdo9V40o3dqz5zLtMIBMIeqMWD XNytdKFmhbLMehCYd9+THzfjhe8WBPn60Q5HqvymAgoD/BpAx/Wj5yVdpcblWCgzOH MuAWVudbiXRPX5iU5yyfMYaObpSMZQOzNxejVN9WA+5OzHrGprSU86xvKxPzLq6Nr0 zWu/iGS6cG/5Y64dhSCqne1mKSuKxK1xFMCM66ERfwrTEHo1HdZb7zSBHy4/9smhnf pau3Z8H2i1FKnmkqdHi5RsVjjVYqKOoU+/rTgBf/qJ97f43Mk32s4gtQ85lysQpmMj 4x7syXzqdV2cw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/JtBgahulF_ZGWwkfV3o-woUuMqg>
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: Fri, 25 Sep 2015 14:25:59 -0000

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.

	Thanks,
	Paul