Subject: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- volunteer needed!

From: Patrik Fältström <[email-masked]>
Date: Thu, 22 Jul 2010 10:10:51 +0200

IETF has received the following liaison:

https://datatracker.ietf.org/liaison/903/

We need someone that can write a response to the liaison. I can help with formalities.

   Patrik Fältström
   Liaison from IETF to ITU-T

P.S. My personal very quick reading of the liaison and related documents together with Olaf Kolkman (as IAB chair) gave:

Patrik wrote:
> Olaf wrote:

>> I've skimmed the doc.
>> 
>> - I observe slightly different RCODE semantics in 5.2.6
>> - I also observe that the service name chosen doesn't seem to followhttp://tools.ietf.org/html/rfc4848#section-4.5 but I may be misreading something here?
>> 
>> 
>> The higher level question is what is the IETF action here? Any IANA registration needed? Do we need to review DDDS formally?
> 
> Yes, some action is needed. And the way I read the documents, an RFC is needed:
> http://tools.ietf.org/html/rfc3958#section-7
> 
> At least one that references the ITU-T document according to the normal referencing mechanisms agreed upon.
> 
>> Who takes has the token for determining next actions?
> 
> I think IAB should try to find someone that can do a more detailed review than what I here has done.
> 
>> 6.2.1	These requirements are placed on the .oid-res.org operational agency (and recursively on all DNS zone files in the .oid-res.org domain.
> 
> If this is an ISO/ITU "formal" namespace "thing", I think the domain should go in .ARPA.
> 
>> 6.3.1.3
>> The DNAME resource record shall be preceded by:
>> a)	the Unicode label on the arc to that child transformed as specified in IETF RFC 3490, section 4.1, including case folding (see IETF RFC 3454) and punycode encoding (see IETF RFC 3492) using the Compatibility Decomposition followed by Canonical Composition (NFKC) specified by Unicode 5.2, Annex 15; then
> 
> They should do something new here, following the newprep work in the IETF. 3490 etc are (on their way to be) obsolete.
> 
>  Patrik

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 22 Jul 2010 19:23:39 -0700

Hi -

> From: "Patrik Fältström" <[email-masked]>
> To: "Apps Discuss" <[email-masked]>
> Cc: "IAB IAB" <[email-masked]>
> Sent: Thursday, July 22, 2010 1:10 AM
> Subject: [apps-discuss] Review of liaison from ITU-T regarding OIDs --volunteer needed!
...

Has anyone thought through how this would (not) work for OIDs
as they are (ab)used in SNMP-land?

Those OIDs aren't defined in ASN.1 modules (though the SMI notation
is historically related to ASN.1, it is most emphatically NOT ASN.1) and
SNMP generates things with OBJECT IDENTIFIER syntax which
won't appear in a definition anywhere.  (Think how table indexing
looks on the wire.)

Randy

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 23 Jul 2010 04:25:06 +0200

> as they are (ab)used in SNMP-land?

No.

We need help here as you understand, and you might obviously be one that helps...at least with a fraction of text.

   Patrik

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Jul 2010 23:46:47 -0500

> won't appear in a definition anywhere.  (Think how table indexing

SNMP is hardly the only place where we use OIDs that don't get defined
in ASN.1 modules.  The smi-numbers registry is full of such OIDs.

I don't think the problem lies in having OIDs not defined in ASN.1
modules.  If an OID is not useable in an ASN.1 module (e.g., GSS-API
mechanism OIDs) then having an ASN.1 module just to define it would add
little value, except, perhaps, as a structured registration entry
documentation format for IANA.

Which brings me to...  What would be really nice is a DNS-like method of
resolving OIDs, so that then IANA can participate in a more structured
way.  Failing that, or even besides that, maybe an IANA API would be
nice.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 23 Jul 2010 07:58:34 +0200

> way.  Failing that, or even besides that, maybe an IANA API would be

That is basically what they want to do, right?

In IETF we have the DDDS algorithm that is in use for E.164 numbers, and similar mechanism is used for RFID tags by ONS that ECDS has defined.

So yes, that could be interesting. And I think we IETF can do something here. And because of that, yes, they might walk into "our turf".

But the question is what to tell ITU.

1. That they of course can work with this

2. That IETF thought OIDs in reality is an ISO thing, not ITU thing

3. That IETF is the SDO where DNS, and DNS like mechanisms are discussed

4. That we have a history of good cooperation between ITU and IETF regarding for example ENUM

5. That IETF is happy to do (is doing?) a resolution mechanism from OIDs to something else using DNS.

