[IOTF] AOB from call #5 - correcting Typo!

Paul M Kane - CWG paul.kane-cwg at icb.co.uk
Wed Apr 20 14:00:49 UTC 2016


Hi Alan

I don't think the word "detrimental" is great either!! :-) .... but I hope you
understand the intent - feel free to make suggestions.

My goal is to obtain reassurance in the docs that customers of ccTLD Registry
will enjoy stable PTI operation of post transition.

What is not captured in the current PTI/ICANN docs is the status quo as defined
in the current NTIA Statement of Works as to the manner in which ccTLDs should
be treated... 

I would note that PTI does not have any authority to try to impose policy
conditions on ccTLDs beyond that which can reasonably be deduced from RFC1591 or
that a ccTLD has explicitly agreed to.

To assist with specifics, the most important are:

Performance exclusion, section C 8.3. agreements or negotiation document with
ICANN are not a requirement to receive IANA services.

Fees: section 2.3, IANA provides a no-cost service to customer, although ccTLD
customers are at liberty (and do) make (voluntary) contributions to ICANN a
percentage of which is used to fund IANA. 
The goal is to avoid discriminatory practice ie if you pay you get service; if
you don't, you don't (or it is slow service).  So to record that PTI will
continue to deliver service free from charge captures the status-quo and avoids
(potential) abuse of position and disenfranchising certain TLD operators.

C 2.5 Separation of operational role and policy development. 

Subsidiarity: C2.9.2. c Subsidiarity prevalence of ccTLD management - it's a
local matter which is not included at all ... which is very different from gTLDs
contractual relationship with ICANN.

Regarding the CWG proposal itself:

Annex C - Principles and Criteria that Should Underpin Decisions on the
Transition of NTIA Stewardship for Names Functions; Section 7ii is very
clear:
Post-transition of the IANA Functions, the IANA Functions Operator will
continue to provide service to existing registries in conformance with
prevailing technical norms, conforming with the policy decisions of
registries and the security and stability of the Root Zone itself.


None of the above is captured in the new ICANN/PTI documents, and silence is not
acquiescence, so IMHO the way to do it, is either enshrine it in bylaws or in
contract PTI- ICANN and I welcome any wording suggestions.

Best

Paul



Quoting Alan Greenberg <alan.greenberg at mcgill.ca>:

