RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets

["Wijnen, Bert \(Bert\)" <[e-mail]>]

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

> -----Original Message-----
> From: David B Harrington [mailto:[e-mail]] 
> Sent: woensdag 24 januari 2007 17:50
> To: 'Romascanu, Dan (Dan)'; Wijnen, Bert (Bert); 'OPS Area'
> Cc: [e-mail]; 'MIB Doctors (E-mail)'
> 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). 
> 
> 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
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> > Sent: Wednesday, January 24, 2007 7:33 PM
> > To: Wijnen, Bert (Bert); OPS Area
> > Cc: [e-mail]; MIB Doctors (E-mail)
> > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - 
> three or 
> > fouroctets
> > 
> > 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
> > 
> > 
> >  
> >  
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> > > Sent: Thursday, January 25, 2007 2:04 AM
> > > To: Romascanu, Dan (Dan); OPS Area
> > > Cc: [e-mail]; MIB Doctors (E-mail)
> > > 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
> > > 
> > > > -----Original Message-----
> > > > From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> > > > Sent: woensdag 24 januari 2007 15:57
> > > > To: OPS Area
> > > > Cc: [e-mail]; 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
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors
> > > > 
> > > 
> > 
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mib-doctors
> > 
> 
> 
> 

_______________________________________________
AAA-DOCTORS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/aaa-doctors