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

"Donald Eastlake" <d3e3e3@gmail.com> Tue, 02 December 2008 03:11 UTC

Return-Path: <int-area-bounces@ietf.org>
X-Original-To: int-area-archive@megatron.ietf.org
Delivered-To: ietfarch-int-area-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F1C3A6BB3; Mon, 1 Dec 2008 19:11:01 -0800 (PST)
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9FB3A68BA for <int-area@core3.amsl.com>; Mon, 1 Dec 2008 19:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_22=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtP6FweWmjR8 for <int-area@core3.amsl.com>; Mon, 1 Dec 2008 19:10:58 -0800 (PST)
Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by core3.amsl.com (Postfix) with ESMTP id 28C4F3A6859 for <int-area@ietf.org>; Mon, 1 Dec 2008 19:10:58 -0800 (PST)
Received: by rn-out-0910.google.com with SMTP id j77so2266148rne.18 for <int-area@ietf.org>; Mon, 01 Dec 2008 19:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ye70/LmoGbMQ8QOWW38u9ZXG07j3FLxkxkYRJk4jDuQ=; b=v4ALzb8YdWGVxwNKZYryEsvoHE2ps3gY8y4Ru2UlkOxZq5zz4JZI1dFIRtQmSSoCQ7 2EJrPG7/rUH/fPCVncPcnxM4jTD2B9E1+pGCCcbjvVOX9ok+CASL7kigbFV4AMmPNfIg 85ItebO/1MBhhCun3d1g9zPkHo7lkIuPHwPMA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=b5OseLgPUX8sb159o0YmuJGEOJ96LCqKs+rOTdUv9cYenZNgCym1xe5e1g+Exs76yi zBhgQgItGEBRRPG/O25NNwDv41gIPsTec4OlLvnJ5zUl6ZyISWUa2vZn21Z8xGVCmqQm lnwlesLsNwZbsbQsBuIUu0F3CiwO+03Ge7IIE=
Received: by 10.100.143.14 with SMTP id q14mr6369186and.47.1228187453374; Mon, 01 Dec 2008 19:10:53 -0800 (PST)
Received: by 10.100.137.8 with HTTP; Mon, 1 Dec 2008 19:10:53 -0800 (PST)
Message-ID: <1028365c0812011910lf02ae57gde99f01c3ba50d12@mail.gmail.com>
Date: Mon, 01 Dec 2008 22:10:53 -0500
From: Donald Eastlake <d3e3e3@gmail.com>
To: Dave Thaler <dthaler@windows.microsoft.com>
In-Reply-To: <E9CACA3D8417CE409FE3669AAE1E5A4F10CF635AE7@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <49345820.6000207@piuha.net> <E9CACA3D8417CE409FE3669AAE1E5A4F10CF635AE7@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Cc: Internet Area <int-area@ietf.org>, Russ Housley <housley@vigilsec.com>
Subject: Re: [Int-area] impacts to other specifications from draft-arkko-arp-iana-rules
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: int-area-bounces@ietf.org
Errors-To: int-area-bounces@ietf.org

On Mon, Dec 1, 2008 at 9:52 PM, Dave Thaler
<dthaler@windows.microsoft.com> wrote:
> 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.

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

> Otherwise, looks ok to me.
>
> -Dave
>
>> -----Original Message-----
>> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] 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,
>>
>> 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
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area