Subject: [OPS-AREA] Enterprise codes - three or four octets

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 25 Jan 2007 01:56:39 +0200

I apologize for the cross-posting. I am not sure if this is a problem,
but I would like to get some advice. I see in different documents two
different ways of coding the SMI Private Enterprise Code. As far as I
can understand these numbers should be coded as 32-bit, or at least I
could not find any reason to limit them in any document that mentions
them starting with RFC 1700. However, in other documents four octets are
allocated, but the most significant octet is specified to be zero - see
RFC 2865, or the more recent draft-cam-winget-eap-fast which is on the
agenda of the IESG telechat tomorrow. An interesting case is
draft-ietf-capwap-protocol-specification-04 which uses three octets in
one place and four octets in four other places of the same document. 

I do not know where the limitation to three meaningful octets started to
be applied and why. Maybe we should not care, because 24 bits are enough
for more than 8 million enterprises, and this may be enough for the
future at sight (28k were allocated up to now). I would however invite
opinions, especially if somebody believes that there is a problem here
and any actions or guidance from the area is needed. 

Dan

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 25 Jan 2007 01:03:59 +0100

Since, (as you note) there is no problem in the forseeable future,
and since some protocols have already defined fields that only
handle a 24-bit (i.e. 3 octet) value, maybe we should add some
comment in the RFC-Editor mainatined registry that if they ever get
to a value close to 25 bits, that we (IETF) need to be aware that
some (older) protocols have limited fields of up to 24 bits.

Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: woensdag 24 januari 2007 15:57
> To: OPS Area
> Cc: [email-masked]; MIB Doctors (E-mail)
> Subject: [AAA-DOCTORS] Enterprise codes - three or four octets
> 
> I apologize for the cross-posting. I am not sure if this is a 
> problem, but I would like to get some advice. I see in 
> different documents two different ways of coding the SMI 
> Private Enterprise Code. As far as I can understand these 
> numbers should be coded as 32-bit, or at least I could not 
> find any reason to limit them in any document that mentions 
> them starting with RFC 1700. However, in other documents four 
> octets are allocated, but the most significant octet is 
> specified to be zero - see RFC 2865, or the more recent 
> draft-cam-winget-eap-fast which is on the agenda of the IESG 
> telechat tomorrow. An interesting case is
> draft-ietf-capwap-protocol-specification-04 which uses three 
> octets in one place and four octets in four other places of 
> the same document. 
> 
> I do not know where the limitation to three meaningful octets 
> started to be applied and why. Maybe we should not care, 
> because 24 bits are enough for more than 8 million 
> enterprises, and this may be enough for the future at sight 
> (28k were allocated up to now). I would however invite 
> opinions, especially if somebody believes that there is a 
> problem here and any actions or guidance from the area is needed. 
> 
> Dan
> 
> 
>  
> 
> 
> AAA-DOCTORS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/aaa-doctors
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 25 Jan 2007 02:32:56 +0200

Bert,

The fact that you mentioned '(older) protocols' means that your opinion
is that we should advise that new IETF documents use only the 32-bit
values? There is no such  guidance now and people rather use existing
protocols as reference, so we may need to issue such a guidance. 

Dan

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 2:04 AM
> To: Romascanu, Dan (Dan); OPS Area
> Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets
> 
> Since, (as you note) there is no problem in the forseeable 
> future, and since some protocols have already defined fields 
> that only handle a 24-bit (i.e. 3 octet) value, maybe we 
> should add some comment in the RFC-Editor mainatined registry 
> that if they ever get to a value close to 25 bits, that we 
> (IETF) need to be aware that some (older) protocols have 
> limited fields of up to 24 bits.
> 
> Bert 
> 
> > them starting with RFC 1700. However, in other documents 
> four octets 
> > are allocated, but the most significant octet is specified 
> to be zero 
> > - see RFC 2865, or the more recent 
> draft-cam-winget-eap-fast which is 
> > on the agenda of the IESG telechat tomorrow. An interesting case is
> > I do not know where the limitation to three meaningful 
> octets started 
> > to be applied and why. Maybe we should not care, because 24 
> bits are 
> > enough for more than 8 million enterprises, and this may be 
> enough for 
> > the future at sight (28k were allocated up to now). I would however 
> > invite opinions, especially if somebody believes that there is a

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 25 Jan 2007 01:46:21 +0100

Mmm... no, my use of "older protocols" would be whatever is
old at the time we get close to the limit. I think I
personally would be ok to limit this Enterprise ID to 24 bits.
I guess you would need IETF consensus on that before you
can actually make that statement

Bert 

