Re: [802SEC] Re: OID arcs & procedures
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)frame
>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
>>>
>>
>>
>>
>
>