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

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




Ack.

 -Bob
 

-----Original Message-----
From: Tony Jeffree [mailto:tony@jeffree.co.uk] 
Sent: Thursday, April 11, 2002 11:35 AM
To: Geoff Thompson
Cc: Geoff Thompson; stds-802-sec@ieee.org; a.ricketts@ieee.org;
c.k.berger@ieee.org
Subject: Re: [802SEC] Re: OID arcs & procedures



Geoff -

Sounds good to me.  Bob (O'Hara) - looks like this should go on the agenda 
for July.

Regards,
Tony

At 11:11 11/04/2002 -0700, Geoff Thompson wrote:
>Tony-
>
>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.
>
>Geoff
>
>At 09:01 AM 4/11/02 +0100, Tony Jeffree wrote:
>
>>Geoff -
>>
>>
>>At 17:42 10/04/2002 -0700, Geoff Thompson wrote:
>>>Tony-
>>>
>>>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 
>>precedent.
>>
>>
>>>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.
>>
>>True.
>>
>>
>>>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:
>>>{iso(1)member-body(2)us(840)ieee802dot3(10006)csmacdmgt(30)attribut 
>>>{iso(1)member-body(2)us(840)ieee802dot3(10006)csmacdmgt(30)attribute(7)fr

>>>a 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.
>>
>>Regards,
>>Tony
>>
>>
>>>Geoff
>>>
>>>
>>>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.
>>>>
>>>>Regards,
>>>>Tony
>>>>
>>>>
>>>>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?
>>>>>
>>>>>Regards,
>>>>>Tony
>>>>>
>>>>>At 11:35 09/04/2002 -0700, Geoff Thompson wrote:
>>>>>
>>>>>>Anita-
>>>>>>
>>>>>>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.
>>>>>>
>>>>>>Geoff
>>>>>>
>>>>>>At 01:08 PM 4/9/02 -0400, a.ricketts@ieee.org 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 
>>>>>>>below.
>>>>>>>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" 
>>>>>>>additional
>>>>>>>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, 
>>>>>>>since
>>>>>>>this standard has a registration component, I would prefer to see 
>>>>>>>the node
>>>>>>>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 
>>>>>>>activity.
>>>>>>>
>>>>>>>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,
>>>>>>>Anita
>>>>>>>
>>>>>>>Forwarded Message:
>>>>>>>----- Forwarded by Anita Ricketts/STDS/STAFF/US/IEEE on 04/09/2002 
>>>>>>>01:04 PM
>>>>>>>-----
>>>>>> >
>>>>>>                     "James D.
>>>>>>                     Allen"               To: <a.ricketts@ieee.org>, 
>>>>>> <y.hosang@ieee.com>
>>>>>>>                     <james.d.allen       cc: <gilb@appairent.com>, 
>>>>>>> "Daniel Bailey" <DBailey@ntru.com>,
>>>>>>>                     @ieee.org>            <asinger@ntru.com>, "John 
>>>>>>> Barr" <John.Barr@motorola.com>, "Robert
>>>>>>>                                           Heile" <bheile@ieee.org>, 
>>>>>>> "Rasor Gregg-ECPP04"
>>>>>>>                     04/04/2002            <Gregg.Rasor@motorola.com>
>>>>>> >
>>>>>>                     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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Background:
>>>>>>>In our draft standard (due for Sponsor ballot in July), we have the 
>>>>>>>ability
>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>Questions:
>>>>>>>
>>>>>>>1- Is there already a numbering system for security options anywhere 
>>>>>>>else
>>>>>>>in
>>>>>>>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 cost
>>>>>>>implication?
>>>>>>>
>>>>>>>3- How is it done now and if it is, can you point us to a 
>>>>>>>application and
>>>>>>>procedure?
>>>>>>>
>>>>>>>
>>>>>>>Thanks!  We are trying to get all of this text for the current letter
>>>>>>>ballot
>>>>>>>re-circulation done before the 12th so your rapid response would be
very
>>>>>>>helpful.
>>>>>>>
>>>>>>>Regards,
>>>>>>>Jim Allen
>>>>>>>
>>>>>>>VP Research & Engineering
>>>>>>>Appairent Technologies
>>>>>>>150 Lucius Gordon Dr.
>>>>>>>Rochester, NY  14586
>>>>>>>
>>>>>>>585-214-2465.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>___________________________________________
>>>>>>>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)
>>>>>>>a.ricketts@ieee.org
>>>>
>
>