> Sent: woensdag 24 januari 2007 16:33
> To: Wijnen, Bert (Bert); OPS Area
> The fact that you mentioned '(older) protocols' means that 
> your opinion is that we should advise that new IETF documents 
> use only the 32-bit values? There is no such  guidance now 
> and people rather use existing protocols as reference, so we 
> may need to issue such a guidance. 
> 
> Dan
> 
> 
>  
>  
> 
> future, and 
> > since some protocols have already defined fields that only handle a 
> > 24-bit (i.e. 3 octet) value, maybe we should add some 
> comment in the 
> > RFC-Editor mainatined registry that if they ever get to a 
> value close 
> > to 25 bits, that we
> > (IETF) need to be aware that some (older) protocols have limited 
> > fields of up to 24 bits.
> > 
> > Bert
> >

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Jan 2007 17:40:40 -0800 (PST)

I would also mention that there has been talk at various points about 
using 2 octet values.  That would seem to be inadvisable -- and it might 
make sense to issue a recommendation describing a recommendation (e.g. 
allocate 4 octets).

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Jan 2007 20:50:04 -0500

Hi,

According to www.iana.org, the defining document for ENTERPRISE is
RFC2578. I believe this is the updated defining document; the original
appears to be RFC1065 (Structure and Identification of Management
Information for TCP/IP-based internets). 

Each enterprise is assigned a subtree:
"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."

A node is represented in SMI as a sub-identifier.
According to RFC2578, a sub-identifier has a value from 0..2^32-1
(4294967295 decimal). 

This would argue for a 32-bit field size, wouldn't it?

dbh

> Sent: Wednesday, January 24, 2007 7:33 PM
> Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - 
> three or fouroctets
> 
> Bert,
> 
> your opinion

> MIB-DOCTORS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 24 Jan 2007 23:40:35 -0500

Hi,

Dave's analysis certainly seems correct to me.

Any protocols that limit enterprise values to something less than a
sub-id would seem to be flawed (albeit with low risk of causing
problems per Dan's observations on usage to date...of course, with IPv6
and the changing definition of enterprise in the real world, who knows!
:).

Cheers,
BobN 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, January 24, 2007 8:50 PM
To: 'Romascanu, Dan (Dan)'; 'Wijnen, Bert (Bert)'; 'OPS Area'
Cc: [email-masked]; 'MIB Doctors (E-mail)'
Subject: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise
codes -three or fouroctets

Hi,

dbh

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 24 Jan 2007 22:51:19 -0800 (PST)

HI,

I was behind using the approach of creating a 32-bit number in
capwap that is EnterpriseId*256 + value. (That is, using only
the lower 24bits and effectively limiting the range to 24 bits.)
I cloned what was done in RFC 3411 for the definition of
SnmpSecurityModel which is used as the value of the
msgSecurityModel field (which is only 31 bits) and
defined in RFC 3412.

I believe that effectively limiting EnterpriseIDs to 24 bits
is reasonable based on the allocation of OUIs, on which
I did a pretty extensive analysis of the
assignements of values values (which have been in
existance before enterpriseIDs were created). I came to the
conclusion that the allocated OUIs were close enough to 16 bits
of allocation to make me uncomfortable with using only 16 bits
of the EnterpriseID, but quite comfortable with using 24 bits.

Please send me email if you have any additional questions!

Regards,
/david t. perkins

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 25 Jan 2007 18:53:04 +0100

Yes, BUT 
- we as SNMP/SMI experts have violated the rule (as Dave Perkins 
  also stated). I know we carefully investigated this at the
  time, and we also made a note of it in our DESCRIPTION clause
  in the TC where we did the violation. Nevertheless, we DID
  violate the approved definition of Enterprise OID.
- we are aware that others are doing (possibly have done)  this
  too. 
- According to Dan and Bernard, there are other wanting to violate,
  some even seem to want to limit it to 2 octets.

So we better:
- recognize/document what we have done (violated the limit)
- document that others are doing so too,
- specify what we all agree (consensus) to be a acceptable
  limit (3 octets)
- document this with IANA so it is public.

Possibly we need a short draft for that, although I would think
that if we as MIB doctors can get agreement and if Dan runs a
sortf of IETF Last Call; then possibly it can just be some text at
the top of the enterprise OID registration directory at iana.

Bert

> Sent: woensdag 24 januari 2007 17:50
> To: 'Romascanu, Dan (Dan)'; Wijnen, Bert (Bert); 'OPS Area'
> Subject: RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes 
> - three or fouroctets
> 
> Hi,
> 
> According to www.iana.org, the defining document for 
> ENTERPRISE is RFC2578. I believe this is the updated defining 
> document; the original appears to be RFC1065 (Structure and 
> Identification of Management Information for TCP/IP-based internets). 
> 
>    "Flintstones, Inc."  enterprise produced networking 
> subsystems, then
> three or 
> > fouroctets
> > The fact that you mentioned '(older) protocols' means that your 
> > opinion is that we should advise that new IETF documents 
> use only the 
> > 32-bit values? There is no such  guidance now and people rather use
> existing
> > > to a value close to 25 bits, that we