headers
Romascanu, Dan (Dan | 23 May 2012 17:05
Favicon

assumption about number of octets encoding PENs

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
Permalink | Reply |
headers
Mark Ellison | 23 May 2012 17:13
Picon

Re: 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area





_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
Romascanu, Dan (Dan | 23 May 2012 17:15
Favicon

Re: assumption about number of octets encoding PENs

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

 

 

From: mark <at> ellisonsoftware.com [mailto:mark <at> ellisonsoftware.com] On Behalf Of Mark Ellison
Sent: Wednesday, May 23, 2012 6:14 PM
To: Romascanu, Dan (Dan)
Cc: ops-area <at> ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang <at> 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 <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area



 

 

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
David Harrington | 24 May 2012 05:06
Picon

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)
Ietfdbh <at> comcast.net
+1-603-828-1401

On 5/23/12 11:15 AM, "Romascanu, Dan (Dan)" <dromasca <at> avaya.com> wrote:

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

Re: assumption about number of octets encoding PENs

Hi -

> From: "David Harrington" <ietfdbh <at> comcast.net>
> To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Mark Ellison" <ellison <at> ieee.org>
> Cc: "Alan DeKok" <aland <at> deployingradius.com>; <ops-area <at> ietf.org>; <pearl.liang <at> icann.org>
> Sent: Wednesday, May 23, 2012 8:06 PM
> Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
...
> 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.

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
Permalink | Reply |
headers
Juergen Schoenwaelder | 24 May 2012 08:25
Picon
Favicon

Re: assumption about number of octets encoding PENs

On Wed, May 23, 2012 at 09:37:29PM -0700, Randy Presuhn wrote:
> Hi -
> 
> > From: "David Harrington" <ietfdbh <at> comcast.net>
> > To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Mark Ellison" <ellison <at> ieee.org>
> > Cc: "Alan DeKok" <aland <at> deployingradius.com>; <ops-area <at> ietf.org>; <pearl.liang <at> icann.org>
> > Sent: Wednesday, May 23, 2012 8:06 PM
> > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
> ...
> > 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.
> 
> 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. 

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/>
Permalink | Reply |
headers
David Harrington | 24 May 2012 09:16
Picon

Re: assumption about number of octets encoding PENs

Currently at 39965.

--
David Harrington
Internet Engineering Task Force (IETF)
Ietfdbh <at> comcast.net
+1-603-828-1401

On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
<j.schoenwaelder <at> jacobs-university.de> wrote:

> 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/>
Permalink | Reply |
headers
Romascanu, Dan (Dan | 24 May 2012 09:53
Favicon

Re: assumption about number of octets encoding PENs

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

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh <at> comcast.net]
> Sent: Thursday, May 24, 2012 10:17 AM
> To: Juergen Schoenwaelder; Randy Presuhn
> Cc: Romascanu, Dan (Dan); Mark Ellison; pearl.liang <at> icann.org; ops-
> area <at> ietf.org; Alan DeKok
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> Currently at 39965.
> 
> --
> David Harrington
> Internet Engineering Task Force (IETF)
> Ietfdbh <at> comcast.net
> +1-603-828-1401
> 
> 
> 
> 
> 
> On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
> <j.schoenwaelder <at> jacobs-university.de> wrote:
> 
> > 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/>
>
Permalink | Reply |
headers
Juergen Schoenwaelder | 24 May 2012 10:19
Picon
Favicon

Re: assumption about number of octets encoding PENs

On Thu, May 24, 2012 at 09:53:48AM +0200, Romascanu, Dan (Dan) wrote:
> 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

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.

> 4. That Enterprise is not always Vendor

/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/>
Permalink | Reply |
headers
David Harrington | 24 May 2012 09:30
Picon

Re: assumption about number of octets encoding PENs


On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
<j.schoenwaelder <at> jacobs-university.de> wrote:

>
>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.
>/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.

--
David Harrington
Internet Engineering Task Force (IETF)
Ietfdbh <at> comcast.net
+1-603-828-1401

>
Permalink | Reply |
headers
Romascanu, Dan (Dan | 24 May 2012 11:39
Favicon

Re: assumption about number of octets encoding PENs

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

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh <at> comcast.net]
> Sent: Thursday, May 24, 2012 10:31 AM
> To: Juergen Schoenwaelder; Randy Presuhn
> Cc: Romascanu, Dan (Dan); Mark Ellison; pearl.liang <at> icann.org; ops-
> area <at> ietf.org; Alan DeKok
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> 
> 
> 
> 
> On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
> <j.schoenwaelder <at> jacobs-university.de> wrote:
> 
> >
> >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.
> >/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.
> 
> 
> --
> David Harrington
> Internet Engineering Task Force (IETF)
> Ietfdbh <at> comcast.net
> +1-603-828-1401
> 
> 
> 
> 
> 
> >
>
Permalink | Reply |
headers
Benoit Claise | 23 May 2012 17:18
Picon
Favicon

Re: 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

-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.

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 <at> ietf.org https://www.ietf.org/mailman/listinfo/ops-area 

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
Romascanu, Dan (Dan | 23 May 2012 18:18
Favicon

Re: assumption about number of octets encoding PENs

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:bclaise <at> cisco.com]
Sent: Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan (Dan)
Cc: ops-area <at> ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang <at> icann.org
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

-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.


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 <at> ietf.org

https://www.ietf.org/mailman/listinfo/ops-area

 

 

 

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
Benoit Claise | 23 May 2012 20:42
Picon
Favicon

Re: assumption about number of octets encoding PENs

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:bclaise <at> cisco.com]
Sent: Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan (Dan)
Cc: ops-area <at> ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang <at> icann.org
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