The trouble is maybe how to formulate 5?

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jul 2010 05:55:26 -0400

--On Friday, July 23, 2010 07:58 +0200 Patrik Fältström
<[email-masked]> wrote:

> In IETF we have the DDDS algorithm that is in use for E.164
> numbers, and similar mechanism is used for RFID tags by ONS
> that ECDS has defined.
> 
> So yes, that could be interesting. And I think we IETF can do
> something here. And because of that, yes, they might walk into
> "our turf".
> 

Clarification:  OIDs came out of one of the "ISO/IEC - ITU Joint
Development Agreement" projects.  The relevant standards have
both ISO/IEC [JTC1] numbers and ISO numbers.  And there are
allocation arcs, separately, for both.  Indeed, one of the
questions we would have to sort out with ITU is whether ISO is
on board or whether this is really a proposal about the ITU arc
only.

> IETF regarding for example ENUM

Well...  :-(

> from OIDs to something else using DNS.

Wouldn't one set of sub-arcs of OIDs be more accurate here?

> The trouble is maybe how to formulate 5?

     john

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 23 Jul 2010 12:06:18 +0200

> Wouldn't one set of sub-arcs of OIDs be more accurate here?

Maybe, but why have IETF do something that can take care of the whole tree?

Only a sub-arc might be populated.

Something like this Harald has already today:

http://www.alvestrand.no/objectid/

   Patrik

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Jul 2010 11:20:35 -0500

> That is basically what they want to do, right?

If so, that context was lacking :)

But I'd still like to see an actual IANA API.  There are a lot of things
that IANA registers that are not OIDs.

> In IETF we have the DDDS algorithm that is in use for E.164 numbers,
> and similar mechanism is used for RFID tags by ONS that ECDS has
> defined.
> 
> something here. And because of that, yes, they might walk into "our
> turf".

I don't much care for turf fights, particularly when the proposed work
is a good idea.

> But the question is what to tell ITU.

If anything.

> 3. That IETF is the SDO where DNS, and DNS like mechanisms are

I don't believe (3) is an appropriate answer.  (2) wouldn't be relevant.

> OIDs to something else using DNS.

I'm for (5).  Resolve OID arc names<->numbers using DNS.  A and PTR RRs
will do, in a pinch, provided some conventions not unlike the
in-addr.arpa. affix for IP->name PTR RRs.  Though I'd like a new RR
type, or at least TXT RR conventions for documenting registration
information (e.g., document whence a registration, owner, registration
rules for arcs below, ...).

I think the best arguments for doing this in the IETF are:

a) we already have a protocol designed for delegating namespaces, so
   let's re-use it;

   (An extension of (a): if you want OID arc owners/delegatees to
    publish arcs/delegations below it would help if they didn't have to
    deploy [much] new software.)

b) many OID arc delegations line up well with existing DNS delegations,
   so this is natural;

I think the best argument for not doing this with DNS, and possibly not
at the IETF at all would be: "DNS, ew, time to try a new protocol".  Not
a terribly convincing argument, IMO.

First we should figure out if we have the desire and energy to do this
at the IETF.  Then we should figure out what to tell the ITU.

Nico
--

---

From: "t.petch" <[email-masked]>
Date: Sat, 24 Jul 2010 12:31:40 +0200

