Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping
draft-ietf-regext-epp-rdap-status-mapping-04

[Ballot comment]
Maybe it's obvious to everyone else, but what is the goal of these mappings? It would help to have a paragraph or two explaining that. (Or did I miss something?)

Are the mappings reversible?

-1, last paragraph: The MUST probably doesn't need a 2119 keyword. IIUC, it's a requirement on this draft, not on implementations.

[Ballot comment]
A few minor comments:

- I guess this doc should cite RFC5730 and RFC7482 (?) in the intro...?

- I would propose to directly put the link to the registation in the introduction instead of using a citation ([rdap-json-values]) because I initially didn't realize that this not a doc.

- And effectively you could even remove section 2 mostly or potentially even competely as all information are given (word-for-word) in the IANA consideration section.

And thanks for the nice in in-depth shepherd write-up!

[Ballot comment]
A few minor comments:

- I guess this doc should cite RFC5730 and RFC7482 (?) in the intro...?

- I would propose to directly put the link to the registation in the introduction instead of using a citation ([rdap-json-values]) because I initially didn't realize that this not a doc.

- And effectively you could even remove section 2 mostly or potentially even competely as all information are given (word-for-word) in the IANA consideration section.

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

The IANA Services Operator has completed its review of draft-ietf-regext-epp-rdap-status-mapping-01.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that we have only one action to complete.

In the RDAP JSON Values registry located at:

https://www.iana.org/assignments/rdap-json-values/

sixteen new JSON values are to be registered as follows:

Value: add period
Type: status
Description: For DNR that indicates if the object is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: auto renew period
Type: status
Description: For DNR that indicates if the object is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the auto renewal.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: client delete prohibited
Type: status
Description: For DNR that indicates the client requested that requests to delete the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: client hold
Type: status
Description: For DNR that indicates the client requested that the DNS delegation information MUST NOT be published for the object.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: client renew prohibited
Type: status
Description: For DNR that indicates the client requested that requests to renew the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: client transfer prohibited
Type: status
Description: For DNR that indicates the client requested that requests to transfer the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: client update prohibited
Type: status
Description: For DNR that indicates the client requested that requests to update the object (other than to remove this status) MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: pending restore
Type: status
Description: For DNR that indicates a object is in the process of being restored after being in the redemptionPeriod state.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: redemption period
Type: status
Description: For DNR that indicates a delete has been received, but the object has not yet been purged because an opportunity exists to restore the object and abort the deletion process.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: renew period
Type: status
Description: For DNR that indicates if the object is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: server delete prohibited
Type: status
Description: For DNR that indicates the server set the status so that requests to delete the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: server renew prohibited
Type: status
Description: For DNR that indicates the server set the status so that requests to renew the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: server transfer prohibited
Type: status
Description: For DNR that indicates the server set the status so that requests to transfer the object MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: server update prohibited
Type: status
Description: For DNR that indicates the server set the status so that requests to update the object (other than to remove this status) MUST be rejected.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: server hold
Type: status
Description: For DNR that indicates the server set the status so that DNS delegation information MUST NOT be published for the object.
Registrant: [IESG]
Reference: [ RFC-to-be ]

Value: transfer period
Type: status
Description: For DNR that indicates if the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
Registrant: [IESG]
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.

We understand that this is the only action required to be completed upon approval of this document.

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 Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: regext-chairs@ietf.org, "Ulrich Wisser" , draft-ietf-regext-epp-rdap-status-mapping@ietf.org, ulrich@wisser.se, alexey.melnikov@isode.com, regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping) to Proposed Standard


The IESG has received a request from the Registration Protocols
Extensions WG (regext) to consider the following document:
- 'Extensible Provisioning Protocol (EPP) and Registration Data Access
  Protocol (RDAP) Status Mapping'
  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 2016-10-10. 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 the mapping of the Extensible Provisioning
  Protocol (EPP) statuses with the statuses registered for use in the
  Registration Data Access Protocol (RDAP).  This document identifies
  gaps in the mapping, and registers RDAP statuses to fill the gaps to
  ensure that all of the EPP RFC statuses are supported in RDAP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-rdap-status-mapping/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-rdap-status-mapping/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-gould-epp-rdap-status-mapping: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (None - )
Note that some of these references may already be listed in the acceptable Downref Registry.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

draft-ietf-regext-epp-rdap-status-mapping is on standards track.  This
document proposes new RDAP status values, motivated by EPP status
values, to be added to the original set of RDAP status values defined
in RFC7483, which is a proposed standard.

The working group agreed that some EPP statuses were missing in the
RDAP status list and after discussion there is broad agreement in the
WG for this document.

Document Quality

ICANN technical staff were a part of the discussions and review of
this document.  They will seek to get these new RDAP statuses to
become part of the implementation requirements for the ICANN gTLD
program.

Verisign, SIDN and NIC.AT are currently working on implementations.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

