Re: assumption about number of octets encoding PENs

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)
[email protected]
+1-603-828-1401





On 5/23/12 11:15 AM, "Romascanu, Dan (Dan)" <[email protected]> wrote:

>Well, with all due respect to SNMP, it is yet another protocol using
>PENs, isn¹t it? J
> 
> 
>From: [email protected] [mailto:[email protected]] On
>Behalf Of Mark Ellison
>Sent: Wednesday, May 23, 2012 6:14 PM
>To: Romascanu, Dan (Dan)
>Cc: [email protected]; Alexey Melnikov; Alan DeKok; [email protected]
>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)
><[email protected]> 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
>[email protected]
>https://www.ietf.org/mailman/listinfo/ops-area
>
>
>
>
> 
>
> 
>
>
>
>_______________________________________________
>OPS-AREA mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ops-area