Subject: [OPS-AREA] assumption about number of octets encoding PENs

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 May 2012 17:05:05 +0200

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

---

From: Mark Ellison <[email-masked]>
Date: Wed, 23 May 2012 11:13:43 -0400

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-masked]>wrote:

> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 May 2012 17:15:33 +0200

Well, with all due respect to SNMP, it is yet another protocol using
PENs, isn't it? J

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Ellison
Sent: Wednesday, May 23, 2012 6:14 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; Alexey Melnikov; Alan DeKok;
[email-masked]
Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs

Dan,

Regards,

Mark

On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan)
<[email-masked]> wrote:

Questions:

Regards,

Dan

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 May 2012 17:18:19 +0200

Hi,

Since we're discussing PENs, I have another some more I would like to 
see addressed in draft-liang-iana-pen-00.
     - What about unassigned PENs? See the part in red in my DISCUSS on 
https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ (on 
the telechat this Thursday)
     - PEN are not always representing manufacturer ID

-The term "vendor" is confusing

    Vendor ID

       The Vendor ID is the SMI Network Management Private Enterprise
       Code of the IANA-maintained Private Enterprise Numbers registry
       [SMI].

The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're
after the Operator-Id
I see what you want to do, but this is confusing. Also, do
we expect that all operators will have Private Enterprise Number?

Maybe you want to redefine this with something such as (I trust you on the right
wording)

    Operator PEN ID

       SMI Network Management Private Enterprise
       Code of the IANA-maintained Private Enterprise Numbers registry
       [SMI] for the operator running ... [actually running what, that's another
       required clarification in the draft] ... the respective interface on mobile access gateway?

In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by
"Operator PEN ID"

And also add a few sentences about
- whether all operators should or must now register new PENs for this spec.
   I checked for a couple of my local ISPs, and
not all of them had a PEN.
-if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
     if "SHOULD NOT", what should be default?
Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
You want to discuss with the authors of draft-liang-iana-pen-00, be in synch
with them.

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 May 2012 18:18:20 +0200

Does this change anything in draft-liang-iana-pen? I do not see the I-D
assuming the Enterprise is a Vendor - this is rather something that some
protocol documents using PENs did. 

Dan

From: Benoit Claise [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; Alexey Melnikov; Alan DeKok;
[email-masked]
Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs

Hi,

Since we're discussing PENs, I have another some more I would like to
see addressed in draft-liang-iana-pen-00.
    - What about unassigned PENs? See the part in red in my DISCUSS on
https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option
/ (on the telechat this Thursday)
    - PEN are not always representing manufacturer ID

   Vendor ID

The example in figure 1 speaks about: "Operator-Id:
provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while
you're
after the Operator-Id
I see what you want to do, but this is confusing. Also, do
we expect that all operators will have Private Enterprise Number?
 
Maybe you want to redefine this with something such as (I trust you on
the right
wording)
 
   Operator PEN ID
 
      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's
another 
      required clarification in the draft] ... the respective interface
on mobile access gateway?
 
In section 3.1.3 (and some other places such as IANA), change "Vendor
ID" by
"Operator PEN ID"
 
And also add a few sentences about
- whether all operators should or must now register new PENs for this
spec.
  I checked for a couple of my local ISPs, and
not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST
NOT/SHOULD NOT be used
    if "SHOULD NOT", what should be default?
Operator PEN ID=8653? (not even sure if this is the right thing to do)
or 0?
You want to discuss with the authors of draft-liang-iana-pen-00, be in
synch
with them.

Regards, Benoit.

Questions: 

 
Regards,
 
Dan

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2012 17:48:42 +0100

Hi Dan,

> is a non-negative integer, which I think assumes (0..2**32-1) range. 

Not necessarily, see below.
> - is there any place where a limit is defined? 

I believe that OID definition explicitly don't have an upper boundary on integers. I don't know if any IETF RFC specifies additional constraints.

> - should we advice new documents to cautiously define 32 bits (at least)

I think that would be a good idea, yes.

> - should we say something on this respect in draft-liang-iana-pen?

I think so.

> that assumed Vendor-Id is limited to three octets

Probably sufficient in medium term.

> - this will probably

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 May 2012 10:48:34 -0700

Hi -

> From: "Alexey Melnikov" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: <[email-masked]>; "Alan DeKok" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 23, 2012 9:48 AM
...
> I believe that OID definition explicitly don't have an upper boundary on integers.
> I don't know if any IETF RFC specifies additional constraints.

