Subject: [dhcwg] Update to status of RFC3315 option code registry?

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 15:41:04 -0400

Currently RFC 3315 says this about registering option codes:

  New DHCP option codes are tentatively assigned after the
  specification for the associated option, published as an Internet
  Draft, has received expert review by a designated expert [11].  The
  final assignment of DHCP option codes is through Standards Action, as
  defined in RFC 2434 [11].

This led to the registry being marked as requiring _both_ expert review and standards action.   The original context in which this text was written, as I recall, was that we had had a big problem with vendors camping on DHCPv4 option codes and not telling us, and we wanted this to not happen for DHCPv6.   So we carved out an exception to incentivize vendors to document their use of option codes, and to get legitimate option code allocations, rather than just picking a number and hoping for the best.

So I think what the above language intends is:

If there is a standards-track document published that allocates option codes, then they should get expert review, but the presence of the standards track document means that there is a presumption that once the document describes something that is acceptable, it definitely gets an option code.
If there is a non-standards-track use for an option, we can allocate an option code for that use, but this allocation requires expert approval, and is tentative.   What it means for it to be tentative is that if it turns out that whatever use the option code had doesn't see widespread deployment, then at some point the option code is returned to the free pool.   The mechanism whereby that happens is likely some sort of working group action and expert review.

This came up recently in the context of draft-ietf-softwire-4rd, which is an experimental document, yet defines new DHCP option codes.   I think in principle we want to be able to allocate options in this case, but the current registry language prevents us from doing so.   So Adrian raised a DISCUSS on this.   I explained the context for the registry language, and he asked me to do a document that updates the registry status, in exchange for which he cleared his DISCUSS.

By "me" here, of course, he means the DHC working group, or so I'm going to claim, for two reasons.   First, it's less work for me, which I always like.   Second, the working group is in the process of updating RFC 3315.   Maybe we can fold this change into the updated document.   Or maybe that will take too long and we should do a short document.

Thoughts?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 31 Oct 2014 02:49:44 +0000

We can definitely roll this into RFC3315bis. I will open up a ticket for it so we at least track it (even if alternative approaches are used, as the text will need to be updated).

But, yes it may take a while.

I know you don't seem to favor errata, but perhaps adding you explanation as to what the intent of the RFC 3315 text (in Section 24) was via that mechanism might be acceptable?

The other option would be to write a document, such as http://tools.ietf.org/html/rfc2939 (though hopefully not as long). But as we're only trying to clarify what the existing text is, rather than 'change' the procedure, that is a bit of a heavy process (yes, I know you can probably expedite it)?

Does IANA have an "Expert Review or Standards Action" (rather than the "Expert Review and Standards Action" it is now)?

And, I guess given the various values in RFC 2434, perhaps we should revisit what we use and try to stick to one of the standard ones, rather than coming up with something else? We could go for IESG Approval or IETF Consensus? (I guess we could do Expert Review AND one of these, though that might be overkill). Given the choices, I'd probably suggest IETF Consensus (without Expert Review, since this would typically be used based on the definition).

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, October 30, 2014 3:41 PM
To: dhcwg
Subject: [dhcwg] Update to status of RFC3315 option code registry?

  *   If there is a standards-track document published that allocates option codes, then they should get expert review, but the presence of the standards track document means that there is a presumption that once the document describes something that is acceptable, it definitely gets an option code.
  *   If there is a non-standards-track use for an option, we can allocate an option code for that use, but this allocation requires expert approval, and is tentative.   What it means for it to be tentative is that if it turns out that whatever use the option code had doesn't see widespread deployment, then at some point the option code is returned to the free pool.   The mechanism whereby that happens is likely some sort of working group action and expert review.

Thoughts?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 06:21:49 -0400

On Oct 30, 2014, at 10:49 PM, Bernie Volz (volz) <[email-masked]> wrote:
> I know you don’t seem to favor errata, but perhaps adding you explanation as to what the intent of the RFC 3315 text (in Section 24) was via that mechanism might be acceptable?

I don't think it is an error, and furthermore errata can't change the outcome of consensus calls, so an erratum would not work for this.

> The other option would be to write a document, such as http://tools.ietf.org/html/rfc2939 (though hopefully not as long). But as we’re only trying to clarify what the existing text is, rather than ‘change’ the procedure, that is a bit of a heavy process (yes, I know you can probably expedite it)?

I can.   I'm not convinced there's that much of a rush, though.

> Does IANA have an “Expert Review or Standards Action” (rather than the “Expert Review and Standards Action” it is now)?

It does, but then we wouldn't get expert review on RFCs, and I think we want that as a stopgap to prevent options from going all the way through to RFC without review by any DHCP experts.   Bear in mind that any working group can write a document!   :)

So I guess the real question is, is the timeline for RFC3315bis too long to wait?   I'm not personally feeling a need for a tearing rush, but I think it should happen sooner than a year, six months at the outside.