Patrick, Thanks for your review and attention on the draft. You find my responses 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 12/20/17, 12:13 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: 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. It has been incorporated. >> 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? Your original comment is associated with section 3.1.1 (check command extension), which is associated with the ability to provision (allocation) an object using the <create> command. The extension in section 3.1.1 does not define any command (e.g., allocation check), so it is exclusively associated with the create command. The use of the allocation token extension for the create, update, and transfer commands is covered in the respective sections. In the case of update, the allocation token is used for an extension of an empty update, which would be used to define a new command (e.g., allocate, release). The allocation token can be used to allocate an object using multiple transform commands, but the draft does not intend to dictate which one must be used. The most likely use case is use of the create command, but I want to ensure that the allocation token can be used to meet current and future server policy. >> 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. Forget about my reference to the auction provider, the language as defined in the draft provides the ability to retrieve the allocation token for allocated objects, which would be past tense. You are correct that the object must exist and the extension of the info command is only meant for an authorized client to retrieve the object information along with the allocation token used. 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 :-) I believe you’re viewing the update and an update of an existing object instead of an extension of the update to define a new command like release or allocate. A server could leverage the create command, transfer command, or define a new command as an extension of the empty update. The goal of the extension is not to dictate a single way to allocate, but to support the use of an allocation token to authorize an allocation. >> 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. There are examples of extending an empty update today in the RGP RFC to define a new command called “restore”. There is a similar example in the ConsoliDate Extension (https://www.verisign.com/assets/consolidate-mapping.txt) to define a new command called “sync”. There could be a specific command created for allocation in a similar fashion that can leverage the allocation token for authorizing the allocation. I don’t see any issue with including a hypothetical empty update extension called “release” in an example. Extending of an empty update to define a new command has been done in prior extensions (both RFC and proprietary), and the allocation token should support these sorts of extensions. > 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. Great, thanks. -- 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
