Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] Re: OID arcs & procedures


We are in violent agreement here.
I propose to co-sponsor this as an Exec item at the July Plenary.
I would like to see the proposed text live in back of the LMSC Operating 
Rules as a "Procedure" with a note to the following effect:
         (This material is published here on a temporary basis until the 
formal adoption of material of equivalent scope in IEEE 802. When such 
material is approved this procedure may be deleted without ballot.)

We will probably need to also propose a "transition plan" that acknowledges 
that we are scattered at the moment and gives "guidance" on how to 
transition to the "universal plan". I would expect such a plan should 
indicate the appropriateness of an Informative Annex containing: (a) 
obsolete root information and (b) discussion that the only difference is 
the "it is only a matter of whether you are going from London to Edinburgh 
via Manchester or York" issue.


At 09:01 AM 4/11/02 +0100, Tony Jeffree wrote:

>Geoff -
>At 17:42 10/04/2002 -0700, Geoff Thompson wrote:
>>It seems to me that this should go into the next revision of the 802 
>>Overview and Architecture with appropriate pointers to web pages where 
>>the most up to date table can be found. Rationale being that this is 
>>technical material.
>It's a fair point - section 9 of the current O&A seems like a reasonable 
>>In addition, it would seem that adherence to this procedure would need to 
>>added to the 802 Five Criteria.
>If it was included in the O&A, then it would already be covered by the 6.2 
>"Compatibility" criterion in the existing operating rules.
>>I believe that the current situation, due largely to obscurity of this 
>>issue and lack of communication, is that 802.3 cleaned up its situation 
>>of mixed use but became consistent in the wrong direction.
>>It should be further noted in your treatise that it is perfectly 
>>acceptable (and much more desirable than actually changing things) to 
>>have multiple root paths into the "pile of leaves", that is:
>>me sTransmittedOK(2)};
>>gets you to exactly the same uniquely defined point as:
>>         {iso(1) std(0) iso8802(8802) 
>> csma(3)csmacdmgt(30)attribute(7)framesTransmittedOK(2)};
>>it is only a matter of whether you are going from London to Edinburgh via 
>>Manchester or York.
>Absolutely - that should certainly be pointed out.
>>Is it your intention to act on this via a e-mail ballot of the SEC or put 
>>it on the agenda for action in July?
>What I would like to see is a formal acceptance by the SEC that this is 
>the right way to go with regard to doing future OID allocations, so that, 
>in advance of it reaching the pages of the O&A (~ 1-2+ years hence) we 
>have an agreed position as to what should be done in the interim.
>I would be happy to do it either way - as an SEC Email ballot or as an 
>agenda item for July.
>>At 04:51 PM 4/10/02 +0100, Tony Jeffree wrote:
>>>The discussion of .15's need for OID registration arcs (see below) has 
>>>reminded me that we have yet to take a position regarding the suggested 
>>>procedures for future OID arc registrations as documented in my paper of 
>>>March 2001 (attached to this email). As I have had no negative  feedback 
>>>on this document, I propose that we adopt the suggested procedure as 
>>>documented, and would like to make an SEC motion to that effect.
>>>At 21:26 09/04/2002 +0100, you wrote:
>>>>Geoff -
>>>>As it happens, I believe I have the most recent paper on this subject - 
>>>>you may recall that I raised the issue of a generalized scheme in the 
>>>>SEC some while back.  Anyhow, I generated the attached document as a 
>>>>result. I believe that using the 8802 arc is the "no brainer" route for 
>>>>802.15.  However, one aspect of what they are asking for concerns me - 
>>>>namely the potential that "...others will want to "register" additional 
>>>>optional schemes that will require OIDs ". I would like to understand 
>>>>better how 802.15 envisage this working - is this a small number of 
>>>>additional arcs that would be vetted and approved for inclusion in the 
>>>>standard, or is this essentially a means whereby proprietary extensions 
>>>>to the standard will be defined? In other words, is this going to 
>>>>become a registration activity that the RAC should be concerned about 
>>>>with a view to the RA administering it?
>>>>At 11:35 09/04/2002 -0700, Geoff Thompson wrote:
>>>>>In 802.3 there are a couple of roots used in 802.3 that I know of.
>>>>>They are:
>>>>>         {iso(1)member-body(2)us(840)802dot3(10006)... (Current)
>>>>>         {iso(1) std(0) iso8802(8802) csma(3)... (Obsolete)
>>>>>In addition we reference 802.1F which has (at least) the following root
>>>>>         {iso(1)member-body(2)us(840)ieee802dot1partF(10011)
>>>>>I believe that there is a system is place for arc assignments within 
>>>>>802. The keeper of the registry for that is Hal Keen. Tony can get you 
>>>>>in touch with him.
>>>>>While it is fine for the RAC to "do the right thing" in terms of new 
>>>>>assignments, this is one of those times when you are supposed to be 
>>>>>VERY careful about changing things. What we don't particularly want is 
>>>>>every standard to have a different scheme just because it started in a 
>>>>>different year.
>>>>>At 01:08 PM 4/9/02 -0400, wrote:
>>>>>>Hello All,
>>>>>>As you may know, in 1997 the IEEE RAC secured an ICD (0111) from the
>>>>>>British Standards Institute.  This ICD allows the RAC to assign an OID as
>>>>>>deemed appropriate.
>>>>>>Recently, I was contacted by P802.15.3.  I have included the message 
>>>>>>They are in the last stages of standards development and require an OID
>>>>>>(for the unique identification of a security suite) for the standard.  At
>>>>>>least one OID would be included in the standard with the possibility 
>>>>>>of an
>>>>>>additional optional OID.  In addition, after the standard is published,
>>>>>>there is a real possibility that others will want to "register" 
>>>>>>optional schemes that will require OIDs.
>>>>>>Here is the issue:  the WG is at the point of getting the node from IANA
>>>>>>and working out the long-term operational issues later.  Personally, 
>>>>>>this standard has a registration component, I would prefer to see the 
>>>>>>assigned from the existing ICD assigned to the IEEE, (via the 
>>>>>>RAC).  There
>>>>>>seem to be a plethora of OID assignments around with no real central
>>>>>>understanding of how many are actually affiliated with some IEEE 
>>>>>>Here is the question: what would be the sub-node assignment?  The ICD is
>>>>>>"iso (1) iso-identified-organization (3) ieee (0111)"
>>>>>>The WG needs to know what would come next in order to help their decision
>>>>>>making process.  Unfortunately, they are very short on time and need to
>>>>>>make their decision before the end of the week, (hence the urgent email).
>>>>>>If I have not made any sense, my apologies in advance.  Please advise 
>>>>>>and I
>>>>>>will do my best to make this more clear.  Regardless,  any assistance you
>>>>>>can offer is much appreciated.
>>>>>>Best Regards,
>>>>>>Forwarded Message:
>>>>>>----- Forwarded by Anita Ricketts/STDS/STAFF/US/IEEE on 04/09/2002 
>>>>>>01:04 PM
>>>>> >
>>>>>                     "James D.
>>>>>                     Allen"               To: <>, 
>>>>> <>
>>>>>>                     <james.d.allen       cc: <>, 
>>>>>> "Daniel Bailey" <>,
>>>>>>           >            <>, "John 
>>>>>> Barr" <>, "Robert
>>>>>>                                           Heile" <>, 
>>>>>> "Rasor Gregg-ECPP04"
>>>>>>                     04/04/2002            <>
>>>>> >
>>>>>                     10:17 AM             Subject:
>>>>>                     Please respond
>>>>>                     to
>>>>>                     james.d.allen
>>>>>>Hi Anita
>>>>>>I understand you are in charge of the IEEE Registration Authority.
>>>>>>I am the Vice chair of 802.15 and 802.15.3 and we have a few 
>>>>>>questions we'd
>>>>>>like to ask.
>>>>>>In our draft standard (due for Sponsor ballot in July), we have the 
>>>>>>to use optional security suites.  The architecture of the draft 
>>>>>>standard is
>>>>>>such that each suite has it's own identification number (called an Object
>>>>>>Identifiers or OID).  We have put several reserved, but unspecified, OIDs
>>>>>>into the standard as place holders.
>>>>>>1- Is there already a numbering system for security options anywhere else
>>>>>>the IEEE that we could use as a reference to this standard?
>>>>>>2- If we asked the IEEE to maintain the registry of suites, is that
>>>>>>possible, how would we do it, who would we work with, and what is the 
>>>>>>3- How is it done now and if it is, can you point us to a application and
>>>>>>Thanks!  We are trying to get all of this text for the current letter
>>>>>>re-circulation done before the 12th so your rapid response would be very
>>>>>>Jim Allen
>>>>>>VP Research & Engineering
>>>>>>Appairent Technologies
>>>>>>150 Lucius Gordon Dr.
>>>>>>Rochester, NY  14586
>>>>>>Anita C. Ricketts
>>>>>>Manager, Business Programs and Services
>>>>>>IEEE Standards
>>>>>>445 Hoes Lane
>>>>>>Piscataway, NJ 08854-1331
>>>>>>+1 732 562 3847
>>>>>>+1 732 562 1571 (Fax)