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)
(Tim Polk)
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