Subject: [regext] REGEXT Interim Meeting

From: Roger D Carney <[email-masked]>
Date: Wed, 23 Aug 2017 20:52:51 +0000

Good Afternoon,

We held an interim meeting this morning and discussed the current Fee draft document (draft-ietf-regext-epp-fees-06) and the Validate draft document (draft-ietf-regext-validate-02).

In attendance was Jody Kolker, Antoin Verschuren, Alex Mayrhofer, James Galvin, Dean Farwell, Andreas Huber and Roger Carney.

Agenda:

  1.  Fee
     *   Confirm Edits (scheme, section 3.8 and reference)
     *   Discuss "Quiet Period": section 3.8 paragraph 5
     *   Discuss WG Last Call
  2.  Validate
     *   Re-introduce
     *   Comments/Questions
  3.  TLD Phase Mapping

We started the meeting by confirming that the current revision of the document (v6) addressed all currently known issues.

Jim Galvin mentioned that we may need to resolve TLD phase detection to make it easier for this draft to move forward as detection (at least in simple form) was removed in the last draft. We spent a few minutes on this and recalled some of the reasons given for removal, e.g. complexity and not a true fit for this draft. We discussed the idea of pulling this into the proposed Registry Mapping draft. We also discussed if the authors were opposed to detection being in the Fee draft and I confirmed that I was not completely against including but I do believe the reasons everyone provided for not including makes sense and that it seems more appropriate in the Registry Mapping draft.

We spent a good amount of time, roughly 35 minutes focused on section 3.8 describing Phase/Subphase. Alex mentioned that 3.8 does not clearly address the scenario of a server not supporting phase/subphase. Alex will provide some language and we will work into the next draft. Discussion continued on the "comfort" idea of phase detection: "Should we allow servers to provide responses with multiple phases/subphases in the same response?" We generally agreed that the added complexity and cost associated with this did not outweigh the possible benefits and that we would stay with the v6 language around this (if client does not supply and only one exists return the one and if multiple exist return error).

No one on the call raised any concerns with the "Quiet Period" in section 3.8 paragraph 5. Please review and express any concerns.

The Chairs did indicate that once we get general agreement on the list for the Fee draft we can move this draft to WG last call. At this point I believe we are in a good state with v6 plus the addition of Alex's suggested text on servers that may not have phase support. Please respond to the list if you agree or disagree.

We moved the discussion onto Validate and Jody provided an overview of the problem space and the proposed solution. There was a general agreement that this proposal sounds good and seems like a logical business issue to resolve. There was some discussion on the possible need to be able to refine this "validate" down to the exact domain name. The draft does allow for this though it was not in the original goals. Jim and Antoin talked about this whole "validate" concept possibly being larger and may need to examined in totality (e.g. with allocation token and verification code). Do they belong together or stay separate, should there be a "higher" framework that pulls together the idea of validation/verification?

If anyone has any additional thoughts on these topics or new topics for these documents please let us know.

Again, thanks to all that were able to participate this morning, it was a very productive meeting.

Thanks
Roger

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 24 Aug 2017 10:01:34 +0200

On Wed, Aug 23, 2017 at 10:52 PM, Roger D Carney <[email-masked]>
wrote:

>
>
> We moved the discussion onto Validate and Jody provided an overview of the
> problem space and the proposed solution. There was a general agreement that
> this proposal sounds good and seems like a logical business issue to
> resolve. There was some discussion on the possible need to be able to
> refine this “validate” down to the exact domain name. The draft does allow
> for this though it was not in the original goals. Jim and Antoin talked
> about this whole “validate” concept possibly being larger and may need to
> examined in totality (e.g. with allocation token and verification code). Do
> they belong together or stay separate, should there be a “higher” framework
> that pulls together the idea of validation/verification?
>
>

What might also be necessary to consider for validation: there are geoTLDs
that do not require a certain contact type to be out of their region, but
rather the policy says that either the registrant or the tech-c or the
admin-c have to be out of that region. The draft allows to state multiple
contact types in one check command, but currently the text does not say if
these contacts are validated separately or if all these contacts are
considered to be then linked to the same domain.

Another situation that seems not be discussed in this meeting is community
TLDs with policies that do out of band validation and accept several
different proofs that you belong to that community. So it is not as simple
as the VATID example in the draft. Hence, I’m not sure if the key value
mechanism could easily cover such scenarios.

Thanks,

Karl

---

From: Roger D Carney <[email-masked]>
Date: Thu, 24 Aug 2017 15:57:34 +0000

Good Morning,

Thanks Karl. Interesting, we had a very similar discussion as we were drafting this document. I believe we had some text describing this but we couldn’t get the language worked out so we pulled it. The intent is that whatever contacts are sent by the client they would be processed by the sever as a whole. We will look to add clarity to the document.

