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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Sep 2014 08:33:55 +1200

Hi,

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

...
>    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
http://www.ietf.org/about/process-docs.html#anchor6 ? 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.

Add:

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.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Sep 2014 07:47:45 +1200

One glitch in my comments has been brought to my attention:

On 08/09/2014 08:33, Brian E Carpenter wrote:
...

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

They of course need to be coordinated with the ASO, not the GNSO.

...
> This should be documented as an ongoing procedure.

Again, that should be ASO.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Sep 2014 15:16:48 +0200

Hi Brian,

Going through your comments...

> insert: and universal interoperability of such implementations,

I propose to change this as follows:

       To ensure consistent interpretation of these
        parameter values by independent implementations, and to
        promote universal interoperability

> Add: These include certain IP addresses reserved by the IETF for technical
The first part of the text refers to RFC 6761.  What you are talking
about is covered separately in RFC 6890.  I am not sure this strictly
counts as overlap (see another message I just sent).  I propose that we
add appropriate references to both, and to clarify the first bullet as
follows:

          The IETF has specified a number of special use registries
          with regard to domain names.  These registries require
          coordination with the GNSO.  We already perform this
          coordination.[RFC6761]

> should not be coy about them.)

That is now captured in the previous point.  But I would say that the
wording in the above bullet could be sharpened, and I propose the following:

          The IETF specifies the DNS protocol.  From time to time
          there have been and will be updates to that protocol.  We
          will continue to coordinate with ICANN regarding those
          changes.

> however, and that is a possible area for outreach.

My proposal is to remove Russ' comment.  Russ can propose additional
text if he feels it necessary.
> and the domain name registry as noted above.

This issue requires more input, in my opinion.

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

I've inverted it slightly to:

"Anyone may comment during a Last Call" and made slight editorial
changes to the tense of the text.

> process. Working group procedures are defined in [RFC2418].

You are not the first person to suggest including RFC2418.  I propose we
accept the above change.
> http://www.ietf.org/about/process-docs.html#anchor6 ? Maybe an Apendix?)

I propose the following text in the same section to address the point
you are making:

        Note that both of these documents have been
        amended    in later RFCs as indicated in the RFC-INDEX.

> of an organization to act as IANA on behalf of the IETF.

I propose that this text be included as stated.
> also appointed by the NOMCOM process described above.

The question is who provides oversight and accountability.  That is not
a function for the IESG, but for the IAB.  I have no problem including
this text elsewhere, if you can tell me where that "elsewhere" should be ;-)

> ratified by the ICANN Board.

I propose to accept the above change and all others I indicated
proposals for unless I hear objections in the next day or so.  I'll try
to have an update out shortly thereafter.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Sep 2014 18:28:57 +0300

> to have an update out shortly thereafter.

Thanks. Brian is right above.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Sep 2014 10:21:52 +1200

Thanks Eliot. I have trimmed what follows to points where
something still seems to be open; otherwise I'm happy with your
responses.

On 11/09/2014 01:16, Eliot Lear wrote:
...
>           coordination with the GNSO.  We already perform this

Yes. I was confused. I do think that coordination with the ASO needs to be
mentioned with regard to special purpose addresses.
...
> This issue requires more input, in my opinion.

Yes, it's a delicate point of phrasing but I think the point
needs to be made somehow. To be specific, I am referring to
at least the following:

http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv6-special-registry-1
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain

> this text elsewhere, if you can tell me where that "elsewhere" should be ;-)

Well, I would include the IESG in "oversight" because they are the first
point of appeal after the WG chair. So I think we disagree on where
this fits.

That said, it could be fitted into the response to
      o A description of the customer(s) of the service or activity.
       [N.B. the IETF response has swapped this question with the next.]
where you mention the IESG.

Nit alert: I just noticed that you have "the Internet Engineering Steering
Community", which is an amusing concept ;-).

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Sep 2014 16:03:44 +0200

Hi Brian,

> mentioned with regard to special purpose addresses.

Ok.  I think I agree because it is possible that the IETF might for some
reason need to mark previously allocated unicast address space as
special purpose addressing, based on whatever circumstances develop. 
This has in effect happened previously, and so it is worth
mentioning.    Therefore, I propose the following text:

       The IETF has established registries with IANA for special
        IPv4 and IPv6 assignments.  These are specified
        in [RFC6890].  The IETF    coordinates such
        assignments with the RIRs.
       
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain

I think this is now covered above.
> where you mention the IESG.

I've accordingly amended the text in that section.
> Community", which is an amusing concept ;-).

Thanks.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Sep 2014 10:48:30 +1200

Thanks Eliot, I think that covers all my points for now.

Regards
   Brian