Subject: Re: [provreg] Standard Extensions

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 11:32:04 +0000

It's been a long time since I started this thread back in January. Someone recently asked me a question about an EPP extension, so I thought it wise to see if I could revisit the discussion and post a summary. Here's the original question:

> Let's assume for a moment that we have enough interest to form a 
> working group focused on the development of a set of standard EPP 
> extensions. If we had to start writing a charter today, what 
> functionality would people most like to see included?

and here's a summary of the suggestions (my apologies if I missed any), including new efforts that have recently surfaced:

1. A garbage collection mechanism.

2. Extension for registrars to get registry/zone policy information.

3. Extension to provide account status information to registrars.

4. An IDN extension*.

5. A TLD launch extension*.

6. A trademark management extension*.

7. Standardized registry-to-registrar notifications.

8. An extension for VAT and/or tax ID information.

9. An extension for a legal/personal attribute on contact objects.

10. An extension for additional status value and/or result codes, perhaps with an associated IANA registry.

11. An extension for cryptographic signatures.

12. An extension for delegation errors/warnings.

Those that are described in a draft I've seen are marked with an asterisk. IMHO twelve is probably too many to bootstrap a new working group. If we could whittle this down to 6 or 7 AND we have actual drafts written for consideration it may be possible for us to get something going.

Which of the above topics has been addressed in a draft? Who is willing to write drafts for those topics that haven't yet been addressed?

Scott

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Aug 2012 13:36:49 +0200

I think registries should first list whatever private extensions they have, and see whether they can not be standardized. Do not increase the number of extensions...

   Patrik

22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" <[email-masked]>:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 11:44:41 +0000

At least one person did that, Patrik (and I inadvertently missed them when compiling the list below):

http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html

I didn't see any follow-up to the list provides by James. I believe that some of the items in the list below *are* implemented private extensions. Yes, it would be helpful to identify those.

Could you identify any extensions you've had to implement to work with different registries?

Scott

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2012 7:37 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [provreg] Standard Extensions
> 
> I think registries should first list whatever private extensions they
> have, and see whether they can not be standardized. Do not increase the
> number of extensions...
> 
>    Patrik
> 
> > It's been a long time since I started this thread back in January.
> Someone recently asked me a question about an EPP extension, so I
> thought it wise to see if I could revisit the discussion and post a
> summary. Here's the original question:
> >
> > and here's a summary of the suggestions (my apologies if I missed
> any), including new efforts that have recently surfaced:
> >
> > 10. An extension for additional status value and/or result codes,
> perhaps with an associated IANA registry.
> >
> > Those that are described in a draft I've seen are marked with an
> asterisk. IMHO twelve is probably too many to bootstrap a new working
> group. If we could whittle this down to 6 or 7 AND we have actual
> drafts written for consideration it may be possible for us to get
> something going.
> >
> > Which of the above topics has been addressed in a draft? Who is
> willing to write drafts for those topics that haven't yet been
> addressed?
> >
> > Scott

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Aug 2012 13:58:16 +0200

> Could you identify any extensions you've had to implement to work with different registries?

If your question is "what where you forced to implement differently with different registries" the answer is so far for me:

- DNSSEC, clarification if DS or DNSKEY is to be passed to registry
- Notifications (as you listed)
- Deletion of domain names (before expiration)
- Management of NS records when a transfer occurs
- Management of dates for expiration, deactivation etc
- Addition of personal or organisational number (i.e. identifier of the registrant)
- VAT information of registrant
:
:

Let me phrase things differently.

This list...

http://search.cpan.org/~pmevzek/Net-DRI/

...have too many entries.

Make that 25% of what it is now, and you have success.

I.e. OF COURSE I thing it is good if IETF work is starting on these issues that you list, or else we will get even more extensions that are specific per registry. What I am worried about is the lack of interest from registries to try to minimize the number of extensions they have that are private.

Of course, many of these I have now implemented which implies that if they change towards a standard, I have to change my code again :-P, but I rather do that than continue to spend time on endless (as it seems) specific implementations for specific registries.

If there was ONE epp flavor to move towards.

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 22 Aug 2012 14:16:31 +0200

