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

[Eliot Lear <[e-mail]>]

Hi Brian,

Going through your comments...

On 9/7/14, 10:33 PM, Brian E Carpenter wrote:
>>        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,
>
> ...

I propose to change this as follows:

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

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


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

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.

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

My proposal is to remove Russ' comment.  Russ can propose additional
text if he feels it necessary.
>
>>    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.

This issue requires more input, in my opinion.

>
>>    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've inverted it slightly to:

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

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

You are not the first person to suggest including RFC2418.  I propose we
accept the above change.
>
> (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?)

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.

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

I propose that this text be included as stated.
>
> ...
>>    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.

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 ;-)

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

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