Registration Protocols Extensions (REGEXT) IETF 106, Singapore, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org ***************************************** Wednesday, November 20th, 10:00-12:00, Hullet 1. Welcome and Introductions (10 minutes) i. Jabber scribe: Barry Liebe ii. Notes scribe: Rick Wilhelm iii. NOTE WELL: noted iv. Document management Antoin: - Pls volunteer to review docs and provide comments v. Special attention document shepherds - Document shepherds: Having a doc shepherd at the time of adoption seems like a good idea. Will help keep the doc moving. Barry: - Thanks for taking this up. "Extending document shepherding" available on WG Chairs' Wiki. Good idea to not make it mandatory. Doc shepherd should not "just" write the shepherd write-up. Should help keep it moving. Antoin: - Being a shepherd isn't that hard. Great way to get introduced to the process at IETF. Galvin: - NomCom is here and looking for comments about leadership 2. Existing Document Status (10 minutes) 2.a. RFC Editor queue i. Registry Fee Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ Antoin: - Everything seems to be going well with this I-D 2.b. IESG evaluation i. Login Security Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ ii. Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration (Informational) https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration Antoin: - For Bundling doc, got comments about why this doc is coming forward as an Informational doc. But this one was reviewed and approved by the WG. Galvin: - This doc is with the IESG. Suggestion is to make it Informational and have it come through the Independent stream Barry: - Agreed. The issue isn't that it's Informational. But this being similar to a Proposed Standard. That struck the IESG as odd. It will go smoother if the document goes through the independent stream process. - Login Security is not yet in IESG evaluation. Scott Hollenbeck: - Shared experience from the past, related to the RRP protocol. People didn't want to see it "standardized", but they wanted to see it "documented". Suggested changing the title to help explain why it's informational. Jiankang Yao: - Lots of years of work on this. - It's really for a few registries in China. Many users in China follow this document. I would like to keep it in the WG. Barry: - If you want the doc published, the best way to do it is via the Independent Stream. IESG has made that clear. Antoin: - It's used by multiple registries, but it's not used by _all_ registries. After a BoF, we tried to get the strict bundling documented. Jiankang Yao: - There are many different bundling approaches. This is just one, strict bundling. Other registries that do strict bundling can use it. 2.c. Working Group last call i. Registry Data Escrow Specification https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/ ii. Domain Name Registration Data (DNRD) Objects Mapping https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ Antoin: - This could nearly be out of WGLC. It needs some changes. We put DNRD in a second WGLC. We need responses that the changes were not material so they can be moved on. Jim Gould: Doc shepherd for data-escrow. In review, it has some changes that are editorial. Need the WG to confirm these are editorial. For example: - Used defined terms from another RFC. - Examples need to be changed due to schema validation errors. - XML schema was importing epp-com schema, which created a hard dependency on an EPP RFC. It was used for just one derived type. But the derived type was not used. Therefore, the import and the hard dependency is unnecessary. - Different types of deposits. The ICANN BRDA uses this draft. Therefore, with the document author, we changed the DNRD draft to define the type of the deposit. Also: in changing the schema, there are some concerns about interoperability. So we may need to reach out to a broader set of participants. Jim Galvin: These docs are widely implemented in the ICANN gTLD environment. Given that, there is an important backward-compatibility consideration for current users. Will give more context here in the review by the joint meeting with ICANN CPH TechOps. Barry: From Jabber: Roger Carney confirming that these docs are going to get revised. Galvin: They are going to get new revisions, but will not materially change. Gould: Both docs will get an update. Alex Mayerhofer: Confirming: the docs will be revised? What is the timeline for the revisions so I can make good use of my review time. Galvin: Both docs will get a revision of the version number. As long as the changes are editorial, they won't go through WGLC. Gustavo Lozano: The timeframe for the updates should be just a couple of days. 3. Existing work (20 minutes) i. RDAP partial response/sorting and paging/reverse search (Mario Loffredo) https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Mario Loffredo: (flipped to Mario's slides) First on Partial Response: - Changes implemented after a good review by Tom Harrison. - Reviewed changes since 105 - -03: added unicodeName field - -04: Recommended that RDAP providers include a "self" link Sorting and Paging: - Three versions published since July - -04: replace ldhName with sortingName; need to use unicodeName when sorting. and also clarified sorting logic and sorting policy for multivariate fields. For example letter sorting vs number sorting. Other changes (see slides for details). - -05: Clarified sorting logic on IP addresses. Sort on numeric conversion, not on the string value. Each RDAP provider may have its own sorting properties. (see slides for details) - -06: renamed pageCount to pageSize; added pageNumber property. These might be redundant, but might help implementers make a better interface - For next version: How to implement pagination when "links" can't be used, that is, when submitting a query with a POST, rather than a GET. Possible solution: an optional property named nextCursor. see slides for more Reverse Search - -02: just a doc refresh - -03: Most significant change is the refactoring of the query model. Was made simpler. See slides for detailed syntax. Now have: resource-type, role, and property. See slides. Servers may implement additional properties to those that are defined. New format is simpler than previous one. Alex: - I like the new format for the query. Antoin: - What do you think the current status is? Mario: - Current status depends on implementations. Knows that different people are doing implementations. Mentioned Tom Harrison is doing work on some reverse search. Mentioned some work on paging being done by Google. But the paging mechanism is somewhat different. Mario talking w/ Google team about implementing the I-D's approach. Asked for more info from implementers. Said ready to help any implementers. Tom Harrison: - Sorting and Paging allows customizable mapping of the field. Reverse search is quite specific. The draft might need to be clarified for terminology. Alex: NIC.AT might start looking at this in early 2020. Our implementation work might be a little late for the doc, but we are going to be doing it. Mario: - We might need more time for these documents. Mentioned RDAP implementations now being launch. Said that implementers might look to some of this to help make their implementations more efficient. Antoin: - Does this mean that the timelines might be missed? Should we take one or two of them off the milestone list? Mario: - There might be new implementations coming that would be interested in partial response and sorting and paging. Reverse search might be different. At my registry, we want to do some reverse search. Other registries might not want to. Reverse search is not planned to be open to everyone, due to privacy reasons related to GDPR. We want to provide the capabilities to our registrars to handle lots of questions that come to us. We handle them out-of-band. We'd like to be able to do them via RDAP. Ulrich Wisser: - Last time, we had an extensive discussion about Privacy Considerations. What sort of updates were made? Mario: - Made updates that Reverse search capabilities MUST be provided by national rules or other rules related to personal info. We want to provide this to registrars that are looking at the data that is theirs. The implementation provides protection on a per-user-role basis. - Not sure if we are the only ones who get these kinds of queries: what are the domains related to this technical contact. Ulrich: - The need for reverse search is not in question. More related to the wording in the document. Should describe the problem and give guidance. Saying follow the law is not really helpful. Galvin: - Share the concerns about the privacy consideration. would like to take the topic to the list. Alex: - To solve the milestone problem? Are they any of the three that is more advanced? Mario: - My opinion, Sorting & Paging and Partial Response don't need more updates. They are only waiting for more implementation. Alex: - Would be good to get more implementations. Rick Wilhelm: - Would be good to get more client implementations. Noted the work by Marc Blanchet in RDAP profile and Tom Harrison's work Mario: - Considering a self-configuring client in the future ii. ICANN TMCH functional specifications (Gustavo Lozano) https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/ Gustavo Lorenzo: - First version was relatively stable. No major changes since May 2014. - Intended to be Informational - Has been widely implemented - Was headed toward RFC. Feedback from Patrik Falstrom was received. (See slides for links) The objection was about the matching rules. - This version addresses those. - Would like to have a stable reference for contracts. Galvin (not as chair) - This doc has lots of history and broad deployment - Needed some changes to make it stable - Objection from Patrik; need to see that the objection is resolved. Jim Reid: - Informational RFC or is this going to get push-back? Galvin: - Not expecting pushback from the IESG Barry: - Won't speak for IESG, but it is reasonable for the WG to put out Informational specs 4. Report from the Joint ICANN TechOps / Regext interim meeting (20 minutes) Debate on new milestones. Slide on screen is the list of Milestones (slide 10) Galvin: - In August we had two milestones for data-escrow and dnrd-objects. Suggest that we let those go. - For RDAP, we had Sept, Oct, Nov milestones for partial-response, sorting-paging, and reverse-search. Suggest that we move partial-response and sorting-paging to WGLC so help drive responses. - If we want to hold them back, we could update the milestones. - We need to consider reverse-search separately. We can discuss this on the list. - OpenID doc, we will leave alone. Hollenbeck: - protocol piece hasn't changed much in the last year or so. Confident in the protocol. - Less confident in the status of the IANA consideration section. Lots of dependency on the ICANN EPDP. Could pull out the IANA Considerations and go forward. Or we could hold on and wait. Galvin: - Would like to not change the milestone at this time. Report from Joint ICANN TechOps / REGEXT interim meeting Galvin: (see slides) Presenting not as co-chair - Met jointly with TechOps, a group of registries and registrars. - ICANN is a place to get more of these parties in one meeting. - We met two weeks ago in Montreal. - The "Objectives" slide was presented at the joint meeting. - Goal was to review 14 potential documents and help get info about which should be considered to be adopted. - Meeting was conducted under NOTE WELL. - Mentioned https://bestpractice.domains. Alex: - Internet standards are supposed to be about broad deployment. These do not seem to be standard-worthy. Galvin: - Fair enough. Some of these might be Informational. (Slide 3) - Five areas - Registry Mapping: work that has been moving forward even though it isn't a milestone. Roger Carney has been helping. - Three docs that are likely coming forward; Secure authinfo Transfer: revision that is going to be produced based on feedback received at CPH TechOps; Registry Maintenance Notification and Unhandled Namespaces. - Registry-registrar reporting: discussed a new approach at CPH TechOps and the Dataset File Format. George Michaelson: - Good sense in the direction and pace of the work. - The pace of the meeting is oriented insufficiently toward RDAP. This work is about business-to-business relationships. The RDAP work would benefit from more mindshare. Barry: - There is more coming on RDAP. Galvin: - There are two workstreams: RDAP and EPP. There is more coming on RDAP in New Business. We are concerned about the balance of the work. (switching to new slides, on Registry Reporting) Galvin: - Every registry produces a set of reports that registrars consume. The goal is to create stabiity in those reports. We also want to allow some flexibiity. Just presenting a concept today. Was presented at CPH TechOps meeting. - Next steps would be that this would continue in design effort. - Slide 2: Here are some example reports. There can be some commonality between reports. - Slide 3: Registrar needs to consume these reports. Goal would be to consume them easily. - Slide 4: Create an IANA registry of column headings. Would be a first-come, first-served registry Jim Reid: - Hope that there is info about who asked for the column. Can be difficult to know who is responsible for what in a first-come, first-served IANA registry. - Galvin: -Yes, we are addressing that. We have planned for contact info in the registry - Slide 5: gave examples - Slide 6: gave examples - Slide 7: gave examples; IESG is the registrant, because it would be defined by an RFC - There were 31 fields total, out of the 9 reports Alex: - Do you see what kind of advantage there will be publishing this in the IETF vs just on Bestpractice.domains? Galvin: - This was discussed. That website is not a persistent, archived reference. - ICANN uses the IETF for this purpose. Alex: - The only reason to do this at the IETF is because people will review them. This is rubber-stamping. Galvin: - Not rubber-stamping. This is a technical concept. So I came here to the WG. Galvin: - Slide 11: these items were left as discussion points. - Someone at TechOps brought up the point that the reports might not be produced as Files. An open question is in the distribution mechanism. - What does one do with unexpected columns? - Slide 12: The proposal for Dataset File Format has additional capabilities. This file shows the file name proposal. - Next step would be further discussion Marcos Sanz: - Not opposed to standarizing. But this is the same as escrow and we are standardizing the same thing. Galvin: - These reports are different than escrow. Alex: - Not against standardizing those things. Don't feel that an RFC is the right venue. - There are discussions at CENTR which are related to this - The scope of the IETF is different Antoin: - CPH TechOps is a gTLD-only group. The CENTR group is ccTLD-only. - Things that come from ICANN feel like pressure to do this at IETF for policy. - We don't want to give the impression that we are being run by ICANN. Barry: - From Jabber: another reason to bring this to the IETF. Galvin: - The two groups are specific to each other. That's actually a reason to bring this to IETF. - The idea for the work may have originated from ICANN, but this is a good place to solve it - We should take input from what CENTR has done Antoin: - Are there others that we need to involve? RIRs? ENUM registries? How can we get broad support for standardization. Reid: - This WG is a good place for this Wilhelm: - There was not a full consensus among CPH Techops on these reports - These reports are a business item between registries and registrars that is, they are not part of contracts like EPP and RDAP are. Antoin: - No time for discussion about new milestones. That will take place on the list. 5. New work (20 minutes) i. jCard with JSContact in RDAP and recent changes in JSContact specification (Mario Loffredo) Mario: - JSContact would a more effection contact card than vCard - Latest version is -05 - Currently in DISPATCH Barry: - This will be done in the JMAP working group. Mario: - Provided examples (see slides) - Handle multi-lingual - Brief overview of transition model (from jCard to jsCard) - Described advantages of the transition model that allows servers and clients to transition independently. Antoin: - Will discuss on list ii. Domain Suggestion Extension (Alexander Mayrhofer) https://datatracker.ietf.org/doc/draft-mayrhofer-epp-domain-suggest/ Alex: - About 15 people in the side meeting - Brief summary of what is domain suggestion - Potential protocol options for the capability - Overview of existing work: EPP by Verisign, deprecated and pulled to REST-based interface; RDAP interface by Mario; Alex developed an EPP approach - Side meeting points: registrar is better positioned for this; EPP is not a good protocol choice; RDAP might be a better choice; room had lots of registries - Will be moving toward a REST implementation Barry: - Roger Carney on Jabber: this might be good for smaller registrars, larger registrars have their own. Jim Reid: - Don't think that this is a good idea for standardization 6. AOB Hollenbeck: - Looks like it's time to address the captured errata and move the RDAP RFCs to Internet Standard status. - Propose that we take on this effort - Will volunteer to take on finding doc authors and shepherds Galvin: - We've discussed and this would be good work to take on. - We might need a tweak to the charter. - This and the jCard work fall to the RDAP side of our charter