On 22-08-12 13:58, Patrik Fältström wrote:

> If your question is "what where you forced to implement differently
> with different registries" the answer is so far for me:
> 

Apart from the DS/DNSKEY question for the delegation, there is also a
request to have an EPP extension for registrars to send ZSK
information (a KEY) to be relayed by the registry in case of a
dns-operator change
(http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04).

As this is a rather new topic, after some registries made their
initial decision to use DS in stead of DNSKEY, I think this might
influence consensus on using DNSKEY. We actually need the "key to be
relayed" as an EPP extension to facilitate automated DNSSEC secure
transfers, and will implement it regardless of standardisation.

But if it needs a request: We would like the "key to be relayed" as a
standard EPP extension. It contains a KEY.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 23 Aug 2012 12:02:06 +0800

Now we already had the draft-kong-epp-cdn-dnssec-mapping, which is the
DNSSEC mapping for the provisioning and management of Chinese Domain Names.
We also want to do a DNSSEC extension for IDN based on the above draft.

Regards,
Linlin Zhou

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hollenbeck, Scott
> Sent: Wednesday, August 22, 2012 7:45 PM
> To: Patrik Fältström
> Cc: [email-masked]
> I didn't see any follow-up to the list provides by James. I believe that
some of
> the items in the list below *are* implemented private extensions. Yes, it
would
> be helpful to identify those.
> 
> > have, and see whether they can not be standardized. Do not increase
> > the number of extensions...
> >
> >    Patrik
> >

---

From: Kevin Tse <[email-masked]>
Date: Thu, 23 Aug 2012 12:14:19 +0800

Hello all,

    We have several private extensions which are not summited as rfc
drafts and some extensions which are summited as rfc drafts.

Not summit:
1.Real information extension for the contact object.
2.Information for purveyor for both contact and domain objects.
If you are interest in these, I'd like to share some information.

RFC Draft:
1.CDN(chinese domain name) extension for the domain
object;(draft-kong-epp-cdn-mapping)
2.CDN DNSSEC extension for the domain
object;(draft-kong-epp-cdn-dnssec-mapping)
3.IDN extension for the domain object;(draft-kong-epp-idn-mapping)

BTW,we have interest to form a working group focused on the development
of a set of standard EPP extensions.

Kind regards,
-- 
Kevin Tse <[email-masked]>
CNNIC

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Aug 2012 07:37:30 +0200

> drafts and some extensions which are summited as rfc drafts.

Btw, I do not as registrar care much whether extensions are RFCs or not, but whether extensions are actually implemented by all(!) registries, and whether I can communicate with a specific registry without implementing the extensions that registry support.

I already see registries that require extensions (compared to registries that have features that are optional implemented as extensions) do not end up being as popular among registrars as other registries.

So, I want to see registries harmonize their implementations. Talk with each other. Coordinate. Have someone say "we have a cool extension, but we will not implement this before we have ten other registries also agreeing to implementing it".

   Patrik

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 23 Aug 2012 11:18:09 +0100

On Wed, Aug 22, 2012 at 11:32:04AM +0000, Hollenbeck, Scott wrote:

> It's been a long time since I started this thread back in January. Someone
> recently asked me a question about an EPP extension, so I thought it wise to
> see if I could revisit the discussion and post a summary. Here's the original
> question:
> 
> > Let's assume for a moment that we have enough interest to form a working
> > group focused on the development of a set of standard EPP extensions. If we
> > had to start writing a charter today, what functionality would people most
> > like to see included?
> 
> and here's a summary of the suggestions (my apologies if I missed any),
> including new efforts that have recently surfaced:

I'd like to add something to that. We've been talking to a ccTLD registry who
are contemplating moving from their own proprietary protocol to EPP. One thing
they'll need to do that is a ticket object mapping for managing pending domain
applications and attaching documentation to those applications programmatically.

It's early days, and thus a long-finger project currently, but it seems like the
kind of thing that ought to be of general use, but of especial use to ccTLDs and
sponsored gTLDs.

> 1. A garbage collection mechanism.

This is currently being worked on, though I haven't been able to get as much
time to write up the initial I-D as I'd like.

