Subject: [eppext] minutes of meeting, Thursday, 6 March 2014

From: James Galvin <[email-masked]>
Date: Thu, 3 Apr 2014 17:05:33 -0400

First, thank you to Alexander Mayrhofer for taking notes during our
meeting.  He did an excellent job.

He provided his notes immediately after the meeting and I delayed until now
to distribute them to the working group for review.  I did an editorial
review of the minutes, expanding acronyms and creating complete sentences.
If there are any mistakes I take responsibility for that.

I left the format as a recording of the dialogue.  If folks would prefer
this be different please comment on this.

These are due for the proceedings tomorrow, Friday, 4 April.

Folks should read through this, especially if you spoke, and confirm that
you are accurately represented.

This chair takes responsibility for the delay in distributing these.  I
will do better in the future, if we actually have another meeting!

Thanks,

Jim

-------- begin meeting minutes

eppext
======

Jim Galvin, Antoin Verschuuren

Meeting opens at 17:02

Notetakers & Scribes available.

Note Well is shown on the screen

Agenda slide
------------

0. Welcome and charter (Jim/Antoin 10 min.)

1. draft-ietf-eppext-reg (Scott Hollenbeck 30 min.)

2. draft-ietf-eppext-keyrelay (Miek Gieben 10 min.)

3. draft-ietf-eppext-launchphase (Gavin Brown 10 min.)

4. draft-ietf-eppext-tmch-smd (Gustavo Lozano 10 min.)

5. draft-ietf-eppext-idnmap (Francisco/Luis Enrique* 10 min.)
   (*Editors did not submit issues)

6. AOB

eppext-idnmap will be dropped from agenda - none of the presenters are
here and there are no issues at this time.

No further agenda comments.

0. EPPEXT Charter slide
-----------------------

As this is the first meeting of the working group the charter is
displayed as a reminder of the scope of our work and set the stage for
our discussions.

Jim notes that the charter mentions individual internet-drafts rather
than working group drafts.

1. Extension Registry (Scott) 17:08
-----------------------------------

draft-ietf-eppext-reg: Specifies creation registry plus definition of
policy; Based heavily on RFC5226.

Current proposal is "specification required" with "designated expert".

