Subject: [eppext] Draft Agenda for IETF London

From: James Galvin <[email-masked]>
Date: Fri, 14 Feb 2014 14:17:10 -0500

WG Chairs here:

The deadline for submitting our agenda for the next IETF meeting is Monday,
17 February.  Antoin did ask for suggested agenda items several weeks ago.
No one asked for anything specific so we'd like to propose the following
agenda.

First, if you haven't noticed, we got the 5pm-6:30pm slot on Thursday
evening for our meeting.

We believe our primary document is draft-ietf-eppext-reg, which is being
edited by Scott.  We would like to focus most of our discussion on that
document, and also ask that Scott include his question about "designated
expert" he posted to the list recently.

We'll then give a smaller but equal amount of time to each of the other
documents.

The most important goal of these discussions is either to identify
questions that we need to bring to the list to resolve or to decide the
document is ready to publish.  Of course, we can and should start this
process now since we don't have to wait for the meeting to speak up.

If there is time left we could allow ourselves a discussion of Patrik
Walstrom's document to see if there's interest for it being an important
topic/document for our group to discuss.

With that, we believe our agenda looks like this.

- Welcome and charter (Jim/Antoin 10 min.)
- draft-ietf-eppext-reg (Scott 30 min.)
- draft-ietf-eppext-keyrelay (Miek 10 min.)
- draft-ietf-eppext-launchphase (James/Wil/Gavin 10 min.)
- draft-ietf-eppext-tmch-smd (Gutavo 10 min.)
- draft-ietf-eppext-idnmap (Francisco/Luis Enrique 10 min.)
- AOB

Any questions, comments, or other suggestions for the agenda?

Thanks!

Jim and Antoin

---

From: Pete Resnick <[email-masked]>
Date: Mon, 24 Feb 2014 15:33:10 -0600

> Any questions, comments, or other suggestions for the agenda?

Folks,

Sorry for piping up late. Just a quick comment on this:

10 minutes per draft is a *very* short amount of time to discuss 
anything, and near impossible if you attempt to do anything that looks 
like a "presentation". I would strongly suggest that the document 
editors or chairs post an issues list for each of the documents to the 
mailing list (possibly with an explanation of the issues if it's not 
clear), and then in the room just have a single slide per document with 
the list of issues. That will leave all of the time for discussion, not 
wasting it with the editors explaining what the issues are.

I'd suggest posting those messages to the list *this week*, or drop the 
document from the agenda. No need to be spending time in the room trying 
to bring everybody up to speed. There's simply not enough time to do that.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: James Galvin <[email-masked]>
Date: Tue, 25 Feb 2014 09:56:38 -0800

Pete,

Thanks for emphasizing this point.

The chairs have separately requested all the document authors to prepare a
single slide with the questions to be reviewed.  They should presume that
their document has been read.

What we did not do was suggest that the list of questions will be collected
and distributed to the list in advance.  Thanks for this and we will
certainly do it.

Document authors, consider yourself so tasked.  Please send your notes to
the list, by COB everywhere Friday, 28 February.  The chairs will collect
these and create an appropriate slide deck for the working group meeting.

Thanks,

Jim

On Mon, Feb 24, 2014 at 1:33 PM, Pete Resnick <[email-masked]>wrote:

