Re: [OPS-AREA] assumption about number of octets encoding PENs
David Harrington <ietfdbh@comcast.net> Thu, 24 May 2012 03:06 UTC
Return-Path: <ietfdbh@comcast.net>
X-Original-To: ops-area@ietfa.amsl.com
Delivered-To: ops-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA921F85A4 for <ops-area@ietfa.amsl.com>; Wed, 23 May 2012 20:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.699
X-Spam-Level:
X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MANGLED_PENIS=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qTo5bdXuGtY for <ops-area@ietfa.amsl.com>; Wed, 23 May 2012 20:06:06 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AC21F85A2 for <ops-area@ietf.org>; Wed, 23 May 2012 20:06:06 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id Ddz61j0011uE5Es59f669i; Thu, 24 May 2012 03:06:06 +0000
Received: from [192.168.1.34] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id Df621j00h3Ecudz3cf630L; Thu, 24 May 2012 03:06:06 +0000
User-Agent: Microsoft-MacOutlook/14.2.2.120421
Date: Wed, 23 May 2012 23:06:01 -0400
From: David Harrington <ietfdbh@comcast.net>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Mark Ellison <ellison@ieee.org>
Message-ID: <CBE31973.223C7%ietfdbh@comcast.net>
Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04079D6FFF@307622ANEX5.global.avaya.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: Alan DeKok <aland@deployingradius.com>, ops-area@ietf.org, pearl.liang@icann.org
Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
X-BeenThere: ops-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPS Area e-mail list <ops-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ops-area>, <mailto:ops-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ops-area>
List-Post: <mailto:ops-area@ietf.org>
List-Help: <mailto:ops-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ops-area>, <mailto:ops-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 03:06:07 -0000
Hi, The IANA application for an enterprise number (http://pen.iana.org/pen/PenApplication.page) refers to the IANA PEN registry. At www.iana,org, private enterprise numbers (PENs) are defined as being based on RFC2578. RFC1155 (SMIv1) and RFC2578 (SMIv2) define enterprises as a particular subtree (1.3.6.1.4.1) of the Internet subtree (1.3.6.1), approved by the IAB back in 1990. So if we're talking about IANA PENs, then it appears we are talking about the {iso.org.dod.internet.private.enterprises} subtree. We could start ANOTHER registry for PENs, but a large number of enterprises have already registered under the IANA PEN registry; it seems counter productive (especially for the IETF) to have multiple standard registries for the same purpose, and to make enterprises register multiple times. A PEN is defined as being an OBJECT IDENTIFIER (a sub-oid if I read RFC1157 correctly). I think that means the number range is constrained by the adapted subset of 1988 ASN.1 that defines an INTEGER sub-oid. But I don't have time right now to research that limit. Juergen, do you know this limit? -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/23/12 11:15 AM, "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote: >Well, with all due respect to SNMP, it is yet another protocol using >PENs, isn¹t it? J > > >From: mark@ellisonsoftware.com [mailto:mark@ellisonsoftware.com] On >Behalf Of Mark Ellison >Sent: Wednesday, May 23, 2012 6:14 PM >To: Romascanu, Dan (Dan) >Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org >Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > > > >Dan, > > >Here is one reference point: > > > >The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN, >but then takes the high order bit for a different purpose. This >essentially leaves 31 usable bits for a PEN within the SnmpEngineID. > >Regards, > > > >Mark > > >On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) ><dromasca@avaya.com> wrote: >This is related to draft-liang-iana-pen-00 and >draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest >defines new Vendor-Id fields in a way consistent with RFC 2865, which >used three octets. However, in draft-liang-iana-pen-00 we say that a PEN >is a non-negative integer, which I think assumes (0..2**32-1) range. > >Questions: > >- is there any place where a limit is defined? >- should we advice new documents to cautiously define 32 bits (at least) >for Vendor-Id fields? >- should we say something on this respect in draft-liang-iana-pen? > >What will happen to RFC 2865 implementations (and maybe other protocols) >that assumed Vendor-Id is limited to three octets - this will probably >need to be dealt by the RADEXT WG. > >Regards, > >Dan > > > > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area > > > > > > > > > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area
- [OPS-AREA] assumption about number of octets enco… Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Mark Ellison
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alexey Melnikov
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alan DeKok