Hello, On 11/07/2017 20:54, Roger D Carney wrote:
> We moved on to discussing any new issues/concerns, three items were raised: > > 1. First of which relates to section 3.8 and specifically what happens > when a client does not provide a phase/subphase. We spent the > majority of the meeting, roughly 45 minutes, discussing this item. > Initial comments were that this functionality seemed to be an over > reach for this document. Originally Alex thought that a compromise > might be that we change the “should”s in paragraph 2 and 4 to “MAY”s. > The group talked this through and said that was possible but > generally it was still thought to be over reaching. The group > concluded that the best approach maybe to: > 1. move this phase/subphase listing functionality out of this > document and into the draft-ietf-eppext-launchphase document; > 2. remove paragraph 2 and 4 of section 3.8; > 3. add text to section 3.8 to handle clients not passing in > phase/subphase: > > i. where there is only one active phase/subphase server MUST return > phase/subphase and appropriate fees, > > ii. where there is no active phase/subphase server MUST return a reason that > there is no active phase at this time, > > iii. where there is more than one active phase/subphase server MUST return a > 2003 > "Required parameter missing" error As announced on the call yesterday, I'd like to put on record that I wasn't in favor of this change (but got overruled). While I do appreciate that a functionality listing all available launch phases can be seen as a overreach of the fee extension, it's worth noting that the authors of the fee extension obviously *do* acknowledge a likely connection between fees and launch phases (otherwise, why include phase information in the extension at all?). In fact, after the changes suggested above, we might just as well consider eliminating *all* references to launch phases and the launch phase extension from the fee extension draft. Admittedly, most of my concerns are based on the fact that in our own registry system, premium prices are closely tied to launch phases. In our model, if a TLD offers premium names, each premium name is available in exactly one launch phase establishing its price (which means that multiple launch phases are active in parallel at any time). In this scenario (which is perfectly legal with regard to the use of phases), determining the price for a name with the current draft-ietf-regext-epp-fees-05 draft is easy - the registrar simply sends a <check> command with the fee extension, including a single <command> element without specifying any launch phase; the server can then return prices for all phases, including the one in which the name is available. Now, after the suggested change, the server would have to return an error message, since multiple phases are active and none were specified. The registrar would then instead have to 1) Determine all the available phases (either out-of-band or with the proposed list functionality of the launch phase extension) and 2) Send a <check> command with fee extension and include *multiple* <command> elements, *one for each active launch phase* The load created on the server for this is essentially the same as above (plus it may add an extra command for getting the launch phases), so nothing is gained on the server side. For the registrar, things are more difficult, too. Note that one can easily find a scenario in which the above problem arises, even if a registry does not use launch phases for premium names. Many of our registries' startup phases involved more than one launch phase at the same time, each with individual name eligibility rules and different prices. For such registries, the proposed change would equally complicate the determination of prices for registrars. In conclusion, I'd be in favor of retaining the "launch phase wildcard" functionality. If that's not deemed acceptable, I'd also be OK with adding the following wording to options i. and iii. above: "i. where there is only one active phase/subphase *in which the name is available* server MUST return phase/subphase and appropriate fees," ... "iii. where there is more than one active phase/subphase *in which the name is available*, server MUST return a 2003 "Required parameter missing" error This would enable a server with multiple launch phases (but only one in which each name is available) to still return useful information without the registrar having to know the right phase up front. > 3. Lastly we touched on the subject of the <fee:cd> “avail” attribute. > James poised the question of value versus complexity. Do members of > the WG understand the purpose of the <cd:fee> “avail” attribute? Do > we need more text in the document to help explain intent? Do we gain > enough value by introducing another level of availability? As I mentioned yesterday, right now the attribute seems redundant since its value can be fully calculated from the contents of the <cd> element; if there are any <command> elements in there with fees, avail will be true, if no <command> element names a fee, avail will be false. However, I'd still be in favor of keeping it since it provides registrars with an easy way to check for the availability of fees without iterating through the contents of the the <cd> element. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
