Hi all, In order to achieve progress, I’m trying to summarize the discussion:
1. Most folks agree there may be a need for phase discovery. When there are multiple phases for registration, and there are real world examples for that, being able to discover the phase a domain is viable in through an availability check is at least "handy”, to avoid trial and error or out of bound discovery processes. This may be true for other EPP "knobs” as well though. 2. This need only arises in corner cases though. We’re not talking millions of domain names here. If we are, then there may be something wrong with the registry policy being too complex, and not the registration process. 3. The Launchphase draft and it’s check command was not meant to address this need. The launchphase process only describes how to do things once you know what you want to do. Can I conclude that the Launchphase draft should proceed as is? 4. The major demand for phase discovery is to discover the correct fee. I understand this business wise. You want to present your customer the correct fee during registration. But this one bugs me a little bit. <chair hat off> While I understand that a special launch phase may be accompanied with a different fee because of potential special handling, this should not be a differentiator to group fees imho though. A (launch) phase is meant to differentiate in a different allocation policy, like preference or limitation in registrants, equal distribution, respect for trademarks or other policy related allocation. When trying to discover a phase based on it’s fee, it feels like you are trying to ignore the policy as the true differentiator, almost saying the policy doesn’t matter, and for the right fee, we will try to comply to or even ignore the policy in stead of the intent of first complying to the policy and then care for the extra fee. </chair hat off> The question therefor is if the Fee document will be able to solve this? The major question for the chairs now is if we can proceed with the Launchphase document. The chairs believe that there is majority consensus to not change the Launchphase document. If not, we would like to hear that before the end of next week so we can proceed that document to the IESG. The second question then is if there is a need to change the Fee document to accommodate the use case Thomas needs. Or that it needs a more generic phase discovery like the suggestion for a Registry Mapping document. We expect that this will be discussed during the interim meeting next wednsesday. Please comment if any of my conclusions on the consensus is incorrect. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 15 aug. 2017, om 15:42 heeft Gavin Brown <gavin.br...@centralnic.com> het volgende geschreven: > On 14/08/2017 19:27, Gould, James wrote: > >> As a co-author of Launch Phase Mapping going back 5 years and the one that >> added the “Domain names may be made available only in unique launch phases, >> whilst remaining unavailable for concurrent launch phases” language to the >> draft, I’m aware of the intent. Wil and Gavin can also weigh in on the >> intent. The intent was for the launch phases to be associated with the TLD >> (or zone), where there may be a policy for launch phases that differentiates >> the availability of domain names. It was never intended or foreseen that a >> launch phase would be used to group a set of domain names as a form of fee >> classification. We can agree to disagree on this topic. > > I agree with Jim. The Launch Phase was not designed to deal with premium > names: I would not have created the fee extension if it were. > > G. > > -- > Gavin Brown > Chief Technology Officer > CentralNic Group plc (LSE:CNIC) > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: 35-39 Moorgate, London, > EC2R 6AR. > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
