IETF Logo Mail Archive

Re: [tram] WGLC draft-ietf-tram-alpn-00

Martin Thomson <martin.thomson@gmail.com> Wed, 10 September 2014 21:19 UTC

Return-Path: <martin.thomson@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 073A81A9243 for <tram@ietfa.amsl.com>; Wed, 10 Sep 2014 14:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8qxWh2310hRd for <tram@ietfa.amsl.com>; Wed, 10 Sep 2014 14:19:16 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264341A9242 for <tram@ietf.org>; Wed, 10 Sep 2014 14:19:15 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id 10so12598354lbg.30 for <tram@ietf.org>; Wed, 10 Sep 2014 14:19:14 -0700 (PDT)
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=scMzuRM6buRrhcM5ASv39KThDbReoGh7CCA2zkFA3vI=; b=MrK2g8a3lBUA7v5ssVW9KnTTnzpXcSKwfecoBxCrkUK47q37kYOGgJ43awedhc87ad sB4etovDhPmWv9Mx22/+8EkcJwuqdxFpL/kob/cDqaZnFWcInqjvHsQxsxN8AXt0uHxW 9GVvS2bKB1/qAPvRxHM9WoxKToqA0G08+w/QzYaGS8UD62nOjGvRxYOkQZewwqtHT/51 aL56YvK0LGXIDyMkCF7F17n2VBto9MxYLXYJdkMEHCz50g7T2ZnTKmrEcaM+2+/iUbNL 3XZnJ111G2fFx7zDScxpeAzcum8TDFRSEQAfZAe78WvPoO3VtftAVZWWr2LfWSfHasT8 ttRw==
MIME-Version: 1.0
X-Received: by 10.112.161.70 with SMTP id xq6mr38703539lbb.49.1410383954409; Wed, 10 Sep 2014 14:19:14 -0700 (PDT)
Received: by 10.25.166.75 with HTTP; Wed, 10 Sep 2014 14:19:14 -0700 (PDT)
In-Reply-To: <C7219C6D-A887-4E05-8869-996F8B32D810@cisco.com>
References: <CANO7kWCiU275DnNsJ7pn8ALjpV5qVViCQUQS8VOgubArGYG_5g@mail.gmail.com> <CABkgnnXWLhAggZwP3ZhDsDMnx6ueYOjrMw12=tD9xEryx_5Z0A@mail.gmail.com> <C7219C6D-A887-4E05-8869-996F8B32D810@cisco.com>
Date: Wed, 10 Sep 2014 14:19:14 -0700
Message-ID: <CABkgnnV_u32ZLpoKxX7Z7ExbJAEOXgR9BgiZnRg7vEWFhaZ4rw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/L7OjqJzXEx--Ba7Xot5afl_H4Vk
Cc: Simon Perreault <sperreault@jive.com>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00
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: Wed, 10 Sep 2014 21:19:18 -0000

On 10 September 2014 13:46, Gonzalo Salgueiro (gsalguei)
<gsalguei@cisco.com> wrote:
> If folks think it is useful we can even throw in a wildcard label (stun.*) as a catch all implying whatever STUN usage.

I'd be surprised if you couldn't enumerate all the options up front.
Inferring semantics based on a prefix is a dangerous precedent to set.
Existing usages of ALPN rely on it being an opaque token.  It would be
good to maintain that.

Not saying you shouldn't create consistency in the form of the labels
though, just don't try to overload meaning on that.

As far as uses go, the three you identify are the two that I think we
might need.  That is, if you are talking to a TURN server, that's
pretty clearly a good use for protocol identification.  Same applies
to talking to a STUN server for NAT discovery purposes.  Not sure that
I'd care to distinguish between NAT discovery and behaviour discovery
though.

v2.23.0 | Report a Bug | By Email