eppext ====== Chairs: Jim Galvin, Antoin Verschuren Scribe: Alexander Mayrhofer Jabber: Jelte Jansen Meeting opens at 17:02 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.