Question for discussion:

 - Is Specification Required ok?

 Pete Resnick: IESG asks "why is first-come-first-served" not possible?

 Alex: FCFS wouldn't gurantee that specification for the extension is
 available.

 Pete: What if i do my private extension, and want an identifier?

 Scott: It's not about the identifier, it's about de-duplication.

 James Gould: If we want to prevent collisions, why do not use "RFC
 required"?

 Pete: Barry will come and ask why do you really need an RFC. Why
 don't register "duplicates" because someone uses them?

 Scott: Correct, document is missing text that describes what the
 designated expert is supposed to do. Experts will probably be a group
 of persons, mailing list will be kept open and serve as the venue.

 Chris Wright: In reference to FCFS, definitely don't want RFC
 required. Fundamentally against the situation where an expert can
 refuse work because there's already work on similar items.

 Frederico Neves: I want a registry where I can look up what's there.

 Antoin: Expert Review means that people with new ideas can be pointed
 to existing solutions.

 Scott: Charter provides rationale why this working group is
 needed. Patrik (Faltström) said he had to implement the same function
 3 times. Expert Review has human interaction built in - could also
 agree that both extensions go in.

 Chris: If they don't what do I do?

 Pete: Appeals go to the IESG. But IESG expects that Experts act
 according to the rules of that RFC. There is something "between",
 which is Expert Review.

 Alex: Yep, Experts Review works well for URI schemes.

 Jim: What if we consider harmonization as a service to the community?
 FCFS is one extreme, other extreme is trying to "merge" similar
 extensions?

 Pete: Policy can be very creative (eg. column with "level of
 acceptance" in the registry).

 Chris: "Standardizing" of existing work will be massive effort for
 both registries and registrars.

 Scott: We are *registering* not *standardizing*.

 Chris: RFC5226 says for expert review the expert could deny entry
 because of duplication - that is what I'm objecting to.

 Scott: Instruction to Expert can be very creative.

 Gavin Brown: IPR considerations: "specification required" could imply
 IPR-laden documents - registry could then implement it, and registrar
 could be forced to violate IPR - can we add into the specification
 that IPR needs to be disclosed?

 Pete: Even RFCs can have IPR against that - we ask people to disclose
 it, but it exists no matter whether or not people disclose it.

 James Gould: We would need some "outreach" to get people to document.

 Scott: Try to find what's out there, and try harmonization on new work.

 Jim: My assessment of the group is that we're not leaning towards
 "harmonization". We're closer to FCFS with refusal for "document
 completeness" only.

 Chris: A checkbox of "documentation is complete" should be good
 enough.

 Sense of the Room: Hum if you agree:

 We want a registry. We want complete technical specifications.

 Group strongly in favor, noone against.

 Pete: "Legacy" extensions: Do they need specifications, or can they
 be marked with "does not exist, but well known"?

 Scott: At least they're written in XML Schema. So a technical
 specification might not be avilable, but some form of documentation
 exists.

 Antoin: What about taking things out of the registry, eg. when the
 registry migrates to another solution?

 Jim: Since we're running short of time let's discuss on the list:
 What has to be in the checkbox to make the spec pass.

 Scott: Does "specification" means an RFC5226 policy, or something else?

2. EPP Keyrelay
---------------

Goal: When domain names are transferred, transfer the ZSK from old to
new registrar (draft by Peter Koch).  Problem is the communication
path between registrars does not exist.

"keyrelay" uses the registry as a 3rd-party trusted channel to
communicate. We are doing transfers successfully using this under .NL.

We are not aware of any outstanding issues. We want to go to WGLC.

Scott: I just want to note that the documents are not really a "-00"
document; they are pretty mature.

Gavin Brown: Security consideration: what is being transported?

Answer: Just the public key.

Dan York: Fully in support, that's exactly what the registry is
supposed to do.

Chris: How many registrars?

Antoin: 4.

Pete: This is an unusual working group, because the document is not
fully reviewed in-working-group, and rather here for "registration
mechanics". PROTO review will need to reflect this properly.

James Mitchell: Standardization does not necessarily foster
interopability, eg. the requirement for authinfo in this extension
allows for variety.

Pete: Having "implementation status" helps to show community support -
could be part of shepherding information.

Chris: Even core EPP allows for so many choices that harmonization is
even hard for the EPP core. Different problem, but do we want to
address this?

James Cole (?): Curious why this is a protocol rather than a object
extension?

James Gould: I had an identical question. This feels like it's tied to
the domain, why not a "domain update"?

Antoin: Idea was to extend it beyond keyrelay (but said no in the
draft itself).

Jay: Why not call it "relay" instead of "key relay"? How specific or
how generic is it?

Miek: We wanted to fix that specific problem, not the generic problem.

Dan: Could we list registrars that support this (in spite of the
marketing issue)?

Pete: RFC6982 describes an implementation report that goes into the
document itself.

Patrik Wallström: Charter Question: We have a limited number of
extensions - I might have another one - do we have to update the
charter?

Jim: Yes, we would have to negotiate with ADs and recharter. However
depending on the registry policy that might not be necessary - the
working group could go away and new extensions could still be
registered.

Pete: I just need to say that "groups with EXT in name" tend to live
forever; that's why the charter was defined the way it is.

James Gould: Why not specify times in seconds, and other periods
differently?

Jim (Chair): We have a few issues to discuss on list, not yet at WGLC,
but close.

3. Launch Phase Document
------------------------

Gavin Brown

Developed by Cloud Registry, later implemented by CentralNIC, process
began in 2011 to standardaze it, 15 revisions so far.

Contains Sunrise, Trademark Claims Period, and Landrush - implements
registry-registrar functions.

Has two dependencies on SMD document, another is the TMCH functional
specification - functional specification is just an informational
reference.

Outstanding issues:

- Async ACK Verification model - not supported at the moment. Shall we do
that?

Alex: Keep that out of the draft, it's already complicated enough and
looks logical: Verification at time when domain create comes in.

James: If somebody wants to do that, would they need to create a duplicate?

Gavin: No, they would need to describe their one transaction.

Chris: We used completely different extensions, not this. We could
have lots to say about this, but we don't use it. Whether or not we
say something depends on outcome of the first document (duplicate
issue).

Gavin: Might be the case that once.

James Gould: It could be done outside of EPP.

Gavin: Yes.

Multiple Status issue: Text says that multiple statuses are possible

Alex: Flowchart does not allow multiple statuses, text should be
corrected.  Also, subphase definition conflicts.

James Gould: Can be used to define a subphase or a new phase.

Jim (Chair): We will decide about progress with this document once we
decide about the first document. Let's take comments on the list.

Implementations: Neustar uses this.

4. SMD document
---------------

Gustavo Lozano

SMD: It's blob of XML plus a signature showing that a trademark
validator has validated a mark.

Shows a slide of the "TMCH ecosystem".

Gavin: Why is there an "unbounded" number of contacts?

Gustavo: The maximum you will see is currently *2*.

Gavin: Type Trademark?

James Gould: Any updates for qualified launch program?

Gustavo: Will be updates, but it's premature.

Chris: It's an XML schema, but not an EPP extension? Would that go
into the registry?

Scott: If it was normatively referenced in the extension it uses, it
would be in.

6. AOB
------

Gavin Brown: Extensions have URNs, but version is always 1.0 - please
do version number your namespace - this would allow for inclusion of
the version in the greeting.

Jim: Include that into the registry specification? Scott nods.

James Gould: Bumping the namespace would create implementation issues.

Chris: Publishing a new version of a draft might not necessarily need
to bump the version number.  It only needs to be done when there are
incompatible changes.

Jim: I agree - a non-backwards-compatible change would bump the
version number.

Meeting concludes.