Dear Leslie,

Thank you for this.  I agree that this is an improvement over "03" but,
regretfully, I cannot support this text, for both procedural and subtantive
reasons.  In essence, I don't think that it is a plan, and I don't think
that it identifies the additional documentation or agreements required to
address the removal of the overarching NTIA contract (I'm paraphrasing here
from this group's charter).  Note that the charter explicitly empowers this
group to request the IAOC to provide such agreements.

The charter of this group assumes that current arrangements will continue,
and in particular that the existing MoU between ICANN and IETF will continue
to remain in force.

In my view, that will not be the case unless additional agreements are made.
I will give one specific example, but analogous reasoning applies to other
issues that have been raised.

David Conrad has correctly pointed out that the current IANA Functions
contract between NTIA and ICANN does not prevent ICANN from charging fees
for performance of the IANA function, under certain conditions.  ICANN can
charge fees as long as the fee structure is approved by NTIA, is fair,
reasonable, based on the cost of providing the services, and developed in
collaboration with the affected parties.

The current MoU between the IETF and ICANN specifies that the IANA function
services for the protocol parameters will be provided free of charge.

It is not clear to me that that MoU is a legally binding contract.  If it is
not, then, absent the NTIA contract, there are no contractual or legal
restrictions preventing ICANN from charging whatever fees it considers
appropriate for the IANA function.  That is, the "fair, reasonable,
cost-based, and collaboration" elements of the current arrangement would no
longer be legal requirements.

Some people are not concerned about legal requirements, so they are not
worried about this.

But, from my point of view, the new legal/contractual structure should be
similar to the current legal/contractual structure, and that will not be the
case if the IAOC is not requested to provide additional agreements, meaning
legally binding contracts.

That is, both "03" and the language that you are proposing would result in a
transition in which the legal/contractual structure is significantly
different from the current structure.

Again, some think this is not an issue, but I beg to differ.  I think that
it is an issue.

So I cannot support either "03" or the new language.

But I thank you again for having made the proposal,
Best,
Richard



> -----Original Message-----
> From: Ianaplan [mailto:ianaplan-bounces@ietf.org]On Behalf Of Leslie
> Daigle (TCE)
> Sent: mercredi, 19. novembre 2014 19:24
> To: ianaplan@ietf.org
> Subject: [Ianaplan] Where (I think) we're at and a final suggestion Re:
> Trial balloon: suggested text
>
>
>
> Okay, reading the list traffic, I'd say that virtually no one likes "3)"
> in the proposed new text. "2)" and "3)" don't shift consensus from where
> we were with -03.
>
> But.
>
> The one thing I wonder if we might want to retain from yesterday's
> proposed text is something from "However in the absence of the NTIA
> contract a few new arrangements have to be put in place that will ensure
> that: ".   Consistently with what this document is meant to do, I think
> it signals that the IETF does recognize that there is change with the
> departure of the NTIA from the scene.
>
> There was support for that language in the list discussion; there was
> also some pushback on it in the specific context of the complete redraft
> of the section.
>
> So, my last suggestion, working to find wording to capture that
> sentiment in a document expressing what the consensus of the IETF
> community is (not the instrument for effecting change), follows.
>
> The one question is:  does this make a better statement than the
> original -03 text, or not, or indifferent?
>
>
>
> [Proposed adjustment to the text as found in
> draft-ietf-ianaplan-icg-response-03:]
>  > IANA protocol parameters registry updates will continue to function
>  > day-to-day, as they have been doing for the last decade or more.  The
>  > IETF community is quite satisfied with the current arrangement with
>  > ICANN.  RFC 2860 remains in force and has served the IETF community
>  > very well.  RFC 6220 has laid out an appropriate service description
>  > and requirements.
>  >
> Insert:
>
> However in the absence of the NTIA contract a few new arrangements may
> be needed in order to ensure the IETF community's expectations are met.
>   Those expectations are:
>
>  > The protocol parameters registries are in the public domain.  It is
>  > the preference of the IETF community that all relevant parties
>  > acknowledge that fact as part of the transition.
>  >
>  > It is possible in the future that the operation of the protocol
>  > parameters registries may be transitioned from ICANN to subsequent
>  > operator(s).  It is the preference of the IETF community that, as
>  > part of the NTIA transition, ICANN acknowledge that it will carry out
>  > the obligations established under C.7.3 and I.61 of the current IANA
>  > functions contract between ICANN and the NTIA [NTIA-Contract] to
>  > achieve a smooth transition to subsequent operator(s), should the
>  > need arise. Furthermore, in the event of a transition it is the
>  > expectation of the IETF community that ICANN, the IETF, and
>  > subsequent operator(s) will work together to minimize disruption in
>  > the use the protocol parameters registries or other resources
>  > currently located at iana.org.
>
>
> Leslie.
>
> On 11/18/14 12:43 PM, Leslie Daigle (TCE) wrote:
> >
> > Out of band, there's been a suggestion of text for a possible "middle
> > ground" between -02 and -03.
> >
> > While, as one of the chairs of this WG, I am pretty comfortable that the
> > -03 version of the document reflects the WGLC comments, and that we have
> > (rough!) consensus to move forward, I'd like to hear whether proponents
> > of -02 text think this suggestion is better than -03 (and, from -03
> > proponents, whether this is unacceptable).
> >
> >
> > [Elsewhere, Andrei Robachevsky suggested the following change:]
> >
> > [OLD] draft-ietf-ianaplan-icg-response-03:
> >
> >> IANA protocol parameters registry updates will continue to function
> >> day-to-day, as they have been doing for the last decade or more.  The
> >> IETF community is quite satisfied with the current arrangement with
> >> ICANN.  RFC 2860 remains in force and has served the IETF community
> >> very well.  RFC 6220 has laid out an appropriate service description
> >> and requirements.
> >>
> >> The protocol parameters registries are in the public domain.  It is
> >> the preference of the IETF community that all relevant parties
> >> acknowledge that fact as part of the transition.
> >>
> >> It is possible in the future that the operation of the protocol
> >> parameters registries may be transitioned from ICANN to subsequent
> >> operator(s).  It is the preference of the IETF community that, as
> >> part of the NTIA transition, ICANN acknowledge that it will carry out
> >> the obligations established under C.7.3 and I.61 of the current IANA
> >> functions contract between ICANN and the NTIA [NTIA-Contract] to
> >> achieve a smooth transition to subsequent operator(s), should the
> >> need arise. Furthermore, in the event of a transition it is the
> >> expectation of the IETF community that ICANN, the IETF, and
> >> subsequent operator(s) will work together to minimize disruption in
> >> the use the protocol parameters registries or other resources
> >> currently located at iana.org.
> >
> >
> >
> >
> > NEW:
> >
> > IANA protocol parameters registry updates will continue to function
> > day-to-day, as they have been doing for the last decade or more.  The
> > IETF community is quite satisfied with the current arrangement with
> > ICANN.  RFC 2860 remains in force and has served the IETF community very
> > well.  RFC 6220 has laid out an appropriate service description and
> > requirements.
> >
> > However in the absence of the NTIA contract a few new arrangements have
> > to be put in place that will ensure that:
> >
> > 1) The protocol parameters registries are in the public domain.
> >
> > 2) In case of future need to transition the operation of the protocol
> > parameters registries from ICANN to subsequent operator(s), this
> > transition will be smooth and have minimum disruption in the use the
> > protocol parameters registries or other resources currently located at
> > iana.org. This arrangement should be comparable to current obligations
> > established under C.7.3 and I.61 of the current IANA functions contract
> > between ICANN and the NTIA [NTIA-Contract].
> >
> > 3) For any future change in the cost of providing these services
> > (currently at zero cost), these costs are fair and reasonable,
> > negotiated, and ample time is given for the transition to the new cost
> > and fee structure.
> >
> >
> >
> > Leslie.
> >
> >
>
> --
>
> -------------------------------------------------------------------
> Leslie Daigle
> Principal, ThinkingCat Enterprises
> ldaigle@thinkingcat.com
> -------------------------------------------------------------------
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>