Re: [Ianaplan] A draft for your review

["Leslie Daigle (TCE)" <[e-mail]>]

I have to say, I stumbled over the "customer" wording, too.  It seems to 
me that a key thing for the protocol parameters is to make sure it is 
crystal clear that the IETF drives its use of this function.  While I 
agree completely that it is the IETF that is the customer, I think we'd 
best be clear that it is only in the sense of selecting a service 
provider to implement the function.

To that end, I wonder about undoing the re-ordering of the bullets in 
the RFP, to define the service first.

[From the draft:]
>      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, a globally available registry contains the parameter
>    values and a pointer to documentation of the associated semantic
>    intent.  The IETF uses the IANA protocol parameter registries for
>    this purpose.


Perhaps, instead:
    Many IETF protocols require the use of protocol parameters.
    These parameters are used by implementers, who are the primary
    users of the IETF standards and other documents.  To ensure
    consistent interpretation of these parameter values by independent
    implementations, these IETF protocol specifications define and 
require a globally available registry containing the parameter
    values and a pointer to documentation of the associated semantic
    intent.  The IETF uses the IANA protocol parameter registries to 
implement such registries.


And then:


> I.  Description of Community's Use of IANA Functions
>
>
>       This section should list the specific, distinct IANA services or
>       activities your community relies on. For each IANA service or
>       activity on which your community relies, please provide the
>       following:
>
>        o A description of the customer(s) of the service or activity.
>       [N.B. the IETF response has swapped this question with the next.]

As noted above -- I'm not sure swapping is helpful.

>
>
>    IETF Response:
>
>    The customer of the IANA protocol parameters function is the Internet
>    Engineering Task Force (IETF).

Perhaps instead:

"The IETF is a customer of the IANA protocol parameter function to 
implement its standards' protocol registries."



If we want to mark all four corners:

> o What registries are involved in providing the service or
>          activity.
>
>
>
>    IETF Response:
>
>    Administration of the protocol registries are themselves the service
>    that is provided to the IETF community by ICANN.

Perhaps:

"The protocol parameter registries are the product of IETF work. 
Administration of the protocol parameter registries is the service that 
is provide to the IETF [no "community" -- it's the organization] by ICANN."


Just some thoughts.

Leslie.





On 8/30/14 9:29 AM, Richard Hill wrote:
> Dear Eliot and Russ,
>
> Thank you very much for this excellent draft.
>
> I have some comments, some minor, some rather more substantive.
>
> 1) In section 1, the draft says "In that announcement, NTIA asked the
> Internet Corporation for Assigned Names and Numbers (ICANN) to
> establish a process to deliver a proposal for transition."
>
> I think that it would be better to include the full mandate, and to
> say: "In that announcement, NTIA asked the Internet Corporation for
> Assigned Names and Numbers (ICANN) to establish a process to deliver
> a proposal to transition key Internet domain name functions to the
> global multistakeholder community."
>
> 2) In section 2, Part I, the proposed IETF response is "The customer
> of the IANA protocol parameters function is the Internet Engineering
> Task Force (IETF)."
>
> I think that this is literally true, but I think it is also worth
> noting here (as the draft does later on) that the real users of the
> protocol parameters are various implementers.  So perhaps this could
> be modified to read: "The customer of the IANA protocol parameters
> function is the Internet Engineering Task Force (IETF), which acts on
> behalf of the numerous implementers that use specific parameter
> values."
>
> 3) In section 2, Part III, at the end, the proposed IETF response is
> "Because of the nature of the agreement, questions of jurisdiction
> are immaterial."  I don't think that this is appropriate, because the
> agreement in question might well be considered a contract. I don't
> see any choice of law or venue clause in the MoU or its 2014
> Supplemental Agreement, so I think that the current situation would
> better be reflected as follows:
>
> "Because of the nature of the agreement, and its dispute resolution
> and escalation clauses, it is not expected that any disputes would
> arise that would require court interventions."
>
> And you might wish to add "Should any such disputes arise, the
> jurisdiction would be the compentent jurisdiction depending on the
> nature of the dispute and the parties to the dispute."
>
> 4) Related to the above, should consideration be given to adding a
> proper dispute resolution clause, that is, including choice of law
> and venue, to the agreement?  For example, that the venue for any
> disputes would be the seat of ISOC, which is the legal entity
> involved from the IETF side.
>
> 5) In section 2, part IV, the proposed IETF response is "No changes
> are required, as over the years since the creation of ICANN, the
> IETF, ICANN, and IAB have together created a system of agreements,
> policies, and oversight mechanisms that covers what is needed."
>
> I would suggest that this be slightly modified to read "No
> operational changes are required, ..."
>
> The reason for this change is that some non-operational changes may
> be required, see below.
>
> 6) In section 2, part IV, under "Transition Implications", the IETF
> response is "No structural changes are required." This is correct,
> but I think that some contractual changes are required in order to
> make it clear that the ultimate authority for the protocol parameters
> is IETF, not ICANN.
>
> So I would propose to add, at the end of that section, the following
> three paragraphs.
>
> "At present, article I.1 of the ICANN Bylaws implies that ICANN has
> the overall responsibility for the coordination and allocation and
> assignment of the protocol parameters. That article should be
> modified to make it clear that, as specified in RFC 2860, it is the
> IETF that has the overall responsibility for the coordination and
> allocation and assignment of the protocol parameters.
>
> "And item 4 of RFC 2860 should be modified to read as follows:
>
> "4. Agreed technical work items.  ICANN agrees, notwithstanding any
> provisions in its Bylaws or other corporate documents that might be
> construed differently, that during the term of this MOU it shall
> cause IANA to comply ..."
>
> For reference, item 4 of RFC 2860 currently reads "4. Agreed
> technical work items. ICANN agrees that during the term of this MOU
> it shall cause IANA to comply ..."
>
> 7) There was extensive discussion (but no agreement) on the IANA
> Transition mailing list regarding whether or not the fact that a US
> court could, in theory, order ICANN/IANA to do something contrary to
> agreed community policies is an issue and, if so, whether anything
> should be proposed to deal with that issue, such as proposing that
> the entity that performs the IANA function should have immunity of
> jurisdiction, or that the entity should have redundant sites in more
> than one jurisdiction.
>
> If there is support for dealing with that issue, then some text could
> be added.
>
> Thanks again for the great work and best, Richard
>
> -----Original Message----- From: Ianaplan
> [mailto:[e-mail]]On Behalf Of Eliot Lear Sent:
> samedi, 30. août 2014 09:32 To: [e-mail] Cc: Russ Housley
> Subject: [Ianaplan] A draft for your review
>
>
> Dear colleagues,
>
> I have posted a -00 draft that seeks to respond to the most current
> version of the RFP I could get my hands on.  Would you kindly provide
> some thoughts about it?  I am most particularly concerned about
> substance at the moment.  The sorts of things I'm looking for are
> these:
>
> Is the text in the "IETF Response" accurate and in fact responsive to
> the question? Is there anything missing? Is there anything that does
> not parse well?  Did you think "Huh??" when you read a sentence? My
> intent is to have a second version out prior to the cutoff for the
> Honolulu meeting as a candidate for the IANAPLAN working group to
> adopt, assuming the working group is chartered.
>
> Kind thanks to Russ Housley and the members of the IAB IANA Strategy
> Program for their very helpful contributions.  I've indicated myself
> and Russ as editors, because we have not been the only ones to insert
> text on this.
>
> Eliot ps: I am aware that the formatting could stand some
> improvement.  I will work on that for the next version.
>
> _______________________________________________ Ianaplan mailing
> list [e-mail]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------