Skip to main content

IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
draft-arkko-arp-iana-rules-06

Yes

(Dan Romascanu)
(Lars Eggert)
(Mark Townsley)
(Russ Housley)

No Objection

(Chris Newman)
(Cullen Jennings)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)

Recuse

(Jari Arkko)

Note: This ballot was opened for revision 06 and is now closed.

Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
Lars Eggert Former IESG member
Yes
Yes () Unknown

                            
Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Russ Housley Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-11-28) Unknown
In section 2, I suggest moving the exception case (single values >256)
for ar$hrd to the end.  Even if you retain the ordering, I think we need
more clarity in sentence that defines when first come first served can be
used.

I was thinking of something along these lines:

OLD:
      Requests for individual new ar$hrd values are made through First
      Come First Served [RFC5226].  Requests for ar$hrd values below 256
      or a batch of several new values are made through Expert Review
      [RFC5226].  Note that certain protocols, such as BOOTP and DHCPv4
      employ these values within a 8 bit field.  The expert should
      determine that the need to allocate the new values exists and that
      the existing values are insufficient to represent the new hardware
      address types.  The expert should also determine the applicability
      of the request, and assign values higher than 255 for requests
      that do not apply to BOOTP/DHCPv4.  Similarly, the expert should
      assign one-octet values for requests that clearly apply to BOOTP/
      DHCPv4 but not ARP, as for example the "IPsec tunnel" with value
      31 [RFC3456].  Conversely, ARP-only uses should favor 2-octet
      values.
NEW:
      Requests for ar$hrd values below 256
      or a batch of several new values are made through Expert Review
      [RFC5226].  Note that certain protocols, such as BOOTP and DHCPv4
      employ these values within a 8 bit field.  The expert should
      determine that the need to allocate the new values exists and that
      the existing values are insufficient to represent the new hardware
      address types.  The expert should also determine the applicability
      of the request, and assign values higher than 255 for requests
      that do not apply to BOOTP/DHCPv4.  Similarly, the expert should
      assign one-octet values for requests that clearly apply to BOOTP/
      DHCPv4 but not ARP, as for example the "IPsec tunnel" with value
      31 [RFC3456].  Conversely, ARP-only uses should favor 2-octet
      values.

      Requests for individual new ar$hrd values that do not specify a
      value, or where the requested value is greater than 256, are made
      through First Come First Served [RFC5226].
Jari Arkko Former IESG member
Recuse
Recuse () Unknown