> 2. Extension for registrars to get registry/zone policy information.

I think the consensus back when this was discussed was that it ought to be kept
more-or-less independent of EPP.

> 9. An extension for a legal/personal attribute on contact objects.

These can surely be merged?

> Which of the above topics has been addressed in a draft? Who is willing to
> write drafts for those topics that haven't yet been addressed?

K.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 23 Aug 2012 11:23:03 +0100

On Thu, Aug 23, 2012 at 07:37:30AM +0200, Patrik Fältström wrote:

> >    We have several private extensions which are not summited as rfc drafts
> >    and some extensions which are summited as rfc drafts.
> 
> So, I want to see registries harmonize their implementations. Talk with each
> other. Coordinate. Have someone say "we have a cool extension, but we will not
> implement this before we have ten other registries also agreeing to
> implementing it".

Agreed. From a registrar's perspective, the proliferation of registry 'quirks'
is the single biggest source of headaches we have.

---

From: Günther Mair <[email-masked]>
Date: Thu, 23 Aug 2012 12:39:32 +0200

> is the single biggest source of headaches we have.

Add me as one more registrar in this line-up.
As Keith already suggested a few times (btw. I loved the one about "the beautiful and unique snowflakes that they are") and Patrik confirmed, the various registries behavior is a nightmare to us.

Just think about the internet where every country had it's own "protocol quirks" because of some "internal policies".
But in the long term I hope it will be in the registries own best interest to help standardize and then stick to the agreed upon standard. Think about it the way Patrik explained.

Regards

Günther

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 11:48:25 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Günther Mair
> Sent: Thursday, August 23, 2012 6:40 AM
> To: Keith Gaughan
> Cc: [email-masked]
> >> So, I want to see registries harmonize their implementations. Talk
> >> with each other. Coordinate. Have someone say "we have a cool
> >> extension, but we will not implement this before we have ten other
> >> registries also agreeing to implementing it".
> >
> As Keith already suggested a few times (btw. I loved the one about "the
> beautiful and unique snowflakes that they are") and Patrik confirmed,
> the various registries behavior is a nightmare to us.
> 
> Just think about the internet where every country had it's own
> "protocol quirks" because of some "internal policies".
> But in the long term I hope it will be in the registries own best
> interest to help standardize and then stick to the agreed upon
> standard. Think about it the way Patrik explained.

Serious question: as a registrar, why do you do business with registries that give you nightmares?

Scott

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Aug 2012 13:59:47 +0200

> 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.

We can do it as registrars by either implementing epp for all of those TLDs or by being a reseller to someone that did bite the bullet for the problematic ones (or started with a different one).

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.

   Patrik

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 12:08:31 +0000

> Sent: Thursday, August 23, 2012 8:00 AM
> To: Hollenbeck, Scott
> Cc: Günther Mair; [email-masked]

[snip]

> 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.

Probably true (casting glances in the direction of ICANN, at least from the gTLD perspective), but I guess part of the reason I asked the question is because one such penalty could be a lack of support from registrars - who are unfortunately caught in the middle.

Scott

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Aug 2012 14:10:41 +0200

> Probably true (casting glances in the direction of ICANN, at least from the gTLD perspective), but I guess part of the reason I asked the question is because one such penalty could be a lack of sup…

The world is not only gTLDs. Those registries are (according to my experience) much more synchronized than ccTLDs.

epp is a protocol for TLDs, not gTLDs.

   Patrik

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 12:16:55 +0000

> Sent: Thursday, August 23, 2012 8:11 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> > Probably true (casting glances in the direction of ICANN, at least
> from the gTLD perspective), but I guess part of the reason I asked the
> question is because one such penalty could be a lack of support from
> registrars - who are unfortunately caught in the middle.
> 
> The world is not only gTLDs. Those registries are (according to my
> experience) much more synchronized than ccTLDs.
> 

Yeah, I get that :). We haven't had a lot of success with broad ccTLD coordination.

Scott

---

From: Günther Mair <[email-masked]>
Date: Thu, 23 Aug 2012 14:22:00 +0200

> epp is a protocol for TLDs, not gTLDs.

