Skip to main content

IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
RFC 5494

Yes

Lars Eggert
(Dan Romascanu)
(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.

Lars Eggert
Yes
Dan Romascanu Former IESG member
Yes
Yes ()

                            
Mark Townsley Former IESG member
Yes
Yes ()

                            
Russ Housley Former IESG member
Yes
Yes ()

                            
Chris Newman Former IESG member
No Objection
No Objection ()

                            
Cullen Jennings Former IESG member
No Objection
No Objection ()

                            
David Ward Former IESG member
No Objection
No Objection ()

                            
Jon Peterson Former IESG member
No Objection
No Objection ()

                            
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Pasi Eronen Former IESG member
No Objection
No Objection ()

                            
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-11-28)
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 ()