> 10 minutes per draft is a *very* short amount of time to discuss anything,
> and near impossible if you attempt to do anything that looks like a
> "presentation". I would strongly suggest that the document editors or
> chairs post an issues list for each of the documents to the mailing list
> (possibly with an explanation of the issues if it's not clear), and then in
> the room just have a single slide per document with the list of issues.
> That will leave all of the time for discussion, not wasting it with the
> editors explaining what the issues are.
>
> document from the agenda. No need to be spending time in the room trying to
> bring everybody up to speed. There's simply not enough time to do that.
>
> pr
>
> --

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Feb 2014 16:01:22 +0000

Pete,

I¹m not going to be at the meeting in person, but I¹ll participate
remotely.  Gavin Brown will present the open issue(s) with
draft-ietf-eppext-launchphase at the meeting.  Below I provide my
implementation status / experience with both draft-ietf-eppext-launchphase
and draft-ietf-eppext-tmch-smd.

Jim Gould has been a co-author of draft-ietf-eppext-launchphase for the
past year and a half and has provided input into
draft-ietf-eppext-tmch-smd since its inception.  He has developed an
implementation that includes full support for all of the features of both
drafts on the client side and the server side in the open source Launch
EPP SDK and the Verisign EPP SDK
(http://www.verisigninc.com/en_US/channel-resources/domain-registry-product
s/epp-sdks/index.xhtml?loc=en_US).  Client-side support is provided by an
API as well as a set of client tests.  Server-side support is provided by
a server framework and a set of stubbed out logic to support the client¹s
tests in an included stub server.    Verisign has two independently-built
servers that implement both drafts in two Operational Test and Evaluation
(OT&E) environments, where one supports just launch registrations and the
second supports both launch registrations and launch applications on a per
TLD basis.  The experience gained in implementing the SDKs and the servers
has been incorporated into the drafts.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 2/24/14, 4:33 PM, "Pete Resnick" <[email-masked]> wrote:

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Feb 2014 21:32:58 +0000

Pete,

We are aware of only one open issue with draft-ietf-eppext-launchphase based on an open item with the referenced draft-lozano-tmch-func-spec that has been discussed but not concluded on the ICANN tmch-tech mailing list ( see http://mm.icann.org/pipermail/tmch-tech/2014-February/001000.html ).    The requirements in draft-lozano-tmch-func-spec helps drive the protocol requirements of draft-ietf-eppext-launchphase.  Currently draft-ietf-eppext-launchphase fully supports the Trademark Claims Period flow defined in section 5.3.1 and the supporting language of section 5.3.2 of draft-lozano-tmch-func-spec.  Interpretation of the language of the fourth paragraph of section 5.3.2 of draft-lozano-tmch-func-spec provides support for a yet to be defined model that has been referred to as the "asynchronous acknowledgement verification model”.  There are three options for
draft-lozano-tmch-func-spec, where the third option most likely will have impacts on draft-ietf-eppext-launchphase.

  1.  Tighten the language in the fourth paragraph of section 5.3.2 of draft-lozano-tmch-func-spec to only support the Trademark Claims Period flow defined in section 5.3.1 of draft-lozano-tmch-func-spec.  The update would be changing "the minimum set of checks MAY be performed when creating the intermediate object…” to "the minimum set of checks MUST be performed when creating the intermediate object…”.  No change would be required in draft-ietf-eppext-launchphase.
  2.  Leave both draft-lozano-tmch-func-spec and draft-ietf-eppext-launchphase as is and leave it up to the servers to define the flow and protocol for supporting an "asynchronous acknowledgement verification model”.
  3.  Updated  draft-lozano-tmch-func-spec to explicitly define the "asynchronous acknowledgement verification model”.  A new Trademark Claims Period flow would be added similar to Figure 7 in section 5.3.1 of draft-lozano-tmch-func-spec along with supporting text.  The new flow most likely will require updates to draft-ietf-eppext-launchphase.  Changes discussed on the list include:
     *   A flag in the domain create response indicating the asynchronous acknowledgement verification model is supported and that the submission of the claims acknowledgement may be required.
     *   Add a new State (e.g. pendingAcknowledgement) in draft-ietf-eppext-launchphase with an associated poll message.  The claimKey could be included in the poll message to forgo the need for the client to submit the claims check after receiving the poll message.  An action date (acDate) element may be required to define the date and time that a claims acknowledgement must be received.  If the claims acknowledgement is not received by the action date, the application will be auto-rejected.
     *   Extend the domain update command to allow for the passing of the claims acknowledgement (<launch:notice>) that if received by the action date will transition the application to the allocated state.

The draft-ietf-eppext-launchphase authors recommendation is option 1.  One Registry Operator posted on the tmch-tech list that they intend to support some form of "asynchronous acknowledgement verification model”, but no detail was provided on how they intend to support it and no requests were made to update draft-ietf-eppext-launchphase.  Option 2 will encourage new custom EPP extensions and flows that are impactful to the clients.  Option 3 will require formal discussion of the "asynchronous acknowledgement verification model”, will require changes to both draft-lozano-tmch-func-spec and draft-ietf-eppext-launchphase, and still might not match custom implementations that have been created based on the existing language in section 5.3.2 of draft-lozano-tmch-func-spec.

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 2/24/14, 4:33 PM, "Pete Resnick" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

pr

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext