The Registration Protocols Extensions (regext) Working Group Virtual IETF107 meeting on 2020-04-27 from 17:00 to 19:00 UTC Webex Link: https://ietf.webex.com/ietf/j.php?MTID=m324df1905fea9a26595469217a900a83 Co-chairs: James Galvin, Antoin Verschuren Mailing list: regext@ietf.org ***************************************** Monday, April 27th, 17:00-19:00 UTC, Webex 1. Welcome and Introductions (10 minutes) i. Jabber scribe ii. Notes scribe iii. NOTE WELL iv. Document management v. Special attention document shepherds Notes: - Please use full name in webex chat. (Reverse etherpad) - Jabber scribe was forgone - Will address doc management later - RFC 8748 Extensible Provisioning Protocol (EPP) published congrats - Two documents : - Data Escrow Specs - Working on logistics - Domain Name Registration Data (DNRD) - Domain Bundling - Had two BOFs - Submitted to IESG - IESG working with authors to publish this as an individual submission - It has expired, it is not a part of this working group - Milestones review: - Three documents are falling behind. Need authors to step up and decide what to do. - Four other documents in flight. Keep in mind as work gets reprioritized. - One other document referenced by Gustavo - Questions/Comments: - None 2. Existing work, newly adopted drafts since last IETF106. (40 minutes) i. Registry Maintenance Notifications for EPP (Sattler/Carney/Kolker?, 20 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ Notes: - Roger Carney presenting. - History - How to standardize maintenance notifications. Different emails, different registries, etc. - First draft oct 2017, adoption request in 2018. - Working Team: - Tobias Sattler, Roger Carney, Jody Kolker - New feedback from Patrick will be presented to move forward with the process. - Qs/Comments: - Alex Mayrhofer: Are there consensus to move the document forward ? - Ans: Not much discussion for the past year or so. Just looking to finalize. - Is the source of the silence because everyone is happy or no one has not read it ? - Agreed so will be pushing forward. - Next steps: - address open question - If any change will create a new version. ii. EPP Unhandled Namespaces (James Gould/Martin Casanova?, 20 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/ Notes: - James F. Gould presenting … - Overview: - Purpose: Server should not return objects and extensions to clients not in login services . Defining operational practice, use RFC 5730. Plus provide reformatted reason for processor to monitor the existence unhandled namespaces. - General EPP Responses. - Server may use unhand. Namespaces approach for general EPP responses - Should be applicable to only command-response extensions - Example includes RGP information in RFC 3915 - Poll message EPP responses. - Server MUST use unhandled name space approach for poll message - MAY be applicable to both object level and command response. Extensions - Example includes namespace information to be processed later by client. - Implementation Experience: - Discussion . - Posted message (https://mailarchive.ietf.org/arch/msg/regext/kjTGIfkm5ednf2l0rSe-FltYLzQ/) to the list applies to BCP/EPP - Q1: Is signaling needed in EPP for the implementation of BCPs? - Q2 : Does signaling mechanism existing today meet the need. - Q3 : Type of URI (object or extension ). EXT is most important to support - Q4: Groups under EPP name space, create BCP sub space under name space. - 01 Version was posted last week. Included registration for EPP extensions , Added signaling section when BCP is supported by client or server. - Unhandled namespace approach, service URI needs more discussion. Need to maintain compliance with RFC 5730. Enable poll queue messages to be consumed independent of client login services. - Qs/Comments: - Document is best current practice, questioning whether is should be a standard or not ? If no feedback received what the next steps should be? - Both drafts have been updated. A version was created to answer the questions. - Patrick: suggest to make response more explicit by not using the human readable reason element, BCP for EPP not to be hard coded, and not sure if these drafts are the best solutions. - Agree with the intention of the usage. Not sold on inclusion of BCP in URI, but open to suggestions. Hope for a final URI as the document matures. - Barry: Doc status issue. RFC 2026 section 3. Even through doc do not create protocol, they can be a standard. Suggest to read that RFC 2026 and see if it applies to this work. - Ulrich: There has been a disagreement to this draft. Do not think this is made for standards track. - Barry: BCP and standards are treated equally. - Jody: Whether signaled in URI or not, BCP needs to be in the logging at minimum. It is more operations friendly. - Should it be in both greeting and login? Maybe both, maybe greeting is more important. Needs further consideration. - Alex: What is server to do when multiple unhandled namespace elements? - This is addressed in the draft - Scott: Can we consider experiment status? - Ulrich: Client and server need to know unhandled namespaces when negotiating. iii.EPP Secure Authorization Information for Transfer (James Gould, 20 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/ Notes: - Problem: - Review security of authinfo. To support secure storage - short lived. - Draft does not scope policy - More details of the problem provided. - Support of secure authinfo for other than transfer - Empty authinfo stored as null - Reference use of SHA-256 - Support indication of set or unset authinfo in the info response of registrar. - Changes: - Request for new transition consideration section - starting with base case. A classic authorization informational model is defined. - three phases - feature compatible, storage, and enforcement were presented. - Conclusion - no new extensions or protocols required - Authinfo can exist only during transfer process - Authinfo can have client managed TTL - Authinfo is not stored by the registrar and stored as a hash by the registry - Qs/Comments: - Hash algorithm suggest salted version of SHA-256 - Many aspects in the draft are not related to EPP - Why authinfo needs to be stored as ‘null’, not every registry uses same type of database. - EPP is a provisioning protocol and its mechanism is important. With respect to NULL value does not require the use of a particular database. Use whatever is null in the database used. - Document mixes protocols with operations instructions. Suggest the operational aspects to be minimized or move to a different document. - Feedback on transition section is welcomed. 3. Existing work, almost done (10 minutes) i. RDAP Partial Response (Mario Loffredo, 5 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ Notes: - Mario Loffredo. - Reviewed changes based on feedback received . Still processing some remaining feedback - No questions: ii. Query Parameters for Result Sorting and Paging (Mario Loffredo, 5 minutes) https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ Notes: - Mario Loffredo. - Reviewed changes based on feedback received. - No questions - Getting more feedback after last call. 4. Other work (40 minutes) i. 7482bis and 7483bis (Scott Hollenbeck, 20 minutes) https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/ https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/ Notes: 7482bis - Scott Hollenback … - Status of drafts designed to capture corrections and clarifications needed to advance to protocol track. - Change#1: - What is an internationalized domain name ? - Change#2: - Registrars are entities - DNR = Domain name registries or registrar - Bootstrap registry which is incomplete to support (see RFC 8521) - Section 3.1.1, 3.1.2, 3.1.3 - Suggested ‘JSON objects’ value to JSON objects properties - Strike text in section 3.2.1 and 3.2.2 - Section 4.1 - a character string representing domain label suffix Qs/Comments - Alex: Slide 9: is YYYY a representation of an IP address ? - Scott will review the discussion related this slide. Notes: 7483bis - Similar approach - Description of a handle , handle is a string - Definition of identifier = string - Unicode characters were morphed. This has been corrected - IPv4 was described as v6. Change completed. - Definition of a country. Qs/Comments: - This WG has to decide evolving this standard. These are standards track document. Are there any other things to add ? - Scott: Qualified ‘technical changes’. The discussion is still on RDAP level 0. - What are the next steps for these documents ? - Intention is to update the docs based on comments received. ii. Simple Registration Reporting (Joseph Yee, James Galvin, 20 minutes) https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/ Notes: - Joseph Yee: - Registries produce different reports. Need to standardize the reports. Examples shared. - In order to standardize these reports, the columns headings need to be registered with IANA - Define what fields in the reported, shard field samples. - The reports need to be registers as well. Shared reports names. - Reports baseline requirements: CSV, first line in columns, what to do with odd columns - More discussions needed to address fields types, like date, - Report storage structure (hierarchical versus flat) - Discussion on separator types (comma, versus other symbols) -Qs/comments: - Suggested a certain type of characters to use. AOB Thanks everyone. Chairs apologized for not turning on recording until the meeting was half through