Shepherd Comments

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

draft-ietf-regext-epp-rdap-status-mapping is on standards track.  This
document proposes new RDAP status values, motivated by EPP status
values, to be added to the original set of RDAP status values defined
in RFC7483, which is a proposed standard.

The working group agreed that some EPP statuses were missing in the
RDAP status list and after discussion there is broad agreement in the
WG for this document.

Document Quality

ICANN technical staff were a part of the discussions and review of
this document.  They will seek to get these new RDAP statuses to
become part of the implementation requirements for the ICANN gTLD
program.

Verisign, SIDN and NIC.AT are currently working on implementations.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

Shepherd Comments

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

draft-ietf-regext-epp-rdap-status-mapping is on standards track.  This
document proposes new RDAP status values, motivated by EPP status
values, to be added to the original set of RDAP status values defined
in RFC7483, which is a proposed standard.

The working group agreed that some EPP statuses were missing in the
RDAP status list and after discussion there is broad agreement in the
WG for this document.

Document Quality

ICANN technical staff were a part of the discussions and review of
this document.  They will seek to get these new RDAP statuses to
become part of the implementation requirements for the ICANN gTLD
program.

Verisign and NIC.AT are currently working on implementations.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

Shepherd Comments

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

draft-ietf-regext-epp-rdap-status-mapping is on standards track.
Standards track is indicated in the document header.  This has been
chosen, because this documents proposes new rdap status values.
The original set of rdap status values is defined in RFC7483 which
is a proposed standard.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

draft-ietf-regext-epp-rdap-status-mapping is on standards track.  This
document proposes new RDAP status values, motivated by EPP status
values, to be added to the original set of RDAP status values defined
in RFC7483, which is a proposed standard.

The working group agreed that some EPP statuses were missing in the
RDAP status list and after discussion there is broad agreement in the
WG for this document.

Document Quality

ICANN technical staff were a part of the discussions and review of
this document.  They will seek to get these new RDAP statuses to
become part of the implementation requirements for the ICANN gTLD
program.

Verisign and NIC.AT are currently working on implementations.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

draft-ietf-regext-epp-rdap-status-mapping is on standards track.
Standards track is indicated in the document header.  This has been
chosen, because this documents proposes new rdap status values.
The original set of rdap status values is defined in RFC7483 which
is a proposed standard.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

draft-ietf-regext-epp-rdap-status-mapping is on standards track.  This
document proposes new RDAP status values, motivated by EPP status
values, to be added to the original set of RDAP status values defined
in RFC7483, which is a proposed standard.

The working group agreed that some EPP statuses were missing in the
RDAP status list and after discussion there is broad agreement in the
WG for this document.

Document Quality

ICANN technical staff were a part of the discussions and review of
this document.  They will seek to get these new RDAP statuses to
become part of the implementation requirements for the ICANN gTLD
program.



Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

draft-ietf-regext-epp-rdap-status-mapping is on standards track.
Standards track is indicated in the document header.  This has been
chosen, because this documents proposes new rdap status values.
The original set of rdap status values is defined in RFC7483 which
is a proposed standard.

Technical Summary

This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP).  This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

The working group agreed that some EPP statuses were missing in the
RDAP status list. There were no arguments about the document at all.
Broad agreement in the WG for this document.

Document Quality

These new RDAP statuses will be part of the implementation requirements
for the ICANN new gTLD program.


Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732,
RFC5733 and RFC3915 have been included in this list. And the IANA considerations
sections fulfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.

draft-ietf-regext-epp-rdap-status-mapping is on standards track.
Standards track is indicated in the document header.  This has been choosen, because this documents proposes new rdap status values. The original set of rdap status values is defined in RFC7483 which is a proposed standard.

Technical Summary

This document describes the mapping of the Extensible Provisioning
  Protocol (EPP) statuses with the statuses registered for use in the
  Registration Data Access Protocol (RDAP).  This document identifies
  gaps in the mapping, and registers RDAP statuses to fill the gaps to
  ensure that all of the EPP RFC statuses are supported in RDAP

Working Group Summary

The working group agreed that some EPP statuses were missing in the RDAP staus list.
James volonteered to write the document. There were no arguments about the document at all. Broad agreement in the WG for this document.

Document Quality

These new RDAP statuses will be part of the implementation requirements for the ICANN new gTLD program.


Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

As document shepherd I have verified that all EPP statuses from RFC5731, RFC5732, RFC5733 and RFC3915 have been included in this list. And the IANA considerations sections fullfills the requirements for inscription mentioned in RFC7483 section 10.2.

As document shepherd I believe this document is ready for publication.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR diclosures have been submitted for this document.

After carefully reviewing the mailingslists of the regext, eppext and provreg working groups I have found no objections to this document. From IETF meetings I recall broad consensus that this document is ready for publication.

There are no informative references. All normative references have been verified.