Re: [ietf-provreg] a question for the list

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] a question for the list

I second Michael.  The sponsorship query service could be defined using a new EPP Mapping and the info command (filters defined in the command supporting sponsorship information across multiple entity types).  This is just one example of a use case that could go up the standards track if there was enough cross-cutting need.  I don’t personally see a need for this but others might.  I wouldn’t touch the base protocol unless it was absolutely necessary, but to focus on the set of custom mappings and extensions that have been created and are being created to see if there is more general interest of moving them up the standards track.  We have many custom mappings and extensions that might be of interest as well.  Collaboration by an EPP Working Group would help address the issue of the growing set of custom EPP mappings and extensions.  

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: Michael Young <myoung@ca.afilias.info>
Date: Wed, 20 Jan 2010 10:58:26 -0500
To: Andrew Sullivan <ajs@shinkuro.com>, EPP Provreg <ietf-provreg@cafax.se>
Subject: RE: [ietf-provreg] a question for the list

I hear your arguments Andrew and I don't disagree. However I just haven't
seen any issues raised here that says we MUST or even SHOULD change the core
protocol.  The listed issues thus far could all be dealt with using
extensions AND I do agree with forming a concentrated effort around managing
extensions.

To my mind, any changes with the core protocol involves risk and cost to
registrars and registries.  This is why a lot of consideration was given to
the extensions in the first place - to avoid having to jump immediately into
core protocol revision work whenever a new use case comes up.  The real
problem I am hearing here is that we (by "we" I mean the EPP community)
haven't done a good job managing extension work. We need to fix that.


Best Regards,

Michael Young



-----Original Message-----
From: Andrew Sullivan [mailto:ajs@shinkuro.com]
Sent: January-19-10 9:05 AM
To: 'EPP Provreg'
Subject: Re: [ietf-provreg] a question for the list

On Tue, Jan 19, 2010 at 07:54:10AM -0500, Michael Young wrote:
> can't help but think that if we were talking about this level of change
with
> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an
analogue won't work: it's too different.  The DNS is involved in just
about every interaction on the Internet, and it has to be deployed on
nearly every Internet node.  Moreover, most DNS deployments (stub
resolvers) are on the machines of people we have no way of reaching
out and talking to.  Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small
carbuncles to have grown on it and become part of the _de facto_
standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,
and because EPP is a two-way protocol with a handshake step and so on,
it is possible to warn clients of an impending change to the protocol.
While provisioning in the DNS is pretty important, it's not core
infrastructure the way resolution in the DNS is, because it's not
directly invoked for every Internet transaction.  And finally, since
the protocol isn't that old, the opportunities for it to have grown
significant differences from the RFCs are fewer (and such cases can,
in any case, be called errors without causing half the installed base
to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some
disruption; but not "time to reformat the Internet", which is what
major changes to the DNS might entail if not done just right.  In the
DNS, there are some pretty big rewards we'd like to go after, but the
risk is too great so we don't make the changes.  Similar rewards, if
they were available in EPP, might be worth the risk.

A


--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se