Sorry for not sending this sooner. We mistakenly believed that
submitting them to the proceedings would alert the working group.
Attached please find the minutes as taken by Zaid AlBanna. He provided
these right after the meeting. Thanks so much for doing this Zaid!
They have been submitted to the proceedings. However, please do review
the summary and let us know if there are any corrections or updates. We
will take those on board and update the proceedings as needed.
Thanks to Zaid and thanks to all for your review!
Antoin and Jim
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
