Hello James and Kal,
Please find below my comments on your draft.
Abstract: remove "or code" in "an allocation token or code", as this is
not repeated after and does not add value.
The introduction needs to be rephrased, multiple sentences did not have
sense to me:
"This mapping, an
extension to EPP object mappings like the EPP domain name mapping
[RFC5731], for passing an allocation token one of the EPP transform
commands including create, update, and transfer."
There is no verb at all: This mapping... for passing...
A "to" is probably missing: an allocation token TO one of the EPP ...
This sentence seems overly complex to say what it says:
The allocation
token is known to the server to authorize a client that passes a
matching allocation token with one of the supported EPP transform
commands.
Why not something simpler like:
A client must pass an allocation token known to the server to be
authorized to use one of the supported EPP transform commands.
This is not clear technically: The allocation token MAY
be returned to an authorized client for passing out-of-band to a
client that uses it with an EPP transform command.
Two clients seem defined here, are they the same one or not? If not,
what is the difference?
1. Introduction
Maybe make more clear if the allocationToken can be used to do
operations on some existing objects by a registrar not being its current
sponsor. Is this the goal, or just something possible among other
things, or not at all?
In 2.1 Inconsistent case: sometimes "Allocation Token", sometimes
"allocation token"
This does not seem clear: The server MUST have
the allocation token for each object to match against the allocation
token passed by the client to authorize the allocation of the object.
I believe that you want to say that the allocation token must be checked
on the server and match the expected value. But no need to overspecify
things the server may not even have the allocation token stored, it can
be the hash of the object ID and a secret hence checked dynamically.
3.1.1
There is a gap between the feature here and the introduction.
The introduction says:
"authorization to
allocate an object using one of the EPP transform commands including
create, update, and transfer."
(and this sentence is not clear by itself, why is an update or a
transfer
now an allocation?)
where in the check command:
Clients can
check if an object can be created using the allocation token.
So how can clients check if an object could be updated or transfered
using the given allocation token, besides trying to do it and seeing if
it fails or not? But since create has a specific command to test the
allocation token (with check), why not the others?
Otherwise the introduction will need to be changed to speak only about
create, which then will make more sense with its name ("allocation") as
otherwise if it really needs to be generic accross multiple actions I
would suggest something more like "authorization token" with the risk of
clashing with EPP core authInfo concept.
Is there a reason to put the result in the domain:reason node instead
of having really an allocationToken extension in the domain:check reply
which will store data specific to it?
(like it is done for the fees extension, or launchphase, etc.)
3.1.2
I would like more explanation on what the allocationToken there
represents, especially considering the gap I see between what is in the
description and the check command as explained above.
When doing domain:info, is the allocation token returned the one used to
do the create? Or is it the one to be used to do a transfer or update?
What if there are not the same?
What is in fact the use case of providing to a registrar an allocation
token that way, when it is said at the beginning that such allocation
tokens are retrieved out of bound?
This is also related to what we see on the field with some registries
that never show the authInfo because they store it hashed or something
like that, so in a one-way destructive method. Shouldn't the allocation
token be kind of "write only", where you can verify you get the correct
one before attempting to use it, but never see it if you do not have it
already (the out of bound of the introduction)
About the 2303: I am not sure that it is the correct error code to
return, as an allocation token is not a registry object and this error
code is more likely tied to the existence or not of the underlying
domain object.
3.2.2 / 3.2.3 why does the allocation token not cover these cases, where
it covers create, update and transfer?
Specially since in section 1 you defer to server policy to decide which
EPP transform commands support the allocation token... but the extension
does not add support for renew/delete, so this is not bound by server
policy but by protocol design.
3.2.4
Nitpick: final extra unneeded ":" at end of:
the server MUST return an EPP error result code of
2201.:
As explained above, I feel uneasy by:
Example <transfer> request command to allocate the domain object with
the allocation token:
A transfer command does not allocate an object (for me, but maybe it is
an error in my English understanding, allocate is a synonym to register
in our context), it transfers it.
3.2.5 Same nitpick as previous section, about the extra : at end.
Your XML example has a:
C: <release:release
C: xmlns:release="urn:ietf:params:xml:ns:release-1.0"/>
which is probably a copy and paste error.
General:
Should there be some guidance somewhere that allocation tokens should be
unique and not reused accross multiple domains?
But then domain:check with multiple domains and only one token are less
useful.
For implementation status, if you wish you can add the Net::DRI client
to the list.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
