WGs marked with an
Regext Status PagesRegistration Protocols Extensions (Active WG) |
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2016-Mar-04 —
Chairs:  |
IETF-106 regext minutes
Session 2019-11-20 1000-1200: Hullet - Audio stream - regext chatroom
Minutes
Registration Protocols Extensions (REGEXT)
IETF 106, Singapore, Agenda
Co-chairs: Jim Galvin, Antoin Verschuren
Mailinglist: regext@ietf.org
*****************************************
Wednesday, November 20th, 10:00-12:00, Hullet
1. Welcome and Introductions (10 minutes)
i. Jabber scribe: Barry Liebe
ii. Notes scribe: Rick Wilhelm
iii. NOTE WELL: noted
iv. Document management
Antoin:
- Pls volunteer to review docs and provide comments
v. Special attention document shepherds
- Document shepherds: Having a doc shepherd at the time of adoption
seems like a good idea. Will help keep the doc moving.
Barry:
- Thanks for taking this up. "Extending document shepherding"
available on WG Chairs' Wiki. Good idea to not make it mandatory.
Doc shepherd should not "just" write the shepherd write-up. Should
help keep it moving.
Antoin:
- Being a shepherd isn't that hard. Great way to get introduced to the
process at IETF.
Galvin:
- NomCom is here and looking for comments about leadership
2. Existing Document Status (10 minutes)
2.a. RFC Editor queue
i. Registry Fee Extension for the Extensible Provisioning Protocol
(EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/
Antoin:
- Everything seems to be going well with this I-D
2.b. IESG evaluation
i. Login Security Extension for the Extensible Provisioning Protocol
(EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/
ii. Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extension
for Strict Bundling Registration (Informational)
https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration
Antoin:
- For Bundling doc, got comments about why this doc is coming forward
as an Informational doc. But this one was reviewed and approved by
the WG.
Galvin:
- This doc is with the IESG. Suggestion is to make it Informational
and have it come through the Independent stream
Barry:
- Agreed. The issue isn't that it's Informational. But this being
similar to a Proposed Standard. That struck the IESG as odd. It will
go smoother if the document goes through the independent stream process.
- Login Security is not yet in IESG evaluation.
Scott Hollenbeck:
- Shared experience from the past, related to the RRP protocol.
People didn't want to see it "standardized", but they wanted to see it
"documented". Suggested changing the title to help explain why it's
informational.
Jiankang Yao:
- Lots of years of work on this.
- It's really for a few registries in China. Many users in China follow
this document. I would like to keep it in the WG.
Barry:
- If you want the doc published, the best way to do it is via the
Independent Stream. IESG has made that clear.
Antoin:
- It's used by multiple registries, but it's not used by _all_
registries. After a BoF, we tried to get the strict bundling documented.
Jiankang Yao:
- There are many different bundling approaches. This is just one,
strict bundling. Other registries that do strict bundling can use it.
2.c. Working Group last call
i. Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
ii. Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/
Antoin:
- This could nearly be out of WGLC. It needs some changes. We put DNRD
in a
second WGLC. We need responses that the changes were not material so they
can be moved on.
Jim Gould: Doc shepherd for data-escrow. In review, it has some
changes that
are editorial. Need the WG to confirm these are editorial. For example:
- Used defined terms from another RFC.
- Examples need to be changed due to schema validation errors.
- XML schema was importing epp-com schema, which created a hard
dependency on
an EPP RFC. It was used for just one derived type. But the derived
type was
not used. Therefore, the import and the hard dependency is unnecessary.
- Different types of deposits. The ICANN BRDA uses this draft.
Therefore,
with the document author, we changed the DNRD draft to define the type of
the deposit. Also: in changing the schema, there are some concerns about
interoperability. So we may need to reach out to a broader set of
participants.
Jim Galvin: These docs are widely implemented in the ICANN gTLD
environment.
Given that, there is an important backward-compatibility consideration for
current users. Will give more context here in the review by the joint
meeting with ICANN CPH TechOps.
Barry: From Jabber: Roger Carney confirming that these docs are going
to get
revised.
Galvin: They are going to get new revisions, but will not materially
change.
Gould: Both docs will get an update.
Alex Mayerhofer: Confirming: the docs will be revised? What is the
timeline
for the revisions so I can make good use of my review time.
Galvin: Both docs will get a revision of the version number. As long
as the
changes are editorial, they won't go through WGLC.
Gustavo Lozano: The timeframe for the updates should be just a couple
of days.
3. Existing work (20 minutes)
i. RDAP partial response/sorting and paging/reverse search (Mario
Loffredo)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
Mario Loffredo: (flipped to Mario's slides)
First on Partial Response:
- Changes implemented after a good review by Tom Harrison.
- Reviewed changes since 105
- -03: added unicodeName field
- -04: Recommended that RDAP providers include a "self" link
Sorting and Paging:
- Three versions published since July
- -04: replace ldhName with sortingName; need to use unicodeName when
sorting. and also clarified sorting logic and sorting policy for
multivariate fields. For example letter sorting vs number sorting.
Other changes (see slides for details).
- -05: Clarified sorting logic on IP addresses. Sort on numeric
conversion, not on the string value. Each RDAP provider may have its
own sorting properties. (see slides for details)
- -06: renamed pageCount to pageSize; added pageNumber property. These
might be redundant, but might help implementers make a better
interface
- For next version: How to implement pagination when "links" can't
be used,
that is, when submitting a query with a POST, rather than a GET. Possible
solution: an optional property named nextCursor. see slides for more
Reverse Search
- -02: just a doc refresh
- -03: Most significant change is the refactoring of the query model.
Was made simpler. See slides for detailed syntax. Now have:
resource-type, role, and property. See slides. Servers may implement
additional properties to those that are defined. New format is
simpler than previous one.
Alex:
- I like the new format for the query.
Antoin:
- What do you think the current status is?
Mario:
- Current status depends on implementations. Knows that different
people are doing implementations. Mentioned Tom Harrison is doing
work on some reverse search. Mentioned some work on paging being done
by Google. But the paging mechanism is somewhat different. Mario
talking w/ Google team about implementing the I-D's approach. Asked
for more info from implementers. Said ready to help any implementers.
Tom Harrison:
- Sorting and Paging allows customizable mapping of the field.
Reverse search
is quite specific. The draft might need to be clarified for terminology.
Alex: NIC.AT might start looking at this in early 2020.
Our implementation
work might be a little late for the doc, but we are going to be doing it.
Mario:
- We might need more time for these documents. Mentioned RDAP
implementations
now being launch. Said that implementers might look to some of this
to help
make their implementations more efficient.
Antoin:
- Does this mean that the timelines might be missed? Should we take
one or
two of them off the milestone list?
Mario:
- There might be new implementations coming that would be interested in
partial response and sorting and paging. Reverse search might be
different.
At my registry, we want to do some reverse search. Other registries might
not want to. Reverse search is not planned to be open to everyone, due to
privacy reasons related to GDPR. We want to provide the capabilities to
our registrars to handle lots of questions that come to us. We handle
them
out-of-band. We'd like to be able to do them via RDAP.
Ulrich Wisser:
- Last time, we had an extensive discussion about Privacy Considerations.
What sort of updates were made?
Mario:
- Made updates that Reverse search capabilities MUST be provided by
national
rules or other rules related to personal info. We want to provide this to
registrars that are looking at the data that is theirs. The
implementation
provides protection on a per-user-role basis.
- Not sure if we are the only ones who get these kinds of queries: what
are the domains related to this technical contact.
Ulrich:
- The need for reverse search is not in question. More related to the
wording in the document. Should describe the problem and give guidance.
Saying follow the law is not really helpful.
Galvin:
- Share the concerns about the privacy consideration. would like to
take the
topic to the list.
Alex:
- To solve the milestone problem? Are they any of the three that is more
advanced?
Mario:
- My opinion, Sorting & Paging and Partial Response don't need more
updates.
They are only waiting for more implementation.
Alex:
- Would be good to get more implementations.
Rick Wilhelm:
- Would be good to get more client implementations. Noted the work
by Marc
Blanchet in RDAP profile and Tom Harrison's work
Mario:
- Considering a self-configuring client in the future
ii. ICANN TMCH functional specifications (Gustavo Lozano)
https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/
Gustavo Lorenzo:
- First version was relatively stable. No major changes since May 2014.
- Intended to be Informational
- Has been widely implemented
- Was headed toward RFC. Feedback from Patrik Falstrom was received. (See
slides for links) The objection was about the matching rules.
- This version addresses those.
- Would like to have a stable reference for contracts.
Galvin (not as chair)
- This doc has lots of history and broad deployment
- Needed some changes to make it stable
- Objection from Patrik; need to see that the objection is resolved.
Jim Reid:
- Informational RFC or is this going to get push-back?
Galvin:
- Not expecting pushback from the IESG
Barry:
- Won't speak for IESG, but it is reasonable for the WG to put out
Informational specs
4. Report from the Joint ICANN TechOps / Regext interim meeting
(20 minutes)
Debate on new milestones.
Slide on screen is the list of Milestones (slide 10)
Galvin:
- In August we had two milestones for data-escrow and dnrd-objects.
Suggest
that we let those go.
- For RDAP, we had Sept, Oct, Nov milestones for partial-response,
sorting-paging, and reverse-search. Suggest that we move partial-response
and sorting-paging to WGLC so help drive responses.
- If we want to hold them back, we could update the milestones.
- We need to consider reverse-search separately. We can discuss this
on the
list.
- OpenID doc, we will leave alone.
Hollenbeck:
- protocol piece hasn't changed much in the last year or so. Confident in
the protocol.
- Less confident in the status of the IANA consideration section. Lots of
dependency on the ICANN EPDP. Could pull out the IANA Considerations
and go
forward. Or we could hold on and wait.
Galvin:
- Would like to not change the milestone at this time.
Report from Joint ICANN TechOps / REGEXT interim meeting
Galvin: (see slides) Presenting not as co-chair
- Met jointly with TechOps, a group of registries and registrars.
- ICANN is a place to get more of these parties in one meeting.
- We met two weeks ago in Montreal.
- The "Objectives" slide was presented at the joint meeting.
- Goal was to review 14 potential documents and help get info about which
should be considered to be adopted.
- Meeting was conducted under NOTE WELL.
- Mentioned https://bestpractice.domains.
Alex:
- Internet standards are supposed to be about broad deployment. These do
not seem to be standard-worthy.
Galvin:
- Fair enough. Some of these might be Informational.
(Slide 3)
- Five areas
- Registry Mapping: work that has been moving forward even though
it isn't
a milestone. Roger Carney has been helping.
- Three docs that are likely coming forward; Secure authinfo Transfer:
revision that is going to be produced based on feedback received at CPH
TechOps; Registry Maintenance Notification and Unhandled Namespaces.
- Registry-registrar reporting: discussed a new approach at CPH
TechOps and
the Dataset File Format.
George Michaelson:
- Good sense in the direction and pace of the work.
- The pace of the meeting is oriented insufficiently toward RDAP.
This work
is about business-to-business relationships. The RDAP work would benefit
from more mindshare.
Barry:
- There is more coming on RDAP.
Galvin:
- There are two workstreams: RDAP and EPP. There is more coming on
RDAP in
New Business. We are concerned about the balance of the work.
(switching to new slides, on Registry Reporting)
Galvin:
- Every registry produces a set of reports that registrars consume. The
goal is to create stabiity in those reports. We also want to allow some
flexibiity. Just presenting a concept today. Was presented at CPH
TechOps
meeting.
- Next steps would be that this would continue in design effort.
- Slide 2: Here are some example reports. There can be some commonality
between reports.
- Slide 3: Registrar needs to consume these reports. Goal would be to
consume them easily.
- Slide 4: Create an IANA registry of column headings. Would be
a first-come,
first-served registry
Jim Reid:
- Hope that there is info about who asked for the column. Can be
difficult
to know who is responsible for what in a first-come, first-served IANA
registry.
- Galvin:
-Yes, we are addressing that. We have planned for contact info in
the registry
- Slide 5: gave examples
- Slide 6: gave examples
- Slide 7: gave examples; IESG is the registrant, because it would be
defined by an RFC
- There were 31 fields total, out of the 9 reports
Alex:
- Do you see what kind of advantage there will be publishing this in
the IETF vs just on Bestpractice.domains?
Galvin:
- This was discussed. That website is not a persistent, archived
reference.
- ICANN uses the IETF for this purpose.
Alex:
- The only reason to do this at the IETF is because people will review
them.
This is rubber-stamping.
Galvin:
- Not rubber-stamping. This is a technical concept. So I came here
to the WG.
Galvin:
- Slide 11: these items were left as discussion points.
- Someone at TechOps brought up the point that the reports might not be
produced as Files. An open question is in the distribution mechanism.
- What does one do with unexpected columns?
- Slide 12: The proposal for Dataset File Format has additional
capabilities.
This file shows the file name proposal.
- Next step would be further discussion
Marcos Sanz:
- Not opposed to standarizing. But this is the same as escrow
and we are standardizing the same thing.
Galvin:
- These reports are different than escrow.
Alex:
- Not against standardizing those things. Don't feel that an RFC is the
right venue.
- There are discussions at CENTR which are related to this
- The scope of the IETF is different
Antoin:
- CPH TechOps is a gTLD-only group. The CENTR group is ccTLD-only.
- Things that come from ICANN feel like pressure to do this at IETF for
policy.
- We don't want to give the impression that we are being run by ICANN.
Barry:
- From Jabber: another reason to bring this to the IETF.
Galvin:
- The two groups are specific to each other. That's actually a reason to
bring this to IETF.
- The idea for the work may have originated from ICANN, but this is a good
place to solve it
- We should take input from what CENTR has done
Antoin:
- Are there others that we need to involve? RIRs? ENUM registries? How
can we get broad support for standardization.
Reid:
- This WG is a good place for this
Wilhelm:
- There was not a full consensus among CPH Techops on these reports
- These reports are a business item between registries and registrars
that is, they are not part of contracts like EPP and RDAP are.
Antoin:
- No time for discussion about new milestones. That will take place
on the list.
5. New work (20 minutes)
i. jCard with JSContact in RDAP and recent changes in JSContact
specification
(Mario Loffredo)
Mario:
- JSContact would a more effection contact card than vCard
- Latest version is -05
- Currently in DISPATCH
Barry:
- This will be done in the JMAP working group.
Mario:
- Provided examples (see slides)
- Handle multi-lingual
- Brief overview of transition model (from jCard to jsCard)
- Described advantages of the transition model that allows servers
and clients
to transition independently.
Antoin:
- Will discuss on list
ii. Domain Suggestion Extension (Alexander Mayrhofer)
https://datatracker.ietf.org/doc/draft-mayrhofer-epp-domain-suggest/
Alex:
- About 15 people in the side meeting
- Brief summary of what is domain suggestion
- Potential protocol options for the capability
- Overview of existing work: EPP by Verisign, deprecated and pulled to
REST-based interface; RDAP interface by Mario; Alex developed an EPP
approach
- Side meeting points: registrar is better positioned for this; EPP
is not
a good protocol choice; RDAP might be a better choice; room had lots of
registries
- Will be moving toward a REST implementation
Barry:
- Roger Carney on Jabber: this might be good for smaller registrars,
larger registrars have their own.
Jim Reid:
- Don't think that this is a good idea for standardization
6. AOB
Hollenbeck:
- Looks like it's time to address the captured errata and move the
RDAP RFCs
to Internet Standard status.
- Propose that we take on this effort
- Will volunteer to take on finding doc authors and shepherds
Galvin:
- We've discussed and this would be good work to take on.
- We might need a tweak to the charter.
- This and the jCard work fall to the RDAP side of our charter