ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [ga] Report on the NC Transfers Task Force activities


In my opinion, Bret's explanation of the consensus process is right on
target.  With regard to impacted parties though, I would add one more to the
registrars and registrants.  The registrar transfer process also involves
registries.  In fact, the transfer process is part of the contractual
relationship between registries and registrars (the Registry Registrar
Agreement).  Depending on what is proposed as a solution, there are
contractual and possibly implementation issues for registries as well.

Chuck

> -----Original Message-----
> From: Bret A. Fausett [mailto:baf@fausett.com]
> Sent: Tuesday, November 06, 2001 5:00 PM
> To: Rick H Wesson
> Cc: ga@dnso.org
> Subject: Re: [ga] Report on the NC Transfers Task Force activities
> 
> 
> > Besides, don't you think its time we learn how to develop a 
> "consensus
> > policy?"
> 
> Absolutely. Here's my view of how it should be done.
> 
> While the DNSO generally operates by consensus (Bylaws, 
> Article VI-B(2)(b)),
> new policies that purport to place binding obligations on 
> registries and
> registrars, like the transfer policy now under consideration, 
> have to meet a
> more specific definition of a "consensus policy" as set out 
> in the various
> accreditation contracts:
> 
>   "Consensus Policies" are those adopted based on a consensus
>   among Internet stakeholders represented in the ICANN process,
>   as demonstrated by (1) the adoption of the policy by the
>   ICANN Board of Directors, (2) a recommendation that the policy
>   should be adopted, by at least a two-thirds vote of the council
>   of the ICANN Supporting Organization to which the matter is
>   delegated, and (3) a written report and supporting materials
>   (which must include all substantive submissions to the Supporting
>   Organization relating to the proposal) that (i) documents the
>   extent of agreement and disagreement among impacted groups,
>   (ii) documents the outreach process used to seek to achieve
>   adequate representation of the views of groups that are likely
>   to be impacted, and (iii) documents the nature and intensity of
>   reasoned support and opposition to the proposed policy.
> 
> http://www.icann.org/registrars/ra-agreement-10nov99.htm 
> (Section I.B.1)
> http://www.icann.org/registrars/ra-agreement-17may01.htm 
> (Section 4.3.1)
> 
> As I see it, you read that definition backwards to find the 
> chronological
> order in which a consensus policy is created. In other words, 
> you first need
> to create a report that meets the definition in subsection 
> (3). That report
> is then adopted by the Names Council as specified in 
> subsection (2). And, in
> turn, the report and the NC recommendation to adopt it are 
> passed to the
> Board for a final vote, as set out in subsection (1). Only then are
> registries and registrars bound to follow it.
> 
> The job of a Working Group is to start the process by 
> creating the report
> described in Section 3.
> 
> The first requirement for the report is that it document "the 
> extent of
> agreement and disagreement among impacted groups." In the 
> present case, the
> "impacted groups" are pretty clearly the registrars and the 
> registrants. If
> the latter voice is not represented, or even inadequately 
> represented, then
> it's simply not possible to adequately complete this section 
> of the report.
> 
> The next requirement of the report is that it document the 
> "outreach process
> used to seek to achieve adequate representation of the views 
> of groups that
> are likely to be impacted." This obviously assumes that there 
> is an outreach
> process and that it is adequate for the task. In an open 
> working group, the
> process is part of the outreach, as impacted parties given 
> adequate notice
> of the opportunity to join can readily participate 
> themselves. In a closed
> task force, affirmative outreach to impacted parties must be 
> undertaken,
> both through the constituencies and to any unrepresented 
> impacted groups.
> 
> I'm also skeptical that a TF that began work on 29 October 
> can create a
> "consensus policy" -- with all the outreach and documentation 
> that such a
> policy requires -- in time for a vote by the NC and ICANN 
> Board next week.
> While it seems that the registrars have done an excellent job 
> preparing
> something that has broad support from their constituency, the 
> process is
> only half complete as long as the much larger and very 
> diverse community of
> registrants has not also expressed its opinion.
> 
> Commercial and non-commercial organizational registrants *might* be
> adequately represented through the existing constituencies 
> (B&C, NCDNHC),
> but individual domain name owners are not. Is the GA an 
> adequate forum for
> representing them? I don't know. This is an instance though 
> in which our
> collective failure to create a constituency for individual domain name
> holders may have an impact, as it's not clear how to solicit 
> the views of
> this impacted group.
> 
> Given the fact that Verisign voted against the transfer policy and,
> according to Danny's message this morning, has now expressed 
> doubt about the
> adequacy of the representation of registrants in this 
> process, the TF and NC
> would be well advised to invest the time and effort in outreach and
> consultation necessary to ensure that Verisign is bound by 
> the outcome,
> whatever it may be. Better to do it right the first time than find the
> policy suspended by an indepedent review or AAA arbitration.
> 
>           -- Bret
> 
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
> 
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>