Re: [tram] Points that should be clarified in STUN-bis and TURN-bis

Oleg Moskalenko <mom040267@gmail.com> Fri, 07 February 2014 22:08 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B001A04B2 for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 14:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 VhzYOEJRYvRo for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 14:08:32 -0800 (PST)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8D21A051E for <tram@ietf.org>; Fri, 7 Feb 2014 14:08:31 -0800 (PST)
Received: by mail-pd0-f169.google.com with SMTP id v10so3701612pde.0 for <tram@ietf.org>; Fri, 07 Feb 2014 14:08:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5xc4bKIKyNci1Wbg+o+XXdDkBui/HMT8X88cisq9NIE=; b=Vudd+gl9f/hWTpiaHyJfPzH8xRhdCU6h/tnYj2KaBk/OT2Qc5iAzTof78DePi4F+7R CJ9D9t3XM16QQk6rAq94fyCvwyA1XUqUZ6028Inbu86SVON6tAvLDkt5barQvnq4Jt94 ttxNGFHNBXDQpnIWA74qp1CAuw8+zEqYtBPyE4STdyy3lcPzic6Jc22Rkx922mm67Y5q ge5JM75Ujt6ZXDCAHB4r3pVRssbdgR6nQ9DqtjMdDUetIh6Xmshkhe2kXghY7OFhAP+J xpHUxIVGanNtfoDSM9FWu17GEFJIgQhmYVBvp/tVU9PSsYcpxNcDXoXbAEsqzdaUKWhW 5uBw==
MIME-Version: 1.0
X-Received: by 10.67.14.231 with SMTP id fj7mr10454844pad.115.1391810911047; Fri, 07 Feb 2014 14:08:31 -0800 (PST)
Received: by 10.68.147.131 with HTTP; Fri, 7 Feb 2014 14:08:30 -0800 (PST)
In-Reply-To: <52F5550D.3020203@viagenie.ca>
References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <CALDtMr+qgdnT5i4fiJidufGZF1CPR=puAZ+Ldqnp5t=At0AS-g@mail.gmail.com> <52F54CDC.1040502@viagenie.ca> <CALDtMrJ4J78t4PboxN5O3ZPMmt243zZ2YV5LBv-Nhz1k3E7LyQ@mail.gmail.com> <52F5550D.3020203@viagenie.ca>
Date: Fri, 07 Feb 2014 14:08:30 -0800
Message-ID: <CALDtMrLdxC8Vdge-XQuU0kmF1YaiRQXGZm=6mExbA6LwsnNGow@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: multipart/alternative; boundary="001a113453ecf2962304f1d83aac"
Cc: "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 22:08:34 -0000

OK, that's fine.

Oleg


On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault <simon.perreault@viagenie.ca
> wrote:

> Le 2014-02-07 16:19, Oleg Moskalenko a écrit :
> > Well... OK. If we want the client always to send the address-family -
> > but we do not enforce that on the receiving side... that sounds
> > awkward,  like a speed limit without cops. It is great - but does that
> > strict requirement make sense without enforcement ? We can always say
> > that TURN client SHOULD send the address-family, but MUST probably would
> > be too strict... I guess.
>
> The idea is: first, we specify that TURN bis clients MUST send
> REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour
> depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify
> TURN bis server behaviour when that parameter is absent. If the
> parameter is absent, the client is not following the TURN bis spec, and
> the server is free to behave however it wants. That includes *wink wink*
> being backward-compatible with TURN.
>
> This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send
> the magic cookie, and STUNv2 server behaviour is defined when the cookie
> is present. But STUNv2 does not specify server behaviour when the cookie
> is absent. The cookie being absent means the client is not a STUNv2
> client. The server is free to behave however it wishes. That includes
> *wink wink* being backward-compatible with STUNv1.
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>