[CWG-Stewardship] Principles: revised draft 9 March

Tue Mar 10 02:46:13 UTC 2015

Martin:
Your footnote sounds good to me. Thanks for the reply.
Best regards,
John Poole

On Mon, Mar 9, 2015 at 6:52 PM, Martin Boyle <Martin.Boyle at nominet.org.uk>
wrote:

>  I have no objection to doing this – the wording is fine for me.  The
> first use of the term is in 5.ii, so I will add the footnote there for the
> next revision:  I’d suggest, “The term IANA functions operator refers to
> the entity organisational structure that provides the service.  It is
> independent of the organisation that hosts the operator, currently ICANN.”
>
>
>
> But I’m more than happy to hear alternatives.
>
>
>
> Martin
>
>
>
> *From:* john at expri.com [mailto:john at expri.com] *On Behalf Of *John Poole
> *Sent:* 09 March 2015 22:51
> *To:* Milton L Mueller
> *Cc:* Martin Boyle; cwg-stewardship at icann.org
>
> *Subject:* Re: [CWG-Stewardship] Principles: revised draft 9 March
>
>
>
> Milton,
> Your definition is fine so long as that is specific definition is added to
> the document (even as a footnote). The term is widely used to refer to
> ICANN generally, in NTIA, ICANN, and other documents, and I do not want
> confusion in the future, either by the CWG or others who may later read
> this.
>
> Best regards,
>
> John Poole
>
>
>
> On Mon, Mar 9, 2015 at 4:29 PM, Milton L Mueller <mueller at syr.edu> wrote:
>
> I thought we had agreed long ago that all references to the IANA functions
> operator were to the IANA functions operator per se, and not to ICANN,
> because it cannot and should not be assumed that ICANN will always be the
> IANA functions operator.
>
>
>
> *From:* cwg-stewardship-bounces at icann.org [mailto:
> cwg-stewardship-bounces at icann.org] *On Behalf Of *John Poole
> *Sent:* Monday, March 9, 2015 4:30 PM
> *To:* Martin Boyle
> *Cc:* cwg-stewardship at icann.org
> *Subject:* Re: [CWG-Stewardship] Principles: revised draft 9 March
>
>
>
> Martin:
>
> I know this has been raised before but I am still unsure of your
> terminology--please define "IANA Functions Operator" which appears multiple
> times in various contexts in the draft of Principles. Are you referring
> only to the IANA department within ICANN, or are you referring to ICANN?
> ICANN is referred to generally as the "IANA Functions Operator" in NTIA
> and ICANN and other documents
> <https://www.google.com/search?q=IANA+functions+operator>. The draft
> Principles seem to use the term in places as referring to ICANN and other
> places as referring only to the IANA department within ICANN--*e.g.*, in
> 5 iii: "... policy processes should be independent of the IANA Functions
> Operator ..."* i.e.,* policy processes should be independent of ICANN?
> Then who is making policy? Could you please clarify?
>
> Best regards,
>
> John Poole
>
>
>
> On Mon, Mar 9, 2015 at 12:34 PM, Martin Boyle <Martin.Boyle at nominet.org.uk>
> wrote:
>
>  Dear Colleagues,
>
>
>
> I attach a revised draft of the principles document based on our calls on
> 3 & 5 March.  I believe we have a text that is pretty much in its final
> form, with only one outstanding issue.
>
>
>
> Looking at the remaining highlighted changes:
>
>
>
> 5.ii & iii:  These are mainly editorial and have been discussed without
> opposition on recent calls.
>
>
>
> 5.iv footnote:  We had comments about the meaning of consensus in the
> footnote.  I do not think that defining consensus is in the remit of this
> document, but is part of the considerations of any entity that we
> establish.  Hence I have added, “Conditions for consensus will need to be
> agreed appropriate for the group” to make this clear.
>
>
>
> 5.vi: As I said when I flagged this paragraph as of concern, I am
> inherently uneasy about a principle that is essentially optional and where
> it might need to be re-written because of subsequent choices that we make.
> Either it is a principle or it isn’t.  I believe that we need to understand
> the implications of what we are trying to say, so I am taking editor’s
> right to propose a new formulation that should be independent of subsequent
> decisions.
>
>
>
> 6.ii:  Was agreed as not being a principle last week.
>
>
>
> 7.i:  Editing agreed last week.
>
>
>
> 7.ii:  We took this off-line.  There has been some progress in discussions
> with Paul and Elise.  I have made a drafting proposal to both for wording
> that tries to take into account the concerns they have expressed.  However,
> this paragraph needs to be held in abeyance until we have heard the views
> of both.
>
>
>
> 8.ii:  In discussion with Erick, we have identified a compromise that
> moves away from saying anything about the policy authority and who it might
> or might not be.  The proposed wording (“In particular, the IANA functions
> operator should not impose any additional requirements on the registry
> unless they are directly and demonstrably linked to global security,
> stability and resilience of the DNS.”) turns this around to prevent the
> IANA functions operator making unilateral decisions that impact the ccTLD
> except in (rare) cases of global security, stability and resilience.  *Given
> the delicate balance behind this text, I hope that others will find this
> formulation acceptable* and I thank Erick for his support in finding this
> compromise.
>
>
>
> 9.i:  A minor point here that was discussed last week.  The wording is not
> necessary to the text, but does make it clearer that i. is about
> separability now and iii. says we would need to include separability for
> all future IANA functions operators.
>
>
>
> 10:  A reasonable edit proposed by Mary last week:  no objections have
> been raised.
>
>
>
> Hence I would hold 5.ii-iv, 6.ii, 7.i, 9.i and 10 to be agreed text if
> there are no objections.
>
>
>
> 5.iv:  I suggest we use the new wording unless there is significant
> opposition.
>
>
>
> 7.ii:  This has to stay in abeyance subject to agreement by Elise (in
> discussion with the GAC) and by Paul Kane.
>
>
>
> 8.ii:  Again I suggest we use the proposed wording unless there is
> significant opposition.
>
>
>
> I look forward to comments on this approach, and please do flag early any
> difficulties you might have with any of the proposals.
>
>
>
> Best
>
>
>
>
>
> Martin
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150309/5e695aa8/attachment.html>