Agreed, there will be some scenarios that this draft will not be able to resolve completely.

Thanks
Roger

From: Karl Heinz Wolf [mailto:[email-masked]]
Sent: Thursday, August 24, 2017 3:02 AM
To: Roger D Carney <[email-masked]>
Cc: [email-masked]
Subject: Re: [regext] REGEXT Interim Meeting

On Wed, Aug 23, 2017 at 10:52 PM, Roger D Carney <[email-masked]<mailto:[email-masked]>> wrote:

We moved the discussion onto Validate and Jody provided an overview of the problem space and the proposed solution. There was a general agreement that this proposal sounds good and seems like a logical business issue to resolve. There was some discussion on the possible need to be able to refine this “validate” down to the exact domain name. The draft does allow for this though it was not in the original goals. Jim and Antoin talked about this whole “validate” concept possibly being larger and may need to examined in totality (e.g. with allocation token and verification code). Do they belong together or stay separate, should there be a “higher” framework that pulls together the idea of validation/verification?

What might also be necessary to consider for validation: there are geoTLDs that do not require a certain contact type to be out of their region, but rather the policy says that either the registrant or the tech-c or the admin-c have to be out of that region. The draft allows to state multiple contact types in one check command, but currently the text does not say if these contacts are validated separately or if all these contacts are considered to be then linked to the same domain.
Another situation that seems not be discussed in this meeting is community TLDs with policies that do out of band validation and accept several different proofs that you belong to that community. So it is not as simple as the VATID example in the draft. Hence, I’m not sure if the key value mechanism could easily cover such scenarios.

Thanks,
Karl

---

From: "James Galvin" <[email-masked]>
Date: Fri, 25 Aug 2017 09:44:17 -0400

The minutes have been uploaded to the proceedings.

If there are any corrections please make that known and I will upload a 
revised version.

Thanks for hosting this meeting!

Jim

On 23 Aug 2017, at 16:52, Roger D Carney wrote:

> Good Afternoon,
>
> We held an interim meeting this morning and discussed the current Fee 
> draft document (draft-ietf-regext-epp-fees-06) and the Validate draft 
> document (draft-ietf-regext-validate-02).
>
> In attendance was Jody Kolker, Antoin Verschuren, Alex Mayrhofer, 
> James Galvin, Dean Farwell, Andreas Huber and Roger Carney.
>
> Agenda:
>
>   1.  Fee
> We started the meeting by confirming that the current revision of the 
> document (v6) addressed all currently known issues.
>
> Jim Galvin mentioned that we may need to resolve TLD phase detection 
> to make it easier for this draft to move forward as detection (at 
> least in simple form) was removed in the last draft. We spent a few 
> minutes on this and recalled some of the reasons given for removal, 
> e.g. complexity and not a true fit for this draft. We discussed the 
> idea of pulling this into the proposed Registry Mapping draft. We also 
> discussed if the authors were opposed to detection being in the Fee 
> draft and I confirmed that I was not completely against including but 
> I do believe the reasons everyone provided for not including makes 
> sense and that it seems more appropriate in the Registry Mapping 
> draft.
>
> We spent a good amount of time, roughly 35 minutes focused on section 
> 3.8 describing Phase/Subphase. Alex mentioned that 3.8 does not 
> clearly address the scenario of a server not supporting 
> phase/subphase. Alex will provide some language and we will work into 
> the next draft. Discussion continued on the "comfort" idea of phase 
> detection: "Should we allow servers to provide responses with multiple 
> phases/subphases in the same response?" We generally agreed that the 
> added complexity and cost associated with this did not outweigh the 
> possible benefits and that we would stay with the v6 language around 
> this (if client does not supply and only one exists return the one and 
> if multiple exist return error).
>
> No one on the call raised any concerns with the "Quiet Period" in 
> section 3.8 paragraph 5. Please review and express any concerns.
>
> The Chairs did indicate that once we get general agreement on the list 
> for the Fee draft we can move this draft to WG last call. At this 
> point I believe we are in a good state with v6 plus the addition of 
> Alex's suggested text on servers that may not have phase support. 
> Please respond to the list if you agree or disagree.
>
> We moved the discussion onto Validate and Jody provided an overview of 
> the problem space and the proposed solution. There was a general 
> agreement that this proposal sounds good and seems like a logical 
> business issue to resolve. There was some discussion on the possible 
> need to be able to refine this "validate" down to the exact domain 
> name. The draft does allow for this though it was not in the original 
> goals. Jim and Antoin talked about this whole "validate" concept 
> possibly being larger and may need to examined in totality (e.g. with 
> allocation token and verification code). Do they belong together or 
> stay separate, should there be a "higher" framework that pulls 
> together the idea of validation/verification?
>

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext