Subject: [nfsv4] The FedFS OID prefix

From: Daniel Ellard <[email-masked]>
Date: Wed, 18 Aug 2010 16:57:17 -0400

A minor point about the FedFS LDAP OIDs: the prefix 1.3.6.1.4.1.31103
is assigned to me.  I am perfectly happy to let fedfs use
1.3.6.1.4.1.31103.1 in perpetuity, so I have no objection to this at
all, but I remember that at one point there was discussion of getting
a prefix to use specifically for FedFS that would be "owned" in some
way by the NFSv4 WG, instead of a random person.

Again, I have no objection to this use, but I remember that the issue
was raised at one point, and I want to raise it again before it gets
forgotten so we can settle whether this is something that needs to get
changed before we move to an RFC, or whether it's fine the way it is.

Apologies if this has already been discussed and I missed it.

Thanks,
    -Dan

---

From: James Lentini <[email-masked]>
Date: Wed, 18 Aug 2010 17:15:16 -0400 (EDT)

> Apologies if this has already been discussed and I missed it.

We're going to use the ones you registered. There wasn't a good reason 
to change them.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 10:51:45 -0500

> We're going to use the ones you registered. There wasn't a good reason 

The ITU-T has a proposal on the table to make OIDs resolvable through
the DNS.  I would argue that it'd be a good idea to use an OID whose
parent's owner is willing and able indefinetely to participate in the
OID resolution system.  If Dan is, then that's that.  Else I recommend
asking IANA to assign an OID.  Though in any case, it will not be tragic
if some OIDs used in Internet protocols are not resolvable -- they
aren't now!  :)

Nico
--

---

From: James Lentini <[email-masked]>
Date: Mon, 23 Aug 2010 15:42:33 -0400 (EDT)

> > > 1.3.6.1.4.1.31103.1 in perpetuity, so I have no objection to this at
      ^^^^^^^^^^^^^^^^^^^
      1.3.6.1.4.1.31103?

> if some OIDs used in Internet protocols are not resolvable -- they

Maybe this would be a reason to change the registration, although I'm 
unclear why Dan's OID range wouldn't be eligible for resolution. In 
any event, I'd need to learn more about the proposal you mention to 
understand if it is relevant to the FedFS OIDs.

Who or what would replace Dan as the contact point? The nfsv4 WG seems 
incorrect since IETF WGs disband from time to time.

Using an individual as the contact point isn't all that unusual. The 
LDAPv3 standards, from the now-defuct ldapbis WG, use OIDs registered 
to a single individual. Specifically, RFC 4517 and RFC 4519 use the 
OID range 1.3.6.1.4.1.1466 which is assigned to Mark Wahl. I remember 
this precedent being one of the reasons we stuck with Dan as the 
contact point. I remember bringing the OID question up, but there 
isn't much about it in the minutes. We discussed it at the 1/29/2009 
meeting: http://www.ietf.org/mail-archive/web/nfsv4/current/msg06524, 
and probably at other times as well.

There are FedFS implementations using these OIDs, so there would be 
some amount of churn if we changed to a new range. If there was a good 
reason to change the contact point, I hope that we could keep the same 
range (assuming Dan is amenable to that and this range is eligible for 
the resolution mechanism you mention above).

-james

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Aug 2010 15:21:15 -0500

On Mon, Aug 23, 2010 at 03:42:33PM -0400, James Lentini wrote:
> unclear why Dan's OID range wouldn't be eligible for resolution.

Nothing prevents Dan's OID from being resolvable, but you'd have to rely
on Dan to provide resolution.

>                                                                  In 

The idea is that you could resolve 1.3.5.1.5.2 into
iso.org.dod.internet.security.kerberosv5 and vice-versa, but also that
you could obtain meta-data about each arc (e.g., registered purpose,
registrar and registration rules).

> incorrect since IETF WGs disband from time to time.

The IANA, of course.

> Using an individual as the contact point isn't all that unusual. The 

Indeed, it's not.

> and probably at other times as well.

My preference is for IANA assigned OIDs in general for continuity
reasons (i.e., they'll be around to do further allocations below a given
OID arc, they'll be around to provide a registry and resolution
services), no offense to Dan.  This is not a strong enough argument to
switch, however, not if I'm alone in this.  I doubt the IESG or the IETF
as a whole will demand that you use IANA's services.

> the resolution mechanism you mention above).

Right, that's a very good reason to stick with the current OID.

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 23 Aug 2010 16:48:25 -0400

> on Dan to provide resolution.

This could be a problem, because I don't understand exactly how this
resolution will occur (maybe nobody does right now, if it's just a
proposal), nor do I have a DNS server I can customize if this isn't a
standard service that my hosting company offers.

In the meanwhile, I'd like to hear more about the benefits of OID->DNS
resolution, because I don't understand the benefits.  It seems like
having OIDs resolvable at run-time would be useful if the OIDs were
subject to revision or improvement over time, so getting the latest
definition from time to time would be a good thing, but in our case I
think we want the opposite--when the draft becomes an RFC, the OID
definitions should be frozen.  (we can always add new ones, but we
shouldn't change the spec out from underneath deployed impls)

-Dan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Aug 2010 16:29:35 -0500

> standard service that my hosting company offers.

The protocol isn't yet a standard.  A liason to the ITU-T SG (17, IIRC)
is being assigned to work with them on this.

In any case, we could choose that we don't care.  After all, we've lived
without OID resolution services since the beginning.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Tue, 24 Aug 2010 16:10:59 -0400 (EDT)

> without OID resolution services since the beginning.

Thanks Nico. It is good to be aware of this.

Since switching to a new OID assignment doesn't appear to offer any 
technical advantages to FedFS and would result in some (minor?) 
interoperability issues, we'll continue using the OID values Dan 
reserved.

-james