[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Rick H Wesson <wessorh@ar.com>
Date: Mon, 14 Jan 2002 11:38:52 -0800 (PST)
In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B55E@vsvapostal3.bkup6>
Sender: owner-ietf-provreg@cafax.se
Subject: RE: <info> Command and authInfo


Scott,

On Mon, 14 Jan 2002, Hollenbeck, Scott wrote:

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

yes it does, but thick and thin registries may not interoperate? there are
other areas that registry policy MAY interfere with interoperability too
such as how name servers are handeled.


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

then may i suggest the following language.

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

it has the same effect on interoperability.


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

durring expiration, if its a name you are competeing over its a
requirement to know if the domain is recently registered. there are other
examples but I can't disclose some other registrar's business practices

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

the issues I have here is that your suggested fix to this "problem" is
that it re-enforces a position, piticular to your employer, and the
VeriSign Registrar. this where our misunderstanding might stem from, your
suggestion makes it much easier for VGRS to implement a policy in EPP that
Registrars using RRP have found VERY cumbersome.

it is hard to keep RRP out of the converstaion as it has provided us
with a wealth of reasons why the <info> command should be available to all
registrars.

personal regards,

-rick





Home | Date list | Subject list