Key Relay Mapping for the Extensible Provisioning Protocol
draft-ietf-eppext-keyrelay-12

[Ballot comment]

Thanks for confirming that the WG are ok with the IPR declaration.

OLD COMMENTS and cleared-DISCUSS point below. (There's
no need to read beyond here:-)

(2) So I can see at least two ways in which this kind of thing can
be done and you don't clearly say which this supports. Option (a)
would be for the gaining DNS operator to provide new public keys
to the losing operator for inclusion before a transfer so that
continuity is maintained during the transfer. Option (b) would be
where the KSK private material is not known by either
operator, but e.g. by the registrant. In the case of option (b)
the DNSKEY would be transferred from the losing to the gaining DNS
operator. (And the arrow in Figure 1 would be in the other
direction.) I think you need to be clear about which of these
cases is actually being supported and about the overall sequence
of events needed. (If you tell me that you really want to do
whatever is in draft-koch, then that's fine but then this draft is
probably premature and draft-koch would need to be a normative
ref.)

- I think I'm missing an overview of EPP here. The intro could
maybe do with a short para, and/or a pointer to something general.
(Ah, I get it in section 3 - the ref to 5730 might be better in
the intro.)

- general: I think it'd be better to talk about public key values
and not "key material" as the latter is often used to describe
secret/private values which aren't at issue here. (Or else
I'm mis-reading stuff:-)

- nit, p8: s/previously send/previously sent/

- Section 6: I'm surprised that you don't recommend or even note
that the gaining registrar/dns operator should be able to check
that the DNSKEY value it sees in XML is or is not the same as one
that is published in the DNS and verifiable there. Wouldn't that
kind of cross check be useful?

[Ballot discuss]