Has anyone actually read this liaison?   I ask because every day, I click on the
link, my browser spins its little icon for five minutes, after which I move on
to something more productive:-(

Tom Petch

----- Original Message -----
From: "John C Klensin" <[email-masked]>; "John C Klensin" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>; "Nicolas Williams"
<[email-masked]>; "Patrik Fltstr m" <[email-masked]>; "Nicolas
Williams" <[email-masked]>
Cc: "Apps Discuss" <[email-masked]>; "IAB IAB" <[email-masked]>; "Apps
Discuss" <[email-masked]>; "IAB IAB" <[email-masked]>
Sent: Friday, July 23, 2010 11:55 AM
Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding
OIDs --volunteer needed!

> --On Friday, July 23, 2010 07:58 +0200 Patrik Fltstr m
> { https://datatracker.ietf.org/liaison/903/ }
>

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Jul 2010 09:21:49 +0200

I read it when it arrived, and not from the Liaison page, but I now checked, and the two files are (which I reach by "clicking on the link" when being at the IETF in Maastricht):

https://datatracker.ietf.org/documents/LIAISON/file1036.pdf
https://datatracker.ietf.org/documents/LIAISON/file1037.pdf

If you have problems reaching the files, let me know and I will unicast them.

   Patrik

On 24 jul 2010, at 12.31, t.petch wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 11:35:02 +0200

Patrik

Yes, thanks, those links work fine (and the original still fails:-(

Tom Petch

----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "Apps Discuss" <[email-masked]>
Sent: Sunday, July 25, 2010 9:21 AM
Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding
OIDs --volunteer needed!

> I read it when it arrived, and not from the Liaison page, but I now =
> checked, and the two files are (which I reach by "clicking on the link" =
> when being at the IETF in Maastricht):
>
> If you have problems reaching the files, let me know and I will unicast =
> them.
>
>    Patrik
>
> > Has anyone actually read this liaison?   I ask because every day, I =
> click on the
> > link, my browser spins its little icon for five minutes, after which I =
> move on
> >=20
> >=20
> > From: "John C Klensin" <[email-masked]>; "John C Klensin" =
> <[email-masked]>
> > To: "Patrik F=E4ltstr=F6m" <[email-masked]>; "Nicolas Williams"
> > <[email-masked]>; "Patrik Fltstr m" <[email-masked]>; =
> "Nicolas
> > Cc: "Apps Discuss" <[email-masked]>; "IAB IAB" <[email-masked]>; =
> "Apps
> > Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T =
> regarding
> > OIDs --volunteer needed!
> >=20
> >=20
> >>=20
> >>=20
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>=20
> >>=20
> >>=20
> >>>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >=20

---

From: SJ Kissane <[email-masked]>
Date: Tue, 27 Jul 2010 20:50:23 +1000

Hi

Looking at section 6 of the document, they define an .oid-res.org
domain. Not that it really matters, but wouldn't that be better as
.oid-res.arpa?

Also, section 6 is defined in terms of the contents of DNS zone files.
I don't think it should be using the phrase "zone file", it carries
the implication that a DNS implementation must store its DNS records
in a zone file, rather than some other format (e.g. relational
database, LDAP entries, etc...) When really, their standard is not
about the storage of DNS records in some file, its a standard about
how a DNS server responds to certain queries [even if all that is
needed to make the server so respond is to change the data in it,
rather than any change to the code of the DNS implementation]

Regards
Simon

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Jul 2010 13:09:11 +0200

Weird, are you really trying <https://datatracker.ietf.org/liaison/903/>? I.e. that URL works for me (that's how I found the links I sent you).

Anyway, you now have the documents.

   Patrik

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 27 Jul 2010 13:30:55 +0200

Weird, are you really trying
    <https://datatracker.ietf.org/liaison/903/>? I.e. that URL works
    for me  (that's how I found the links I sent you).

To confirm, that also works for me 

	jaap

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 14:23:12 +0200

Yes, I really am clicking on the URL in the e-mail:-)

Dredging up something from a deep, dark past, I tried it without the trailing
solidus on the URL; and that works, so now all I have to do is to remember why
that is so significant (apart from the obvious that one is a directory and the
other is a file - and this is Windows Internet Explorer 6 which I am sure is
significant).

Subscribing to the MPLS-TP list, I do see ITU-T liaisons most weeks and those I
can click on and retrieve without any difficulty.

Tom Petch

----- Original Message -----
From: "Jaap Akkerhuis" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "Apps Discuss" <[email-masked]>
Sent: Tuesday, July 27, 2010 1:30 PM
Subject: Re: [apps-discuss] [IAB] Review of liaison from ITU-T regarding
OIDs --volunteer needed!

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 16:16:22 +0200

Having read, marked, learnt and inwardly digested,

----- Original Message -----
From: "John C Klensin" <[email-masked]>; "John C Klensin" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>; "Nicolas Williams"

> { https://datatracker.ietf.org/liaison/903 trailing solidus elided}
>

For me, the biggest bit of our turf is DNS, something critical to Internet
operation and yet somewhat fragile, judging by my memory of the reaction
to previous proposals to enhance it on the main IETF list ie they should not
be using it unless the IETF DNS community says ok (e-mail security et al?)

In practical terms, the basic idea would have been great had it appeared in
1976, but trying to retrofit it to all our existing SMI (not exactly ASN.1)
definitions in ASCII (definitely not XSD/XML) documents is ..
well, misguided.

Yet I have my own hand-maintained list of nodes under mib-2 to RFC
index which is one of those things I always have to hand for any
practical work on SNMP, so having an online mechanism, at least
down to the first arc from mib-2, would be most useful; just not the
way it is specified here.  I note that they are requesting comments
on DNS and not really on any other aspect of their system.

And the liaison is explicit, ITU-T SG17 and ISO.  ..SC6, so yes, both
would seem to be on board

Tom Petch

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 11:26:42 -0500

> domain. Not that it really matters, but wouldn't that be better as

Does it really matter?

> rather than any change to the code of the DNS implementation]

This is standard DNS terminology.  Zone file does not, in fact, imply a
flat text file edited by hand, and it is certainly not taken to imply
that.  I understand why some people might think that it does, but that's
a cultural problem.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 11:48:37 -0500

> be using it unless the IETF DNS community says ok (e-mail security et al?)

Some kinds of enhancements to the DNS clearly belong firmly in IETF
hands, and specifically in whatever WG(s) is(are) currently chartered to
maintain and/or extend DNS.  However, it is not remotely true that
making innovative uses of DNS requires IETF approval -- plenty of people
make use of SRV and TXT RRs in ways never approved by the IETF.

(For example, Windows / Active Directory makes extensive use of SRV
RRs.  And people use all sorts of TXT RR naming and RDATA conventions in
intranets all the time.  Sure, some folks might complain that some such
uses should be standardized, and that some such uses should be replaced
by new RR types, but complain is all they can do.)

I've not read the ITU-T proposal in detail, but a cursory look indicates
that it involves a straightforward mapping of OID arc names and numbers
onto the DNS using NAPTR RRs.  That's not necessarily how I'd have done
it, but it isn't exactly "wrong" either.  Moreover, the use of a
specific domain (oid-res.org) to host the root of the OID resolution
name space that there's zero chance of any conflicts between the ORS and
the rest of the DNS.  It's possible I'll find something to dislike about
this proposal, but unlikely that I'll be able to argue convincingly that
the IETF has any kind of veto power over this specific proposal.

I don't oppose the ITU-T's use of DNS in this way.  I would oppose any
proposal from the ITU-T to, say, add DNS RR types outside the IETF, but
the ITU-T is making no such proposal.

> definitions in ASCII (definitely not XSD/XML) documents is ..

Really?  Why?  The DNS did not exist in 1976, incidentally.  Can you
expand on why any of this is misguided?

Nico
--

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 18:02:09 +0200

----- Original Message -----
From: "Nicolas Williams" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "Patrik Fältström" <[email-masked]>;
"Apps Discuss" <[email-masked]>
Sent: Tuesday, July 27, 2010 6:48 PM
> expand on why any of this is misguided?

Yup, 1976 was when ASN.1 came into my orbit.  What I am saying is that
if you want to build an index, a database to allow ready access to a vast range
of instances, then the time to do it is when you start, not trying to
retrofit it later.  SMI is ASN.1 frozen in time, seeing no good reason to come
up to date in ASN.1 terms.  Likewise our ASCII RFC represent a way of
doing things that was leading edge 30 years ago; itstill serves us well and I
resist a change to eg XML.  So this ISO/ITU-T proposal is using current
technology that I do not see retrofitting well to our aarchives of usage of
the ISO/ITU-T object tree; like I said, I maintain an index hand-written on
paper.

Tom Petch

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 12:16:49 -0500

If I've any problem with the ITU-T it's likely to be around IDNA (it
seems to refer to IDNA2003; it'd be better to make it IDNA2008), and
security (it really should RECOMMEND that DNSSEC be used and discuss the
consequences of not using DNSSEC).

Also, I think the IANA should look at the RINF (registration
information) module and see what else they might want to be added to it,
if anything.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 12:32:45 -0500

On Tue, Jul 27, 2010 at 06:02:09PM +0200, t.petch wrote:
> up to date in ASN.1 terms.  [...]

What a silly argument!  The Internet didn't have a DNS before 1986, so
why did anyone bother inventing the DNS then?  Why didn't they say "hey,
there was no DNS in 1981, and that's when it should have been done, so
now it's too late, sorry, no DNS ever because they screwed up! now we're
all stuck with hand-edited hosts files forever".

Like it or not, the OID namespace is based on delegations of child node
registration of authority, and like it or not anyone can produce a
protocol to enable delegation-based name resolution of OIDs, at any
time.  If the ASN.1 had had such a thing back in 1976, we would still be
free to replace it, just as we are free to create it now.  And since the
OID namespace is so well matched to the DNS, using DNS for OID
resolution is just too obvious.

>                     [...].  Likewise our ASCII RFC represent a way of

You can stay in the stone age if you like, but you can't keep the rest
of us there with you :)

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jul 2010 06:37:00 +0200

>> domain. Not that it really matters, but wouldn't that be better as

Yes it does. .ARPA is explicitly under control of IAB.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jul 2010 06:46:25 +0200

To go back to my original question, do we have anyone wanting to hold the pen regarding writing a 1-page response, or maybe 2? I.e. not much text is needed, not a review of their "stuff". More a note in the form of "thank, we do this plase, remember that we exist".

Nicolas?

   Patrik

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 23:53:24 -0500

> Yes it does. .ARPA is explicitly under control of IAB.

That's.. not what I meant.  What I meant:

Q: Is there any reason why it must be .something.arpa.  instead of
   .oid-res.org.?  I shall answer myself:

A: Yes, it does matter for the simple reason that we already have a root
   for URN lookups, and it's .urn.arpa. [RFC3403] [RFC3404].  The
   correct affix should be .oid.urn.arpa.

   (Note that the IAB would not have to approve of .oid.urn.arpa.)

In fact, is there any reason to think that DDDS is not enough?  I'd like
to see a discussion of that first.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2010 23:59:31 -0500

On Wed, Jul 28, 2010 at 06:46:25AM +0200, Patrik Fältström wrote:
> To go back to my original question, do we have anyone wanting to hold
> the pen regarding writing a 1-page response, or maybe 2? I.e. not much
> text is needed, not a review of their "stuff". More a note in the form
> of "thank, we do this plase, remember that we exist".

I could write it, but I know nothing about the ITU-T other than how to
find such things as x.680, x.690 and friends.

I think an expert in DDDS would be much more appropriate, or at least
I'd like to see a review from a DDDS expert.

I'm not sufficiently familiar with DDDS to know whether it can be
leveraged to create an OID resolution mechanism without any additional
specifications (at first glance it sure seems that way!).  Of course,
the schemas for documents to be found via DDDS, such as those introduced
in the ITU-T proposal, do need to be specified, but the resolution
mechanism is provided for by DDDS already, no?

> Nicolas?

Volunteer and opinion, get volunteered for the job.  I get it.  :(

:)

Well, like I said, I think someone with DDDS experience should look at
this first.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jul 2010 07:20:18 +0200

> to see a discussion of that first.

I completely agree. That as well.

I see you already start writing a response to the liaison ;-)

Go for it!

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jul 2010 07:25:27 +0200

> Well, like I said, I think someone with DDDS experience should look at

It will happen in parallell. (Happens...)

You can bravely say you think DDDS is a good choice ;-)

   Patrik

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Jul 2010 00:32:35 -0500

> You can bravely say you think DDDS is a good choice ;-)

Heh.  Well, in that case the correct response might well be:

    Dear ITU-T,

    Have you considered using DDDS [RFC 3401, 3402, 3403 and 3404] for
    OID URN resolution?  It seems very likely that DDDS should be usable
    for OID URN resolution right now, without further ado (other than to
    define the schemas for documents to be found via DDDS resolution of
    OID URNs, which you've already done).

    Separately, have you inquired with the IANA (and any other similar
    registrars that deal with OIDs) about what other items might be
    desirable in the RINF schema.

    Thanks,

    <IETF-ITU-T Liason name, e-mail address, and signature>

    IETF-ITU-T Liason

Yes?  If so, whoever would be the liason, please review, edit to your
liking, and send the above to the relevant ITU-T working group.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Jul 2010 00:51:55 -0500

>     <IETF-ITU-T Liason name, e-mail address, and signature>

I think one might want to point out that implementations of DDDS may
exist that can handle OID URN resolution _now_, or could, if the
necessary RRs existed.

Also, if DDDS is applicable, then I think we'd have a very strong
architectural argument for requesting that the ITU-T make use of it.

Letting the ITU-T know right away that DDDS exists will save time -- the
ITU-T SG 17 and IETF participants can then review, in parallel, the
applicability of DDDS to OID URN resolution.  Besides the sooner the
ITU-T finds out that they've [potentially] made a mistak, the better.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Jul 2010 02:45:30 -0400

--On Wednesday, 28 July, 2010 06:37 +0200 Patrik Fältström
<[email-masked]> wrote:

>>> Looking at section 6 of the document, they define an
>>> .oid-res.org domain. Not that it really matters, but
>>> wouldn't that be better as .oid-res.arpa?
>> 
>> Does it really matter?
> 

Yes.  Also remember that the last time something like this came
up, we wasted a few years of everyone's time in a debate about
demands for a TLD linked to the particular function and under
ITU control.  Part (but only part) of the reason was that .ARPA
was under IAB control.  So, while .ARPA is the right answer, we
should remember that willingness to do it in .ORG is progress.

     john