Subject: [Int-area] impacts to other specifications from draft-arkko-arp-iana-rules

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2008 23:33:20 +0200

Folks,

As you recall, I recently wrote a draft about the IANA rules regarding
ARP, as no such rules were defined before.

During last call, it became apparent that there are a few other
protocols that use the same numbers. For instance, specialized forms of
ARP for certain link layers or DHCPv4/6. Having realized this, we did a
more thorough search of the RFC series to attempt to find all such uses.
The new version of my draft lists all these uses and updates the RFCs in
question.

I would like to ask for your review to make sure (a) that the ARP rule
change is OK from the perspective of your protocol and (b) we have found
all uses of the ARP numbers. Here's what the draft says:

"The change is also applicable to extensions of ARP that use the same
message format, such as [RFC0903], [RFC1931], and [RFC2390].

The change also affects other protocols that employ values from the ARP
name spaces.  For instance, the ARP hardware address type (ar$hrd)
number space is also used in the "htype" (hardware address type) fields
in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration
Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in
the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are
therefore affected by the update in the IANA rules.  Other affected
specifications include the specialized address resolution mechanisms in
HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM
(Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance
Parallel Interface ARP) [RFC2834], [RFC2835], Dual MAC FDDI (Fiber
Distributed Data Interface) ARP [RFC1329], MAPOS (Multiple Access
Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy)
ARP [RFC2176], FC (Fibre Channel) ARP [RFC4338], and DNS Resource
Records [RFC4701]."

(We have only listed a protocol as affected when uses ARP values
directly, e.g., in its own protocol message formats. Use of ARP as-is is
of course not an issue. I have also not listed the many IP over Foo
specifications that talk about how to use ARP in Foo, describing what
hardware type values to use, etc.)

Here's the URL for the draft:
http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04

Jari

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Dave Thaler <[email-masked]>
Date: Mon, 1 Dec 2008 18:52:48 -0800

Re
"Requests for new ar$op values are made through IETF Review or IESG
Approval"

Who decides which of these two is required?  I assume it's the IESG,
but would be good to clarify.

Otherwise, looks ok to me.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Monday, December 01, 2008 1:33 PM
> To: Internet Area
> Cc: Russ Housley
> Subject: [Int-area] impacts to other specifications from draft-arkko-
> arp-iana-rules
>
>
> Folks,
>

---

From: "Donald Eastlake" <[email-masked]>
Date: Mon, 1 Dec 2008 22:10:53 -0500

On Mon, Dec 1, 2008 at 9:52 PM, Dave Thaler
<[email-masked]> wrote:
> Re "Requests for new ar$op values are made through IETF Review or IESG
> Approval"
>

My understanding of that sort of wording is that the applicant get to
decide which path they want to try. (These paths are further
documented at http://tools.ietf.org/html/rfc5226#page-11 )

Donald

>> http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2008 07:52:16 +0200

Dave, Donald,

> but would be good to clarify.
This is a standard expression used in many IANA considerations sections. 
As Donald mentioned, its basically up to the applicant to choose. 
However, the circumstances typically dictate what to do.

For instance, IETF Review requires an RFC from IETF WGs or an AD 
sponsored IETF submission. If you have that, then you have to do nothing 
and the numbers will be automatically given to you after your RFC is 
approved. If you have something else, such as an RFC Editor submission 
that was not reviewed in the IETF, or perhaps a use that is not even 
associated with an RFC, then IETF Review cannot be used. IESG Approval 
will then be used, which basically means that the IESG makes a judgment 
call on whether the allocation should be granted.

We have often used IANA policies of the type "<some rule> or IESG 
Approval". The idea is that the normal process should follow <some rule> 
but the IESG can grant exceptions. If we we later see an exceptional 
situation that warrants a code point, it can be allocated without 
revising the RFC that defined the IANA policy. For instance, we've had 
standards track RFC requirement for some number spaces in our protocols, 
but the IESG granted code points for some experimental specifications 
from the IRTF.

Jari