RE: <info> Command and authInfo

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Rick,

While I appreciate the apology, I still think you're misunderstanding the
intent of the proposal.  The EPP spec has had recommendations in it (see the
last paragraph of section 2.8.2.2 of epp-05, for example) for quite some
time to describe how the commands should be implemented:

"This action SHOULD be limited to authorized clients; restricting this
action to the sponsoring client is RECOMMENDED."

My contention is that this leaves room for interoperability problems.  A
client who expects a server to support unrestricted <info> commands will
likely have problems at a higher layer when working with another server that
restricts <info> commands as described in the spec.  Maybe this is a false
assumption on my part, but that's why I floated the idea in the first place.

I recognize the problem with RRP in the context of domain transfers, and I
don't want EPP to have the same problem.  The gaining client has a
legitimate reason to see domain info as part of processing a transfer
request, they have the <authInfo> in-hand, and if the <info> command is
changed as I described the client can perform the <info> command
successfully.  As the specs are currently written, a server can legitimately
prevent the gaining client from performing the <info> command.  I wanted to
suggest a change to make this scenario work while sticking to the spirit of
the "authorized clients" recommendation.

You've suggested that "the status command should be open to all registrars".
Let's change "status" to <info> to make this about EPP and not RRP.  Here's
my question to you: other than as part of requesting a transfer, what other
_technical_ reason(s) does a client have to perform an <info> command on a
domain sponsored by another client?

Sorry if you've answered that question in some other forum recently, but
what I recall was gleaned from our shared experiences of mid-1999.  Knowing
that some registries will likely implement EPP to the "authorized clients"
recommendation, I wanted to propose a solution that takes care of the
problem in the context of transfers.  Yes, opening up the command completely
would also eliminate the problem, but I feel very strongly that it
introduces other problems relating to privacy and load management.  Yes,
some of the info returned in response to an <info> command is publicly
available via whois, but not everything is.

Finally, there was a recent thread on the list [1] about requiring
<authInfo> for transfer queries.  Folks supported that change.  Don't the
same privacy concerns come into play here?

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.html

> -----Original Message-----
> From: Rick H Wesson [mailto:wessorh@ar.com]
> Sent: Monday, January 14, 2002 1:01 PM
> To: Hollenbeck, Scott
> Cc: 'ietf-provreg@cafax.se'
> Subject: RE: <info> Command and authInfo
> 
> 
> 
> Scott,
> 
> ok, my comments were not meant as an ad-hominem attack on you, we have
> known each other a long time and I'm not attacking you 
> personally, but I
> do have strong opinion on the subject from a long experience with RRP.
> 
> registries have a contract with registrars and MUST enforce those
> contracts; we should not be designing defense from datamining into the
> protocols. registries MUST enforce their contracts and 
> provide appropriate
> oversite of the registrars.
> 
> We have recent experience of registrars abusing the common 
> resource of a
> RRP based registry, just because the Registry does not enforce their
> contracts does not mean we should design mechanisms into the 
> protocol to
> cover administrative procedures.
> 
> I hope this clarifies my previous comment. apologies if you 
> thought they
> were of a personal nature directed at you.
> 
> personal regards,
> 
> -rick