(1) The IPR declaration says that license terms will be available
"later." As things stand, I don't understand how the WG can have
made an informed decision in that case. I looked at the archive
and saw essentially no discussion, other than the announcement. I
also looked at the application and it's not crystal clear to me at
least that none of the claims are relevant. The shepherd write-up
also doesn't help me, but of course there may have been discussion
in a f2f meeting that is documented in minutes or something - I've
not checked for such, or I may have missed out on some list
traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not
how can WG participants have rationally considered an IPR
declaration if the licensing information will only arrive "later"
after the document is approved to become an RFC?  (Note: If I am
explicitly told that this was considered and participants were ok
with the declaration even as-is, then I'll clear.)

[Ballot comment]

OLD COMMENTS and cleared-DISCUSS point below. (There's
no need to read beyond here:-)

(2) So I can see at least two ways in which this kind of thing can
be done and you don't clearly say which this supports. Option (a)
would be for the gaining DNS operator to provide new public keys
to the losing operator for inclusion before a transfer so that
continuity is maintained during the transfer. Option (b) would be
where the KSK private material is not known by either
operator, but e.g. by the registrant. In the case of option (b)
the DNSKEY would be transferred from the losing to the gaining DNS
operator. (And the arrow in Figure 1 would be in the other
direction.) I think you need to be clear about which of these
cases is actually being supported and about the overall sequence
of events needed. (If you tell me that you really want to do
whatever is in draft-koch, then that's fine but then this draft is
probably premature and draft-koch would need to be a normative
ref.)

- I think I'm missing an overview of EPP here. The intro could
maybe do with a short para, and/or a pointer to something general.
(Ah, I get it in section 3 - the ref to 5730 might be better in
the intro.)

- general: I think it'd be better to talk about public key values
and not "key material" as the latter is often used to describe
secret/private values which aren't at issue here. (Or else
I'm mis-reading stuff:-)

- nit, p8: s/previously send/previously sent/

- Section 6: I'm surprised that you don't recommend or even note
that the gaining registrar/dns operator should be able to check
that the DNSKEY value it sees in XML is or is not the same as one
that is published in the DNS and verifiable there. Wouldn't that
kind of cross check be useful?

[Ballot comment]
Agree with Stephen and looking forward to the IPR declaration being updated.

In Section 1.2:

"The registry SHOULD have certain policies in place that require the
  losing DNS operator to cooperate with this transaction, however this
  is beyond this document."

This seems like a misplaced normative SHOULD.

[Ballot discuss]

(1) The IPR declaration says that license terms will be available
"later." As things stand, I don't understand how the WG can have
made an informed decision in that case. I looked at the archive
and saw essentially no discussion, other than the announcement. I
also looked at the application and it's not crystal clear to me at
least that none of the claims are relevant. The shepherd write-up
also doesn't help me, but of course there may have been discussion
in a f2f meeting that is documented in minutes or something - I've
not checked for such, or I may have missed out on some list
traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not
how can WG participants have rationally considered an IPR
declaration if the licensing information will only arrive "later"
after the document is approved to become an RFC?  (Note: If I am
explicitly told that this was considered and participants were ok
with the declaration even as-is, then I'll clear.)

(2) So I can see at least two ways in which this kind of thing can
be done and you don't clearly say which this supports. Option (a)
would be for the gaining DNS operator to provide new public keys
to the losing operator for inclusion before a transfer so that
continuity is maintained during the transfer. Option (b) would be
where the KSK private material is not known by either
operator, but e.g. by the registrant. In the case of option (b)
the DNSKEY would be transferred from the losing to the gaining DNS
operator. (And the arrow in Figure 1 would be in the other
direction.) I think you need to be clear about which of these
cases is actually being supported and about the overall sequence
of events needed. (If you tell me that you really want to do
whatever is in draft-koch, then that's fine but then this draft is
probably premature and draft-koch would need to be a normative
ref.)

[Ballot comment]

- I think I'm missing an overview of EPP here. The intro could
maybe do with a short para, and/or a pointer to something general.
(Ah, I get it in section 3 - the ref to 5730 might be better in
the intro.)

- general: I think it'd be better to talk about public key values
and not "key material" as the latter is often used to describe
secret/private values which aren't at issue here. (Or else
I'm mis-reading stuff:-)

- nit, p8: s/previously send/previously sent/

- Section 6: I'm surprised that you don't recommend or even note
that the gaining registrar/dns operator should be able to check
that the DNSKEY value it sees in XML is or is not the same as one
that is published in the DNS and verifiable there. Wouldn't that
kind of cross check be useful?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-eppext-keyrelay-10.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the ns section of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

a new registration will be added as follows:

ID: keyrelay-1.0
URI: urn:ietf:params:xml:ns:keyrelay-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema section of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

a new registration has been requested by the authors.

IANA QUESTION --> The URI provided by the authors in section 5.2 of the current draft is:

urn:ietf:params:xml:ns:keyrelay-1.0

IANA wonders if this might be a typo and that the URI should really be:

urn:ietf:params:xml:schema:keyrelay-1.0

If so, IANA understands the request in section 5.2 to be to add the following registration:

ID: keyrelay-1.0
URI: urn:ietf:params:xml:schema:keyrelay-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

If not, could the authors confirm the correct URI for the request in section 5.2?

This request also requires Expert Review as defined by RFC 5226. We will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

http://www.iana.org/assignments/epp-extensions/

a new extension will be registered as follows:

Name of Extension: "Key Relay Mapping for the Extensible Provisioning Protocol"
Document status: Standards Track
Reference: [ RFC-to-be ]
Registrant Name and Email Address: IESG, iesg@ietf.org
TLDs: Any
IPR Disclosure: https://datatracker.ietf.org/ipr/2393/
Status: Active
Notes: None

This request also requires Expert Review as defined by RFC 5226. We will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

IANA will not be able to complete the registry actions for this document until these issues have been resolved.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: eppext-chairs@ietf.org, ulrich@wisser.se, draft-ietf-eppext-keyrelay@ietf.org, barryleiba@gmail.com, eppext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Key Relay Mapping for the Extensible Provisioning Protocol) to Proposed Standard


The IESG has received a request from the Extensible Provisioning Protocol
Extensions WG (eppext) to consider the following document:
- 'Key Relay Mapping for the Extensible Provisioning Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes an Extensible Provisioning Protocol (EPP)
  mapping for a key relay object that relays DNSSEC key material
  between EPP clients using the poll queue defined in RFC5730.

  This key relay mapping will help facilitate changing the DNS operator
  of a domain while keeping the DNSSEC chain of trust intact.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2393/

1. Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
mapping for a key relay object that relays DNSSEC key material between
EPP clients using the poll queue defined in RFC5730. This key relay
mapping will help facilitate changing the DNS operator of a domain while
keeping the DNSSEC chain of trust intact.

This document is submitted for consideration as a Proposed Standard.
Ulrich Wisser is the Document Shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

When first introduced this document didn't get much attention. After the
Honolulu meeting the discussions started in earnest. The most
controversial question has been the introduction of a new "relay"
command. At last the working group decided that a simple object that is
managed by the standard EPP commands would be the way to go. At the
meeting in Prague several attendees indicated that they will implement
the extension.

The Document Shepherd did a thorough editorial and technical review of
the document, and resolved any issues brought up during WGLC. The
Document Shepherd does not have any concerns about the depth or breath
of the reviews.

3. IPR
Verisign Inc. has filed an IPR disclosing their patent on "Transfer of
DNSSEC Domains, US Patent Application No. :13/078,643". The working
group has not regarded this as a major problem.

4. Other

All EPP XML examples have been validated against the XML schema provided
in the draft by the Document Shepherd.

This document requests IANA to register a new XML namespace URI and the
XML schema for the namespace definitions. Additionally it requests IANA
to insert the document in the EPP Extension Registry.

This document is submitted for consideration as a Proposed Standard.

Technical Summary
This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC5730.
This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.

Working Group Summary

When first introduced this document didn't get much attention. After the Honolulu meeting the discussions started in earnest. The most controversial question has been the introduction of a new "relay" command. At last the working group decided that a simple object that is managed by the standard EPP commands would be the way to go. At the meeting in Prague several attendees indicated that they will implement the extension.

Document Quality

The Document Shepherd did a thorough editorial and technical review
of the document, and resolved any issues brought up during WGLC.

The Document Shepherd does not have any concerns about the depth
or breath of the reviews.

This document requests IANA to register a new XML namespace URI and the XML schema for the namespace definitions. Additionally it requests IANA to insert the document in the EPP Extension Registry.

IPR
Verisign Inc. has filed an IPR disclosing their patent on "Transfer of DNSSEC Domains, US Patent Application No. :13/078,643".
The working group has not regarded this as a major problem.

XML Validation
All EPP XML examples have been validated against the XML schema provided in the draft by the Document Shepherd.

Personnel

Ulrich Wisser is the Document Shepherd
Barry Leiba is the responsible Area Director.