Subject: [saag] New approach to allocating OIDs in experimental work

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Dec 2013 12:14:05 -0500

One of the commonly occurring problems in IETF process is what to do when a
project is transferred from private to public space. In particular should
names be registered in a corporate namespace or an IETF namespace and if
the latter what should be done with earlier registrations.

Once in use it is practically impossible to kill an existing code point.
For example Comodo has a Netscape email OID in its S/MIME certs to this
day. I was just wondering if I should knife it since I doubt that there is
any client that relies on that identifier being used and supports use of
SHA-2-512.

So what I was thinking about as an alternative approach is the following:

1) Ask IANA for a new OID assignment for each new project that might
transition into public space, give the arc the name of the project.

2) If the IETF accepts change control then turn over management of the arc
with the project.

The big advantage of this approach is that it is completely clean. There is
no need to duplicate code points.

One possible objection is that the registry might bloat but that is also
manageable, if it gets out of hand then IANA cuts a new oid off its arc for
'projects'.

Anyway, I have decided to do a trial run on this approach for the email
security scheme based on strong email addresses and phingerprint blocks.

-- 
Website: http://hallambaker.com/

---

From: Ira McDonald <[email-masked]>
Date: Fri, 13 Dec 2013 13:15:39 -0500

Hi,

I endorse this proposal.

The use of the 'experimental' arc in MIB development has for years
caused implementors to have to retain BOTH the 'experimental'
and 'mib-2' arcs indefinitely in their code for interoperability and
simply causes confusion, with no obvious benefit.

Cheers,
- Ira (editor of Printer MIB v2, Finisher MIB, and Charset MIB)

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Dec 13, 2013 at 12:14 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> One of the commonly occurring problems in IETF process is what to do when
> a project is transferred from private to public space. In particular should
> The big advantage of this approach is that it is completely clean. There
> is no need to duplicate code points.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Dec 2013 12:53:24 -0600

> 2) If the IETF accepts change control then turn over management of the arc

3) When the project completes (successfully or otherwise) change control
goes back to the IETF/IANA.

> manageable, if it gets out of hand then IANA cuts a new oid off its arc for

It's one arc per-project.  It's like saying that we have mailing list
bloat.  (OK, we do have mailing list bloat, but we live with it.)

+1!

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Dec 2013 21:49:35 +0000

Sounds reasonable. Do we need an oid to start from based
on an IANA one? Can someone write up the details in a mail
and I can ask IANA to start a FCFS registry as a management
item on some IESG telechat. Please try suggest the parent
OID/arc from which you want IANA to allocate a new one
as the parent of these.

Let's see if we can do this without an RFC, unless someone
wants to document it in one (no harm but could happen later).

S.

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Dec 2013 16:11:27 -0600

> wants to document it in one (no harm but could happen later).

I think all we need is to ask IANA.  IANA may want the IESG's say-so.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Dec 2013 23:31:07 +0000

> I think all we need is to ask IANA.  IANA may want the IESG's say-so.

I think they will. I'm happy to ask the IESG the question
(that'd be done as a "management item" on an IESG telechat).
But, we can either wait until I get around to it, or else
send me a mail with all the details so's I can just do a
bit of cut'n'paste. The latter will be much quicker;-)

S.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Dec 2013 22:09:42 +0000

> goes back to the IETF/IANA.
Agreed, but "completion" needs to be better defined, in case people 
disagree.
> bloat.  (OK, we do have mailing list bloat, but we live with it.)
Sounds like a good idea to me.