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

Greg Wilkins <gregw@intalio.com> Tue, 31 May 2011 21:52 UTC

Return-Path: <gregw@intalio.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 E758FE0919 for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 14:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.95
X-Spam-Level:
X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 kfqJMbywZFro for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 14:52:29 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F138E06B5 for <hybi@ietf.org>; Tue, 31 May 2011 14:52:28 -0700 (PDT)
Received: by vws12 with SMTP id 12so5061543vws.31 for <hybi@ietf.org>; Tue, 31 May 2011 14:52:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.98.231 with SMTP id el7mr1081873vdb.229.1306878748265; Tue, 31 May 2011 14:52:28 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Tue, 31 May 2011 14:52:27 -0700 (PDT)
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11402F796C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.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>
Date: Wed, 01 Jun 2011 07:52:27 +1000
Message-ID: <BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>, 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 21:52:30 -0000

On 1 June 2011 02:27, Gabriel Montenegro
<Gabriel.Montenegro@microsoft.com> wrote:
> We have as many counterexamples of the opposite with the bits in the IP header, TCP headers, IP TOS bits, as well as protocol numbers (e.g., for IP, TCP, ESP, IPv6, UDP, etc), etc. There is nothing new about IANA sections and process to control shared resources. Sure, there's no police and people can use bits as they see fit and sometimes they do so, but rules are already clear, and no extra wording will change that.


I was thinking that the extra text was not so much trying to enforce
IANA rules/exclusions.  More to remind the developers that extra data
can be added to the payload for extra op-codes and flags.  Ie reduce
the temptation to squat on the reserved bits by steering them to an
acceptable alternative.

regards