Re: [Ianaplan] I-D Action: draft-lear-iana-icg-response-00.txt

Brian E Carpenter <> Sun, 07 September 2014 20:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 919391A0701 for <>; Sun, 7 Sep 2014 13:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YyUxIxLa4VlY for <>; Sun, 7 Sep 2014 13:33:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B5811A0705 for <>; Sun, 7 Sep 2014 13:33:56 -0700 (PDT)
Received: by with SMTP id p10so2425698pdj.23 for <>; Sun, 07 Sep 2014 13:33:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZS+pBXoN9IidNlJ3+8p8qpxt+nxV9xudIZAOHYxUJiE=; b=Ou9m6bXIoxqyVJ/2SNN5NjqhLWcD+MhTm7MlLdNz0ttKzIK/jXAoObU1QqtWtMkL1g NePqj67KrnUgO1cSC59bOVt0v83pQyUZc11YT8Cvb5A7FihWbPowC63D/OfF+Lilu1wY uYWeIL7pOq+eyEPF2O/Wf0RxaNigEEowHdnfhxqKUwu1SI+lXID1jnqbql8MIrkXRji0 s9bnpMxDmbxpF/0MIUOvsLCDOqYqY5IIgDUcIfpBfejS31XswXf/kJ8NQCaDRjwT2bFg oJs5wnZtJRpMM8KZaSB9ecTUgPivLeFJzz8c2eqq1xLnvMNHFp3m5nKeyO1fghF9naGH 1a8Q==
X-Received: by with SMTP id fl5mr40722568pab.35.1410122036124; Sun, 07 Sep 2014 13:33:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id zr6sm7048393pbc.50.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 13:33:55 -0700 (PDT)
Message-ID: <>
Date: Mon, 08 Sep 2014 08:33:55 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [Ianaplan] I-D Action: draft-lear-iana-icg-response-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Sep 2014 20:33:58 -0000


Here are my comments after a careful reading of the draft.

IMHO the structure of the draft is right and I fully agree with
its message. All the comments below are subsidiary to that.

I think for the final submission to the world and the ICG, it
might be useful to make a pretty version with fonts and block
quotes to separate the ICG questions from the IETF responses,
even if the archival version is an ASCII RFC.

Now here are some specific comments and suggestions on the text:

>        o A description of the service or activity.
>    IETF Response:
>    Many IETF protocols make use of commonly defined protocol parameters.
>    These parameters are used by implementers, who are the IETF's primary
>    users of the IETF standards and other documents.  To ensure
>    consistent interpretation of these parameter values by independent
>    implementations...

insert: and universal interoperability of such implementations,

>        o A description of any overlaps or interdependencies between your
>          IANA requirements and the functions required by other customer
>          communities
>    IETF Response:
>    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.
>    o  The IETF has specified a number of special use registries.  These
>       registries require coordination with the GNSO.  We already perform
>       this coordination.

Add: These include certain IP addresses reserved by the IETF for technical

>    o  The IETF specifies the DNS protocol.  From time to time there are
>       changes.  We continue to coordinate with ICANN regarding those
>       changes.

Insert here:

o  The IETF specifies certain domain names reserved for technical reasons.

(These two additions are of course also called out in RFC 2860 and we
should not be coy about them.)

Now commenting on Russ's comment:

>        [[RH2]I think there are two areas of overlap:
>          Addresses: special-purpose addresses, such as anycast.  We need
>          to set up procedures to coordinate assignments.

Why? These are discussed in IETF open process when they occur, where
NRO and IANA people are welcome, so the coordination already happens.
This should be documented as an ongoing procedure.

>          Names: special-purpose names, such as .local.  We need to set
>          up procedures to coordinate such assignments.  ]]

Well, the same argument should apply: these names are discussed in IETF
open process. It isn't so clear that the naming community realises it,
however, and that is a possible area for outreach.

>    A.  Policy Sources
>    o  Which IANA service or activity (identified in Section I) is
>       affected.
>    IETF Respponse: The protocol parameters registry.

Add: This includes technical reservations in the IP address registry
and the domain name registry as noted above.

>    o  A description of how policy is developed and established and who
>       is involved in policy development and establishment.
>    IETF Response:
>    proposal as it progresses.  A proposal cannot be passed by the IESG
>    unless it enjoys sufficient community support as to indicate rough
>    consensus [RFC7282]  Last calls are made so that there is notice of
>    any proposed change to a policy or process.

Add: Like all IETF discussions, Last Calls are open to anybody.

(I know this is redundant but it needs to be underlined.)

>    o  References to documentation of policy development and dispute
>       resolution processes.
>    IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
>    conflict resolution and appeals process.

Change to:

IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies
the standards development process and a conflict resolution and appeals
process. Working group procedures are defined in [RFC2418].

(Question: should we actually list out the amendments to 2026 and 2418,
and the "Conduct of participants" RFCs such as you can find at ? Maybe an Apendix?)

>    o  A description of the entity or entities that provide oversight or
>       perform accountability functions, including how individuals are
>       selected or removed from participation in those entities.
>    IETF Response:
>    The Internet Architecture Board (IAB) is an oversight body of the
>    IETF whose responsibilities include, among other things, confirming
>    appointment of IESG members, managing appeals as discussed above,
>    management of certain domains, including .ARPA [RFC3172], and general
>    architectural guidance to the broader community.  The IAB is also
>    responsible for establishing liaison relationships with other
>    orgnaizations on behalf of the IETF.  The IAB's charter is to be
>    found in [RFC2860].

Add: Among other duties, the IAB must approve the appointment
of an organization to act as IANA on behalf of the IETF.

>    The IAB provides oversight of the protocol parameter registries of
>    the IETF, and is responsible for selecting appropriate operator(s)
>    and related per-registry arrangements.  Especially when relationships
>    among protocols call for it, many registries are operated by, or in
>    conjunction with, other bodies.  Unless the IAB or IETF has concluded
>    that special treatment is needed, the operator for registries is
>    currently ICANN.


Day to day responsibility for declaring IETF consensus on technical decisions,
including those that affect IANA, lies with the IESG. The IESG members are
also appointed by the NOMCOM process described above.

>    o  A description of the mechanism (e.g., contract, reporting scheme,
>       auditing scheme, etc.).  This should include a description of the
>       consequences of the IANA functions operator not meeting the
>       standards established by the mechanism, the extent to which the
>       output of the mechanism is transparent and the terms under which
>       the mechanism may change.
>    IETF Response:
>    A memorandum of understanding (MoU) between ICANN and the IETF
>    community has been in place since 2000.  It can be found in
>    [RFC2860].  It has been amended several times.  The MoU defines the
>    work to be carried out by the IANA staff for the IETF and IRTF.

NO, it has never been amended!! Please s/amended/augmented by supplementary
agreements/. This is important; every word of the MoU still stands as
ratified by the ICANN Board.