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

[Alan Greenberg]

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