Re: [hybi] method of allocation of reserved bits to extensions

John Tamplin <jat@google.com> Tue, 31 May 2011 22:50 UTC

Return-Path: <jat@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D0E078B for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 15:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96yzX48f-X-v for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 15:50:30 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E652E0731 for <hybi@ietf.org>; Tue, 31 May 2011 15:50:30 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p4VMoOmB020815 for <hybi@ietf.org>; Tue, 31 May 2011 15:50:25 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306882229; bh=Vqq9hUkJCxC9hwsRtULFO3da/TQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N7efjme5MOOlC1idw1PceKoFe5qI6ANK4OlvjUvBsL3Fb37rUN/LSrrMAaW9pDsqe ToOiUR0zEMtw9BOmZA8Fg==
Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq12.eem.corp.google.com with ESMTP id p4VMjhbK022874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 31 May 2011 15:50:23 -0700
Received: by qwj9 with SMTP id 9so3130641qwj.7 for <hybi@ietf.org>; Tue, 31 May 2011 15:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aiixd8EkdaFKJRHKO3TOOGkwWORSs13fUSrW/+1hKYo=; b=o26MpviuzSSrv5yibqmteBZN5BNpTz4vv9uMkrfzjrwkPLdpwvt6dfO4sHE/q4D5vj 70SWBFDwakqeZ6ufnfaA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ove9GOeex6f2qhd3ckJMeKHywfTnj13wSuGGlvwuU4T2os8NrHmXeUOnLRMDfhB7jL wG4DWJGLO0WxazjGeJlg==
Received: by 10.229.42.73 with SMTP id r9mr4752701qce.189.1306882223141; Tue, 31 May 2011 15:50:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.78.229 with HTTP; Tue, 31 May 2011 15:50:03 -0700 (PDT)
In-Reply-To: <BANLkTimNrSVhZicjwz4pGiS6aufaTzbRfw@mail.gmail.com>
References: <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com> <BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com> <4DBA3809.4010004@oracle.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <cbutt65hgt3ujdbi9jqa3v9a42iigglldk@hive.bjoern.hoehrmann.de> <CA566BAEAD6B3F4E8B5C5C4F61710C11402F796C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com> <BANLkTimn3vcjuk3fSW=zY6ZpAfRMt1c0vw@mail.gmail.com> <BANLkTimNrSVhZicjwz4pGiS6aufaTzbRfw@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Tue, 31 May 2011 18:50:03 -0400
Message-ID: <BANLkTim3PYcTZra_Qr-3hshS1nWJxXvB2A@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary="00163683249cac728f04a49a3a36"
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [hybi] method of allocation of reserved bits to extensions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2011 22:50:31 -0000

On Tue, May 31, 2011 at 6:44 PM, Greg Wilkins <gregw@intalio.com> wrote:

> I can see that argument and while not entirely convinced by it, don't
> object to it either.
>
> Which suggests that if we want to go the IANA path and not have
> cyber-squatting, then we need to
> define an opcode that says the frame is an extension frame and that
> the interpretation of it is entirely up to the extension(s)
>

So what happens when multiple extensions are defined?  How do you make sure
their use of such extension frames don't conflict?  That sounds at least as
complicated as the proposal to dynamically assign opcodes/bits.

I don't know if it is necessary -- I don't know about IANA allocation
procedures, but I would hope that bits can be allocated temporarily for
experimentation.  For example, something like "opcode 0x7 is reserved for
experimentation with MUX-related extensions until 31 Dec 2011".  If that is
feasible, then I think having a central registry is a good idea, rather than
saying only opcodes/bits are registered but secondary extension opcodes are
free-for-all.

-- 
John A. Tamplin
Software Engineer (GWT), Google