Skip to main content

Minutes IETF108: regext

Meeting Minutes Registration Protocols Extensions (regext) WG
Title Minutes IETF108: regext
State Active
Other versions plain text
Last updated 2020-08-07

Registration Protocols Extensions (REGEXT)
Virtual meeting replacing IETF 108
Co-chairs: Jim Galvin, Antoin Verschuren
Mailing list:

Friday, July 31, 11:00-12:40 UTC, Meetecho
1. Welcome and Introductions (5 minutes)
i. Jabber scribe
ii. Notes scribe
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)

Registry Data Escrow Specification

Domain Name Registration Data (DNRD) Objects Mapping

ICANN TMCH functional specifications

Registration Data Access Protocol (RDAP) Partial Response

RDAP Query Parameters for Result 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)

ii. Registry Maintenance Notifications for EPP (Sattler/Carney/Kolker,
10 minutes)

ii. EPP Unhandled Namespaces (James Gould/Martin Casanova, 10 minutes)

iii.EPP Secure Authorization Information for Transfer (James Gould, 10 minutes)

iv. Registration Data Access Protocol (RDAP) Reverse search
capabilities (10 minutes)

v. Simple Registration Reporting (Joseph Yee, James Galvin, 20 minutes)

   * 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)

     iii.EPP Secure Authorization Information for Transfer (James
     Gould, 10 minutes)

   * James Gould
      * Unhandled: only to talk the track. Both ready for WGLC. Want a
        more detailed discussion on use of BCP track (Unhandled
      * 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)

      * 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
         * 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

         * Jody Kolker
         * wondering… have registry maintenance draft out there,
           milestone of July, not much feedback. how do we get it to

         * 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