Registration Protocols Extensions (REGEXT)
IETF 109 online


BKK time zone, but without the Pad Ka Prao Gai :/


~45 participants.


Co-chairs: Jim Galvin, Antoin Verschuren
Mailing list: regext@ietf.org


Wednesday, November 18, 2020 05:00-07:00 UTC, Meetecho


Chair slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-regext-chair-slides-v01-00




1. Welcome and Introductions (4 minutes)
i. Jabber scribe -> Meetecho will be used
ii. Notes scribe -> Alex Mayerhofer
iii. NOTE WELL
iv. Document management -> thanks to the document shepherd, please provide a shepherd early on (once doc is adopted by WG)
v. Special attention document shepherds


2. Published (1 minute)
One document published:


Login Security Extension for the Extensible Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/rfc8807/


3. Status of existing work in Progress (RFC Editor, IESG, AD evaluation) (5 minutes)
  Registry Data Escrow Specification (AUTH48/RFC8909)
  https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
  
  -> Barry Leiba: published on Friday! 


  Domain Name Registration Data (DNRD) Objects Mapping (DISCUSS)
  https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/
-> In the process to resolve the DISCUSS


  ICANN TMCH functional specifications (Move to Independent stream, AD follow-up)
  https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/
-> Will be off the REGEXT agenda, not a milestone anymore. WG has done its word.


  Registration Data Access Protocol (RDAP) Partial Response (IESG Evaluation)
  https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
->


  RDAP Query Parameters for Result Sorting and Paging (IESG evaluation)
  https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
-> went together with partial response


Barry: Both have no DISCUSSes on, waiting for review of the shepherd writeup, whether they are ready, will give them a final check once notified. Please notify me about the status, what action is expected.


  7482bis and 7483bis (Waiting for IESG submission by chairs)
  https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
  https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/
-> Waiting for Antoin, doc shepherd have done their writeup. Will be submitted this or beginning next week.


  EPP Secure Authorization Information for Transfer (Waiting for shepherd writeup)
  https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/


  EPP Unhandled Namespaces (Waiting for shepherd writeup)
  https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/
-> Antoin, question: Had to extend the WGLC for 3 of the 4 last documents - is our WGLC window too short?


Jim Gould: 3 weeks would be better. on unhandled namespaces: added implementation consideration section, please check that update.


Antoin: Maybe we call WGLC too early, please review documents!


4. Existing work past WGLC. (5 minutes)


i. Registry Maintenance Notifications for EPP (Sattler/Carney/Kolker?)
  https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
-> Jim: Small group, document went back to the WG from WGLC. We need to finish that discussion (Jody <-> Jim G. discussion was unresolved) - WG, please review that thread!


Jim G: Apologies for late feedback, did deep dive once WGLC was called. Encourages others to do their deep dive as well.


Rick Wilhelm: Had separate conversations (from business side). Contractual need for these notifications. Unclear if/when this is satisfying the business requirements.


Jim channeling Antoin: Keep policy considerations separate from tech considerations - need to be careful. should examine whether that’s an issue here.


5. Existing work presentations. (20 minutes)


