Subject: [Dhcpv6bis] [dhcpv6bis] #127 (XML 3315): Update how DHCPv6 option code registry assignments made?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 03 Nov 2014 18:27:51 -0000

#127: Update how DHCPv6 option code registry assignments made?

 Ted sent the following email to the DHC WG (see http://www.ietf.org/mail-
 archive/web/dhcwg/current/msg16023.html):

 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?

-- 
----------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:
Component:  XML 3315        |   Keywords:
----------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/127>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 03 Nov 2014 18:29:29 -0000

Comment (by [email-masked]):

 I responded (http://www.ietf.org/mail-
 archive/web/dhcwg/current/msg16025.html):

 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

 To which Ted responded (http://www.ietf.org/mail-
 archive/web/dhcwg/current/msg16026.html):

 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.

-- 
----------------------------+------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:
Component:  XML 3315        |  Resolution:
 Keywords:                  |
----------------------------+------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/127#comment:1>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 11 Nov 2014 20:09:17 -0000

Changes (by [email-masked]):

 * owner:   => [email-masked]

-- 
----------------------------+-----------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:
Component:  XML 3315        |  Resolution:
 Keywords:                  |
----------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/127#comment:2>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 11 Nov 2014 20:09:43 -0000

Changes (by [email-masked]):

 * milestone:   => B moderate, apply after merge

-- 
----------------------------+--------------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:  B moderate, apply after merge
Component:  XML 3315        |  Resolution:
 Keywords:                  |
----------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/127#comment:3>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 11 Nov 2014 20:11:22 -0000

Deadline: 12/1/2014.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/127#comment:4>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>