RFC 2578 (SMIv2) imposes additional constraints beyond those in ASN.1:

| 3.5.  OBJECT IDENTIFIER values
|
|    An OBJECT IDENTIFIER value is an ordered list of non-negative
|    numbers.  For the SMIv2, each number in the list is referred to as a
|    sub-identifier, there are at most 128 sub-identifiers in a value, and
|    each sub-identifier has a maximum value of 2^32-1 (4294967295
|    decimal).

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 May 2012 19:50:25 +0200

So this is an indirect answer. As PENs where originally designed to be
part of an OID, what results is that the upper limit is 2**32-1. Should
we say this explicitly in the future RFC? 

Dan

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2012 8:49 PM
> To: Alexey Melnikov; Romascanu, Dan (Dan)
> Cc: [email-masked]; Alan DeKok; [email-masked]
> > Cc: <[email-masked]>; "Alan DeKok"
> <[email-masked]>; <[email-masked]>
> > I believe that OID definition explicitly don't have an upper
boundary
> on integers.
> |    numbers.  For the SMIv2, each number in the list is referred to
as
> a

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 May 2012 11:00:39 -0700

Hi -

If those OIDs will ever need to be carried around by SNMP,
I think the answer is yes.  If they won't, then the question
remains open, I think.

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>; "Alan DeKok" <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 23, 2012 10:50 AM
Subject: RE: [OPS-AREA] assumption about number of octets encoding PENs

Dan

boundary
as

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 May 2012 20:42:27 +0200

Hi Dan,
>
> Does this change anything in draft-liang-iana-pen? I do not see the 
> I-D assuming the Enterprise is a Vendor
>
Correct. By "PEN are not always representing manufacturer ID", I wanted 
to express that draft-liang-iana-pen could also cover a section on "PEN 
applicability". After all, the title says "Private Enterprise Number 
(PEN) _practices_ and registration procedures"

Regards, Benoit.
>
> -- this is rather something that some protocol documents using PENs did.
>
> Dan
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Wednesday, May 23, 2012 6:18 PM
> *To:* Romascanu, Dan (Dan)
> *Cc:* [email-masked]; Alexey Melnikov; Alan DeKok; 
> [email-masked]
> *Subject:* Re: [OPS-AREA] assumption about number of octets encoding PENs
>
> Hi,
>
> https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ 
> (on the telechat this Thursday)
> [email-masked]  <mailto:[email-masked]>

---

From: David Harrington <[email-masked]>
Date: Wed, 23 May 2012 23:06:01 -0400

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-masked]
+1-603-828-1401

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

