Skip to main content

Key Relay Mapping for the Extensible Provisioning Protocol
RFC 8063

Revision differences

Document history

Date Rev. By Action
2018-12-20
12 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays …
Received changes through RFC Editor sync (changed abstract to '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 RFC 5730.

This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.')
2017-02-14
12 (System)
Received changes through RFC Editor sync (created alias RFC 8063, changed abstract to 'This document describes an Extensible Provisioning Protocol (EPP) mapping for a …
Received changes through RFC Editor sync (created alias RFC 8063, changed abstract to '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 RFC 5730.', changed pages to 16, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-02-14, changed IESG state to RFC Published)
2017-02-14
12 (System) RFC published
2017-02-08
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-01-30
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-01-27
12 Henrik Levkowetz Added the appropriate states based on document history. It seems that states were lost when missing authors were added.
2017-01-26
12 (System) RFC Editor state changed to RFC-EDITOR
2017-01-26
12 Henrik Levkowetz Added missing authors
2017-01-17
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-12-15
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-12-15
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2016-12-15
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-12-12
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-12-06
12 (System) RFC Editor state changed to EDIT
2016-12-06
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-12-06
12 (System) Announcement was received by RFC Editor
2016-12-06
12 (System) IANA Action state changed to In Progress
2016-12-06
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2016-12-06
12 Amy Vezza IESG has approved the document
2016-12-06
12 Amy Vezza Closed "Approve" ballot
2016-12-06
12 Amy Vezza Ballot approval text was generated
2016-12-06
12 Amy Vezza IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2016-12-06
12 Amy Vezza Ballot writeup was changed
2016-12-06
12 Alissa Cooper Shepherding AD changed to Alissa Cooper
2016-12-05
12 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to Yes from No Objection
2016-12-02
12 Stephen Farrell
[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 …
[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?
2016-12-02
12 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2016-11-14
12 Antoin Verschuren Added to session: IETF-97: regext  Fri-0930
2016-11-10
12 Stephen Farrell
[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 …
[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.)
2016-11-10
12 Stephen Farrell
[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 …
[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?
2016-11-10
12 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2016-05-31
12 Rik Ribbers IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-05-31
12 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-12.txt
2016-05-20
11 Alexey Melnikov Waiting for Verisign to clarify IPR situation. Authors/WG can also respond to the second part of Stephen's DISCUSS.
2016-04-06
11 Amy Vezza Shepherding AD changed to Alexey Melnikov
2015-12-24
11 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2015-12-22
11 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2015-12-17
11 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2015-12-17
11 Spencer Dawkins [Ballot comment]
I also agree with the IPR section of Stephen's discuss.
2015-12-17
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-12-17
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-12-17
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-12-17
11 Brian Haberman [Ballot comment]
I support Stephen's DISCUSS.
2015-12-17
11 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-12-16
11 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2015-12-16
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-12-16
11 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-12-16
11 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-12-16
11 Alissa Cooper
[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 …
[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.
2015-12-16
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-12-15
11 Joel Jaeggli [Ballot comment]
Once Stephen's point is addressed I think this is fine with the editorials nit's in Tina TSOU's opsdir review already processed.
2015-12-15
11 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-12-15
11 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-12-15
11 Stephen Farrell
[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 …
[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.)
2015-12-15
11 Stephen Farrell
[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 …
[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?
2015-12-15
11 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-12-14
11 Robert Sparks Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks.
2015-12-14
11 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-12-12
11 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tina Tsou.
2015-12-10
11 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2015-12-10
11 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2015-12-07
11 Rik Ribbers IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2015-12-07
11 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-11.txt
2015-12-07
10 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-12-07
10 Barry Leiba Ballot has been issued
2015-12-07
10 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2015-12-07
10 Barry Leiba Created "Approve" ballot
2015-12-07
10 Barry Leiba Changed consensus to Yes from Unknown
2015-12-07
10 Barry Leiba Placed on agenda for telechat - 2015-12-17
2015-12-04
10 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-12-03
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-12-03
10 Sabrina Tanamal
(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 …
(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
2015-11-29
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2015-11-29
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2015-11-26
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Leif Johansson
2015-11-26
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Leif Johansson
2015-11-23
10 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2015-11-23
10 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2015-11-20
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-11-20
10 Amy Vezza
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 …
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/



2015-11-20
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-11-20
10 Barry Leiba Last call was requested
2015-11-20
10 Barry Leiba Last call announcement was generated
2015-11-20
10 Barry Leiba Ballot approval text was generated
2015-11-20
10 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2015-10-15
10 Barry Leiba
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 …
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.
2015-10-15
10 Barry Leiba Ballot writeup was changed
2015-10-15
10 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2015-10-15
10 Barry Leiba Ballot writeup was generated
2015-10-14
10 (System) Notify list changed from eppext-chairs@ietf.org, draft-ietf-eppext-keyrelay.shepherd@ietf.org, draft-ietf-eppext-keyrelay.ad@ietf.org, ulrich@wisser.se, draft-ietf-eppext-keyrelay@ietf.org to (None)
2015-10-10
10 James Galvin
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 …
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.



2015-10-10
10 James Galvin Responsible AD changed to Barry Leiba
2015-10-10
10 James Galvin IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2015-10-10
10 James Galvin IESG state changed to Publication Requested
2015-10-10
10 James Galvin IESG process started in state Publication Requested
2015-10-10
10 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-10.txt
2015-10-09
09 James Galvin IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2015-09-23
09 Ulrich Wisser Changed document writeup
2015-09-22
09 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-09.txt
2015-09-02
08 Ulrich Wisser Changed document writeup
2015-09-02
08 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-08.txt
2015-08-26
07 Ulrich Wisser Changed document writeup
2015-08-26
07 Ulrich Wisser Changed document writeup
2015-08-24
07 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-07.txt
2015-08-24
06 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-06.txt
2015-07-31
05 Ulrich Wisser Changed document writeup
2015-07-31
05 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-05.txt
2015-07-29
04 Antoin Verschuren Notification list changed to eppext-chairs@ietf.org, draft-ietf-eppext-keyrelay.shepherd@ietf.org, draft-ietf-eppext-keyrelay.ad@ietf.org, ulrich@wisser.se, draft-ietf-eppext-keyrelay@ietf.org from "Ulrich Wisser" <ulrich@wisser.se>
2015-07-29
04 Antoin Verschuren Notification list changed to "Ulrich Wisser" <ulrich@wisser.se>
2015-07-29
04 Antoin Verschuren Document shepherd changed to Ulrich Wisser
2015-07-24
04 James Galvin WGLC ends on 31 July 2015
2015-07-24
04 James Galvin IETF WG state changed to In WG Last Call from WG Document
2015-07-24
04 James Galvin Intended Status changed to Proposed Standard from None
2015-06-29
04 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-04.txt
2015-06-09
03 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-03.txt
2015-05-01
02 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-02.txt
2015-01-08
01 Rik Ribbers New version available: draft-ietf-eppext-keyrelay-01.txt
2014-07-21
(System) Posted related IPR disclosure: Verisign Inc.'s Statement about IPR related to draft-ietf-eppext-keyrelay
2014-03-06
00 Antoin Verschuren This document now replaces draft-gieben-epp-keyrelay instead of None
2014-01-19
00 Antoin Verschuren New version available: draft-ietf-eppext-keyrelay-00.txt