Re: [Ianaplan] A draft for your review

Eric Burger <eburger@standardstrack.com> Sun, 31 August 2014 18:42 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537961A8AD1 for <ianaplan@ietfa.amsl.com>; Sun, 31 Aug 2014 11:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.908
X-Spam-Level:
X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4L3FNqyEivz for <ianaplan@ietfa.amsl.com>; Sun, 31 Aug 2014 11:42:33 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE11E1A8AAC for <ianaplan@ietf.org>; Sun, 31 Aug 2014 11:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=CLX8t2RRAP1XROnocyBgDcJzWdXgTg4nH7GTcciRJmY=; b=Kzm/j7GZhCy6oe7goH/EivEJ7Iaec9jZAdqIl+WPtxrXOx1s5rksi2jmQ011YfAbIp7frFBHYi2arSz1h3utftyrkOIc2xmKTECGk8iTJbKGBvUGs4bOCaLl9ck8bC64q1oLo0oeb2ZUVjf7ASEbt7UlSx5W8woPOpb4JNCqFCU=;
Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:50105 helo=[192.168.15.119]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <eburger@standardstrack.com>) id 1XOA50-0000GL-PN for ianaplan@ietf.org; Sun, 31 Aug 2014 11:42:30 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E185E1D9-4D15-44E7-B9FF-7B79A5619EB2"; protocol="application/pkcs7-signature"; micalg="sha1"
Message-Id: <E8F176B3-3531-458A-A566-A50EC31CAC16@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Sun, 31 Aug 2014 14:42:22 -0400
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net>
To: ianaplan@ietf.org
In-Reply-To: <6.2.5.6.2.20140830052032.0c96c880@resistor.net>
X-Mailer: Apple Mail (2.1878.6)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/Q4dm74L_GcKMjwGVXw7k3Q4YF20
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 18:42:34 -0000

I like the humor, like the MIB dig. However, for the substantive comments, we should fix. 

Inline.

On Aug 30, 2014, at 10:38 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Eliot,
> [snip]
>  "The customer of the IANA protocol parameters function is the Internet
>   Engineering Task Force (IETF)."
> 
> The above is inconsistent with a stated IETF position.
> 
>  "1.  The IETF protocol parameter registry function has been and
>      continues to be capably provided by the Internet technical
>      community."
> 
> What is the "Internet technical community”?

I think the disconnect is /direction/ for the IANA protocol parameters function comes from the IETF, which is an embodiment of the Internet technical community. The /input/ for the function is capably provided, not the /function/ itself. The language needs fixing.

How about:
The Internet technical community, through the IETF, has in the past and for the foreseeable future will provide direction to the IANA protocol parameter registry.


> 
>  "The IETF uses the IANA protocol parameter registries for
>   this purpose."
> 
> The above is not aligned with the stated position of the IETF.

It is not that it is not aligned with the stated position of the IETF, it is that it is the IETF community, including implementers, “the IETF's primary users of the IETF standards and other documents,” that use the IANA protocol parameter registries. How about:

Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IANA protocol parameter registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.

> 
> Quoting two parts of the responses out of context:
> 
>  "It is important to note that the IETF includes anyone who wishes to
>   participate, including anyone from ICANN or the RIRs, and many people
>   from those organizations regularly do."
> 
>  "In-person attendance is not required for participation, and many
>   people participate in email discussions that have never attended
>   an IETF meeting."
> 
> I scanned the ietf@ mailing list archives and I did not find anyone from ICANN or the RIRs participating on that mailing list.

RIR and ICANN people regularly come to IETF meetings, which means they participate. As we say, in-person attendance is not required for participation. Likewise, email discussions are also not required for participation. Thus, there is no inconsistency. Moreover, participation does not require posting. I will bet there are a lot of ICANN and RIR people subscribed (i.e., participating) to IETF email lists.

> 
>  "Because of the nature of the agreement, questions of jurisdiction are
>   immaterial."
> 
> Why are questions of jurisdictions immaterial?

See my other note to Richard.

>  "Any modifications to the protocol parameter registry function
>   should be made using the IETF process"
> 
> The above is incorrect.

How? Any text for what you think it is / should be?

> 
> The IETF responses are not well-formulated in my opinion.  There isn't any reference to the IANA Functions contract.
> 
> As this topic has been mentioned I'll comment.  From https://www.icann.org/resources/pages/bylaws-2012-02-25-en
> 
>  "The mission of The Internet Corporation for Assigned Names and Numbers
>   ("ICANN") is to coordinate, at the overall level, the global Internet's
>   systems of unique identifiers, and in particular to ensure the stable
>   and secure operation of the Internet's unique identifier systems.  In
>   particular, ICANN:
> 
>   1. Coordinates the allocation and assignment of the three sets of unique
>    identifiers for the Internet, which are
> 
>      "c. Protocol port and parameter numbers."
> 
> ICANN may have to adjust its bylaws if RFC 6220 is to be followed.
> 
> Regards,
> S. Moonesamy
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan