Subject: [regext] REGEXT Interim Meeting

From: Roger D Carney <[email-masked]>
Date: Tue, 11 Jul 2017 18:54:56 +0000

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 <fee:command> "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 <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?

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 12 Jul 2017 07:26:22 +0000

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:[email-masked]] Im Auftrag von Roger D Carney
Gesendet: Dienstag, 11. Juli 2017 20:55
An: [email-masked]
Betreff: [regext] REGEXT Interim Meeting [x_phishing]

Good Afternoon,

Thanks
Roger

---

From: Thomas Corte <[email-masked]>
Date: Wed, 12 Jul 2017 11:45:38 +0200

Hello,

On 11/07/2017 20:54, Roger D Carney wrote:

>  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:
> 

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: [email-masked]
Germany

---

From: Thomas Corte <[email-masked]>
Date: Wed, 12 Jul 2017 14:40:59 +0200

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 <check> 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

---

From: Pat Moroney <[email-masked]>
Date: Wed, 12 Jul 2017 17:18:01 +0000

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 <[email-masked]> wrote:

> <+49%20231%209703222>
> <+49%20231%209703200>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: Thomas Corte <[email-masked]>
Date: Thu, 13 Jul 2017 10:37:48 +0200

Pat,

On 2017-07-12 19:18, Pat Moroney wrote:

> 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.

Good point.

On that topic, in Tuesday's call we briefly touched the question of what
constitutes an "active" phase in the context of the fee extension.
In my understanding, a phase is regarded as "active" if it is infinite
(no end date) or if its end date is in the future, regardless of its
start date. This means that even phases starting in the future are
deemed "active".
I'm not sure whether there was consensus about this interpretation in
the group.

/Thomas

---

From: Jody Kolker <[email-masked]>
Date: Mon, 17 Jul 2017 22:42:37 +0000

Active to me means a phase where the start date is in the past and the end date is in the future.  

This interpretation would cause an issue when a check is performed if a registry was in a quiet period between phases, where no phase is active.  If a check command was performed during this time without a phase/subphase, what should be returned?

Options:

1.  Return an error - no phase/subphase specified.
2.  Return the fee for GA phase.
3.  Return the fee for the next phase in the future.
4.  Return the fee for all future phases.

Thoughts? 

Thanks,
Jody Kolker

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Thursday, July 13, 2017 10:38 AM
To: Pat Moroney <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [regext] REGEXT Interim Meeting

Pat,

On 2017-07-12 19:18, Pat Moroney wrote:

> 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.

Good point.

On that topic, in Tuesday's call we briefly touched the question of what constitutes an "active" phase in the context of the fee extension.
In my understanding, a phase is regarded as "active" if it is infinite (no end date) or if its end date is in the future, regardless of its start date. This means that even phases starting in the future are deemed "active".
I'm not sure whether there was consensus about this interpretation in the group.

/Thomas

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 17 Jul 2017 20:19:10 -0300

> Em 17 de jul de 2017, à(s) 19:42:000, Jody Kolker <[email-masked]> escreveu:
> 

Option 4 looks better to me, but it requires the most "interesting" phase (like GA) to be well-known, otherwise you might not get the most important information. 

Rubens