>PENs, isn¹t it? J
>Cc: [email-masked]; Alexey Melnikov; Alan DeKok; [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 May 2012 21:37:29 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>; "Mark Ellison" <[email-masked]>
> Cc: "Alan DeKok" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 23, 2012 8:06 PM
...
> But I don't have time right now to research that limit.

In ASN.1 the range for sub-oids isn't tied to the definition of the
INTEGER type.  In ASN.1 no upper bound is mandated for sub-ids, other
than in the first position and in the second position if the first is a 0 or 1,
due to the way BER mashes them together.

RFC 1157 also didn't specify limits for sub-identifiers.  Some early
SNMP implementers responded to this by writing their code to 
handle well-formed subidentifiers larger than 0xFFFFFFFF.
I ran into one very early SNMP implementation that had problems
handling subidenfiers greater than a measly 0xFFFF. 

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 May 2012 08:25:16 +0200

> handling subidenfiers greater than a measly 0xFFFF. 

And because of this, sub-identifiers were restricted to 32 bits in
SMIv2. In other words, assuming PENs can be larger than 32 bits will
surely not work with SNMP. And as has been pointed out before, the
SnmpEngineID format kind of restricts this further to 31 bits. I think
documenting that the number space is de facto limited to 32 bits is a
good idea. Are we anywhere close to this limit? If not, I suggest to
postpone the discussion what to do if we run out of numbers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: David Harrington <[email-masked]>
Date: Thu, 24 May 2012 02:47:53 -0400

Hi,

<dan>
Does this change anything in draft-liang-iana-pen? I do not see the I-D
assuming the Enterprise is a Vendor  this is rather something that some
protocol documents using PENs did.
<dan>

I think the usage of PENs to represent equipment vendors was described in
RFC1065 as one possible usage, not the only usage.
[Note that a PEN is an SMI Private Enterprise Code (RFC1065) used in the
MIB (RFC1066). It is not defined as part of SNMP (RFC1067).
SNMP (RFC1067) references MIB objects that incorporate the PEN
(sysObjectID).
It would help to keep that distinction between the SMI, the MIB, and
protocols.]

>From RCC1065:
"The private(4) subtree is used to identify objects defined
unilaterally. Administration of the private(4) subtree is delegated
by the IAB to the Assigned Numbers authority for the Internet.
Initially, this subtree has at least one child:

enterprises OBJECT IDENTIFIER ::= { private 1 }

The enterprises(1) subtree is used, among other things, to permit
parties providing networking subsystems to register models of their
products.

Upon receiving a subtree, the enterprise may, for example, define new
MIB objects in this subtree. In addition, it is strongly recommended
that the enterprise will also register its networking subsystems
under this subtree, in order to provide an unambiguous identification
mechanism for use in management protocols. For example, if the
"Flintstones, Inc." enterprise produced networking subsystems, then
they could request a node under the enterprises subtree from the
Assigned Numbers authority. Such a node might be numbered:

1.3.6.1.4.1.42

The "Flintstones, Inc." enterprise might then register their "Fred
Router" under the name of:

1.3.6.1.4.1.42.1.1
"

<background archeology>

RFC1065 specifies how the Internet subtree of the {iso org dod} subtree
should be organized:
"Under the iso(1) node, the ISO has designated one subtree for use by
   other (inter)national organizations, org(3).  Of the children nodes
   present, two have been assigned to the U.S. National Bureau of
   Standards.  One of these subtrees has been transferred by the NBS to
   the U.S. Department of Defense, dod(6).

   As of this writing, the DoD has not indicated how it will manage its
   subtree of OBJECT IDENTIFIERs.  This memo assumes that DoD will
   allocate a node to the Internet community, to be administered by the
   Internet Activities Board (IAB) as follows:

      internet    OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
   prefix:

      1.3.6.1.

   This memo, as an RFC approved by the IAB, now specifies the policy
   under which this subtree of OBJECT IDENTIFIERs is administered.
   Initially, four nodes are present:

      directory     OBJECT IDENTIFIER ::= { internet 1 }
      mgmt          OBJECT IDENTIFIER ::= { internet 2 }
      experimental   OBJECT IDENTIFIER ::= { internet 3 }
      private       OBJECT IDENTIFIER ::= { internet 4 }

"

RFC1065 provides the earliest definition of "private enterprise number" I
have found so far.
It was represented in ASN.1 for use across multiple standards
organizations, as described in RFC1052 and RFC1021
>From 1052:
"It is the intention of the IAB that the MIB definitions be applied   both
to the SNMP system in the short term and CMIS/CMIP for TCP/IP in
   the longer term.  The three working groups will have to coordinate
   their efforts carefully to achieve these objectives:

           1. Rapid convergence and definition for SNMP.

           2. Rapid convergence and definition for the TCP/IP MIB.

           3. Provision for transitioning from SNMP to CMIP/CMIS.

           4. Early demonstration of the CMIP/CMIS capability using the
              TCP/IP MIB."

So {private enterprises} (1.3.6.1.4.1) was developed as part of the SMI to
be usable by multiple protocols, not just SNMP.

<end history lesson ;-) >

On 5/23/12 12:18 PM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>assuming the Enterprise is a Vendor  this is rather something that some
>Since we're discussing PENs, I have another some more I would like to see
>addressed in draft-liang-iana-pen-00.
>-The term "vendor" is confusing    Vendor ID       The Vendor ID is the
>SMI Network Management Private Enterprise      Code of the
>IANA-maintained Private Enterprise Numbers registry      [SMI]. The
>example in figure 1 speaks about: "Operator-Id:
>provider2.example.com"Vendor Id, in the network management world is the
>manufacturer id, while you'reafter the Operator-IdI see what you want to
>do, but this is confusing. Also, dowe expect that all operators will have
>Private Enterprise Number? Maybe you want to redefine this with something
>such as (I trust you on the rightwording)    Operator PEN ID       SMI
>Network Management Private Enterprise      Code of the IANA-maintained
>Private Enterprise Numbers registry      [SMI] for the operator running
>... [actually running what, that's another       required clarification
>in the draft] ... the respective interface on mobile access gateway? In
>section 3.1.3 (and some other places such as IANA), change "Vendor ID"
>by"Operator PEN ID" And also add a few sentences about- whether all
>operators should or must now register new PENs for this spec.  I checked
>for a couple of my local ISPs, andnot all of them had a PEN.- if there is
>no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
>   if "SHOULD NOT", what should be default?Operator PEN ID=8653? (not
>even sure if this is the right thing to do) or 0?You want to discuss with
>the authors of draft-liang-iana-pen-00, be in synchwith them.Regards,
>Benoit.
>
>
>
>This is related to draft-liang-iana-pen-00
>anddraft-ietf-radext-radius-extensions-05.txt now in WGLC. The
>latestdefines new Vendor-Id fields in a way consistent with RFC 2865,
>whichused three octets. However, in draft-liang-iana-pen-00 we say that a
>PENis 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 probablyneed to be dealt by the RADEXT WG.  Regards, Dan
>_______________________________________________OPS-AREA mailing
>[email-masked]://www.ietf.org/mailman/listinfo/ops-area
>
>

