Hello James, > 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.
I can understand that but then, being too much extensible also comes with its own perils. With the same reasoning, why not extend the renew command also? > 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”. These documents define the extension being discussed. In your draft you give an example using an extension not used anywhere nor defined. I still fail to understand that, but maybe it is just me. > 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. I am not saying that extending the update extension is the problem (while I am still not 100% convinced by the use case, I can accept it technically) I am saying that the example is not clear, as it is using something not even discussed in your document, without explanations. But if it is clear for everyone else, then it is ok. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
