Re: [regext] REGEXT Interim Meeting
Roger, thanks for putting the notes together. Later during the day yesterday, i came up with a very simple requirement that i think would cover my concerns regarding mixing in launch phases in the fee document: - The Fee Extension MUST provide full functionality with registries implementations which are unaware of the Launch Phase extension. I think that pretty much covers it. Everything else would be dangerous mixup. My personal preference is still to investigate why exactly the "class" functionality does not cover Thomas' use cases anymore, because i'd like to see the launch phases be completely disconnected from the Fees document. best, Alex Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Roger D Carney Gesendet: Dienstag, 11. Juli 2017 20:55 An: regext@ietf.org Betreff: [regext] REGEXT Interim Meeting [x_phishing] Good Afternoon, We held an interim meeting this morning and discussed the current Fee draft document (draft-ietf-regext-epp-fees-05). In attendance was Thomas Corte, Jody Kolker, Antoin Verschuren, Alex Mayrhofer, James Galvin, Scott Hollenbeck, Joe Snitker, and Roger Carney. We started by confirming that the current revision of the document (v5) addressed all currently known issues (except the "minOccurs" issue that Thomas raised on the list two weeks ago, which will be addressed in next revision). 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: * move this phase/subphase listing functionality out of this document and into the draft-ietf-eppext-launchphase document; * remove paragraph 2 and 4 of section 3.8; * 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 1. Scott mentioned that we need to add a normative reference to the draft-ietf-eppext-launchphase document as we refer to it in 3.8. This is planned for the next revision. 2. Lastly we touched on the subject of the "avail" attribute. James poised the question of value versus complexity. Do members of the WG understand the purpose of the "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? Additionally, we talked about including support in draft-ietf-eppext-launchphase to get a list of phases for a TLD and a list of current active phases. Scott was going to bring this up to James Gould as well (Gould was one of the authors of the launch phase document). We would like to get WG thoughts and comments on any and all of these items so that we can gain a rough consensus and get closure of these items. Next week in Prague, at the REGEXT meeting Tuesday at 13:30 local time, I will provide an update on how the interim meeting went and on the draft. The plan is to get rough consensus on the changes needed for the next revision of the Fee document, and shortly after IETF-99 produce revision 6 and look to go to WG last call. If anyone has any additional thoughts on these topics or new topics for the Fee document please let us know. Thanks to all of you that participated this morning, it was a very productive meeting. I look forward to seeing most of you next week. Thanks Roger ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting
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 command with the fee extension, including a single 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 command with fee extension and include *multiple* 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 “avail” attribute. > James poised the question of value versus complexity. Do members of > the WG understand the purpose of the “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 cal
Re: [regext] REGEXT Interim Meeting
Alexander,
On 12/07/2017 09:26, Alexander Mayrhofer wrote:
> Later during the day yesterday, i
> came up with a very simple requirement that i think would cover my
> concerns regarding mixing in launch phases in the fee document:
>
> - The Fee Extension MUST provide full functionality with
> registries implementations which are unaware of the Launch Phase extension.
Hmm, but how exactly would you define "full functionality" in this
context? Requiring to read each "MAY"/"SHOULD" as a "MUST"?
> I think that pretty much covers it. Everything else would be dangerous
> mixup. My personal preference is still to investigate why exactly the
> „class“ functionality does not cover Thomas‘ use cases anymore, because
> i’d like to see the launch phases be completely disconnected from the
> Fees document.
Old versions of the draft treated the "class" attribute as a pure
*return* value, i.e. it never appeared in any command, just in responses.
Hence we saw it as an option (which we also discussed with Gavin Brown
back then) to return the correct launch phase as a class.
Later versions of the document added the class to the commands, and also
required to use specific class names ("standard") in certain situations.
This would have required an awkward mapping from e.g. the launch phase
name "open" to "standard". At the same time, the draft added dedicated
launch phase support, which gave us a more elegant way to solve our issues.
The more I think about it, the more I agree that launch phases have
indeed no place in the fee extension *at all*. With the changes
introduced yesterday, the fee extension does not provide any
helpful information with regard to launch phases; actually it now even
requires the registrar to have a hunch about which of multiple active
launch phase may be suitable for a name in order to obtain fee information.
My preference would therefore be to either leave the draft as it is, or
the remove all references to launch phases completely.
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
Re: [regext] REGEXT Interim Meeting
We actually request fees for future phases so we can sell pre-registrations
and the like. Removing all references to launch phases would prevent that
ability and make things much more complex and prone to errors.
Thanks,
-Pat
On Wed, Jul 12, 2017 at 6:41 AM Thomas Corte wrote:
> Alexander,
>
> On 12/07/2017 09:26, Alexander Mayrhofer wrote:
>
> > Later during the day yesterday, i
> > came up with a very simple requirement that i think would cover my
> > concerns regarding mixing in launch phases in the fee document:
> >
> > - The Fee Extension MUST provide full functionality with
> > registries implementations which are unaware of the Launch Phase
> extension.
>
> Hmm, but how exactly would you define "full functionality" in this
> context? Requiring to read each "MAY"/"SHOULD" as a "MUST"?
>
> > I think that pretty much covers it. Everything else would be dangerous
> > mixup. My personal preference is still to investigate why exactly the
> > „class“ functionality does not cover Thomas‘ use cases anymore, because
> > i’d like to see the launch phases be completely disconnected from the
> > Fees document.
>
> Old versions of the draft treated the "class" attribute as a pure
> *return* value, i.e. it never appeared in any command, just in responses.
> Hence we saw it as an option (which we also discussed with Gavin Brown
> back then) to return the correct launch phase as a class.
>
> Later versions of the document added the class to the commands, and also
> required to use specific class names ("standard") in certain situations.
> This would have required an awkward mapping from e.g. the launch phase
> name "open" to "standard". At the same time, the draft added dedicated
> launch phase support, which gave us a more elegant way to solve our issues.
>
> The more I think about it, the more I agree that launch phases have
> indeed no place in the fee extension *at all*. With the changes
> introduced yesterday, the fee extension does not provide any
> helpful information with regard to launch phases; actually it now even
> requires the registrar to have a hunch about which of multiple active
> launch phase may be suitable for a name in order to obtain fee information.
> My preference would therefore be to either leave the draft as it is, or
> the remove all references to launch phases completely.
>
> Best regards,
>
> Thomas
>
> --
> TANGO REGISTRY SERVICES® is a product of:
> Knipp Medien und Kommunikation GmbH
> Technologiepark Phone: +49 231 9703-222
> <+49%20231%209703222>
> Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200
> <+49%20231%209703200>
> D-44227 Dortmund E-Mail: supp...@tango-rs.com
> Germany
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
--
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