True, it may be lack of support from registrars; all the more a reason for us to make a statement about this situation here, where some of them listed in.
One more explanation could be the a transition from their previous, local policies towards EPP.

And yes, it's mainly ccTLDs that would need to get their policies better synchronized (contact object extensions being a big issue).

Günther

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Aug 2012 14:32:55 +0200

> One more explanation could be the a transition from their previous, local policies towards EPP.

Let me change that a bit to "One more explanation could be implementing their policies with epp."

But, as you say Scott, the end result might be that registrars do not implement epp for the registries, and instead move towards the registries that do have synchronized epp implementations. And that should create, hopefully, an interest for the registries to synchronize between themselves. At least for the minimum necessary extensions.

Once again, I have no problems what so ever with whatever extensions created. As long as they are implemented by many registrars.

And yes, I was the Area Director in charge when the 'e' in epp was proposed from the community and also accepted by IETF as a whole. With the knowledge I have now, I would have pushed back a bit harder...or at least required some wording in epp so that it would be more clear for registrars whether a registry implement baseline epp or not. I.e. whether some private extension is needed to be a registrar. Today, one can claim to support epp but at the same time require implementation of extensions that are private.

What do you all think is needed to be able to claim one implements epp (on server and client side respectively)? How is implementation to be validated?

   Patrik

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 23 Aug 2012 14:34:55 +0200

> Serious question: as a registrar, why do you do business with registries that give you nightmares?

For a living? For market requirements? Think for an US-based registrar that 
would not offer .com/.net domains because they think that Verisign's 
implementation would be a nightmare. What would be the probability for them to 
survive?

Regards,

Klaus

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 23 Aug 2012 08:35:49 -0400

> 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 potent…

Consider as well that this is also a cost for new registries. A new registry wishing to enter the market also needs to think hard about the differences that have already been implemented and try to conform to them in order to reduce the effort required by the registrars down the road (ie, if you aim for quick acceptance by the registrars).

The cynical point of view would be that established registries have this as an incentive to not change their unique ways. After all, they already have a market that is working for them. An existing registry wishing to provide back end operations for a new gTLD knows that there is a base of registrars that are able to connect "out of the box". Why make it easier for other registries to compete for that new gTLD?

Best regards.

-lem

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 23 Aug 2012 08:42:51 -0400

> What do you all think is needed to be able to claim one implements epp (on server and client side respectively)? How is implementation to be validated?

IMHO, one step in the right direction would be to have a community maintained(*) set of published test cases. Passing those cases would give you the baseline functionality. Coverage would have to be enough so as to provide basic functionality.

(*) I'm using "community maintained" as a way to try and prevent single players from bending the set of test cases in their favor. Picture a registry with enough resources so as to fill the test case list with cases that they easily pass. This would require other registries wishing to play that game to invest in implementing all those features, that they or their customers might not need.

For instance, there should be a minimum n of registries and registrars implementing a feature (ie, passing that test) in order for it to be adopted into the test case set. That would force registries and registrars that want to see a feature added to the set, to lobby others into implementing them.

Best regards

-lem

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 13:00:06 +0000

> Behalf Of Klaus Malorny
> Sent: Thursday, August 23, 2012 8:35 AM
> To: [email-masked]
> For a living? For market requirements? Think for an US-based registrar
> that would not offer .com/.net domains because they think that
> Verisign's implementation would be a nightmare. What would be the
> probability for them to survive?

Verisign probably isn't a good example because we have contractual obligations to implement the protocol as specified in the RFCs. If implementing the protocol as specified is a nightmare maybe the registrar shouldn't be a registrar, and Verisign can be held accountable if contractual obligations are unmet. I see your point, though - a registrar has to meet customer demand. 

If money motivates registrars to support and enable inconsistent implementations then there would have to be a greater financial incentive for them to boycott non-conforming registries. I'm not aware of any.

Scott

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Aug 2012 14:03:26 +0100

On 23 Aug 2012, at 13:35, Luis Muñoz wrote:

> The cynical point of view would be that established registries have  
> this as an incentive to not change their unique ways. After all,  
> they already have a market that is working for them. An existing  
> registry wishing to provide back end operations for a new gTLD knows  
> that there is a base of registrars that are able to connect "out of  
> the box". Why make it easier for other registries to compete for  
> that new gTLD?

