[nc-transfer] FYI Fw: [ga] Domain Transfers

["Ross Wm. Rader" <ross@tucows.com>]

Folks,

Just a quick FYI on the post below - we will likely need to take a look at
these structures as part of our efforts here - none of these facilities are
found in the Verisign RRP protocol which is one of the main reasons that the
bulk of our work will likely be RRP-registry specific. A review of the
EEP-registry policies will also likely be required however to ensure that
they are consistent with the transfer policies found elsewhere in the
namespace.

At some point, a technical briefing on the similarities, differences and
impact of RRP v. EPP might be in order. I would pleased to arrange for this
if there is interest from the TF.

Thanks,

-rwr

----- Original Message -----
From: "Ross Wm. Rader" <ross@tucows.com>
To: <Eric@Business.com.VN>; "Kent Crispin" <kent@songbird.com>; "Sandy
Harris" <sandy@storm.ca>; "Kristy McKee" <k@widgital.com>
Sent: Saturday, December 15, 2001 7:07 PM
Subject: Re: [ga] Domain Transfers


>
> > What we need is a protocol to establish parameters for such
> > authentication.
> > Yes I advocate that user ability be included, $$$ always a factor.
> > Isn't this the same argument as ALSC voter authentication?
> > Any and all voting.
> > E-commerce holds many answers but fails in that it costs.
> > Translation of documents is another matter required.
> > Security is important as long as it is not the tail wagging the dog.
>
> This is largely a moot point actually - the new EPP (extensible
provisioning
> protocol - http://www.ietf.org/html.charters/provreg-charter.html) that
the
> new registries are using (.au, .info, .biz and others I'm sure) actually
> fulfill this requirement. Each user is provided with authorization
> information that must be presented in a key-like manner in order that a
> transfer can occur. An examination of the relevant policy need be
undertaken
> however to ensure that customers are fairly provided with the
authorization
> information etc. I would expect the transfers TF to look at this
> specifically. The following is the relevant portion of the EPP draft.
>
> The full text can be found at
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-05.txt
>
> "The EPP <transfer> command is used to manage changes in client
sponsorship
> of an existing object.  Clients may initiate a transfer request, cancel a
> transfer request, approve a transfer request, and reject a transfer
request
> using the "op" command attribute.
>
> A client who wishes to assume sponsorship of a known object from another
> client uses the <transfer> command with the value of the "op" attribute
set
> to "request".  Once a transfer has been requested, the
> same client may cancel the request using a <transfer> command with the
value
> of the "op" attribute set to "cancel".  A request to cancel the transfer
> MUST be sent to the server before the current sponsoring
> client either approves or rejects the transfer request and before the
server
> automatically processes the request due to responding client inactivity.
>
> Once a transfer request has been received by the server, the server MUST
> notify the current sponsoring client of the requested transfer by queuing
a
> service message for retrieval via the <poll> command.  The current status
of
> a pending <transfer> command for any object MAY be found using the
> <transfer> query command.
>
> The current sponsoring client MAY explicitly approve or reject the
transfer
> request.  The client may approve the request using a <transfer> command
with
> the value of the "op" attribute set to "approve".  The client may reject
the
> request using a <transfer> command with the value of the "op" attribute
set
> to "reject".
>
> A server MAY automatically approve or reject all transfer requests that
are
> not explicitly approved or rejected by the current sponsoring client
within
> a fixed amount of time.  The amount of time to wait for
> explicit action and the default server behavior are local matters not
> specified by EPP, but they SHOULD be documented in a server-specific
profile
> document that describes default server behavior for client
> information.
>
> Objects MAY have associated authorization information that MUST be
provided
> to complete a <transfer> command.  The type of authorization information
> required is object-specific; passwords or more complex mechanisms based on
> public key cryptography are typical.
>
> The elements needed to identify and complete the transfer of an object are
> object-specific, so the child elements of the <transfer> command are
> specified using the EPP extension framework.  In addition to the standard
> EPP command elements, the <transfer> command contains the following child
> elements:
>
>   - An object-specific <obj:transfer> element that identifies the object
to
> be transferred and the elements that are required to process the transfer
> command.
>
> Example <transfer> request command:
>
>   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   C:     epp-1.0.xsd">
>   C:  <command>
>   C:    <transfer op="request">
>   C:      <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj"
>   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
>   C:        <!-- Object-specific elements. -->
>   C:      </obj:transfer>
>   C:    </transfer>
>   C:    <clTRID>ABC-12346</clTRID>
>   C:  </command>
>   C:</epp>
>
> When an <transfer> command has been processed successfully, a server MAY
> respond with an EPP <resData> element that MUST contain a child element
that
> identifies the object namespace and the location of the object schema.
The
> child elements of the <resData> element are object-specific, but they MUST
> include elements that identify the object, the status of the transfer, the
> identifier of the client that requested the transfer, the date and time
that
> the request was made, the identifier of the client that SHOULD act upon
the
> request, the date and time by which an action is expected, and an OPTIONAL
> date and time noting changes in the object's validity period (if
applicable)
> that occur as a result of the transfer.
>
> Example <transfer> request response with <resData>:
>
>   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   S:     epp-1.0.xsd">
>   S:  <response>
>   S:    <result code="1000">
>   S:      <msg>Command completed successfully</msg>
>   S:    </result>
>   S:    <resData>
>   S:      <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
>   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
>   S:        <obj:name>example</obj:name>
>   S:        <obj:trStatus>pending</obj:trStatus>
>   S:        <obj:reID>ClientX</obj:reID>
>   S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
>   S:        <obj:acID>ClientY</obj:acID>
>   S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
>   S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
>   S:      </obj:trnData>
>   S:    </resData>
>   S:    <trID>
>   S:      <clTRID>ABC-12346</clTRID>
>   S:      <svTRID>54322-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp>
>
> The EPP <transfer> command is used to manage changes in client sponsorship
> of an existing object.  This action SHOULD be limited to authorized
clients;
> restricting <transfer> requests to a client other
> than the current sponsoring client, <transfer> approval requests to the
> current sponsoring client, and <transfer> cancellation requests to the
> original requesting client is RECOMMENDED.  Object transfer MAY be
> unavailable or limited by object-specific policies."
>