Subject: <authInfo> in Transfer Query for Domain and Contact

From: "Liu, Hong" <[email-masked]>
Date: Fri, 11 Oct 2002 19:10:19 -0400

For some reason, I did not see this email appear in the archive. So here is
the resend.

-----Original Message-----
From: Liu, Hong 
Sent: Friday, October 11, 2002 3:33 PM
To: [email-masked]'
Subject: <authInfo> in Transfer Query for Domain and Contact

Scott,

I have a question about <authInfo> being mandatory for the <transfer>
command. I understand that it was added into EPP-06 [1] based on the
"spying" issue raised by Dan Manley [2]. I also feel that this parameter
should be mandatory for the other four operations related to <transfer>,
i.e., request, cancel, reject and approve.

However, there is a special case where it is helpful NOT to make <authInfo>
manadatory. The scenario is the following: domain abc.tld is transferred
from Registrar A to Registrar B. During the transfer pending period, both A
and B share the knowledge of the same <authInfo> of abc.tld. However, after
the transfer is completed successfully, Registrar B may change the
<authInfo> (for security reasons or at the request of the registrar of
abc.tld). Once that happens, Registrar B will not be able to see the
transfer result of abc.tld anymore...However, GRRP Requirements (RFC 3375)
requires that (page 10):

[8] The protocol MUST provide services that allow both the original
sponsoring registrar and the potential new registrar to monitor the status
of both pending and completed transfer requests. 

The same problem exists for <authInfo> being mandatory for contact transfer.

Do you think this is a problem in the EPP domain and contact specs that
needs to be fixed? Thanks!

--Hong

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

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 20 Oct 2002 19:29:29 +0200

Hong,

The reason was:

Subject: BOUNCE [email-masked]:     Admin request of type /\bcancel\b/i at line 7  

Which translates to:

In the first n-lines (I'm not sure about the value of n) the majordomo
server noticed ``cancel'' and thought it was a  cancel request. Me,
being away, hadn't the opportunity to approve the message.

Sorry about all this. It does raises another question: Anybody else
out there willing to share the administrational burden maintaining
the provreg list?

	jaap

To quote the part that triggered the bounce: