Minutes IETF108: regext
minutes-108-regext-00
| Meeting Minutes | Registration Protocols Extensions (regext) WG | |
|---|---|---|
| Date and time | 2020-07-31 11:00 | |
| Title | Minutes IETF108: regext | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2020-08-07 |
minutes-108-regext-00
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