Attached is the notes as recorded in etherPad during the meeting.
Thanks to those contributed.
These have been submitted to the proceedings. If there are any
corrections or updates please post them here and we’ll make sure the
notes get updated in the proceedings.
Thanks to all for an excellent meeting!
Antoin and Jim
MEETING SUMMARY - IETF108
Registration Protocols Extensions (REGEXT)
Virtual meeting replacing IETF 108
Co-chairs: Jim Galvin, Antoin Verschuren
Mailing list: regext@ietf.org
________________
Friday, July 31, 11:00-12:40 UTC, Meetecho
https://meetings.conf.meetecho.com/ietf108/?group=regext&short=&item=1
1. Welcome and Introductions (5 minutes)
i. Jabber scribe
ii. Notes scribe
iii. NOTE WELL
iv. Document management
v. Special attention document shepherds
2. Status of existing work in Progress (RFC Editor, IESG, AD
evaluation) (10 minutes)
Login Security Extension for the Extensible Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/
Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/
ICANN TMCH functional specifications
https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/
Registration Data Access Protocol (RDAP) Partial Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
RDAP Query Parameters for Result Sorting and Paging
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
* Jim Galvin
* Lot of documents ‘in progress’ on the way to publication
* No documents this meeting come out the other side
* Many close to being published.
* Security extensions in AUTH47.5
* Data Escrow in IESG evaluation RFC-ED soon
* Functional Spec -was languishing, now under review with AD
Barry Leiba
* recommending moving the Functional Spec document to individual stream.
- documents an ICANN process. what would it mean to say the IETF has
consensus on the document. it’s fine in the independent stream, its
what its for
Gustavo Lozano
* You need to have one of the AD to sponsor your draft?
Barry Leiba you contact the RFC Editor directly. Adrian Farrell is
independent s tream editor and it is a lightweight process not through
IETF consensus.
Gustavo Lozano Discuss on ML or discuss here?
Jim Galvin can ask the Q here, if anyone wants to comment. If no
objections on the ML, then Barry is making a suggestion unless
somebody has a strong opinion that's the direction he will go in
Richard Wilhelm Agree with and understand where Barry is coming
from. ICANN leverages the work of the IETF in similar situations in
order to get the input and ‘wisdom’. Barry’s points have a ton of
merit, but moving to individual stream: how do they get broad,
technical review from experts in REGEXT, into functional
specification. Does it get the thorough review it needs.
Barry Leiba Fine for WG to process, provide tech input, but in the
end, publication depends with independent stream not the IETF stream
Jim Galvin ask on the list, decisions vest in the ML. If you want WG
review that's the process to follow.
Barry Leiba I owe Gustavo a response on the ML
* other docs continued: Jim
* DNRD skipped
* RDAP partial response put out recently
* RDAP query params for sorting and paging
* Authenticated queries ‘on hold’ pending ?code? work
* Milestones review
* review now of docs don’t have milestones, and so not in milestones review
Antoin Verschuren
3. Existing work. (70 minutes)
i. 7482bis and 7483bis (Scott Hollenbeck, 10 minutes)
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/
ii. Registry Maintenance Notifications for EPP (Sattler/Carney/Kolker,
10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
ii. EPP Unhandled Namespaces (James Gould/Martin Casanova, 10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/
iii.EPP Secure Authorization Information for Transfer (James Gould, 10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/
iv. Registration Data Access Protocol (RDAP) Reverse search
capabilities (10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
v. Simple Registration Reporting (Joseph Yee, James Galvin, 20 minutes)
https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/
Discussion
* Antoin Verschuren
* What is suggestion of WG to reverse search capabilities? without
advice cannot progress. Feedback so far was to PI
* Jim Galvin
* Are we going to proceed with the documents and are we going to
work on them.
* Ulrich Wisser
* The reverse Search document has come up in our meetings, and
always had this problem with security and privacy
considerations. This is the main problem with the documents. The
functionality is needed but, the privacy part can’t just say
“follow the law” -it has to say something more. The functionality
is needed But if ICANN is going to have a big WG around this,
maybe this is something which should be tested in the WG after
they come to a conclusion on the privacy problem.
* Jim Galvin
* we’ve asked for text, had lengthy texts which felt
inappropriate. Is the technical specification enough, to get past
the privacy and security considerations.
* Jim Reid
* I would suggest what we do here is focus on the technical
concerns and when it comes to the problems around privacy and
security which surrounds the space all we can say here is the
problem is intractable from a technical Point of View. We can’t
solve this problem. it's up to individual registries to take
local legal advice which will differ. Everyone starts talking
about GDPR but even in countries bound by GDPR there are
differences of emphasis and so what is legal in one, is illegal
in another even underpinned by the legislation in the EU. the
best which can be done to somebody standing up an RDAP server is
‘consult local law enforcement’
* Roger Carney
* Getting back to the question, it seems like something somebody
from the numbers side should ‘push the pen’ on. Everyone here can
contribute, but it seems like … somebody from the numbers side
should stand up
* Jody Kolker
* My question is, there seems to be a problem with ‘the numbers’
-when somebody puts it into APNIC, we are giving up the
consideration and it's not the same in domain registrars. When
somebody applies for a number they give up their privacy, that's
part of signing up, your name will be searched. Not in domains as
far as ICANN is concerned. Maybe the numbers people should be
putting it in there.
* Scott Hollenbeck
* It does have privacy and security considerations. if we think
this is inadequate we should work on the text. It also notes ‘no
IANA considerations’ but there should be some RDAP conformance,
beyond the core specs. If mario is on the call…
* Jasdip Singh
* missed
* Jim Galvin
* Chair hat on: never got past the privacy and security
considerations part. thanks for noticing the IANA
considerations. I felt we never quite got consensus on the
Privacy/Security section. The proposal I would put here, we don’t
have to ‘solve the problem’ but we have to ‘call it out’. Jim
Reid called it out best. What you need to do is different all
over the world. It's a policy consideration. Our job is to
provide the facility for HOW and not cover this. For right now,
the answer is, do we want to move this document along? if so on
the ML we have to come to some closure on the text for this
section. No issues otherwise for some time (except for the IANA
issue just now). Does this need a shepherd? (yes it does) as well
as an updated milestone, to move the document along. Will take to
ML and force it out.
* Antoin Verschuren discussing
* 7482bis and 7483bis (Scott Hollenbeck, 10 minutes)
* Scott Hollenbeck
* I think these are ready for WGLC. All the issues were taken care
of, we have shepherds, all shepherd comments folded in, no more
coming up, I think ready for WGLC
* Antoin Verschuren
* Chairs we will move WGLC on both documents
* Jim Galvin
* Yes, shepherd, ready to go. Both numbers and names have looked?
* Scott Hollenbeck
* Yes, the feedback on the ML is from Jasdip (Numbers)
representative, Mario (Names) prolific feedback. Also been looked
at extensively in the ICANN community Operational Profile into
clarifications and corrections.
* Antoin Verschuren
* Milestone date August 2020
* Antoin Verschuren Now we discuss ii. EPP Unhandled Namespaces
(James Gould/Martin Casanova, 10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/
iii.EPP Secure Authorization Information for Transfer (James
Gould, 10 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/
* James Gould
* Unhandled: only to talk the track. Both ready for WGLC. Want a
more detailed discussion on use of BCP track (Unhandled
namespaces)
* On secure auth… Draft updates on salting, clarification on
representation of the null value and added text. Work to do on
the draft is also just the track, it's ready for WGLC.
* Antoin Verschuren
* Take to ML?
* James Gould
* Yes, but considerations of which track. Applicability
statement standards track for both of these is possible, or
BCP. I feel like they are BCP because they are not defining
protocol but practices (to increase security or compliance to
existing BCPs) -maybe Barry can speak to this?
* Barry Leiba
* it was a suggestion to consider, not thinking you ought to do
it. A technical statement specifies protocol, an applicability
does not necessarily specify a protocol, specifies how to to
use it, but arguably so does BCP. it's just what you think how
to use, or is the current practices and might change at a
different time. Do you want to call it a standard or not. Up
to the WG, happy for WG to decide but what you said sounds
like Applicability to me
* James Gould
* When I read through, Applicability said, one or more
implementations… Could fit that. BCP, designed to be a way to
standardize practices, the two drafts do that. Applicability
would be describing how to apply it. I still feel BCP is the
right track would like to hear from others in the WG
* Antoin Verschuren
* When I look in the data tracker, I do see that unhandled
namespaces has no shepherd. Has that been discussed?
* James Gould
* David from Verisign is nominated. Antoin we’ll handle that If
* no strong feelings, then I prefer stick as BCP and request
* WGLC
* Jim Galvin
* We’ll include status as part of WGLC probably that's the direction
* Jim Galvin
* Ends discussion on current work except for one item
* Simple Registration Reporting (Joseph Yee, James Galvin, 20 minutes)
https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/
* Joseph Yee
* sound broke up. could not minute
* Jim Galvin
* Does there always have to be a value in fields, to be
consistent. This document makes suggestions about this,
* Larger question of mandatory/optional on report columns:
have to make a choice. Arguments on both sides. Need
broader review by more registrars, operators.
* Plenty of room for ad hoc reports and less universally
available reports, do we have the right set for minimum and
the columns. captured what we know. did we not capture any
reports? the documents goal is to be a framework. want
people to think about reports not in here, but make sure
they can be covered by this framework for defining them.
* Are column headings optional or mandatory? Example has
ordered list of elements
* Questions from the first version of the document. suitable
for another document as work? defining filename. Q to WG:
follow through, or think we should not do any work in this
area?
* With respect to operations, what is the publication mechanism?
* No shepherd, no milestone.
* James Gould
* Reviewing the draft, this pack, I think draft should focus
on mechanism. Focus on format. Filenames, transport, not
well suited for this document. metadata in filename not
scalable. Leave it to format/mechanism and leave concrete
reports out
* Antoin Verschuren
* What do you want as a milestone date?
* Jim Galvin
* Since feedback dropping off, should be reasonable to finish
this year maybe a couple of more iterations, all set to
go. so absent objections/comment how about December 2020
* Antoin Verschuren
* Will put to ML, and will put shepherd request to ML. Jim
will do some outreach
4. AOB
* Jim Galvin
* Had pretty good cadence. Hit a bit of a good cadence. New
stuff which will move along quickly. If we get past
searching, registration reporting, only thing left on the
agenda is OpenID. Do we end?
* Jim Reid
* Even if the WG has no immediate stuff, premature to talk
about winding up, who knows what is coming from ICANN. can
it become dormant and spring to life if ICANN throws over
the wall?
* Jim Galvin
* we’re not a group which just takes on ICANN’s work, incites
‘feelings’ But point taken. Dormancy might be a better
model. ‘we will see’ -discuss with AD and WG input
* Jim Reid
* May need to think about it. If there is no ICANN venue for
technical stuff it may go to another venue: ‘swings and
roundabouts’
* Jody Kolker
* wondering… have registry maintenance draft out there,
milestone of July, not much feedback. how do we get it to
WGLC
* Jim Galvin
* Chairs need to put it into live work. we missed it. Apologizes
* Document seems stable, ready to move along, like rest, only
thing required for WGLC is somebody volunteering to do
it. Has shepherd. (Jim)
* Unless anyone has discussion, ready to move along. Will
take to ML with request to WGLC
* Jody Kolker
* fine to send to list. Do we do that or Chairs?
* Antoin Verschuren
* you request we send
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