-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.


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 <at> ietf.org

https://www.ietf.org/mailman/listinfo/ops-area

 

 

 


_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
David Harrington | 24 May 2012 08:47
Picon

Re: assumption about number of octets encoding PENs

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 ;-) >

--
David Harrington
Internet Engineering Task Force (IETF)
Ietfdbh <at> comcast.net
+1-603-828-1401

On 5/23/12 12:18 PM, "Romascanu, Dan (Dan)" <dromasca <at> avaya.com> wrote:

>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:bclaise <at> cisco.com]
>Sent: Wednesday, May 23, 2012 6:18 PM
>To: Romascanu, Dan (Dan)
>Cc: ops-area <at> ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang <at> icann.org
>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
>-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
>listOPS-AREA <at> ietf.orghttps://www.ietf.org/mailman/listinfo/ops-area
>
>
>_______________________________________________
>OPS-AREA mailing list
>OPS-AREA <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ops-area
Permalink | Reply |
headers
Alexey Melnikov | 23 May 2012 18:48
Favicon

Re: assumption about number of octets encoding PENs

Hi Dan,

On 23 May 2012, at 16:05, "Romascanu, Dan (Dan)" <dromasca <at> 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. 

Not necessarily, see below.
> 
> Questions: 
> 
> - 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)
> for Vendor-Id fields? 

I think that would be a good idea, yes.

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

I think so.

> What will happen to RFC 2865 implementations (and maybe other protocols)
> that assumed Vendor-Id is limited to three octets

Probably sufficient in medium term.

> - this will probably
> need to be dealt by the RADEXT WG. 
> 
> Regards,
> 
> Dan
Permalink | Reply |
headers
Randy Presuhn | 23 May 2012 19:48
Picon

Re: assumption about number of octets encoding PENs

Hi -

> From: "Alexey Melnikov" <alexey.melnikov <at> isode.com>
> To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>
> Cc: <pearl.liang <at> icann.org>; "Alan DeKok" <aland <at> deployingradius.com>; <ops-area <at> ietf.org>
> Sent: Wednesday, May 23, 2012 9:48 AM
> Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
...
> 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
Permalink | Reply |
headers
Romascanu, Dan (Dan | 23 May 2012 19:50
Favicon

Re: assumption about number of octets encoding PENs

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:randy_presuhn <at> mindspring.com]
> Sent: Wednesday, May 23, 2012 8:49 PM
> To: Alexey Melnikov; Romascanu, Dan (Dan)
> Cc: pearl.liang <at> icann.org; Alan DeKok; ops-area <at> ietf.org
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> Hi -
> 
> > From: "Alexey Melnikov" <alexey.melnikov <at> isode.com>
> > To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>
> > Cc: <pearl.liang <at> icann.org>; "Alan DeKok"
> <aland <at> deployingradius.com>; <ops-area <at> ietf.org>
> > Sent: Wednesday, May 23, 2012 9:48 AM
> > Subject: Re: [OPS-AREA] assumption about number of octets encoding
> PENs
> ...
> > 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
Permalink | Reply |
headers
Randy Presuhn | 23 May 2012 20:00
Picon

Re: assumption about number of octets encoding PENs

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)" <dromasca <at> avaya.com>
To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "Alexey Melnikov" <alexey.melnikov <at> isode.com>
Cc: <pearl.liang <at> icann.org>; "Alan DeKok" <aland <at> deployingradius.com>; <ops-area <at> ietf.org>
Sent: Wednesday, May 23, 2012 10:50 AM
Subject: RE: [OPS-AREA] assumption about number of octets encoding PENs

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:randy_presuhn <at> mindspring.com]
> Sent: Wednesday, May 23, 2012 8:49 PM
> To: Alexey Melnikov; Romascanu, Dan (Dan)
> Cc: pearl.liang <at> icann.org; Alan DeKok; ops-area <at> ietf.org
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> Hi -
> 
> > From: "Alexey Melnikov" <alexey.melnikov <at> isode.com>
> > To: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>
> > Cc: <pearl.liang <at> icann.org>; "Alan DeKok"
> <aland <at> deployingradius.com>; <ops-area <at> ietf.org>
> > Sent: Wednesday, May 23, 2012 9:48 AM
> > Subject: Re: [OPS-AREA] assumption about number of octets encoding
> PENs
> ...
> > 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
Permalink | Reply |
headers
Alan DeKok | 23 May 2012 17:13
Favicon
Gravatar

Re: assumption about number of octets encoding PENs

Romascanu, Dan (Dan) 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. 

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

> Questions:

  I have little input to those questions.

> 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. 

  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.
Permalink | Reply |

Gmane