[CWG-Stewardship] Principles: revised draft 9 March

Tue Mar 10 18:22:47 UTC 2015

Hello Martin,

Well it seem to me that that new text you proposed may still be "wish
based" version and not necessarily "what is". However i agree with your
definition of the IANA operator to the extent that ICANN is the current
operator (ref: SAC 067 from page 10). So i think the translation of that
could mean the following:

“The term IANA functions operator refers to the entity that provides the
service, the entity is hosted by an organisation, currently ICANN”

Putting the word independent seem to loose the essense of the
operator/contractor (which is currently ICANN). I think there is difference
between "independent" and "functional separation". IANA is just a set of
tasks that is currently executed by ICANN.

Regards

On Tue, Mar 10, 2015 at 6:35 PM, Martin Boyle <Martin.Boyle at nominet.org.uk>
wrote:

>  Hi Seun,
>
>
>
> I’m not sure I agree with you!
>
>
>
> IANA functions operator is the phrase used to identify the operator *only*.
> It needs to be independent of where that role might sit.  Currently it is a
> part of ICANN, but in the future it might be with another organisation,
> dependent on who wins a RfP launched by Contract Co. or triggered by a
> golden bylaw.
>
>
>
> But your comment has had me re-reading the text and I do see some
> potential for confusion.  So I wonder whether, “The term IANA functions
> operator refers to the entity that provides the service, independent of the
> organisation that hosts it, currently ICANN” would be better.
>
>
>
> What do you think?
>
>
>
> Martin
>
>
>
>
>
> *From:* Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
> *Sent:* 10 March 2015 18:16
> *To:* Martin Boyle
> *Cc:* John Poole; cwg-stewardship at icann.org; Milton L Mueller
>
> *Subject:* Re: [CWG-Stewardship] Principles: revised draft 9 March
>
>
>
> Hi,
>
> While i have no major objection to this, I am not sure that description is
> correct. ICANN is the operator of IANA simple, so I don't think an attempt
> to describe IANA operator in the proposed manner is adequate.(it's like
> saying sidely) However perhaps it can be used for the purpose of the
> document only. So I propose the following:
>
> "For the purpose of this document, the term IANA functions operator refers
> to the entity that provides the service.  It is part of the organisation
> that hosts the function, currently ICANN.”
>
> Regards
> sent from Google nexus 4
> kindly excuse brevity and typos.
>
> 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
>
>
>
>
>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
<seun.ojedeji at fuoye.edu.ng>*

The key to understanding is humility - my view !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150310/d5f047f6/attachment-0001.html>