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

Paul M Kane - CWG paul.kane-cwg at icb.co.uk
Mon Apr 18 15:56:46 UTC 2016


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
> 







More information about the IOTF mailing list