Patrick, Sorry about the long delay in my review of your feedback. Thank you for doing the detailed review. From a high-level, I need to discuss the extension of the info command / response with Kal. I include my responses to your feedback embedded below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/20/17, 11:40 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: 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. Ok, no problem. 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 ... Agreed, a “to” is missing so it should read “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. I agree, the reworded sentence is better; although I believe it should use a RFC 2119 “MUST”. The wording “supporting EPP transform commands” implies that the object (domain name) requires the allocation token, since the allocation token may not be required for all objects (domain names) in the registry. Also, the wording “allocation token known” does not mean that the value of the allocation token must be pre-defined, since using an allocation token that uses a digital signature that is validated by the server means that the server knows the token format and validates it. 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? I agree that is somewhat confusing. There are two separate clients (authorized client like an auction provider and registrant). An authorized client (e.g., auction provider) could use the allocation token extension to the info command to retrieve the allocation token that can be passed to another client (registrant) to authorize the registration / allocation of the domain name. Now that the use case is defined, how does this sentence get cleaned up to be less confusing? 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.”? 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? No, that is not the goal. The goal is around authorizing a registration or allocation of an object based on passing a validate allocation token. There are no other known uses of the allocation token extension to do things like what is done with the verification code extension (draft-ietf-regext-verificationcode). 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. Yes, I agree that the draft should not be overly restrictive on the format of the allocation token, where the allocation token extension is simply a conduit to pass an allocation token that is known and can be verified by the server. There are multiple known use cases for allocation tokens that include pre-generated values and digitally signed tokens. 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. 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. The fix here would to be change “object can be created” to be “object can be allocated”. The mechanism for allocation is not restricted to create; although create is the most likely command. The object is being allocated in any case, but using different commands to do it, so I don’t believe that changing the name will help. 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.) The allocation token extension is extending the domain check command to drive the avail attribute value in the domain check response. This is a simple check that does not require additional information other than the Boolean “avail” value and a human readable reason. 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. Let me chat this over with Kal, since Neustar added the extension to the info command / response. 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) 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. The most likely scenario is to provide the allocation token values to the “authorized client” out-of-band. Using a 1-way hash is a more secure option on the server-side; although I’m not sure if a 1-way hash is necessary considering that it’s a short lived, single use token. The reference to out-of-band in the introduction is associated with the “authorized client” (e.g., auction provider) providing the token value to the client (e.g., registrant). 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. The use of 2303 makes sense if the info extension defined an Allocation Token Info Command, where the query is about the allocation token and not the domain information with the addition of the allocation token. If the allocation token does not exist for an Allocation Token Info Command, then 2303 makes sense if the Allocation Token does not exist. 3.2.2 / 3.2.3 why does the allocation token not cover these cases, where it covers create, update and transfer? Allocation has been handled via create, update (new command), and transfer, but not using delete or renew. 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. Correct, the server policy would define which of the supported commands the allocation token extension applies to. 3.2.4 Nitpick: final extra unneeded ":" at end of: the server MUST return an EPP error result code of 2201.: Thanks, the unneeded “:” will be removed. 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. Yes, I personally wouldn’t recommend using transfer for allocation, but the allocation of premium domain names has been handled via transfer. The difference is that the domain exists under sponsorship of the registry or a special premium registrar account that are allocated to a registrar via the transfer command. 3.2.5 Same nitpick as previous section, about the extra : at end. Thanks, the unneeded “:” will be removed. 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). 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. Yes, that would be applicable for pre-generated allocation tokens. An allocation token could be a digitally signed by a trusted third party that pre-authorizes the allocation of domain names. Since the makeup of an allocation token is not formally defined within the draft, I’m not sure whether the draft can put any constraints on it. 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? 1. Organization 2. Description 3. Level of maturity 4. Coverage 5. Licensing 6. Contact 7. URL -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
