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

Christer Holmberg <> Tue, 20 October 2015 07:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DFBC1A6F3B for <>; Tue, 20 Oct 2015 00:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rE8Ga7q5-jry for <>; Tue, 20 Oct 2015 00:27:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5D9E1A001D for <>; Tue, 20 Oct 2015 00:19:44 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-f4-5625eb0e77dd
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id EF.A6.17026.E0BE5265; Tue, 20 Oct 2015 09:19:42 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 20 Oct 2015 09:19:42 +0200
From: Christer Holmberg <>
To: "Gonzalo Salgueiro (gsalguei)" <>, Paul Kyzivat <>
Thread-Topic: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02
Thread-Index: AQHQ8YTkilozGbm1pEqGAhsDM9Evg55Cy/CAgAqgCICAAED+AIAmK9QAgABTKyA=
Date: Tue, 20 Oct 2015 07:19:41 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+JvjS7fa9Uwg8YmPYuXPSvZLeZO8bO4 sOYuk8WKDQdYHVg8Ll/x9vj7/gOTx5TfG1k9liz5yRTAEsVlk5Kak1mWWqRvl8CVseHwD5aC dRoVM7f2szQwrlDvYuTkkBAwkWg6cZcNwhaTuHBvPZDNxSEkcJRRounATlYIZzGjxJbVE9m7 GDk42AQsJLr/aYM0iAjES3w+dYgdxGYW8JRo2nSMGcQWFvCQ2ND1mBGixlPiTFcXlO0nMeF6 M1g9i4CqxINdt9hARvIK+Ep8OcsMseoGo8T+yzfA5nAK2EqcPrEF7DhGoOO+n1rDBLFLXOLW k/lMEEcLSCzZc54ZwhaVePn4HyuErSjx8dU+RpD5zAKaEut36UO0KkpM6X4IdgKvgKDEyZlP WCYwis1CMnUWQscsJB2zkHQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYXwe3/Nbd wbj6teMhRgEORiUe3gfpqmFCrIllxZW5hxilOViUxHlbmB6ECgmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamCc02Gn3idTKl0stFs418rd0lRG+5nPdef9brcN1txr5Fjk58PheSflxPY4o5bl csypT4/zu9iF74/ZEahZ6KIj33VhWtoOoVvHuI27HhtJrt630udTeOyfhDNCM3ae0l41Ld3R OTplN+udCfWFMWskV6bztnRcvrfeJ/Na4I1Dn57rSG05mqbEUpyRaKjFXFScCACPpyHukAIA AA==
Archived-At: <>
Cc: Marc Petit-Huguenin <>, "" <>
Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Oct 2015 07:27:10 -0000


I assume we don't need to update BUNDLE because of this, as BUNDLE doesn't specify the details of the multiplexing, but simply refers to RFC 5764 (which means it implicitly refers to this draft):

BUNDLE currently says:

	"Section 5.1.2 of [RFC5764] describes a mechanism to identify the
	   protocol of a received packet among the STUN, Datagram Transport
	   Layer Security (DTLS) and SRTP protocols (in any combination).  If an
	   offer or answer includes bundled "m=" lines that represent these
	   protocols, the offerer or answerer MUST support the mechanism
	   described in [RFC5764], and no explicit negotiation is required in
	   order to indicate support and usage of the mechanism."



-----Original Message-----
From: avt [] On Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: 20. lokakuuta 2015 1:20
To: Paul Kyzivat
Cc: Marc Petit-Huguenin;
Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02

Hi Paul - 

We have published an -03 addressing Magnus’ comments.  We don’t believe this has addressed your concern, so we have a TODO note in the draft to still address your comment.  We aren’t sure how best to resolve this yet.  Any specific text proposals based on -03 would be very helpful at this point.



> On Sep 25, 2015, at 10:25 AM, Paul Kyzivat <> wrote:
> On 9/25/15 6:33 AM, Marc Petit-Huguenin wrote:
>> 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
> _______________________________________________
> Audio/Video Transport Core Maintenance 

Audio/Video Transport Core Maintenance