Re: [regext] REGEXT Interim Meeting

[Roger D Carney <[e-mail]>]

Hi James,

After rereading the <check> commands in RFC 5730 and 5731, I do agree with you that it appears the RFCs intended (Scott Hollenbeck may provide clarity) the <check> command to return “avail=0” during a “quiet period” even though “quiet period” was not mentioned specifically or defined in these RFCs. I just want to recognize in practice today this is not always the case, some registries return “avail=1” on <check> commands processed during quiet periods if the name has not been registered.

So in reference to the Fee draft I am recommending that paragraph 5 of section 3.8 be changed from:

“If the client <fee:command> contains no phase/subphase attributes and the server is currently in a "quiet period" (e.g. not accepting registrations or applications) the server MUST return data consistent with the general availability phase.”

to

“If the client <fee:command> contains no phase/subphase attributes and the server is currently in a "quiet period" (e.g. not accepting registrations or applications) the server MUST return data consistent with RFCs 5730 and 5731 and MUST include a <fee:reason> in the response extension.”

Should we force a specific reason (e.g. <fee:reason>Quiet period, please provide appropriate phase details for fee information.</fee:reason>)?

Does anyone else have thoughts on this rewording?


Thanks
Roger


From: Gould, James [mailto:[e-mail]]
Sent: Friday, August 25, 2017 12:22 PM
To: Roger D Carney <[e-mail]>; [e-mail]
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

It’s not clear what the “quiet period” is.  Is it really part of the open phase, is it a sub-phase, or is it a gap between phases?  Without a clear definition of what a “quiet period” is, I believe it is difficult to define the expected behavior for it in the registry fee extension.  My recommendation is to define the registry fee draft to cover one or more active phases, where a TLD should always be in at least one defined phase (“sunrise”, “landrush”, “claims”, “open”, or “custom”), where a “quiet period” may be a custom phase that does not require special handling in the registry fee extension.  The registrars are not required to implement draft-ietf-regext-launchphase, but should be aware of the possible set of phases the TLD operates in when determining the target fee.  If the registrar is unaware of the phases, then the server will respond based on the current active phase(s) according to what is defined in the registry fee extension (e.g., fee of the current phase if there is just one or an error if there is more than one phase).


—

JG

[id:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Roger Carney <[e-mail]<mailto:[e-mail]>>
Date: Friday, August 25, 2017 at 12:33 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Hi James,

So you are suggesting the “quiet period” is a distinct phase. As I was suggesting the “quiet period” is the “open” phase, I don’t think that is an exception to the rule, just defining “quiet period.”

If we write it into the document, there is no assuming/forecasting of client desire.

I do want to sort of retract my presumption from my previous email to the list. There are registrars that did not implement draft-ietf-regext-launchphase, but the link to fee is really not appropriate.


Thanks
Roger


From: Gould, James [mailto:[e-mail]]
Sent: Thursday, August 24, 2017 2:43 PM
To: Roger D Carney <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client when the current phase is a quiet period by defaulting the return to the “open” / general registration phase.  When there is an active phase the behavior is to return the fee for the active phase by default.  If you consider the quiet period a phase (null or explicitly the custom “quiet” period) then why would you make an exception to that rule?  A client submitting pre-registration availability checks needs to be aware of what they’re looking for (fee during “sunrise”, fee during “claims”, fee during “open”), and the protocol should not attempt to forecast the clients desire.


—

JG

[cid:[e-mail]40FA10]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Roger Carney <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but I have one “compatibility/legacy” concern. There are registrars that do not participate in “launches/phases”, for various reasons I am sure. Some of these registrars most likely never implemented draft-ietf-regext-launchphase, which would mean any “pre-registration” availability checks from these registrars would return unavailable. I don’t think that we would want to exclude these potential registrations.


Thanks
Roger


From: Gould, James [mailto:[e-mail]]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate in the meeting.  I include some points below based on review of draft-ietf-regext-epp-fees-06 and the minutes:

1.       I agree that we shouldn’t mix launch phase detection into the fee extension, and this is best suited for a draft specifically designed for policy and feature detection like the Registry Mapping.
2.       The “quiet period” is not formally defined, but if it were I would define as a period when there is no active launch phase (null launch phase) or when there is a launch phase that does not accept any registrations or applications (custom “quiet” launch phase).  In either case, I believe that if the phase / sub-phase is not supplied by the client that the fee should be returned in context to the current launch phase.  If no registrations or applications are allowed during the current launch phase (null or custom “quiet” launch phase) then the fee should come back as unavailable.  Returning the fee as if the active phase is the “open” phase (general availability) does not seem to match the default behavior of returning the fee according to the current active phase.  The client can pass the “open” phase explicitly if they needed to determine the fee for that future phase.
3.       The Validate extension meets a similar purpose as the policy and feature detection of the Registry Mapping, where the Registry Mapping provides TLD level service, policy, and feature information that enables the client to automate their configuration.  The Validate extension implements a pre-check of the contact policy using real data.  One option for the Validate extension that we discussed in the past is providing a pre-check extension (e.g., no-op) to the domain mapping or the contact mapping, but the issue with the pre-check (e.g., no-op) extension is that a registrar may need to create a set of objects (contacts, hosts, and domains) that are validated against the server policy at the time of the domain create.  The Registry Mapping provides meta-data to drive client policy discovery and configuration and the Validate extension provides a pre-check or test of contact policy using real contact data.  I view the Allocation Token and Verification Code extensions serving a completely different purpose of authorizing the allocation of a domain name via an allocation token and enabling the client to provide proof of one or more forms of verification in meeting one or more verification profiles, respectively.  In summary, I would group the Validate extension and the Registry Mapping in one bucket of discovering the verifying policy, and the Allocation Token and the Verification Code extensions in another bucket of providing tokens or codes to apply different policies (allocation and verification).

—

JG

[cid:[e-mail]40FA10]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Roger Carney <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, August 23, 2017 at 4:52 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting

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
a.       Confirm Edits (scheme, section 3.8 and reference)
b.       Discuss “Quiet Period”: section 3.8 paragraph 5
c.       Discuss WG Last Call
2.       Validate
a.       Re-introduce
b.       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