Many thanks to Rick Wilhelm for creating this summary of our meeting at
IETF103 in Bangkok.
Please review and if you have any questions or comments, please reply to
the list.
Thanks!
Antoin and Jim
Registration Protocols Extensions (REGEXT)
IETF 103, Bankok, Thailand, Agenda
Co-chairs: Jim Galvin, Antoin Verschuren
Mailinglist: [email protected]
*****************************************
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.
*****************************************
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
