Re: Standard Extensions

On 23/08/12 12:59, Patrik Fältström wrote:

> On 23 aug 2012, at 13:48, "Hollenbeck, Scott" <[email protected]> wrote:
> 
>> Serious question: as a registrar, why do you do business with registries
>> that give you nightmares?
> 
> The first registry does not give me as a registrar nightmare. The 2nd that
> differ from the first do.
> 
> And the question is then, why do we work on implementing this 2nd anyway?
> The simple answer is that our customers want us to be able to manage all of
> their domains, in all of the TLDs of their choice.

Spot on.

It's like death by a thousand papercuts, to use the old cliché.

Sometimes it's that some element of the registry's implementation is
just plain broken, such as the way NeuStar decided not to treat the
namespace names identifying objects and extensions as opaque and
stripped off the '-1.0' off the end of all of them in the greeting
document.

Or maybe it's the way that some registries return 1001 (pending) as the
status for a pending transfer and some return 1000 (completed) but with
the <trStatus> element in the body set to 'pending'. Then there's the
crapshoot as to whether the registrar supports/allows/requires
international address types, local address types, or both, which often
goes undocumented.

There's surprisingly little agreement on the actual meaning of 2201
(authorisation error) and 2202 (invalid authorisation information),
when they should be used, and how the registrar should react to them.
I've even seen 2306 (parameter value policy error) cropping up where
I'd expect either 2201 or 2202.

Ditto goes for confusion around the use of the 200[1-5] series of status
codes.

Differing behaviour between registrars of the <host:check> command:
some registries will respond with a negative if the host already exists
regardless of the registrar who owns it, others will only respond with
a negative if it already exists on the registrar's own account.

Registrars differ on whether the year added during the autorenew grace
period is taken away when the domain's put in redemption whereas others
leave the domain on.

There are layering violations in some some implementations, such as
VeriSign's own NameStore extension, which is doing something that
really ought to be done at the wire protocol level so the multiplexing
can be made transparent rather than forcing either (a) every place
request stanzas are built to have to account for stuff it might not
know that very moment ("I'm creating a host object, but is it going to
be used with a .com domain on a .net domain? Dunno.") or (b) the
introduction of some kind of proxy to demux the shared connection and
mess around with greeting and request stanzas to hide the addition of
the extra extension.

Then there are servers that straight up lie about their capabilities,
such as mixing and matching thin and thick registries on the same
connection, or putting stuff in their greeting that they don't even
support and leaving out stuff that they do.

Then there are registries that require contacts to be typed for
whatever reason.

Dragging information from registries about when, relative to the
expiration date, is the latest date they will accept a renewal before
we need to delete it is like pulling teeth.

Much as I dislike RFC 3915, I understand why it is the way it is (even
if it's asking me for a lot of information the registry already has,
effectively in duplicate), I'd prefer registries to be using that
rather than their own proprietary mechanism for removing domains from
redemption.

Several registries (ccTLDs) don't use the standard message queue
responses for various actions, and insist on imposing their own bespoke
extensions that do *exactly* the same thing as the standard ones.

There are times when a registry will only put messages on the message
queue for things that either were pending and have now completed or were
initiated by another party, while there are other registries who put the
message on the message queue regardless of who initiated it or
whether it completed immediately. This can lead to... interesting problems.

That's everything I can think of off the top of my head, but given time
to trawl though code, I'm sure I could come up with many, many more.

Some of these differences are down to differing interpretations of the
specification, others are due to bloodymindedness on the part of the
registry operators, but fundamentally the lack of effort on the part of
registry operators to co-ordinate how they function so that their
behaviour is consistent is, frankly, selfish and does nothing more than
multiply the amount of work required by registrars to integrate with
registries: there is no additional costs involved for the registry in
having its own set of quirks, but when those quirks are present, every
registrar they deal with has to account for their quirks, and the cost
in terms of time and money wasted piles up very, very quickly.

> So, the reason why I think registrars like myself are a bit concerned
> is I guess because we see that it is we (registrars) that have to take
> all the cost (i.e. implementing epp) for the differences between two
> registries.
> 
> I.e. if registry A and registry B implement epp even the slightest
> differently, that imposes a direct cost on the registrars that work
> with A and B. A cost that is to be balanced against the potential
> extra income we can get by using epp instead of being a reseller.
> 
> If the differences in epp also imposed an extra cost on the registries,
> so that there was an economical penalty on a registry to implement
> something "different from other registries", then I think we might
> have seen a different evolution of epp.

K.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg