Hello James,
Just following on the remaining points:
>> 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?
>
> How about
> modifying it to “The allocation token MAY be returned to an authorized
> client (e.g., auction provider) for passing out-of-band to another client
> (e.g., registrant) that uses it with an EPP transform command.”?
I prefer that, indeed.
>> 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?)
>
> It depends on the approach that the registry takes in allocating domain
> names that may be premium. One approach is to have them defined in a
> reference list, which would mean that the create command would be the
> allocation command. Another approach is to hold the domain in the domain
> table and to have the registry or another account be the sponsoring
> client, which would mean that the update (new command) or transfer
> commands could be used for allocation. The protocol supports passing the
> allocation token to any one of the transform commands, where the most
> likely use case is use of the create command for allocation.
Part of the above should be in the document to make things clearer.
I could see things about the transfer, but I am still not convinced
that domain names could spring into existence from an update command.
If this does not reflect existing use cases and if noone presses for it,
it might be better to just drop the part about the update?
>> 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?
>
> The extension of the info command / response is an alternative mechanism
> for the “authorized client” (e.g., auction provider) to get the
> allocation token value.
This confuses me a little: how can the authorized client being in your sentence
the auction provider get the allocation token that way as it would mean it is
an EPP client that connects to the registry? Also since you can do a
domain:info only on a domain name that exists, how
can you expect to retrieve data there (the allocation token) that would be
needed to create the domain name? I see that this could be for the transfer or
update cases, but I'm no fan
of those.
I know you said they were used in the past. But then it must be clear I think
if your document is Informational and writes down what happens on the field
just for historic information or if
your document wishes to become a Standard so showing the "right way" to do
things,
irrespective to what already happened (in the sense that it should not bear
responsabilities
to necessarily sanction what was done in the past).
In the last case, I would still ask for proponents of the "update" case
specifically
to voice themselves.
I could be convinced by transfer, but I really have to force myself :-)
>> 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.
>>
> No, this is by design. The intent here is that the allocation token
> would not be used by itself to allocation an object, but as an extension
> to a new command. The new command is an extension of an empty update.
> In this case the “release:release” is an example of defining a new
> release command that uses the allocation token to authorize the release.
> The release-1.0.xsd includes only the <schema> <element name=”release”/>
> element, and is only defined as an example. You can find the
> “good-domain-release.xml” sample with the referenced “release-1.0.xsd”
> XML schema in the samples directory of the
> EPP-Allocation-Token-Specification GitHub project
> (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git).
I still think there is a problem with an example. As all the previous
discussions
show, transfer in a way but specially update are like edge cases and close
to bending the notion of allocating a domain name. So here you give an example
by just dropping another extension absolutely never explained anywhere in the
draft.
I doubt that this could be accepted as an RFC.
You can not just publish it as a standard and say "the extension is defined in
github"
There is clearly something to phrase differently here.
And I think, in a way, this clearly shows again that the update case for an
allocation
is very strange.
> For implementation status, if you wish you can add the Net::DRI
> client
> to the list.
>
> First off thanks for the work on Net::DRI, and we can certainly add
> Net::DRI to the Implementation Status section. Can you provide the
> following key values to add to the draft or you can also submit a pull
> request to the EPP-Allocation-Token-Specification GitHub project
> (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git)
> if you want to define it yourself?
Ok, I will follow on that separately, thanks.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