i. RDAP Reverse search capabilities (Mario Loffredo, 10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/


Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-regext-loffredo-rdap-reverse-search-00


Major point of Mario: EU directive might require direct access to data


Jim Galvin: Encourages participants to join the discussion here - lots of work in ICANN side


Scott Hollenbeck: Not a fan of reverse search (privacy!), notes connection to AAA functionality (OAuth document)


Alex: Working on an RDAP prototype, using plain JWTs now. We need scalable AAA infrastructure for that.


Ulrich Wisser: Mario has done a privacy section, how do we know if that’s a “good one”.


Antoin: HRPG opposed this document in the first place. Their work was about not publishing that document at all, could ask them to review the privacy section.


Barry: there was an IAB document a few years ago. If issues were documented and raised, IESG would “not bark”.


Alex Mayrhofer: no need to say “follow the law”, but there should be a MUST consider implications for implementors.


Ulrich Wisser: We should point our where exactly the privacy problems are! Follow the law is not enough.


ii. Simple Registration Reporting (Joseph Yee, James Galvin, 10 minutes)
  https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/
Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-regext-yee-galvin-simple-registry-registrar-reporting-00


Jim Gould: Likes to see less reports in the draft, draft should focus on the format. Actual reports will make it complicated to get consensus on.


Jim: Splitting that into two documents seems fine to me, calls out to WG if there are any objections. Framework could be Standards Track?


Alex: empty columns: CSV format problem, let’s use no string. We can do more explicit values in eg. JSON. Splitting is good, if registry policy is “spec required” then even other venues can create report and register definitions (eg. ICANN).


Jim Gould: Splitting makes a lot of sense. Creating drafts for specific reports might not be required anymore then.


Jim Galvin: Registry policy is “specification required”


Barry: right way to go.


Joseph: Might require “Experts” for the reports, like we have for EPP extensions at the moment.


Zidago: there’s a use case in AfriNIC region, is there a contact at AfriNIC in charge for this?


Antoin: Please join discussion on the mailing list. Jim will put a link to mailing list into the chat.


Joseph describes the list of fields


Jim gould: Data Escrow draft could be a good point for data points


Jim Galvin: Decided to choose only fields that ar e in existing reports.


Joseph: picked a cautious approach, eg authinfo could be security-relevant if defined as field.


6. New work and requests for adoption (50 minutes)


i. UnRenew extension for EPP (Jody Kolker, 20 minutes)
(no slides)


Way to “undo” an explicit renew, without deleting the domain. Currently, refund is only possible by deleting domain.


It makes sense on auto-renew (customer has 45 days grace period). For an explicit renew (can be sent anytime) the only way is deletion (which makes them lose the remaining “current” lifecycle period)


Proposal: “unrenew” extension to the “renew” command, and that would only be possible in the renew grace period. Would not apply to auto-renewals.


Sees it as a “queue”, eg. 5 renewals for 1y would require 5 unrenewals to “roll up”.


unrenew should never unroll renewal periods that have already started.


Jim: Is unrenew an EPP issue, or a business logic issue?


Jody: we see thousands of those per month.


Gavin Brown: there is prior art, nominet has an unrenew command (that precedes EPP). Experience is quite similar at centralnic. Published a draft called “reverse” extension about 5 years ago - main use case was reverse a renewal, but was more general in design, via clTRID. 2015 draft might be a good basis. Link went into chat.


Jody: Will take a look, we have a draft draft


Jim: Pointer to unrenew nominet


Alex: can a multi-year renew be “split” into smaller un-renews? would make it very complicated


Jody: Discussed this, can only “unroll” the full renew command in reverse order.


Rick: Will have to go through a lot of ICANN policy work to get traction.


ii. Using JSContact in RDAP JSON Responses (Gavin Brown, 10 minutes)
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/


(TODO: add slides)


Gavin Brown: Was discussed in the regiops workshop.


JCard is machine interpretation instead of human readable. Even current implementations contain lots of errors in vcardArray.


JScontact would be a simpler alternative. (draft-stepanek-jscard)


Draft provides a “transition” option


Alex: Supports this work to go forward.


iii.Use of Internationalized Email Addresses in EPP protocol (Dmitry Belyavsky, 10)
https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/


Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-regext-belyavskiy-epp-eai-email-address-internationalization-profile-02


Alex: Thinks this is not needed. Server can return 2306 is EAI is not supported


Jim G: No signalling possible, that’s the key of this extension. Also, separate element allows client to signal explicitly they do EAI.


Scott: Channeling Alex a bit, but many implementations have eg. left side email validations. We need some signaling mechanism on validating the local part, at least. Not a fan of updating the core EPP specs.


Jim Galvin: Thinks that local part should be whatever the user thinks it should be.


Jiankang Yao: many emails in eg. india asia already EAI, so there might be a need.


Jim Gould: Issue with server storage - if server can store UTF8


iv. RDAP Redirect with Content (Tom Harrison, 10 minutes)
https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-redirect-with-content/


Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-regext-harrison-rdap-redirect-with-content-00


Jim Galvin: Question is whether or not WG wants to adopt this work.


Tim: If nobody has issue with that being an extension, we can simply register it. Has anybody any


Alex: No concerns, please go forward with the registration!


7. Review of available milestone slots (5 minutes)
RDAP Reverse Search is behind (Nov 2019 milestone)
Simple registration reporting has no milestone (suggests Mar 2021)


Had the model of “7 work items” on list


Alex: Take names of X people to do work on during adoption process:


Antoin: Have tried that, but there were not enough people in many cases.


8. AOB