Minutes interim-2020-regext-01: Mon 17:00
minutes-interim-2020-regext-01-202004271700-00

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