* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Regext Status Pages

Registration 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

minutes-106-regext-00 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
          
          



Generated from PyHt script /wg/regext/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -