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

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sorry for the delay in processing this.  See my answer inline.

On 09/25/2015 07:25 AM, Paul Kyzivat wrote:
> 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.

After more discussions between authors, we decided to remove the section about ordering altogether.  We now think that even if the proposal is not as future-proof as possible, it is good enough.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWp9ZoAAoJECnERZXWan7Eg9oQALxnxiHdd+pW0rBxWr4IlMfH
E+HPFapkzpfLAofPzh3Kx0UBWBJLM+zD4NHtgNKxEsrHc8fNuhI9tVLwxPeX4Qal
8LEVkAf0VLu9LzjvCNkeDtHxT4H40ioBhqeqARpU+4apPtftziG8oiye6e8lVpwy
00sXoKGea69UxW8zQg9/lCPtcwfV1Epa1zJPLYCxC6Kv6b9i7jbGf8dzW+8zI5Rr
xS0J6CHvq3hgI20axedYJrZwAkhNIkGxfcNkQC2c9J7K5yf1eyZf1k1Rg3XYacwE
cnr819fOXh+52P4pToAtmYqiAB5MkhkznJ5C5cDDx3aacnuzfOsxt5/RBEmhavI7
pqX4NalNNU0JAbo+mlxXHsdUrg2Ym6ZP3JZMRwdnttKTSJMMPXMp5kErFpuVtTUB
0Pp5mZFCxLkqvbY8J/WcESlMisgYtNJArJoB64rg1y9fkMrJwBR2L6QxZAjxkGwx
7/qgMmnSJJ3taspWa6NXPdKfx3KNsEPi7N7rhAohpeddEGNq4tdzv6jcyP4fUw42
B77BXc5y/itp9EmB1M6ipPGIyfmXuu0hIEg04/8B6N281nGN5gdx4efWS2PpCHih
kfkyZWEdbNNRHJMYmlrzAJhdE0/wdyFN+fhJOTPQgysjLvzsIhWR/JXiBLhH3d+o
qB62Yh2IlxGKcds5SKUZ
=oWoq
-----END PGP SIGNATURE-----