> Paul, I am not comfortable with that wording.
> 
> What is "detrimental" is a very subjective issue. That wording would 
> require that ICANN get written approval from every ccTLD operator 
> before changing anything. Since it is unlikely that one could get a 
> even any reply from EVERY ccTLD, that is not a workable solution.
> 
> Alan
> 
> At 18/04/2016 11:56 AM, Paul M Kane - CWG wrote:
> >Trang
> >
> >I've re-read parts of the CWG proposal and whilst care was taken to 
> >ensure both
> >ccNSO ccTLDs and non-ccNSO ccTLDs were equal, most or all of the 
> >(new) language
> >refers just to the ccNSO.
> >Please make sure that the interests of non-ccNSO member ccTLDs are (at
> least)
> >equally well protected as ccNSO member TLDs and gTLDs in ALL cases.
> >
> >Rough draft - suggested text:
> >
> >ICANN, shall not directly or indirectly act in a manner that is detrimental
> to
> >existing IANA/PTI customers of a [country code] top level domain registry
> >without the explicit written consent of the registry operator.
> >
> >Hope this is helpful
> >
> >Best
> >
> >Paul
> >
> >
> >Quoting Paul M Kane - CWG <paul.kane-cwg at icb.co.uk>:
> >
> > > Sorry for the typo in the earlier mail - this one is corrected!
> > >
> > > Have a good w/end all
> > >
> > > <><><>
> > >
> > > Thanks Trang/Allan
> > >
> > > Yes there are operational differences which impacts the IANA 
> > modus operandi.
> > >
> > > 1) Policy authority
> > > For gTLDs Policy authority originates within the ICANN community and
> ICANN
> > > sponsored consultations.
> > >
> > > For ccTLDs Policy authority originates by the ccTLD Registry conducting
> a
> > > process within their respective user community and tailoring the
> different
> > > models of Industry Best Practice to their specific national (legal
> > > framework)
> > > circumstances. For example: the ccTLD Policy authority for 
> > Australia, UK and
> > > China all have different models.
> > >
> > > For ICANN "Sponsoring organisation" works for gTLDs but it does 
> > not work for
> > > ccTLDs as RFC1591 followed international norms of using the term
> "Registry
> > > Manager".
> > >
> > > 2) Technical
> > > With gTLDs, the Technical parameters within which a gTLD operates is
> > > determined
> > > by ICANN based on recommendations by IETF and formulated in a contract.
> For
> > > example DNSSEC is developed by IETF and gTLDs registries have to use
> NSEC3.
> > >
> > > With ccTLDs, the Technical parameters within which a ccTLD operates is
> > > determined by the ccTLD Registry Manager based on recommendations by the
> > > IETF
> > > and others including local technical forums.
> > > For example, a large number of ccTLD do not use DNSSEC at all (as the
> > > Registry
> > > management determines the risks out weight the benefits); some ccTLDs
> use
> > > NSEC3
> > > whilst others use NSEC3 with opt-out to prevent zone walking and
> additional
> > > zone
> > > compression benefits.
> > >
> > > 3) Legal frameworks.
> > > The legal authority for a gTLD rests in the contract the gTLD Registry
> has
> > > with
> > > ICANN which is subject to the legal jurisdiction of California. As a
> > > consequence, legal authority for gTLD entries in the IANA is 
> > determined by a
> > > judicial process in California. So a Judge in California can 
> > instruct that a
> > > gTLD not be delegated to a ICANN (s)elected registry operator.
> > >
> > > For ccTLD Registries each registry is subject to the legal jurisdiction
> in
> > > which
> > > the Registry Manager is based/incorporated. So within that jurisdiction
> the
> > > ultimate authority is a Court. So should a Court in that jurisdiction
> hear
> > > evidence that the incumbent Registry Manager needs to be replaced and so
> > > determines, the judgment will specify within a period of X days there
> shall
> > > be a
> > > transfer of all operational assets from incumbent Registry Manager to
> the
> > > new
> > > Registry operator. (In such instances there is frequently a market price
> > > payment
> > > for the assets from the new to the old... which is not disclosed). When
> > > ccTLD
> > > Registries such as .CO are purchased by Neustar IANA was not involved.
> > >
> > > ICANN/IANA is not involved in the process - IANA decides whether to
> update
> > > their
> > > database or not - IANA is not the master of the Registry Manager, but it
> is
> > > in
> > > control of entries in its database and undertakes not to break the
> stable
> > > operation of the TLD. For example, the .IE (Ireland ccTLD Registry) -
> the
> > > Registry Manager (Sponsoring organisation) is listed as University
> College
> > > Dublin, Computing Services Computer Centre, Belfield, Dublin 
> > City, Dublin 4,
> > > Ireland.
> > > The University has not been the Registry Manager for more than a decade
> as
> > > IANA
> > > has elected not to update its entry to record IE Domain Registry Limited
> as
> > > the
> > > Registry manger. Everything works and no harm done.
> > >
> > > There are situations where ICANN can be involved where either party
> wants
> > > them
> > > to be.
> > > For the incumbent ccTLD registry they can be members of the ccNSO and
> agree
> > > in
> > > writing to follow ICANN developed Policy. If the member of the ccNSO
> does
> > > not
> > > agree with the ICANN Policy (or it conflicts with the laws in 
> > which they are
> > > based) - they can withdraw and terminate membership and not be impacted
> by
> > > the
> > > ICANN Policy.
> > >
> > > Finally there are those ccTLDs that have contracts with ICANN that
> > > specifically
> > > determine the legal jurisdiction in which the relationship is determined
> -
> > > the
> > > majority being the Laws of California.
> > >
> > > <><><><>
> > >
> > > I think it is important as part of the transition process the 
> > three branches
> > > of
> > > ccTLD world are captured, the independent ccTLD, the ccNSO ccTLDs and
> the
> > > ICANN
> > > contracted party ccTLDs and it is clearly noted that post-transition due
> > > respect
> > > for maintaining the autonomy and integrity of the diverse ccTLD
> community
> > > with
> > > the principle of subsidiarity being of paramount importance.
> > >
> > > Best
> > >
> > > Paul
> > >
> > > PS: I guess for completeness (but not relevant to the debate) - 
> > depending on
> > > the
> > > country also depends on how many TLDs a user can access. In some
> countries
> > > their
> > > ISPs are told which TLDs users within that country (including visitors)
> are
> > > able
> > > to access (or not access) - some ISPs will block access to specific TLDs
> on
> > > their own. Some countries/ISPs allow users to access the whole IANA
> Root,
> > > others
> > > a subset of the IANA Root, other countries/ISPs have additional special
> > > purpose
> > > TLDs for their user community.
> > > As I travel the world, I test which TLDs are accessible and you would be
> > > surprised that sometimes large country TLDs are not accessible (or the
> DNS
> > > is
> > > manipulated).
> > >
> > >
> > > Quoting Alan Greenberg <alan.greenberg at mcgill.ca>:
> > >
> > > > Paul, regardless of whether it is in any of the reports, can you be
> > > > more specific on the differences you are referring to. Clearly there
> > > > rules on delegation are different, but are you saying that there are
> > > > operational differences as well?
> > > >
> > > > Alan
> > > >
> > > > At 15/04/2016 09:38 PM, Trang Nguyen wrote:
> > > >
> > > > >Hi Paul,
> > > > >
> > > > >You had raised the below topic for discussion in the AOB portion of
> > > > >the agenda on Wednesday's IOTF call. Because we ran out of time, I
> > > > >had suggested that we pick up this discussion in the IOTF mail list.
> > > > >Below is what you raised on the call:
> > > > >
> > > > >"I've raised this a number of times on the list. Historically there
> > > > >has always been a difference of the way in which ccs and gTLD are
> > > > >handled or respected within the IANA frame work and obviously the
> > > > >post transition we want the difference to continue. I don't know
> > > > >what juncture it needs to be captured, whether it's in the Bylaws of
> > > > >PTI, whether it's implementation recognition in the document,
> > > > >implementation documentation. And I would welcome your guidance, as
> > > > >to how you intend to respect the differences between the authority
> > > > >parts for ccTLDs and gTLDs."
> > > > >
> > > > >Could you please point to the part in the ICG, CWG or CCWG proposal
> > > > >that speak to any requirements for implementation on this topic?
> > > > >
> > > > >Thank you,
> > > > >
> > > > >Trang
> > > > >
> > > > >_______________________________________________
> > > > >IOTF mailing list
> > > > >IOTF at icann.org
> > > > >https://mm.icann.org/mailman/listinfo/iotf
> > > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > IOTF mailing list
> > > IOTF at icann.org
> > > https://mm.icann.org/mailman/listinfo/iotf
> > >
> >
> >
> >
> >
> >
> >_______________________________________________
> >IOTF mailing list
> >IOTF at icann.org
> >https://mm.icann.org/mailman/listinfo/iotf
> 
> 







More information about the IOTF mailing list