Registration Protocols Extensions (REGEXT) IETF 103, Bankok, Thailand, Agenda Co-chairs: Jim Galvin, Antoin Verschuren Mailinglist: regext@ietf.org ***************************************** Tuesday, November 6th, 13:50-15:50, Boromphimarn 4 Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-regext-00 1. Welcome and Introductions (4 minutes) Chair slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-chair-slides-00 Meeting opened on time by co-chair Jim Galvin. Co-chair Antoin Verschuren participating remotely. i. Jabber scribe Paul Wouters ii. Notes scribe Richard Wilhelm iii. NOTE WELL Reviewed by Galvin as per usual. Also passed Blue Sheets. iv. Charter update (2 min.) -Galvin reviewed the slide in the Chair's deck on the charter content -Recent change: WG may also take on work to develop specs that describe various types of info exchanged between entities involved in Internet identifier registration that are using the RDAP or EPP protocols -Galvin described discussions/negotiations with IESG on the charter scoping v. Document management Galvin reminded people to help out with document reviews in other areas 2. Existing Document Status 2.a. RFC Editor queue (2 minutes) i. Registration Data Access Protocol (RDAP) Object Tagging https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ ii. Allocation Token Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ -Galvin asked if anyone had comments on these. None offered. 2.b. IESG Evaluation (4 minutes) i. Change Poll Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ ii. Extensible Provisioning Protocol (EPP) Organization Mapping https://datatracker.ietf.org/doc/draft-ietf-regext-org/ Organization Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ iii.Registry Fee Extension for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ -Galvin gave brief updates on the three docs in IESG eval phase. -All docs are generally moving -Galvin noted that these docs don't appear on the WG milestone list -Jim Gould brought up a topic recently brought up a recent list topic related to the xml namespace on change-poll. (It's been suggested that this be changed to be scoped.) -Galvin said that going forward, we should be careful about these namespaces 2.c. Past WG last call: Waiting for shepherd writeup (3 minutes) i. Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration -Galvin noted that there is a draft version of the shepherd writeup for this doc. Expected to be revised before submission. 3. HRPC Human Rights Review of draft-ietf-regext-verificationcode (15 min) -Galvin commented that there has been list discussion on human rights reviews of drafts. Galvin said that AD has said that human rights reviews are individual contributions and that they don't have special status coming from hrpc. Should be treated as any other contributions. -Gould: reviewed feedback received; identified normative language that required the VSP to store the data that was verified, which was removed. Was changed to make clear that the verification code extension is a pointer to verification and that relevant laws and regulations should be -Gurshabad Grover: Disagreed that it was not the only item; there are some pending issues. First one is: what is the intended document status? Depends on the number of use cases. If limited, has the option of documenting separately (see RFC 3735). -Gould: this is generic and broadly applicable. Most recent update has other usage information -Scott Hollenbeck: Extension describes that they may be documented in various ways, but nothing is a mandate. And there is nothing about broad applicability I've seen nothing to suggest deviation from that path -Gurshabad: Depends on the amount of extension and the amount of general interest. -Galvin: Asked what are the additional technical concerns -Gurshabad: There is a grace period: Draft does not define the behavior if the verification service provider does not respond -Gould: the grace period is not associated with the VSP... it's associated with the registry policy. -Galvin: Does it say that the action is based on server policy? -Gould: We can double-check -Gurshabad: The integrity of the object when it goes to the VSP. when the VSP sends the verification code back, the VSP should not alter the object -after some discussion... will bring it to the list -Gurshabad: The effects should be considered; perhaps add a human rights area consideration to the document -Galvin: We've handled the discussion of technical issues; regarding the human rights item; -Gurshabad: disagreed with the conclusion around human rights considerations -Niels ten Oever: Discussion has been going for a while; happy that we're engaging in the process; think that proposed standard goes a bit far; -Hollenbeck: Comparing this to security considerations; we have docs representing IETF consensus around security considerations and IANA considerations. We have no such document around capturing human rights considerations. I don't know that this doc should be taking place in this WG. Should be taken up. -Ulrich Visser: It's not that much to document it. I don't see why we wouldn't do it. -Galvin: Fair point, we should discuss on the list. Should handle all the technical items first. -ten Oever: After a doc is adopted by a WG, the right of change is handled by the WG, not the author. The implications of technology are not policy. RFC 8280 has discussion on the writing of human rights considerations -Gould: I've read 8280, I'm unqualified to incorporate 8280 as an input I don't want this doc to be a guinea pig -Galvin: it's up to this WG as a group to add any additional human rights considerations as a group. -Alex Mayrhofer: Agreed that the doc is improved by the changes; and as an author, it's hard to add another section. -Galvin: We need to separate out the broader discussion about adopting human rights considerations 4. New candidate documents for adopting: (Max 9 min per item) i. Registration Data Access Protocol (RDAP) Reverse search capabilities (Mario Loffredo) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ ii. Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (Mario Loffredo) https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-loffredo-rdap-reverse-search-and-rdap-sorting-and-paging-00 -Mario Loffredo did the presentation. -Presentation covered both papers -first discussed sorting and paging -And then onto reverse search -Intermittent was some back-and-forth about whether or not reverse search was permitted by GDPR -Wilhelm: commented that the next-gen RDS PDP has been closed down. And also that it is very early in RDAP implementations and these things have implementation burden for contracted parties -Loffredo described an implementation approach that's used in dotIT; a controlled approach to reverse search -Eduardo Alverez (ICANN): Would be good for this to have this start moving. Should seen as how this might build upon current whois capabilities -Galvin: there are lots of discussions going on about RDAP rollout. Want to be careful that we don't motivate work solely by what is needed by ICANN. This is a carry-over from original RDAP specification. Given that this is early days, we will have an opportunity to influence in both directions. -Loffredo: We are focused on requirements of ccTLDs iii.Login Security Extension for the Extensible Provisioning Protocol (EPP) (James Gould) https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-gould-login-security-00 Galvin noted that the URL referenced in the agenda should actually be: https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/ -Gould: the login-security extension allows for longer passwords -Gould went through the slides, largely self-explanatory -Galvin: Asked about a dependency on registry mapping -Gould: there is one. Not asking for the doc to be added to the WG at this time waiting to get an IPR declaration handled for registry mapping (no comments or questions at the mic) iv. Extensible Provisioning Protocol (EPP) Unhandled Namespaces (James Gould) https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-gould-unhandled-namespaces-00 -Gould went through the slides -Mayrhofer asked a question about the location of the unhandled xml, which Gould answered -Related that the key item is that it addresses that poll messages will not be "poison" under this approach. -Visser: My understanding was that this was "not a problem"; -Gould: This is an example of how it could be handled -Galvin: I would offer that the poll message was an important item -Visser: As a registry, we have two kinds of registrars: those that poll and those that don't. We've done non-backward-compatible changes and had no problems. -Gould: We didn't have a good answer -Visser: This is a technical solution to a policy problem. We have contracts that require registrars to understand EPP. -Galvin: We have similar kinds of registrars; as a general registry service provider, you get a lot of mixing and matching. Taking on the opportunity to be well-behaved -Loffredo: How to parse the XML inside the extvalue? But if you have a parser that builds from the namespaces, the client should know -Gould: Since it's put under the "value" it won't parse it. And haven't lost it v. Registry Reporting Repository (Who??) https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/ -Galvin: has been borne out of the ICANN technical operations group. So registrars can get access to reports. -Gould: Perhaps an approach that defines an approach for a report definition as opposed to defining the exact reports -Mayrhofer: I don't find this as work in our charter -Wilhelm: Concerned that this document is focused on SFTP -Roger Carney: Understanding these points, but the challenge is interoperability and where should that happen. Maybe a definition is a good approach. vi. Registry Mapping for the Extensible Provisioning Protocol (EPP) (Roger Carney https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/ -Carney (no slides) -This is ongoing work; need to finalize an IPR issue before we bring it into the group -Galvin: there have been interim meetings for the design team working on this 5. WG Adoption discussion and Milestone review. (10 min) -Galvin reviewed open milestones (see chair slides) -How many open docs should regext have? Is 5 the right number? -Questions about the two open docs? Should we keep them? Should we discard them? -We will discuss this on the mailing list -Hollenbeck: some concerns about a fixed number, things will come up (gave an example of possible policy things at ICANN) -Carney: similar, but not quite the same... the number is a good goal, but not all docs are going to be created the same. We might need to go to four to get some better action. -Kal Feher: comment from Antoine: why does your standard depend on ICANN? -Hollenbeck: It's more of a matter of efficiency -Gould: Different drafts require different work -Carney: Encourage Scott to push the draft forward (on federated identity) -Galvin: Understand the need for an exception process; expect that the AD would be open to that. However, it feels like something is going to get swapped out if something is going to get swapped in. Then our AD is going to want us to be careful about unloading things. Agree with Roger about putting forth that identity document. Four with a slot for an extra one seems better than five with a slot for an extra one. Actions: 1. Restart the questions to the WG 2. Reach out on the list to the DNS operator folks the milestone document 3. Create a consolidated list of docs for 4. Conduct a pollling -Adam: liked the 'goal and the limit' 6. AOB -Hollenbeck: Registry Operations Workshop, here in Bangkok, in May at the ICANN GDD Summit, encouraged participation and presentations. -Final call for blue sheet signing Adjourned on time. *****************************************