headers
Patrick Mevzek | 2 Jul 2011 17:32

Re: Why must there be one solution? was Re: Lists and EPP

brunner <at> nic-naa.net <brunner <at> nic-naa.net> 2011-06-10 02:08
> At the Paris ICANN meeting I asked the Registrar Constituency members
> present which would be doing new gTLDs -- as registrars.
> 
> No hands were raised.

Which probably does not reflect what happens in reality... just see
the rate of adoption of .XXX among registrars...
(almost 100% already during a month of accreditations,
if I take your own account of 60 "true" registrars below)

> The Vertial Integration Botch (tm) now means that we've 600+600 as
> a design space. 600 registries (legacy ex-RRP-speakers, 2001+2004
> EPP-speakers, a "bigger N" number of 3166 registries, and ICANN's
> 500 (or whatever) of 201x registries, AND the same 60 registrars
> (ignoring the 600+ shell registrars that exist only for the 3pm
> race), the same "+N0" registrars pursuing local geo markets, AND
> each registry-as-a-registrar.

However there are not 600+60 registry back-end providers, software and
solutions.
And I do not believe that each registrar wanting to be a gTLD
operator will create from scratch a registry system.
There are maybe
30 or 50 commercial provider providing parts or all of a registry
solution (including current gTLD operators), a few open source software and companies
building on them. You can even add all current ccTLDs operators
(since some will be gTLD operators), you are still far from 600.

So, in my view, there is still hope of some factorization of EPP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Mevzek | 2 Jul 2011 17:43

Re: Another look at the data model for launch phase registrations

Wil Tan <wil <at> cloudregistry.net> 2011-06-16 15:47
> >      * MUST have 1 or more <status> codes from the set: [pending,
> >        validated, invalid, cancelled, allocated] (Q: possibly others?)
> 
> I'm ambivalent about allowing the status field to be extended. These status
> values suited our use case fine, but others may have a need for a different
> set of values.

I would prefer to have the extension being as extensible itself as
possible.
Fixed list of status code in EPP is one of the most visible problems,
as nearly all registry need to extend that list in some way.
So I would argue: provide a set of "sensible" (aka currently known)
status codes, but make the schema in such a way that other status
could be added.
Extended statuses could be mandatory to follow a specific form (to
separate them from standard ones, and from one registry to another),
such as the often used "X-" prefix, or following the contact srids
having some sort of registry id being prepended or appended to the
status, or available along it.

Also, allowing a free text to be attached to a status is useful for
providing extra information.

> 
> >      * MUST have a <phase> from the set [SR, LR] (Q: should we let
> >        servers define further phases?)
> >
> 
> I think <phase> should be optional, and it should just be free form. I can
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Mevzek | 2 Jul 2011 18:01

Re: Proposal: A method in EPP for registry policy discovery

Keith Gaughan <keith <at> blacknight.com> 2011-06-16 18:56
> This proposal comes out of the comments Jothan has been making recently, which
> I agree wholeheartedly with.
> 
> As a registrar, one of our great problems registry policy discovery. This is
> of particular importance with it comes to ccTLDs, whose policies can vary
> drastically. For instance:
> 
>  * what commands does the registry support with particular objects,
>  * what is the lifecycle of a domain in a particular zone,
>  * does removing a domain from redemption incur a cost to the registrar,
>  * how long after registration, transfer, and renewal must it be before a
>    domain can be transferred or renewed,
>  * what periods does a registry support for registrations, transfers, and
>    renewals,
>  * does the registry support the poll command,
>  * for contacts, which types does the <postalInfo> element support (this is a
>    crapshoot and registries, in my experience, never document this),
>  * does the registry support registrant modification,
>  * are there per-command limits.
> 
> These are just the ones I could think of off the top of my head.

If not done already, I believe you can find other examples/ideas in
section 4.4 of my draft at
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

However, I fear to have the same opinion than Klaus, meaning that it
would be hard to specify clearly all details for everyone. For
example, pricing components would be probably better left out of such
(Continue reading)

Permalink | Reply | 0 comments |
headers
brunner | 2 Jul 2011 16:05
Favicon

Re: Why must there be one solution? was Re: Lists and EPP

> brunner <at> nic-naa.net <brunner <at> nic-naa.net> 2011-06-10 02:08
> > > At the Paris ICANN meeting I asked the Registrar Constituency members
> > > present which would be doing new gTLDs -- as registrars.
> > > 
> > > No hands were raised.
>  
> Which probably does not reflect what happens in reality... just see
> the rate of adoption of .XXX among registrars...

a 2004 round applicant, with some non-trival lead-time. the .post
trajectory should be similar, whenever it gets to delegation.

my question -- in 2008 -- was about registrar interest in a vastly
larger number, with vastly different inter-availability waits.

> (almost 100% already during a month of accreditations,
> if I take your own account of 60 "true" registrars below)

i really don't care what you take into account, given the substitution
of many-in-a-year with one-in-a-decade, as the registrar problem statement,
above.

> > > The Vertial Integration Botch (tm) now means that we've 600+600 as
> > > a design space. 600 registries (legacy ex-RRP-speakers, 2001+2004
> > > EPP-speakers, a "bigger N" number of 3166 registries, and ICANN's
> > > 500 (or whatever) of 201x registries, AND the same 60 registrars
> > > (ignoring the 600+ shell registrars that exist only for the 3pm
> > > race), the same "+N0" registrars pursuing local geo markets, AND
> > > each registry-as-a-registrar.
> However there are not 600+60 registry back-end providers, software and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Mevzek | 2 Jul 2011 18:44

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type

Patrik Fältström <paf <at> cisco.com> 2011-06-17 12:10
> When you do transfer of a domain, what happens with the host and contact objects that are bound to the
domain? What notifications are sent, and what actions have to be taken?
> 
> I think, even though we have 200+ different business models, I claim those can be implemented with only say
3-5 different ways of doing transfer.

I mostly agree with this.

> > It might be better to approach this from a different direction. How about defining a standard set of
registry transactions -- create/delete/modify objects, renew and transfer a domain name, etc -- and
writing this up as a BCP? Once that's done, the BCP could be encoded in a standard test suite. In other words,
document what it is that's to be tested before developing a test suite. Some tests might be optional (for
instance IDN and DNSSEC might not be deployed in places) while others are mandatory.
> 
> I fully support this. And is implicitly what I am asking for. That registries try to, before they invent
their own epp architecture, look carefully at if they can not reuse what someone else is doing.

I would suggest before that to make sure that each registry document
and publish (eventually up to an IETF Informative RFC) their
extensions.
So that we would have a "catalogue" of what is happening on the field.

However this purely technical hope is severly constrained by an
economic one: each registry taken independantly has no
financial/economical/technical interest in redoing things that work
today but using another extension (so the current fragmentation has
little hope to be resolved), and even documenting it clearly and
publishing it outside of their registrars circle (and this is indeed
one example of response I got when I query registries for their
(Continue reading)

Permalink | Reply | 4 comments |
headers
Patrick Mevzek | 2 Jul 2011 18:52

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type

Hello Keith,

Keith Gaughan <keith <at> blacknight.com> 2011-06-16 18:26
> This is the first in a series of suggestions from a registrar's point of view
> improvements that can be made to and around EPP to make the life of registrars
> easier. Consider them food for thought if nothing else.

At least personnally I welcome your initiative and wish that other
registrars participate here and do the same.

> A standard EPP test suite from OT&E would, I think, serve two important
> purposes. Firstly, it would be an immense help to registrar who are
> developing their domain management systems for the first time as not all of
> us use Net::DRI for Perl or EPP-RTK for Java and C++. Ours, for instance, is
> written in a combination of Python and PHP. Secondly, it would mean that
> registrars would only need to run through the test suite *once*, which would
> greatly reduce the management overhead for both registrars and registries
> during accreditation. A central registry, likely maintained by ICANN, listing
> whether a registrar has successfully completed a particular part of the test
> suite, would also be useful.

I'm not sure this suits ICANN mandate or role. I even fear it would
complicate the system.

However, I also agree with Klaus and Wil: current accreditation tests
are *worthless* and I would say even *dangerous*.

They mandate to do things specifically forbidden in EPP (such as
syntax of some elements outside accepted values), and seem to concentrate in detail with some
arcane parts that almost never appear in production.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrik Faltstrom (pfaltstr | 3 Jul 2011 05:51
Picon
Favicon

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type

On 2 jul 2011, at 18:46, "Patrick Mevzek" <provreg <at> contact.dotandco.com> wrote:

> So, Patrick, I agree with you, registries should "try to" see what exists
> already before reinventing the wheel, but how to achieve that? I
> honestly have no idea while still believing it is a worthwile goal.

We can not police, but IETF can help by "stop being so nice" and ack that two registries that require ANY
change in the registrar epp implementation are NOT interoperable. If just that is known, we are in a better situation.

> Maybe registrars (as a group) + independant implementors should try to
> raise their voice together...

I think/hope that is what is now happening? ;-)

   Patrik - tired of all non-interoperable registry inventions in epp

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 3 comments |
headers
ebw | 3 Jul 2011 14:25
Favicon

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type

patrik,

If you, or anyone else with an interest in the implementation consequences
of the post-2004 scaling properties of new icann contracts for registries,
had been engaged in the vertical integreation policy area, from the point
in time when icann staff, sui sponte, included the continuation of the '01
and '04 structural separation with the more general question of economic
utility analysis [1], you would have witnessed two salient meta-requiements
expressed by the majority involved in the policy area:

	o registrars generally had no interest in restrictions upon their
	  behavior as registries, though a few significant exceptions did
	  exist, e.g., core and godaddy,

	o non-registrars had no interest in restrictions upon their 
          behavior as registries.

if you go back to the final vi report and see how many participants (note
also their business, or their academic/ideological affiliation) rejected
continuity of the basic '01 and '04 separation requirement.

the ec and doj letters of last month deal with the existing competition policy
problem of allowing an entity with an 83% market share, or entities with a
100% market share, compete with external registrar functional units, though
it is expressed as a market power analysis, allowing integration where market
power is absent.

what the ec and doj letters do not deal with is nacent competition policy
problem of 500 registries, each able to express a distinct business model,
through its registration policy, and each able to operate as a registrar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrik Wallstrom | 4 Jul 2011 12:07
Favicon
Gravatar

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type


On Jul 3, 2011, at 5:51 AM, Patrik Faltstrom (pfaltstr) wrote:

> On 2 jul 2011, at 18:46, "Patrick Mevzek" <provreg <at> contact.dotandco.com> wrote:
> 
>> So, Patrick, I agree with you, registries should "try to" see what exists
>> already before reinventing the wheel, but how to achieve that? I
>> honestly have no idea while still believing it is a worthwile goal.
> 
> We can not police, but IETF can help by "stop being so nice" and ack that two registries that require ANY
change in the registrar epp implementation are NOT interoperable. If just that is known, we are in a better situation.

That would be very hard for the IETF to do for a protocol that the IETF claims to be extensible, right? If you
want protocols that can be policed like that, at least that word should not be in the name of the standard. :)

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |
headers
Patrik Faltstrom (pfaltstr | 4 Jul 2011 12:20
Picon
Favicon

Re: Proposal: A standard EPP OT&E test suite for each object type and extension type

On 4 jul 2011, at 12:07, "Patrik Wallstrom" <pawal <at> blipp.com> wrote:

>> We can not police, but IETF can help by "stop being so nice" and ack that two registries that require ANY
change in the registrar epp implementation are NOT interoperable. If just that is known, we are in a better situation.
> 
> That would be very hard for the IETF to do for a protocol that the IETF claims to be extensible, right? If you
want protocols that can be policed like that, at least that word should not be in the name of the standard. :)

Absolutely correct!

As I have said before, I was the area director and because of that somewhat responsible when epp was
standardized. I did then not envision what problems would arise.

   Patrik
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |

Gmane