Re: [Ianaplan] A draft for your review

S Moonesamy <sm+ietf@elandsys.com> Mon, 01 September 2014 09:57 UTC

Return-Path: <sm@elandsys.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 CB7BD1A0305 for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 02:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.785
X-Spam-Level: *
X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, 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 Qkt7qqLkK76F for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 02:57:46 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DDC1A0302 for <ianaplan@ietf.org>; Mon, 1 Sep 2014 02:57:45 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.133.234]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s819vWUV007155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2014 02:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1409565464; x=1409651864; bh=Epb60ltoWjMla3fEDq3T7RyLn/GnUx2BivBxvPPbFzs=; h=Date:To:From:Subject:In-Reply-To:References; b=r+qDE6FhbJYPL1QmsErZeWq/ZUI92UsBiWnyxYX8ntNLzRhHuGD4B575m42ZZqrhp I7rHj2SFuWuy30l8vMtBd0UVT21BWd0L+wAbvR/VaaacaRLlCkBSWMhwNJiHylUOub cj+BfbVaSndRjKb6cP09LnCpmFzzRpBMSdx9EEHk=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1409565464; x=1409651864; i=@elandsys.com; bh=Epb60ltoWjMla3fEDq3T7RyLn/GnUx2BivBxvPPbFzs=; h=Date:To:From:Subject:In-Reply-To:References; b=MZcHSVXtumWwSco34CUSqJ4NA15g0KpHnXjmewhht+ysIwBGW4Q7hqY6slK18WtSS 4X04NINQUS2zSpjgd3odgWxubg0u4R61abhSsTf1+DHKJFJvHBHUCEUH8UrmMnHd9a vg32947Y3tqBg7Vx7DIvKRW3IdXiXRlmF92eter8=
Message-Id: <6.2.5.6.2.20140831175817.0bf0b6d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 31 Aug 2014 19:35:33 -0700
To: Eric Burger <eburger@standardstrack.com>, ianaplan@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <E8F176B3-3531-458A-A566-A50EC31CAC16@standardstrack.com>
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <E8F176B3-3531-458A-A566-A50EC31CAC16@standardstrack.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/uneOysrEO0mTPon8kvoxbvDBi8c
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: Mon, 01 Sep 2014 09:57:48 -0000

Hi Eric,
At 11:42 31-08-2014, Eric Burger wrote:
>I like the humor, like the MIB dig. However, for the substantive 
>comments, we should fix.

:-)

>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 stated position is:

   "The IETF Protocol Parameter Registry function is undertaken under the
    auspices of the Internet Architecture Board."

The above basically says that the IETF considers that function as an 
IETF matter.  If you (used in the general sense) call it "IANA 
protocol parameters function" it is no longer an IETF matter.

One of the questions I asked was about the "Internet technical 
community".  The problem with using the term is that it is 
ill-defined.  I'll step back; there was a discussion about "global 
multistakeholder community" on this mailing list around the beginning 
of this month.  It was concluded that it is better to use the term 
"Internet community".

My reading of the question is that it is about the IETF Community's 
use of the IANA functions.  The less difficult way to answer that is 
to build from RFC 6220 (and the relevant BCPs if that is 
necessary).  I am taking into account the arguments that the IETF or 
the IAB has made previously.  It make sense to be consistent or have 
an explanation for a change in direction or else there will be a loss 
of credibility.

>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.

The above looks better.  It uses the term IANA protocol parameter 
registry though.  Please see my previous comment about that.

>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.

The point was that:

   (i)  It is possible to argue either way, i.e. people participate
        or people do not participate.

   (ii) It does not add anything substantive to the response.

What you (used in the general sense) could do here is to explain that 
there is coordination and how it is being done when there is an overlap.

>See my other note to Richard.

Thanks, I read that.  From RFC 6220:

   "Any intellectual property rights of the IETF protocol parameter
    assignment information, including the IETF protocol parameter
    registry and its contents, are to be held by the IETF Trust."

The IETF Trust is based in the Commonwealth of Virginia.  There is 
also the following:

   "In addition, the IAOC has the responsibility to ensure long-term
    access, stability, and uniqueness across all such registries.  This
    responsibility is of particular significance in the event that a
    relation with a Protocol Parameter Registry Operator is terminated."

And this is the proposed IETF response:

   "Because of the nature of the agreement, questions of jurisdiction are
    immaterial."

Mr Hill commented about disputes arising out of the agreement in his 
message.  I don't think that is an issue as it is covered in the 
agreement.  Mr Huston commented about an issue on March 13 which I'll 
quote (out of context):

   "I have absolutely no idea whether a) the IETF itself is an ISOC activity
    per se and b) issues about the intellectual property rights associated
    with the protocol parameter registry contents vest with any of the
    preceding bodies."

There has already been some public discussion about (b).  I have not 
seen any answer to it.  I am okay if the IETF says that intellectual 
property rights are not important.

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

It's an IAB matter.  The term "IETF process" may or may not cover 
that.  There is already the following as part of the response:

   "RFC 6220 specifies the role and function of the protocol parameters
    registry, which is critical to IETF standards processes and IETF
    protocols.  The IAB, on behalf of the IETF, has the responsibility to
    define and manage the relationship with the protocol registry
    operator role.  This responsibility includes the selection and
    management of the protocol parameter registry operator, as well as
    management of the parameter registration process and the guidelines
    for parameter allocation."

In my opinion it is a matter of fitting that into the response.

As a general comment, there is the following under "required proposal 
elements":  "associated references to source documents of specific 
policies/practices".  A plausible response would be one which could 
be substantiated with references.  Otherwise (in my opinion), it will 
look like the IETF is not comfortable with what it has written.

Regards,
S. Moonesamy