In other words, you can have any colour of TLD you want as long as  
it's black. To misquote Henry Ford.

This starts to smell like an anti-competitive cartel: "If you don't  
conform to our world view, we won't play and you will fail. Have a  
nice day.".

So to get back to Patrik's original question, what can be done to  
reduce the number of extra extensions and registry (or registrar)  
foibles? Could this list define a minimum set of requirements and/or  
interoperability features which every EPP-capable registry or registry  
would be expected to implement?

I think the E of EPP may be the problem... :-)

---

From: Günther Mair <[email-masked]>
Date: Thu, 23 Aug 2012 15:20:53 +0200

> So to get back to Patrik's original question, what can be done to reduce the number of extra extensions and registry (or registrar) foibles? Could this list define a minimum set of requirements and/or interoperability features which every EPP-capable registry or registry would be expected to implement?

Jim, maybe we (registrars) could come up with the main differences and how those were implemented by the registries.

As of personal experience I can tell that some of the 'e' 's have been implemented throughout different registries, just differently.
Inside the EPP standard those parameters could be optional, but at least they should be standardized.

Also as a minimum requirement, the use of optional parameters in extensions should be deprecated by way of the standard's own definition.

Other thoughts? Comments?

Günther

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Aug 2012 14:39:06 +0100

On 23 Aug 2012, at 14:00, Hollenbeck, Scott wrote:

> Verisign probably isn't a good example because we have contractual  
> obligations to implement the protocol as specified in the RFCs. If  
> implementing the protocol as specified is a nightmare maybe the  
> registrar shouldn't be a registrar, and Verisign can be held  
> accountable if contractual obligations are unmet. I see your point,  
> though - a registrar has to meet customer demand.

Scott, I doubt Klaus was saying that doing business with Verisign is a  
nightmare for registrars.

What both of you are agreeing is that registars may well be forced to  
do business with nightmare TLD registries because of customer demand  
or other layer-9 and up factors.

> If money motivates registrars to support and enable inconsistent  
> implementations then there would have to be a greater financial  
> incentive for them to boycott non-conforming registries. I'm not  
> aware of any.

FYI registrars chose not to sell .tel because it was "non-conforming"  
for them. The EPP side was just fine: no issues there at all. The  
registrars that walked away generally did so because .tel didn't fit  
with their business models which were based on selling web hosting,  
warehousing names and pay-per-click adverts. The financial incentives  
to "just keep on doing what we do in .com" won. The extent of EPP  
conformance (or not) didn't really figure in those calculations.

The point I'm making is there are many flavours of conformance in the  
registry-registrar model. It would be nice if one of them could be a  
"core" EPP feature set which a registrar could be sure was fully  
supported across all EPP compliant registries. That would mean the  
industry could in principle have toolkits that don't change if/when  
the back-end provider or TLD changes and maybe do away with TLD- 
specific EPP accreditation and OT&E. The lack of commonality between  
EPP compliant registries must be a business and technical nightmare  
for registrars.

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 23 Aug 2012 16:49:06 +0200

On 23/08/12 15:00, Hollenbeck, Scott wrote:
> implementing the protocol as specified is a nightmare maybe the registrar
> shouldn't be a registrar, and Verisign can be held accountable if contractual
> obligations are unmet. I see your point, though - a registrar has to meet
> customer demand.
>

I mentioned Verisign as an example because of its dominance in the US market 
(more than tenfold of domains to the next competitor AFAIK), and not because 
potential extra implementation efforts.

But as you mention: I don't want to start a Verisign bashing here, but I ask you 
to be a bit more realistic: due to various concessions to Verisign by ICANN, 
esp. the allowance for keeping the thin registry model, supporting .com/.net 
causes extra effort to the registrar. For example, the development and operation 
of a Whois server is not for free. The Whois issue also becomes a real nightmare 
in the context of IRTP due to the uncounted different output formats and access 
limitations of the Whois servers of the other registrars. This might go away 
with the efforts of ICANN to establish a next generation Whois protocol and to 
provide an open-source reference implementation, but this is all still up in the 
air.

