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

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 03 Jun 2015 02:24:16 -0000

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

Comment (by [email-masked]):

 New Proposed Text:

 New DHCP option codes are assigned is through IETF Consensus, as defined
 in RFC 2434.

 The only left to discuss is what to do about Internet drafts, we could put
 back this line:

 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].

 If we fell like Internet drafts really needs codes.   What do other think?

-- 
----------------------------+--------------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  assigned
 Priority:  P1 blocker      |   Milestone:  B moderate, apply after merge
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:  11/02/2015
----------------------------+--------------------------------------------

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 04 Jun 2015 17:32:06 -0000

Comment (by [email-masked]):

 Discussion with Brian Haberman, Ted Lemon, and others regarding Expert
 Review ... It is recommended we add text to define the criteria for the
 expert review (see Section 3.2 of RFC 7280 for an example).

 Ted wrote (in response to what he has done for reviews in the past): "I
 generally check the option description for correctness, make sure there
 aren't any unintentional updates to the base protocol (normative language
 that either repeats or inappropriately augments what e.g. RFC 3315 says
 about option handling) and check for inappropriate use of encapsulation."

 Perhaps the "Expert Review Guidelines" section could read something like
 the following:

 ---
 The Designated Expert(s) shall review a proposed Option registration for
 the following:

 - The option description is correct and complete and follows the
 guidelines and conventions in RFC 7227 (and any updates, successors, or
 documents that create additional option formats) and this [dhcpv6-bis]
 document. In particular:
         - All data types and encodings used are clearly defined without
 relying on multiple external references. (External references, such as
 registries, may define the actual permitted values and provide additional
 descriptive information, but the document should stand on its own in terms
 of actual encoding of the data.)
 [NOTE to To/CC folks and not to be included - this is to prevent some of
 the ambiguity around some of the Kerberos options that has occurred.]
         - Terminating characters (such as null bytes) are avoided and
 length encoding is used, if applicable.

 - There are no unintentional updates to the base protocol (normative
 language that either repeats or inappropriately augments what e.g. this
 document (dhcpv6-bis) says about option handling).

 - The use of encapsulation, if applicable, is appropriate.

 If not all applicable criteria is met, the Designated Expert(s) shall not
 approve the registration to IANA and must provide a list of the issues in
 the rejection notification.

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