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

[David Harrington <[e-mail]>]

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)
[e-mail]
[phone]





On 5/23/12 12:18 PM, "Romascanu, Dan (Dan)" <[e-mail]> 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:[e-mail]]
>Sent: Wednesday, May 23, 2012 6:18 PM
>To: Romascanu, Dan (Dan)
>Cc: [e-mail]; Alexey Melnikov; Alan DeKok; [e-mail]
>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
>[e-mail]://www.ietf.org/mailman/listinfo/ops-area
>
>
>_______________________________________________
>OPS-AREA mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ops-area