IETF Logo Mail Archive

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

SM <sm@resistor.net> Wed, 25 May 2011 07:01 UTC

Return-Path: <sm@resistor.net>
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 25CAEE0688 for <hybi@ietfa.amsl.com>; Wed, 25 May 2011 00:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 vxzvMkDC1KzY for <hybi@ietfa.amsl.com>; Wed, 25 May 2011 00:01:49 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20735E0662 for <hybi@ietf.org>; Wed, 25 May 2011 00:01:48 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4P71bqo017171 for <hybi@ietf.org>; Wed, 25 May 2011 00:01:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1306306904; bh=TVIasn3Uadireqc/9JoOom3BkIAg17luP/8pJA+y7+4=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=vA+covrETaQzA7tZPwnBVe+p0zSXKx64b18ClJC8kLYy03kbFzPMXOK1QolaIvOma CBBDdQiiUCgGqPofmhQ6zw9Vru8E2QU1rZBEP4/ZlH9ZjgrzU2G+lcOkyq/G/WeAFd Z61tGDhzUkBPonZ3eIKEbLAg8Ku+9xdYYTDvWhFs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1306306904; bh=TVIasn3Uadireqc/9JoOom3BkIAg17luP/8pJA+y7+4=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=GA/grqseWQ0dkxKaXdM1ncEl5xo+WWkGShUDHIAka/SUwSmu7iPGa5whAlzRRIa8R Otnr4ZcmoRB55DWIf4pvmo48JRcCbRBppfA/fGUrYqcLU4DvTe0dvtsZZTgsPK35Xi xMzR9jowzCLISByLqwU2eCpW+hbyDOvypaaywzA8=
Message-Id: <6.2.5.6.2.20110524234152.03017c30@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 24 May 2011 23:52:41 -0700
To: hybi@ietf.org
From: SM <sm@resistor.net>
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wi ngroup.windeploy.ntdev.microsoft.com>
References: <BANLkTi=vOQDtL5GobitKe8yiUoQFb2go_Q@mail.gmail.com> <BANLkTikaOXg0u+4d8Ly6OxUQ7PFUU=udgQ@mail.gmail.com> <BANLkTikiUkivJitZGU-+q6wBfJ3VW45F8g@mail.gmail.com> <BANLkTindmLQ0KE6K5qUX2ue+=hoLUaznLA@mail.gmail.com> <BANLkTim9w83iSY-TH1yuVAUXxypJk_tmrw@mail.gmail.com> <BANLkTimnMBwNgP_e29exT6dUkp60s2xU3g@mail.gmail.com> <BANLkTi==RTfqaYFT3CQs1pM5Tb501rk2Vg@mail.gmail.com> <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com> <BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com> <4DBA3809.4010004@oracle.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: Wed, 25 May 2011 07:01:50 -0000

At 18:03 19-05-2011, Gabriel Montenegro wrote:
>Reserved bits should only be allocated for very compelling reasons, 
>either because there is an extension that has full backing of the WG 
>or because there is a new version of the protocol that needs it. I 
>think we should word our IANA considerations on bit assignment with 
>a very strict assignment policy of "Standards Action":
>http://tools.ietf.org/html/rfc5226#section-4.1

Reserved bits can be allocated in future.  When a bit is marked as 
"reserved" it does not mean that it will never be used.

Having a strict assignment requirement has advantages and 
disadvantages.  If people find it difficult to get an assignment, 
they will squat on the bits.  It would be good if the working group 
give some thought to this question.

Regards,
-sm

v2.23.0 | Report a Bug | By Email