REGEXT 121 Meeting Notes
Registration Protocols Extensions (REGEXT)
IETF 121 Dublin, IE / Online
Co-chairs: Jim Galvin, Antoin Verschuren
Mailing list: regext@ietf.org
Session I: Adopted or new work presentations and discussions
Monday, 4 November 2024, 13:00-15:00 Liffey Hall 1
https://meetings.conf.meetecho.com/ietf121/?session=33514
Chair slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-regext-sessa-chair-slides-monday-00
Welcome and Introductions (3 minutes)
i. NOTE WELL
Noted by Antoin
ii. Notes scribe (Rick Wilhelm, others?)
iii.New work session
Other session has admin updates
Adopted work presentations
i. RDAP Extensions (Andy Newton)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-regext-rdap-extensions-00
Andy reviewed the slides.
Q&A:
Jim Gould: General agreement regarding 'extension styles' and having the
draft describe those (following a hallway discussion). Andy, also need
to discuss other types of extensions.
Scott Hollenbeck: Some of the noncompliant extensions are "harmless".
"Harm" could be a lack of implementation experience. Might not be
causing 'harm', but is causing work. While it's updating STD95, that's
not a Standard yet. Not that it's a problem, but it might be a bit of a
challenge, process-wise. Andy: we were thinking it would just be
Informational. But maybe not.
Orie Steele: If adding an entry to IANA, don't need to update. But if
changing the process, likely need to update. But I haven't read the
draft.
Jim Gould: The word non-compliance concerns me. That might be opinion.
Perhaps we need to have consensus on non-compliance. Andy: agreed that
it's hard to have agreement on non-compliance.
New work presentations
i. An RDAP Extension for RPKI Registration Data (Andy Newton/Jasdip
Singh)
Jasdip reviewed the slides.
This is a request for adoption.
Q&A:
Scott Hollenbeck: Supportive of adoption. Concerned about
workload/attention and timing.
Galvin: let's discuss priority tomorrow
James Gould: Agree that it is important. Regarding the names. X509
object class, seems like it should be CamelCase
Tim Bruijnzeels: Supportive. Should also involve a discussion with
CIDROPS. Look at RPKI validator and router and how they would use it.
Rick Wilhelm: Supportive. Consider exploring referral and bootstrap
concepts
ii. RDAP Extension for DNS Time-To-Live (TTL Values) (Gavin Brown)
https://datatracker.ietf.org/doc/draft-brown-rdap-ttl-extension/
Gavin presented the slides.
Jim Gould: Concerned about including addl info in RDAP that is public in
DNS and replicating the functionality that is in EPP. Making it
available to the public seems questionable.
Scott Hollenbeck: Haven't read the draft. Values could be different at
the authoritative.
Maarten Wullink: Concerned about consistency between Registry and the
DNS. Gavin: This is going to have to be sorted regardless if you are
implementing the EPP extension.
Rick Wilhelm: Concerned about user confusion. Gavin: Server might need
to provide some guidance in a remark
Jim Reid: Ambivalent. Need to be clear about what the number means.
Clarification about what the number means in practice
Andy Newton: Agreed that the number RDAP provides is the number that the
registry is being told is quite helpful.
Pawel Kowalik: Does every response require this response? OR only names
with a customized TTL? Gavin: yet to be determined. As a client
implementer, you'd likely want everyone to do it.
iii.EPP over HTTPS (EoH) and EPP over QUIC (EoQ) Implementation
Experience (James Gould)
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
https://datatracker.ietf.org/doc/draft-yao-regext-epp-quic/
Jim Gould reviewed the slides.
Q&A:
Gavin Brown: With the start packet, is that particular to the KWIC
implementation? Jim: It seems to be particular to QUIC.
Gavin: re: client authN, doing EPP login later. With a long-lived QUIC
connection, is there a risk related to that? Jim: We did it with a
keep-alive on the Stream and not the Connection.
iv. AuthCodeSEC (Victor Zhou)
Victor reviewed the slides.
Q&A:
Andy Newton: We shouldn't reinvent other public key crpto that we can
just 'steal'. That is, there are x509 certs, we should just reuse those
as a container object.
Pawel Kowalik: Model A: If a registrant signs the object, how would a Ry
know the public key of the registrant. Victor: in the new paradigm of
blockchain usage, people are managing their own keys.
Jim Gould: domain-ext would be appropriate since this is a new mechanism
for authorization info. Victor: seems like it would be undecided.
Scott Hollenbeck: Transfer friction currently exists by design. That is
to prevent domain "slamming".
Rick Wilhelm: AuthCodes are changing to be ephemeral due to the
transfer. Not sure if this is worth the effort. Victor: in the context
of a sale, the security is still important.
Jody Kolker: Agree with Scott and Rick. Instant transfer has been pushed
back in the ICANN world several time. Model A (registrant sign) is not
practical in the real world.
v. Domain variant support for EPP (James Galvin)
https://datatracker.ietf.org/doc/draft-galvin-regext-epp-variants/
Jim Galvin reviewed the slides.
Q&A:
Andy Newton: Supportive. Does blocked mean 'no intent to allocate'.
Terminology is a little confusing
Scott Hollenbeck: Does this include the description of the algo the
server must use to generate the variant. (Jim: no, that's part of a
different doc.). Scott: Is there a normative reference. Jim: Fair point.
Stefan Ubbink: Does this have any implication on fees? That would be on
the policy side.
Jim Gould: There is an impact for 'blocked'. I have a concern about
'primary'. It adds complexity. Especially related to statuses. And as it
relates to deleting domains. Galvin: deserves further discussion,
especially re: policy implications
David Krizanic: Concerned about primary label and possible confusion
that could result related to UDRP. Jim Galvin: That will be a good
discussion. It's not an issue from the ICANN policy side because the
policies account for it. But from a ccTLD side, it could be interesting.
Edmon Chung: Believe that the upate of the Primary is allowed. To
calculate the alloatable set, the set can be different if the Primary is
different. Also need to be careful related to the terminology regarding
statuses in the doc. Re: Scott's comment: this doc should point to the
LGR RFCs, but not mandate it, because a particular registry policy may
do something different. But still supportive of adoption.
vi. The extension identifier issue (Tom Harrison)
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-regext-rdap-extension-identifiers-00
Tom reviewed the slides
Q&A:
Jim Gould: Maybe we just need tighter language in the RFCs. ABNF in the
base RFC language would be helpful. No concerns with bare. Just need
them to be unique.
Scott Hollenbeck: 5 extension identifiers from 1 extension. Seems
inconsistent to prior practice. Tom: agreed, but will it cause problems
in practice.
Antoin ajourns on time.
Session II: Existing work status updates and administrivia.
Tuesday, 5 November 2024, 15:00-16:00 Liffey B
https://meetings.conf.meetecho.com/ietf121/?session=33515
Meeting opened on time.
Tuesday chair slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-regext-sessb-chair-slides-tuesday-01
Welcome and Introductions (3 minutes)
i. NOTE WELL
Noted by Jim
ii. Notes scribe
Rick Wilhelm & others(??)
iii.Document management
Published (0.67 minutes)
None
RFC Ed Queue (1.33 minutes)
None
Submitted to IESG (10 minutes)
i. EPP mapping for DNS Time-To-Live (TTL) values
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
ii. Use of Internationalized Email Addresses in EPP (Scott
Hollenbeck)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
iii. Best Practices for Deletion of Domain and Host Objects in EPP
(Scott Hollenbeck)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/
Only just got in the IESG queue.
Past WG last call (15 minutes)
i. RDAP RIR Search (Jasdip Singh)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/
Waiting on Doc Shepherd write up
ii.An RDAP Extension for Geofeed Data (Jasdip Singh)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/
Waiting on Chair review of doc shepherd write up
RDAP with Extensions Media Type
draft-ietf-regext-rdap-x-media-type
Andy: Needs the Extensions and versioning to go first
Versioning in the Registration Data Access Protocol (RDAP)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-versioning/
Waiting on authors - James Gould, Dan Keathley, Mario Loffredo
Gould: good meeting discussing compatibility; solve different problems
and they work together. Anticipate an update to both drafts. Expect an
update to the mailing list. Also agrees that the Extensions should
finish first. Versioning and X-Media should 'go together'
Use of Internationalized Email Addresses in EPP (10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
WG Document - ready for WG Last Call
Scott Hollenbeck
Galvin: This went to the IESG and was remanded back; and (somehow) the
doc status got confused. That's now sorted. Document appears stable, but
requires WGLC because there was a material change. And needs an updated
doc shepherd write up. Expect the WGLC to come soon.
RDAP Extensions
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/
Work in progress - ready for WG Last Call?
Galvin: presentation about this topic yesterday.
Andy: needs an update and a review before WGLC
Gould: Agree; no need to rush and we want to coordinate for the other
drafts
Jasdip: re: Extensions, Media Type, and Versioning: do Extensions first,
b/c it provides guidance for the others. Media Type and Versioning would
stay separate docs and cross-reference where necessary and go together.
No objections voiced in the room on this approach.
Using JSContact in RDAP JSON Responses (10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
Work in progress - moving to Experimental, what to do about transition?
Mario Loffredo
i. Using JSContact in RDAP JSON Responses (Mario Loffredo)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
Mario declined the opportunity to go through the slides.
Summarizing the slides:
Orie: Glad we're using Experimental. Could we get a summary of what does
success look like for Experimental? What would it require to promote
this to Proposed Standard?
Galvin: See what the uptake is like compared to the current installed
base.
Mario: The number of implementations using the specification.
Galvin (to Orie): Are we supposed to raise the question?
Orie: It's up to the WG. Gather feedback and experience via the
Experimental doc. Might even describe the experiment in the doc.
Wes: it's helpful for an Experimental doc to lay out what a successful
experiment would look like
Scott: Would like to suggest that we create a public record of these
suggestions of what the experiment might be.
Jim Reid: Should be careful about the use of Experimental documents.
Particularly in the context of ICANN.
Andy: What is success? If you can make the transition between the two
data models, that would be success.
Galvin: Would be good for the experiment to be documented on the mailing
list. Suggested that Mario make the initial draft.
Mar 2023 - Using JSContact in RDAP JSON Responses
Jun 2023 - DNS Data Dictionary -- EXPIRED and will be deleted
Mar 2024 - RDAP RIR Search -- Chair actions, then IESG
Jul 2024 - An RDAP Extension for Geofeed Data -- Chair actions, then
IEST
To be a milestone:
Use of Internationalized Email Addresses in the EPP
These will be WG Docs, probably, roughly in this order:
Gould: Don't see any conflict caused by the EoH and EoQ work
Edmon: Consider the importance of the domain variant support for other
impacts
Pawel: I appreciate the transparency
Orie: On the EoH and EoQ topic, can they be a single document?
Gould: They are both options. There is no relation between the two,
other than the fact that they are both options
Zahed Sarker (Transport AD): It somewhat depends on what clients you are
using. Different clients, then maybe different papers.
Wes: General trend is to move to smaller papers. When talking about
transport, better to recommend one.
Karl Dyson: Agree with Gould. We have a preference for a protocol. By
being in separate documents, it's easier to specify which protocol is
being supported.
Galvin: Aiming for 2 meetings for next IETF meeting.
Andy: RPP BOF on Wednesday