[discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body

Sun Mar 16 17:41:49 UTC 2014

Absolutely agree with all what Steve has said below. Very much inline with
the few lines i posted earlier.

Thanks Steve.

Cheers!

On Sun, Mar 16, 2014 at 6:32 PM, Steve Crocker <steve at shinkuro.com> wrote:

> Greg, et al,
>
> I do not read NTIA's announcement as calling for the creation of a new
> organization nor the movement or replacement of the current contract with
> another contract.  Instead, I believe NTIA is asking for the community to
> think through how to replace the role the NTIA has performed, which is only
> a review of the root zone update actions and ICANN's processes and
> reporting.
>
> I think it would be very helpful to everyone to focus first on coming up
> with a list of *issues* and *principles* before suggesting specific
> mechanisms or solutions.  By "issue" I mean a problem that needs to be
> solved or an aspect of the current arrangement that is not satisfactory in
> some fashion.  And the focus here really needs to be on the functions
> covered by the current IANA contract.  Issues related to gTLD contractual
> matters, overall organization of ICANN, non-ICANN matters such as network
> surveillance by various governments, etc. are quite far outside the scope.
>  There are other venues for discussing those topics.
>
> By "principles" I mean qualities that need to be preserved going forward.
>
> If the community can agree on a set of issues and principles, I think the
> path forward will be much clearer.  If the issues and principles are in
> place, choosing a specific mechanism becomes, to use the tongue-in-cheek
> phrasing from the technical community, just an implementation detail.
>
> Steve
>
>
>
>
> On Mar 16, 2014, at 12:59 PM, Shatan, Gregory S. <GShatan at ReedSmith.com>
> wrote:
>
> > At the most basic level, the NTIA is going to assign the IANA Contract
> to the new organization created by this process ("NewOrg"), so that NewOrg
> steps into the shoes of the NTIA.
> >
> > Then the question becomes should the IANA Contract be "revised" or
> "renegotiated" as part of the process to add to, subtract from or modify
> the privileges and obligations of NewOrg and ICANN?  By what process and
> who will be involved?  And -- is this question set even on the table? Or is
> the contract being assigned "as is "?
> >
> > Also, what will NewOrg look like? What form, what domicile, what
> governance? This is probably the question set more directly asked as a
> result of the NTIA announcement.
> >
> > Greg Shatan
> > --------------------------
> > Sent from my BlackBerry Wireless Device
> >
> >
> > ----- Original Message -----
> > From: John Curran [mailto:jcurran at istaff.org]
> > Sent: Sunday, March 16, 2014 09:24 AM
> > To: Milton L Mueller <mueller at syr.edu>
> > Cc: 1Net List <discuss at 1net.org>; <governance at lists.igcaucus.org> <
> governance at lists.igcaucus.org>
> > Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web
>  Policymaking Body
> >
> > On Mar 15, 2014, at 12:25 PM, Milton L Mueller <mueller at syr.edu> wrote:
> >
> >> Furthermore, I would refer people back to the IGP plan, and the call to
> separate the globalization/reform of the IANA functions from the broader
> and more difficult reforms that must be made in ICANN's policy making
> process, domicile, etc. Parminder's comments confuse these two things.
> >
> > The existing co-mingling of overall Internet identifier coordination
> role, DNS policy
> > development role, and IANA administration and implementation role (all
> within ICANN)
> > does make it difficult at times to keep track of which aspect we are
> talking about
> > at any given moment...
> >
> >> Let's do one thing at a time, so that each can be done right. The
> distinction between ICANN's policy process, its corporate domicile, its
> contracts with registries, etc., with the globalization of the IANA
> functions has been reiterated many times on this list. We don't have to
> change everything about ICANN in one stage. Once the IANA functions are
> dealt with, a lot of options open up regarding the policy process.
> >
> > I'd like to explore the various roles just a bit, so I can better
> understand what is
> > really proposed in "the IGP plan".  To do this, I'd like to consider the
> tasks performed
> > for the generic case of IANA protocol parameter registries and then for
> the specific
> > case of the DNS root zone registry, as revised per the IGP proposal.
> >
> > (I'll spare repeating all of the IETF registry background, but one can
> refer to for
> > <http://1net-mail.1net.org/pipermail/discuss/2014-March/002434.html>
> for reference)
> >
> > When the IETF specifies a protocol, there are often associated
> registries.  To a rough
> > approximation, the IESG is the policy development body (as it works with
> the community
> > via working groups and approves the registry creation via the "IANA
> Considerations'
> > section of an RFC) and the IAB is the registry authority.  Via the
> mechanisms in RFC
> > 6220 and per an MOU with ICANN (RFC 2860), the IAB has arranged for
> ICANN to perform
> > the IANA registry administration and operations tasks.  In this role,
> IANA receives
> > requests from third parties to make entries in any IETF registry, and if
> they conform
> > with the established policy for the registry then the entry is made.
>  This approach
> > encourages both clarity of registry policy as well as fair and impartial
> administration
> > of the registry itself.
> >
> > The IAB also noted that some general-propose registries (DNS names and
> IP addresses)
> > pose "policy issues", and per the MOU with ICANN recognizes that ICANN
> may have policy
> > which affect how those registries (such as the DNS root zone) are
> administered (and
> > this is a good thing because the the IANA function contract with NTIA
> specifically
> > calls for the IANA to follow ICANN policy when processing DNS root zone
> requests...)
> >
> > With respect to DNS root zone, there is a significant difference being
> proposed in
> > the roles under the IGP proposal, in that you have ICANN-sans-IANA
> performing policy
> > development _and_ policy administration roles, i.e. from reading, it is
> hard to tell
> > if your new "DNSA" is only performing the clerical registry operations
> task, as opposed
> > to the actual administration of policy via processing of incoming
> requests for changes
> > from the community -
> >
> >  "The DNSA would require a binding contract with ICANN regarding the
> conditions
> >   under which it would agree to implement changes in the root zone or
> other
> >   associated databases to reflect policies emerging from ICANN's policy
> development
> >   processes. The contract should ensure that the DNSA has no policy
> authority but
> >   merely implements valid requests for additions or deletions emerging
> from ICANN's
> >   policy process."
> >
> > From the above, is the determination of a "valid request" performed
> first by ICANN
> > (and the result send to DNSA for processing), or does DNSA receive the
> "raw" request
> > and make the determination of validity in accordance with the
> established policy?
> > I believe you intended the former: ICANN-sans-IANA would the body which
> performs
> > policy administration and it then sends only clerical direction for
> registry update
> > to the DNSA, but could potentially read the proposal either way.
> >
> > Thoughts?
> > /John
> >
> > Disclaimer: My views alone.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at 1net.org
> > http://1net-mail.1net.org/mailman/listinfo/discuss
> >
> >
> >
> >                                                                * * *
> >
> > This E-mail, along with any attachments, is considered
> > confidential and may well be legally privileged. If you have received it
> in
> > error, you are on notice of its status. Please notify us immediately by
> reply
> > e-mail and then delete this message from your system. Please do not copy
> it or
> > use it for any purposes, or disclose its contents to any other
> > person. Thank you for your cooperation.
> >
> >                                                                * * *
> >
> > To ensure compliance with Treasury Department regulations, we
> > inform you that, unless otherwise indicated in writing, any U.S. Federal
> tax
> > advice contained in this communication  (including any attachments) is
> not
> > intended or written to be used, and cannot be used, for the purpose of
> (1)
> > avoiding penalties under the Internal Revenue Code or applicable state
> > and local provisions or (2) promoting, marketing or recommending to
> another
> > party any tax-related matters addressed herein.
> >
>  Disclaimer Version RS.US.20.10.00
> > _______________________________________________
> > discuss mailing list
> > discuss at 1net.org
> > http://1net-mail.1net.org/mailman/listinfo/discuss
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
>

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

*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>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140316/ad0bcfb2/attachment.html>