Minutes IETF103: regext
minutes-103-regext-00

Registration Protocols Extensions (REGEXT)
IETF 103, Bankok, Thailand, Agenda

Co-chairs: Jim Galvin, Antoin Verschuren
Mailinglist: regext@ietf.org

*****************************************

Tuesday, November 6th, 13:50-15:50, Boromphimarn 4

Agenda:
https://datatracker.ietf.org/meeting/103/materials/agenda-103-regext-00


1. Welcome and Introductions (4 minutes)

Chair slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-chair-slides-00

Meeting opened on time by co-chair Jim Galvin.
Co-chair Antoin Verschuren participating remotely.

   i.   Jabber scribe
		Paul Wouters
   ii.  Notes scribe
		Richard Wilhelm
   iii. NOTE WELL
	Reviewed by Galvin as per usual.  Also passed Blue Sheets.
   iv. Charter update (2 min.)
	-Galvin reviewed the slide in the Chair's deck on the charter content
	-Recent change:  WG may also take on work to develop specs that
	 describe various types of info exchanged between entities involved in
	 Internet identifier registration that are using the RDAP or EPP protocols
	-Galvin described discussions/negotiations with IESG on the charter scoping
   v. Document management
	Galvin reminded people to help out with document reviews in other areas


2. Existing Document Status


2.a. RFC Editor queue (2 minutes)

   i.  Registration Data Access Protocol (RDAP) Object Tagging
       https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/

   ii. Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
       https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/
      
	-Galvin asked if anyone had comments on these.  None offered.

2.b.  IESG Evaluation (4 minutes)
     
   i.  Change Poll Extension for the Extensible Provisioning Protocol (EPP)
       https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

   ii. Extensible Provisioning Protocol (EPP) Organization Mapping
       https://datatracker.ietf.org/doc/draft-ietf-regext-org/
       Organization Extension for the Extensible Provisioning Protocol (EPP)
       https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

   iii.Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
       https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

	-Galvin gave brief updates on the three docs in IESG eval phase.
	-All docs are generally moving
	-Galvin noted that these docs don't appear on the WG milestone list
	-Jim Gould brought up a topic recently brought up a recent list topic
	 related to the xml namespace on change-poll.  (It's been suggested that
	 this be changed to be scoped.)
	-Galvin said that going forward, we should be careful about these namespaces

2.c. Past WG last call: Waiting for shepherd writeup (3 minutes)

   i.  Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict 
       Bundling Registration
       https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration
                     
	-Galvin noted that there is a draft version of the shepherd writeup for
	 this doc.  Expected to be revised before submission.

3.   HRPC Human Rights Review of draft-ietf-regext-verificationcode (15 min)

	-Galvin commented that there has been list discussion on human rights reviews
	 of drafts.  Galvin said that AD has said that human rights reviews are individual
	 contributions and that they don't have special status coming from hrpc.  Should 
	 be treated as any other contributions.
	-Gould: reviewed feedback received; identified normative language that required
	 the VSP to store the data that was verified, which was removed.  Was changed
	 to make clear that the verification code extension is a pointer to verification
	 and that relevant laws and regulations should be 
	-Gurshabad Grover:  Disagreed that it was not the only item; there are some pending
	 issues.  First one is:  what is the intended document status?  Depends on the 
	 number of use cases.  If limited, has the option of documenting separately (see
	 RFC 3735).
	-Gould:  this is generic and broadly applicable.  Most recent update has other usage
	 information
	-Scott Hollenbeck:  Extension describes that they may be documented in various
	 ways, but nothing is a mandate.  And there is nothing about broad applicability
	 I've seen nothing to suggest deviation from that path
	-Gurshabad: Depends on the amount of extension and the amount of general interest.
	-Galvin:  Asked what are the additional technical concerns
	-Gurshabad: There is a grace period: Draft does not define the behavior if the
	 verification service provider does not respond
	-Gould:  the grace period is not associated with the VSP... it's associated with
	 the registry policy.
	-Galvin:  Does it say that the action is based on server policy?
	-Gould:  We can double-check
	-Gurshabad:  The integrity of the object when it goes to the VSP.  when the VSP
	 sends the verification code back, the VSP should not alter the object
	-after some discussion... will bring it to the list
	-Gurshabad:  The effects should be considered; perhaps add a human rights area
	 consideration to the document
	-Galvin: We've handled the discussion of technical issues; regarding the human
	 rights item; 
	-Gurshabad: disagreed with the conclusion around human rights considerations
	-Niels ten Oever: Discussion has been going for a while; happy that we're engaging
	 in the process; think that proposed standard goes a bit far; 
	-Hollenbeck: Comparing this to security considerations; we have docs representing
	 IETF consensus around security considerations and IANA considerations.  We have
	 no such document around capturing human rights considerations.  I don't know
	 that this doc should be taking place in this WG.  Should be taken up.
	-Ulrich Visser: It's not that much to document it.  I don't see
	 why we wouldn't do it.
	-Galvin:  Fair point, we should discuss on the list.  Should handle all the technical
	 items first.
	-ten Oever: After a doc is adopted by a WG, the right of change is handled by
	 the WG, not the author.  The implications of technology are not policy.
	 RFC 8280 has discussion on the writing of human rights considerations
	-Gould:  I've read 8280, I'm unqualified to incorporate 8280 as an input
	 I don't want this doc to be a guinea pig
	-Galvin:  it's up to this WG as a group to add any additional human rights
	 considerations as a group.  
	-Alex Mayrhofer:  Agreed that the doc is improved by the changes; and as an
	 author, it's hard to add another section.
	-Galvin:  We need to separate out the broader discussion about adopting human
	 rights considerations
	 

4.   New candidate documents for adopting: (Max 9 min per item)

   i.  Registration Data Access Protocol (RDAP) Reverse search capabilities (Mario 
       Loffredo)
       https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/

   ii. Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and 
       Paging (Mario Loffredo)
       https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/

Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-loffredo-rdap-reverse-search-and-rdap-sorting-and-paging-00

	-Mario Loffredo did the presentation.
	-Presentation covered both papers
	-first discussed sorting and paging
	-And then onto reverse search
	-Intermittent was some back-and-forth about whether or not reverse search was
	 permitted by GDPR
	-Wilhelm: commented that the next-gen RDS PDP has been closed down.  And also that
	 it is very early in RDAP implementations and these things have implementation
	 burden for contracted parties
	-Loffredo described an implementation approach that's used in dotIT; a controlled
	 approach to reverse search
	-Eduardo Alverez (ICANN): Would be good for this to have this start moving.  Should
	 seen as how this might build upon current whois capabilities
	-Galvin:  there are lots of discussions going on about RDAP rollout. Want to be
	 careful that we don't motivate work solely by what is needed by ICANN.  This is
	 a carry-over from original RDAP specification.  Given that this is early days,
	 we will have an opportunity to influence in both directions. 
	-Loffredo:  We are focused on requirements of ccTLDs


   iii.Login Security Extension for the Extensible Provisioning Protocol (EPP) (James 
       Gould)
       https://datatracker.ietf.org/doc/draft-gould-regext-login-security/

Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-gould-login-security-00

Galvin noted that the URL referenced in the agenda should actually be:
       https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/

	-Gould:  the login-security extension allows for longer passwords
	-Gould went through the slides, largely self-explanatory
	-Galvin:  Asked about a dependency on registry mapping
	-Gould:  there is one.  Not asking for the doc to be added to the WG at this time
	 waiting to get an IPR declaration handled for registry mapping
	(no comments or questions at the mic)


   iv. Extensible Provisioning Protocol (EPP) Unhandled Namespaces (James Gould)
       https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/

Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-regext-gould-unhandled-namespaces-00

	-Gould went through the slides
	-Mayrhofer asked a question about the location of the unhandled xml, which Gould
	 answered
	-Related that the key item is that it addresses that poll messages will not be
	 "poison" under this approach.
	-Visser: My understanding was that this was "not a problem"; 
	-Gould: This is an example of how it could be handled
	-Galvin:  I would offer that the poll message was an important item
	-Visser:  As a registry, we have two kinds of registrars: those that poll and those
	 that don't.  We've done non-backward-compatible changes and had no problems.
	-Gould:  We didn't have a good answer
	-Visser:  This is a technical solution to a policy problem.  We have contracts
	 that require registrars to understand EPP.
	-Galvin:  We have similar kinds of registrars; as a general registry service 
	 provider, you get a lot of mixing and matching.  Taking on the opportunity
	 to be well-behaved
	-Loffredo: How to parse the XML inside the extvalue?  But if you have a parser
	 that builds from the namespaces, the client should know
	-Gould:  Since it's put under the "value" it won't parse it. And haven't lost it



   v.  Registry Reporting Repository (Who??)
       https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

	-Galvin:  has been borne out of the ICANN technical operations group.  So 
	 registrars can get access to reports.
	-Gould:  Perhaps an approach that defines an approach for a report definition
	 as opposed to defining the exact reports
	-Mayrhofer:  I don't find this as work in our charter
	-Wilhelm:  Concerned that this document is focused on SFTP
	-Roger Carney:  Understanding these points, but the challenge is interoperability
	 and where should that happen.  Maybe a definition is a good approach.


   vi. Registry Mapping for the Extensible Provisioning Protocol (EPP) (Roger Carney
       https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/

	-Carney (no slides)
	-This is ongoing work; need to finalize an IPR issue before we bring it into
	 the group
	-Galvin:  there have been interim meetings for the design team working on this


5.   WG Adoption discussion and Milestone review. (10 min)

	-Galvin reviewed open milestones (see chair slides)
	-How many open docs should regext have?  Is 5 the right number?
	-Questions about the two open docs?  Should we keep them?  Should we discard them?
	-We will discuss this on the mailing list
	-Hollenbeck:  some concerns about a fixed number, things will come up (gave an example
	 of possible policy things at ICANN)
	-Carney:  similar, but not quite the same... the number is a good goal, but not all
	 docs are going to be created the same.  We might need to go to four to get some
	 better action.
	-Kal Feher: comment from Antoine:  why does your standard depend on ICANN?
	-Hollenbeck: It's more of a matter of efficiency
	-Gould:  Different drafts require different work
	-Carney:  Encourage Scott to push the draft forward (on federated identity)
	-Galvin: Understand the need for an exception process; expect that the AD would
	 be open to that.  However, it feels like something is going to get swapped out
	 if something is going to get swapped in.  Then our AD is going to want us to
	 be careful about unloading things.  Agree with Roger about putting forth that
	 identity document.  Four with a slot for an extra one seems better than five
	 with a slot for an extra one.

	Actions:
	1.  Restart the questions to the WG
	2.  Reach out on the list to the DNS operator folks the milestone document
	3.  Create a consolidated list of docs for 
	4.  Conduct a pollling 
	-Adam:  liked the 'goal and the limit'

 
6.   AOB

	-Hollenbeck:  Registry Operations Workshop, here in Bangkok, in May at 
	 the ICANN GDD Summit, encouraged participation and presentations.
	-Final call for blue sheet signing

Adjourned on time.

*****************************************