Besides this, the implementation IRTP the WDRP service is an extra effort, too. 
While this cannot be directly debited to the effort for the registrar support of 
the Verisign registry, these two services would have made more sense to be 
located at the registry instead of at the registrar, but this was impossible 
with the thin registry model.

Regards,

Klaus

---

From: Gavin Brown <[email-masked]>
Date: Thu, 23 Aug 2012 15:50:57 +0100

> 11. An extension for cryptographic signatures.

I did a draft for this and mentioned it on this list, it's not been
published as an I-D:

https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsig.txt

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 15:02:26 +0000

> Sent: Thursday, August 23, 2012 10:49 AM
> To: [email-masked]

[snip]

> While this cannot be directly debited to the effort for the registrar
> support of the Verisign registry, these two services would have made
> more sense to be located at the registry instead of at the registrar,
> but this was impossible with the thin registry model.

Then this is a case of "be careful of what you wish for" because the thin registry model was *NOT* an NSI/Verisign mandate. It was demanded by the early registrars who were concerned about the privacy of their customer data when NSI had both registry and registrar functions within the same company. There has been some more recent discussion of changing the model, but I'm not aware of any change in direction.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 23 Aug 2012 16:39:01 +0000

Scott,

Let me add a few more to the list, since we have some custom extensions
that could be of general interest:

1. Account finance (balance, credit limit, available credit, low credit
thresholds) information.  Our custom Low Balance Mapping for poll
messaging of low balance conditions and the Balance Mapping for on-demand
balance commands. 
2. General Key / Value Pair attribute extension which is defined by our
custom Client Object Attribute Extension.
3. A registry routing extension for servers that support more than one
TLD.  Our custom NameStore Extension handles this.
4. Additional domain attributes needed to support transfers.  Our custom
Whois Info Extension supports returning the domain's registrar name, the
registrar whois server, and the registrar URL to support transfers without
the need to hit whois for the information.
5. Add poll messaging for the expiry of restore commands due to not
receiving the restore report command in RFC 3915.  Our custom RGP Poll
Mapping addresses this.
6. Registry mapping that support returning the list of supported TLD's of
the server along with features and policy information for the TLD's.  Past
postings on the list recommended to do this out-of-band, but I still
believe that this information can and should be provided in-band.
7. Support for .NAME objects elsewhere.  Specifically if there is interest
in support for Defensive Registration or NameWatch objects in other
registries.  
8. We have a custom IDN Language Tag extension that can be discussed with
the "An IDN Extension" item.
9. ConsoliDate Mapping (sync command) that supports synchronizing domain
expiration dates.  
10. Premium Domain Extension for dealing with the registration of premium
domains (is a domain a premium domain, what is the price, etc.).  Our
custom Premium Domain Extension addresses this.

--
  
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 8/22/12 1:32 PM, "Hollenbeck, Scott" <[email-masked]> wrote:

>Someone recently asked me a question about an EPP extension, so I thought
>it wise to see if I could revisit the discussion and post a summary.
>Here's the original question:
>
>group. If we could whittle this down to 6 or 7 AND we have actual drafts
>written for consideration it may be possible for us to get something
>going.
>
>Which of the above topics has been addressed in a draft? Who is willing
>to write drafts for those topics that haven't yet been addressed?
>
>Scott

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 23 Aug 2012 23:03:32 +0100

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

> 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.
> 
> 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

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 23 Aug 2012 23:13:50 +0100

On 23/08/12 13:42, Luis Muñoz wrote:
>> What do you all think is needed to be able to claim one implements
>> epp (on server and client side respectively)? How is implementation
>> to be validated?
>
> (*) I'm using "community maintained" as a way to try and prevent
> single players from bending the set of test cases in their favor.
> Picture a registry with enough resources so as to fill the test case
> list with cases that they easily pass. This would require other
> registries wishing to play that game to invest in implementing all
> those features, that they or their customers might not need.
> 
> For instance, there should be a minimum n of registries and registrars
> implementing a feature (ie, passing that test) in order for it to be
> adopted into the test case set. That would force registries and
> registrars that want to see a feature added to the set, to lobby
> others into implementing them.

I proposed this very thing on June 16th last year. I still think it's
worthwhile to at least have a baseline that a registry would have to
conform to in order to work, even if there have to be certain opt-outs
for things required by the registry's character--.tel and its handling
of nameservers being an example--though such deviations ought to be
minimised.

K.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 23 Aug 2012 23:32:33 +0100

On 23/08/12 14:00, Hollenbeck, Scott wrote:
> obligations to implement the protocol as specified in the RFCs.

Aside from some relatively minor annoyances, if all registries behaved
more like VeriSign's EPP implementation (NameStore extension and
mingling of thick and thin registries on the same EPP endpoint aside),
I'd be much happier with life.

> If implementing the protocol as specified is a nightmare maybe the
> registrar shouldn't be a registrar, and Verisign can be held accountable
> if contractual obligations are unmet. I see your point, though - a
> registrar has to meet customer demand. 

That implies that there's a choice in the matter. Typically, there's
little choice in the matter but to integrate regardless.

Keep in mind that my criticisms and--I'm sure--those of my fellow
registrars--are not directed at VeriSign, but at registry operators in
general, be they operating small ccTLDs or behemoth gTLDs.

> incentive for them to boycott non-conforming registries. I'm not

That's down to a lack of co-ordination on the part of registrars, best
as I can tell, though individually we have been able to browbeat some
registries into behaving better.

With large registry operators, is much more difficult because of the
degree of inertia involved and the fact that only massive concerted
action would be likely to yield results.

In the case of ccTLD operators, as they have a monopoly over something
tied to the country they operate in, the customer cost of any action
far outweighs any benefit that might be had from getting the registry
to reform their ways. Unless, that is, the registrars in question happen
to manage much of the zone.

---

From: James Mitchell <[email-masked]>
Date: Fri, 24 Aug 2012 11:29:22 +1000

I am having trouble identifying the problem that this extension aims to
solve. Is the use case for this consider transport mechanisms other than
TCP with TLS (and client authentication)? Perhaps someone can enlighten me?

---

From: Gavin Brown <[email-masked]>
Date: Fri, 24 Aug 2012 09:42:00 +0100

> TCP with TLS (and client authentication)? Perhaps someone can enlighten me?

The use cases I came up with are described in the draft. ⌘C, ⌘V:

2.  Use Cases

   Digital signatures may be useful in a number of scenarios, such as:

   1.  a registry which charges a very high fee for object provisioning,
       where the cost of refunds and chargebacks is sufficiently high
       that it is necessary to deter frivolous registration requests.

   2.  a registry operating at a high level of security, where defence-
       in-depth and the need to provide a full audit trail require
       strong authenticity of provisioning requests.

   3.  future extensions to EPP may permit use of transport protocols
       such as SMTP [RFC5321] or XMPP [RFC6120], which cannot provide
       end-to-end authenticity of frames.

G.

---

From: Gavin Brown <[email-masked]>
Date: Fri, 24 Aug 2012 09:42:30 +0100

> custom Premium Domain Extension addresses this.

We have an extension that allows querying of pricing data:

https://www.centralnic.com/company/labs/epp/ext/pricing

G.

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 24 Aug 2012 12:35:15 +0200

>         end-to-end authenticity of frames.

Hi,

well, I do not consider myself a security expert, but I don't see how XML 
signatures would be beneficial, especially in the context of its overwhelming 
complexity, which is considered as an attack vector to its security.

re 1: this scenario assumes that the registrar is not capable keeping his 
credentials for accessing the registry in a safe place, so that they can be 
misused by non-authorized employees. But then the storage of the private key for 
the signature is likely to be similar unsafe.

re 2: I don't think that such use cases should not be integrated into a 
protocol, esp. as this can be done on-top. Transport integrity is guaranteed by 
TLS (RFC 5734). If this is not sufficient, a different transport protocol can be 
implemented.

re 3: I think one should follow the principle of separation of concerns, or, 
differently said, on the layer model. If the base transport protocol does not 
support the desired security or cannot be extended appropriately (e.g. S/MIME 
for SMTP), one should better ask in the first place why it should be used at all.

Just my two cents,

Klaus