---

From: David Harrington <[email-masked]>
Date: Thu, 24 May 2012 03:16:51 -0400

Currently at 39965.

On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

> I think

---

From: David Harrington <[email-masked]>
Date: Thu, 24 May 2012 03:30:44 -0400

On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>surely not work with SNMP.
>/js

Notes:
1) sysObjectID includes SMI PENs, and many SNMP network monitoring systems
use sysObjectID to identify devices, as suggested by RFC1065.
Auto-discovery is especially reliant on these values.
2) syslog (RFC5424) uses the SMI PEN registry.
3) ipfix (RFC5101) uses the SMI PEN registry.
4) sipclf IDs use the SMI PEN registry.
5) middisc ID does not use the SMI PEN registry because it is too large
for its intended use, and requests a smaller (8-bit) vendor code registry.

I am not sure how these uses would be impacted by a PEN larger than 32
bits.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 May 2012 09:53:48 +0200

It looks that we are far away from the 2**32-1 or 2**31-1 limit. 

My opinion is that we can postpone the discussion about how to extend
the space beyond 31 or 32 bits for the moment in time when we get
closer. 

In the meantime I would suggest that we document in draft-liang: 

1. The assumed limit and its reasons
2. The fact that although one of the popular uses is SMI, the PENs are
designed to be used by multiple protocols and DMLs
3. The recommendation for future protocols to allocate at least 31 bits
in fields derived from PEN
4. That Enterprise is not always Vendor

Regards,

Dan

> From: David Harrington [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 10:17 AM
> To: Juergen Schoenwaelder; Randy Presuhn
> Cc: Romascanu, Dan (Dan); Mark Ellison; [email-masked]; ops-
> [email-masked]; Alan DeKok

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 May 2012 10:19:29 +0200

> in fields derived from PEN

My preference would be to suggest that future protocols allocate at
least 32 bits. The SnmpEngineID use case is kind of wired and should
be mentioned in the document but perhaps a solution is simply to
update the SnmpEngineID TC so that 32 bit enterprise IDs can be used
should we ever get close to 2^31 bits. This gives us 2^31 more PENs
should we need them.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 May 2012 11:39:54 +0200

Yes. And worse. This discussion started from the fact that RADIUS (RFC
2865) assumes 24 bits, and draft-radext-radius-extensions  prepared to
do the same. Actually Vendor-ID field in the Vendor-Specific attribute
in RFC 2865 is defined like this: 

>     The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order. 

So I there may be a way in the protocol to extend from 24 to 32 bits,
but implementations need to change. Beyond 32 bits the problem is the
same as with the other protocols listed below, but that moment in time
seems very remote. 

Regards,

Dan

> Sent: Thursday, May 24, 2012 10:31 AM

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 May 2012 17:13:02 +0200

> is a non-negative integer, which I think assumes (0..2**32-1) range. 

  I'm the author of draft-ietf-radext-radius-extensions-05.txt

> Questions:

  I have little input to those questions.

> need to be dealt by the RADEXT WG. 

  I'm aware of a number of widely-used RADIUS implementations which have
a 16-bit limit on PECs.  These implementations won't be able to handle a
larger PEC.  They require substantial re-engineering of their internals.

  The current maximum PEN is ~40K.  At the current rate, we have a few
years left before 2^16 is reached.  We should recommend that
implementations be fixed before then.

  My $0.02 is that we should require protocols to support 32-bit PENs.
That should be enough for quite a while.

  Alan DeKok.