Registry Data Escrow Specification
draft-ietf-regext-data-escrow-10

[Ballot comment]
Previous discuss comments:

I spotted some issues with the terminology and the description of the algorithm that I would like you to please address.

Section 2: Terminology

The definitions provided for "Differential" vs "Incremental" are the opposite to their standard meaning in backups.  The term definitions should be reversed to align with the common vernacular.  I.e. differential is the diff against the last full backup, incremental is the backup since the backup (of any type) was performed.


5.1.3.  Child  element

  The specification for each object to be escrowed MUST declare the
  identifier to be used to reference the object to be deleted.

An identifier is equally important in the add/update case as well to know which object needs to be updated.  I would suggest pulling this sentence out of this subsection and adding a new subsection under 5 to briefly describe the requirement on object identifiers and how they are used both in the delete and contents cases.


5.1.4.  Child  element

  When applying Incremental or Differential Deposits (when rebuilding
  the registry from data escrow deposits) the relative order of the
    elements is important, as is the relative order of the
    elements.  All the  elements MUST be applied
  first, in the order that they appear.  All the  elements
  MUST be applied next, in the order that they appear.

I think that the text for processing deposits would be better outside of section 5.1.4, since some of the text is referring to section 5.1.3, and isn't specific to the  element.

Why does the relative order of  elements matter?  Is this because of potential dependencies between the elements, if so, it would be useful if that was explicitly stated.  If not, then I don't understand why the order of deletes would matter.

Also, should there be a statement that an object SHOULD NOT exist multiple times (either in the  or  elements in a single deposit)?

  If an object is present in the  section of several deposits
  (e.g.  Full and Differential) the registry data from the latest
  deposit (as defined by the Timeline Watermark) SHOULD be used when
  rebuilding the registry.

This doesn't just apply to objects in the  section, but equally applies if the object is present in any  or  section.  I.e. the status of whether an object exists and its contents must be taken from the latest deposit.

Abstract:

  This document specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  However, the
  specification was designed to be independent of the underlying
  objects that are being escrowed, therefore it could be used for
  purposes other than domain name registries.

Propose tweaking the abstract text to something like:

  This document specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  The
  specification is designed to be independent of the underlying
  objects that are being escrowed and therefore it could also be used for
  purposes other than domain name registries.

1. Introduction:

  This document specifies a format for data escrow deposits independent
  of the objects being escrowed.  A specification is required for each
  type of registry/set of objects that is expected to be escrowed.

I suggest changing "A specification" to "An independent specification"

5.  Protocol Description
It might be useful to have a sentence that states that a formal XML schema is defined in section 6, and this section describes how those fields are used in the escrow procedure.


5.1.3.  Child  element
  This element SHOULD be present in deposits of type Incremental or
  Differential.  It contains the list of objects that were deleted
  since the base previous deposit.  Each object in this section SHALL
  contain an ID for the object deleted.

The SHOULD is not really right because an incremental or differential backup may contain no deletions.

This may be better stated as something like:

"For Incremental deposits, this element contains the list of objects that have been deleted since the previous deposit of any type.  For Differential deposits, this element contains the list of objects that have been deleted since the previous full deposit."


5.1.4.  Child  element

  This element of the deposit contains the objects in the deposit.  It
  SHOULD be present in all type of deposits.  It contains the data for
  the objects to be escrowed.  The actual objects have to be specified
  individually.

  In the case of Incremental or Differential Deposits, the objects
  indicate whether the object was added or modified after the base
  previous deposit.  In order to distinguish between one and the other,
  it will be sufficient to check existence of the referenced object in
  the previous deposit.

I don't think that this is a SHOULD because the update might not contain any new or updated objects.

Perhaps better stated as something like:

"For Full deposits this element contains all objects.  For Incremental deposits, this element contains the list of objects that have been created or updated since the previous deposit of any type.  For Differential deposits, this element contains the list of objects that have been created or updated since the previous full deposit."

[Ballot comment]
Roman took many of my ideas, so I support his DISCUSS position and his comments.

Version -08 resolves my DISCUSS point.  Thanks for making that change.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all necessary precautions" isn't very precise, while normally interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section, either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says that the type of the deposit is FULL, INCR or DIFF.  Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the XML schema in Section 6.1, I suggest a sentence be added making it clear that this document specifies version "1.0".

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That strikes me as MUST territory.

[Ballot discuss]
I support Benjamin's DISCUSS and Roman's last DISCUSS point. Regarding Section 11, there are often legal agreements in place that govern all sorts of things about how protocols transfer data between parties, but those are not the main thing to document in an RFC. Section 11 should be documenting the technical considerations for how to protect the data that may be escrowed.

[Ballot discuss]
I had originally included these just as comments, but since another AD brought up the same point I'd like to discuss them:

Section 5.1.3: "This element SHOULD be present in deposits of type Incremental or Differential."  This makes it sound like a deposit of those two types not using this element might be non-compliant.  I suggest instead "This element is only used in Incremental and Differential deposits."  (Or instead of "used", maybe "meaningful".)

Section 5.1.4: " It SHOULD be present in all type of deposits."  Same issue.  Maybe "It is valid for use in all types of deposits."

[Ballot comment]
Roman took many of my ideas, so I support his DISCUSS position and his comments.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all necessary precautions" isn't very precise, while normally interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section, either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says that the type of the deposit is FULL, INCR or DIFF.  Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the XML schema in Section 6.1, I suggest a sentence be added making it clear that this document specifies version "1.0".

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That strikes me as MUST territory.

[Ballot discuss]
Hi,

I spotted some issues with the terminology and the description of the algorithm that I would like you to please address.

Section 2: Terminology

The definitions provided for "Differential" vs "Incremental" are the opposite to their standard meaning in backups.  The term definitions should be reversed to align with the common vernacular.  I.e. differential is the diff against the last full backup, incremental is the backup since the backup (of any type) was performed.


5.1.3.  Child  element

  The specification for each object to be escrowed MUST declare the
  identifier to be used to reference the object to be deleted.

An identifier is equally important in the add/update case as well to know which object needs to be updated.  I would suggest pulling this sentence out of this subsection and adding a new subsection under 5 to briefly describe the requirement on object identifiers and how they are used both in the delete and contents cases.


5.1.4.  Child  element

  When applying Incremental or Differential Deposits (when rebuilding
  the registry from data escrow deposits) the relative order of the
    elements is important, as is the relative order of the
    elements.  All the  elements MUST be applied
  first, in the order that they appear.  All the  elements
  MUST be applied next, in the order that they appear.

I think that the text for processing deposits would be better outside of section 5.1.4, since some of the text is referring to section 5.1.3, and isn't specific to the  element.

Why does the relative order of  elements matter?  Is this because of potential dependencies between the elements, if so, it would be useful if that was explicitly stated.  If not, then I don't understand why the order of deletes would matter.

Also, should there be a statement that an object SHOULD NOT exist multiple times (either in the  or  elements in a single deposit)?

  If an object is present in the  section of several deposits
  (e.g.  Full and Differential) the registry data from the latest
  deposit (as defined by the Timeline Watermark) SHOULD be used when
  rebuilding the registry.

This doesn't just apply to objects in the  section, but equally applies if the object is present in any  or  section.  I.e. the status of whether an object exists and its contents must be taken from the latest deposit.

[Ballot comment]
Abstract:

  This document specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  However, the
  specification was designed to be independent of the underlying
  objects that are being escrowed, therefore it could be used for
  purposes other than domain name registries.

Propose tweaking the abstract text to something like:

  This document specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  The
  specification is designed to be independent of the underlying
  objects that are being escrowed and therefore it could also be used for
  purposes other than domain name registries.

1. Introduction:

  This document specifies a format for data escrow deposits independent
  of the objects being escrowed.  A specification is required for each
  type of registry/set of objects that is expected to be escrowed.

I suggest changing "A specification" to "An independent specification"

5.  Protocol Description
It might be useful to have a sentence that states that a formal XML schema is defined in section 6, and this section describes how those fields are used in the escrow procedure.


5.1.3.  Child  element
  This element SHOULD be present in deposits of type Incremental or
  Differential.  It contains the list of objects that were deleted
  since the base previous deposit.  Each object in this section SHALL
  contain an ID for the object deleted.

The SHOULD is not really right because an incremental or differential backup may contain no deletions.

This may be better stated as something like:

"For Incremental deposits, this element contains the list of objects that have been deleted since the previous deposit of any type.  For Differential deposits, this element contains the list of objects that have been deleted since the previous full deposit."


5.1.4.  Child  element

  This element of the deposit contains the objects in the deposit.  It
  SHOULD be present in all type of deposits.  It contains the data for
  the objects to be escrowed.  The actual objects have to be specified
  individually.

  In the case of Incremental or Differential Deposits, the objects
  indicate whether the object was added or modified after the base
  previous deposit.  In order to distinguish between one and the other,
  it will be sufficient to check existence of the referenced object in
  the previous deposit.

I don't think that this is a SHOULD because the update might not contain any new or updated objects.

Perhaps better stated as something like:

"For Full deposits this element contains all objects.  For Incremental deposits, this element contains the list of objects that have been created or updated since the previous deposit of any type.  For Differential deposits, this element contains the list of objects that have been created or updated since the previous full deposit."

[Ballot discuss]
Let's have a discussion about the overall plans for providing guidance
on mechanisms for (e.g.) cryptographic confidentiality and integrity
protection of data both in transit and at-rest,
authentication/authorization requirements, etc..  In particular, what
it's appropriate and necessary to include in this document vs. other
documents, and how to provide some specific general baseline guidance
that can be used in the absence of conflictinc scenario-specific
deployment requirements.  Some further details in the COMMENT section,
but in general, it seems like there should be some "off-the-shelf"
mechanism that can be used without a need for every deployment to do a
custom thing, for cases where there are not custom requirements.  It may
not need to be part of this document, but we should have a plan for
where it will be.

Also, it's not clear to me whether we expect escrow of
credentials/verifiers used to authenticate/authorize fourth parties that
perform operations (e.g., registrations) at the registry (see comment on
Section 3), and that is pretty important for knowing what security
requirements to place on the escrow'd data.

[Ballot comment]
I agree with Roman that the link to the charter is tenuous; perhaps this
is a "data format for files exchanged between registration entities that
needs extraction from EPP or RDAP", but it's not a perfect fit.

Section 1

  The goal of data escrow is higher resiliency of registration
  services, for the benefit of Internet users.  The beneficiaries of a
  registry are not just those registering information there, but all
  relying parties that need to identify the owners of objects.

Only relying parties that need to identify *owners* specifically (as
opposed to consuming other registered data)?

  In the context of domain name registries, registration data escrow is
  a requirement for generic top-level domains and some country code
  top-level domain managers are also currently escrowing data.  There
  is also a similar requirement for ICANN-accredited domain registrars.

Are there easy references for these requirements being requirements?

Section 2

  Watermark.  If the Timeline Watermark of an Incremental Deposit were
  to cover the Timeline Watermark of another (Incremental or
  Differential) Deposit since the last Full Deposit, the more recent
  deposit MUST contain all the transactions of the earlier deposit.

Do we define what it means for one Timeline Watermark to "cover" another?

Section 3

  Specifications covering the objects used by registration
  organizations shall identify the format and contents of the deposits
  a registry has to make, such that a different registry would be able
  to rebuild the registration services of the former, without its help,
  in a timely manner, with minimum disruption to its users.

Rebuilding registration *services* as opposed to just *operation* sounds
like it will require also escrowing credentials/credential verifiers
used to authenticate to the registration organization in order to make
use of such services.  Such credentials would of course need very
careful protection both in transit and at rest, in order to avoid
compromising the integrity of the primary operations of the current
registration organization.

  Given the requirement for confidentiality and the importance of
  accuracy of the information that is handled in order to offer
  registration services, parties using this specification shall define
  confidentiality and integrity mechanisms for handling the
  registration data.

Do we have any recommendations/examples of such mechanisms in the
pipeline?

  Specifications covering the objects used by registration
  organizations shall not include in the specification transient
  objects that can be recreated by the new registry, particularly those
  of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys.

I'm not sure this is going to be terribly helpful guidance for
non-domain-name data.  I am acutely aware that cryptographic (symmetric
and/or private) keys are not the only type of data that this could apply
to, but it is the only type that I know of a concise/precise description
for.  E.g., "cryptographic key material that is vital to the integerity
and/or security of operation of the registry and the systems that rely
on it but that is not vital to the continuity of operations (e.g.,
DNSSEC KSK/ZSK private keys)".

Also, I would assume that the authenticatoin credentials I mention above
would not qualify for this requirement, since they are not things that
can be recreated by the new registry.

  Details that are a matter of policy should be identified as such for
  the benefit of the implementers.

(For human consumption or machine consumption?)

Section 4

Could we maybe use the section title "Conventions Used in This
Document"?  "General Conventions" could be interpreted as intended for a
broader scope, though based on (e.g.) RFC 8748 I don't think that's the
intent.

Section 5

  registry.  The deposits are represented in XML.  Only the format of
  the objects deposited is defined, nothing is prescribed about the
  method used to transfer such deposits between the registry and the
  escrow agent or vice versa.

nit: comma splice.

Also, we said earlier that "parties using this specification shall
define confidentiality and integrity mechanisms for handling the
registration data" without, AFAICT, conditions on when that should be
done.  So in some sense we do prescribe properties of the method used
for transfer, if I'm reading that correctly.

Section 5.1.1

  A REQUIRED  element contains the data-time corresponding
  to the Timeline Watermark of the deposit.

I will offer a third opinion, that this was meant to be dateTime.

Section 5.1.2

I'm confused about the relationship between the  elements in the
and the objects in the  and  elements -- is
just a list of "here are all objects that this update
touchers", with the details in the other sections?

Section 5.1.4

  If an object is present in the  section of several deposits
  (e.g.  Full and Differential) the registry data from the latest
  deposit (as defined by the Timeline Watermark) SHOULD be used when
  rebuilding the registry.

Why is this not a MUST?

Section 6.1

Why is there a 13-character maximum for the deposit ID?
But client IDs range from 3 to 16 characters (which seems kind of short
as a maximum, especially if a registrar wants to use a domain name as an
identifier)?

   
   
     
       
       
     
   

I assume the  is there to give the overall structure that
subsequently defined s will adhere to?

I see the rrType defined but not used anywhere; is it still needed in
this document?

Section 10

  Authentication of the parties passing data escrow deposit files is
  also of the utmost importance.  The escrow agent SHOULD properly
  authenticate the identity of the registry before accepting data
  escrow deposits.  In a similar manner, the registry SHOULD
  authenticate the identity of the escrow agent before submitting any
  data.

I am failing to come up with a scenario in which these SHOULDs would be
violated; should they be MUSTs instead?  (I'd like for the "encrypting
the data" in the previous paragraph to be a MUST as well, but that case
is less clear-cut.)

  Additionally, the registry and the escrow agent SHOULD use integrity
  checking mechanisms to ensure the data transmitted is what the source
  intended.  Validation of the contents by the escrow agent is

It seems like if there are no integrity checks then the escrow mechanism
is not really fit for purpose -- can't this be MUST?

Section 11

  This specification defines a format that may be used to escrow
  personal data.  The process of data escrow is governed by a legal
  document agreed by the parties, and such legal document must regulate
  the particularities regarding the protection of personal data.

"Regulate the particularities" is an interesting phrase, as it merely
specifies that some restrictions be made, but nothing about the nature
of them.  Shouldn't we be saying something like "ensure that
privacy-sensitive and/or personal data receives appropriate protection"?

Section 14, 15, 16

Could we not reuse the same deposit-id for different examples?
(Also, using 20191017001 with a watermark date of 2019-10-18
midnight-UTC is perhaps unnecessary cognitive dissonance.)

Is it appropriate to use the urn:ietf:params:xml:ns:rdeObj[N] namespaces
in the examples, vs. a dedicated "example" namespace?

[Ballot comment]
Thank you for the work put into this document. I have appreciated the examples of section 13.

I am also support the "data at rest encryption" as noted by Roman's DISCUSS as by Carlos in his INTDIR review.

Please address the issues found by Carlos during the INTDIR review:
https://mailarchive.ietf.org/arch/msg/int-dir/8BJEPavSHK0BYTe_f1W1BFG-fwA

Finally, for my own curiosity, is there a reason why using the word "watermark" rather than "timestamp" ?

Regards,

-éric

[Ballot discuss]
Section 8.

As this document will be an IETF proposed standard I think the registrant for the RDE and XML schema shall follow the recommendation in RFC 3688:

  Registrant Contact
      The individual/organization that is the registration contact for
      the component being registered.  Ideally, this will be the name
      and pertinent physical and network contact information.  In the
      case of IETF developed standards, the Registrant will be the IESG.

So please change that registrant to follow the above. The purpose of this is to prevent any issues over who has change control of the registered entries.

[Ballot comment]
{No Objection once others are happy}

[nits]

S5.1

* Is the universe of "id"s within which "id" must be unique the set of all
  "id"s from a given depositor?  Or do the "id"s need to be globally unique?

S5.1.1

* "data-time" or perhaps "date-time"?

S5.1.4

* I wonder if swapping the order of the last two paragraphs makes sense.

[Ballot comment]
Roman took many of my ideas, so I support his DISCUSS position and his comments.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all necessary precautions" isn't very precise, while normally interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section, either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says that the type of the deposit is FULL, INCR or DIFF.  Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the XML schema in Section 6.1, I suggest a sentence be added making it clear that this document specifies version "1.0".

Section 5.1.3: "This element SHOULD be present in deposits of type Incremental or Differential."  This makes it sound like a deposit of those two types not using this element might be non-compliant.  I suggest instead "This element is only used in Incremental and Differential deposits."  (Or instead of "used", maybe "meaningful".)

Section 5.1.4: " It SHOULD be present in all type of deposits."  Same issue.  Maybe "It is valid for use in all types of deposits."

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That strikes me as MUST territory.

[Ballot comment]
[comments under development, not an official position yet]

Roman took many of my ideas, so I support his DISCUSS position and his comments.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all necessary precautions" isn't very precise, while normally interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section, either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says that the type of the deposit is FULL, INCR or DIFF.  Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the XML schema in Section 6.1, I suggest a sentence be added making it clear that this document specifies version "1.0".

Section 5.1.3: "This element SHOULD be present in deposits of type Incremental or Differential."  This makes it sound like a deposit of those two types not using this element might be non-compliant.  I suggest instead "This element is only used in Incremental and Differential deposits."  (Or instead of "used", maybe "meaningful".)

Section 5.1.4: " It SHOULD be present in all type of deposits."  Same issue.  Maybe "It is valid for use in all types of deposits."

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That strikes me as MUST territory.

I have moved this until after the AD changeover, as there are more urgent docs to get through before the outgoing ADs leave in 2 weeks.

[Ballot discuss]
** Section 6.1.  Please provide a normative reference to XML Schema.

** Section 6.1. The schema defines types “clIDType” and “rrType” but their use isn’t explained in the text and they don’t appear to be used in the definition of .

** Section 11.  Was a requirement to secure the deposit data at rest considered?  The text here suggests that such details needed to be worked out individually.  However, Section 9 notes that the whole deposit is likely to be confidential.  It would seem best practice to store such sensitive information encrypted.

[Ballot comment]
** I didn’t follow how this draft fits with EPP or RDAP per the REGEXT charter (and neither of these protocols are references).

** Section 5.1. @resend.  How does the registry know the escrow deposit failed to increment this attribute and resend?

** Section 5.1.2.  .  The schema indicates that this should be set to 1.0, but this isn’t said in the text.  How should an implementation process a version number it doesn’t recognize?

** Section 10.  Per “As such, the registry transmitting the data to the escrow agent _should_ take all the necessary precautions …”, why isn’t this a “_MUST_ take all necessary precautions …”?  Under what circumstances would transport security not be desirable?

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

The IANA Functions Operator has completed its review of draft-ietf-regext-data-escrow-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

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

a single, new namespace will be registered as follows:

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the schema registry also on the IETF XML Registry page located at:

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

a single, new schema will be registered as follows:

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

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-28):

From: The IESG
To: IETF-Announce
CC: jgould@verisign.com, regext-chairs@ietf.org, James Gould , barryleiba@gmail.com, regext@ietf.org, draft-ietf-regext-data-escrow@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Registry Data Escrow Specification) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Registry Data Escrow
Specification'
  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
last-call@ietf.org mailing lists by 2020-02-28. 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 specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  However, the
  specification was designed to be independent of the underlying
  objects that are being escrowed, therefore it could be used for
  purposes other than domain name registries.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/ballot/


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

Technical Summary

This document describes the Registry Data Escrow Specification
(draft-ietf-regext-data-escrow) that specifies the format and contents
of data escrow deposits primarily for domain name registries.

Working Group Summary

draft-ietf-regext-data-escrow is on standards track.  This document
specifies a format for data escrow deposits independent of the objects
being escrowed.  A specification is required for each type of
registry/set of objects that is expected to be escrowed, such as
draft-ietf-regext-dnrd-objects-mapping for Domain Name Registration
Data (DNRD).

Document Quality

This document has been widely discussed on the ire mailing list,
has been broadly implemented by members
of the domain name industry (registries and data escrow agents), and
has been adopted and discussed in the regext working group.
The author has addressed all comments and many
changes have been incorporated in the document.

The ICANN Base Registry Agreement requires registries, data escrow agents,
and ICANN to implement the document.  ICANN receives daily notifications
from data from data escrow agents confirming that more than 1,200 gTLDs
are sending deposits that comply with this document.  ICANN receives on a
weekly basis per gTLD, from more than 1,200 gTLD registries, a
Bulk Registration Data Access file that also complies with this document.
In addition, ICANN is aware of Registry Service Provider transitions using
data files that conform to this document.


Personnel

Document shepherd is James Gould, jgould@verisign.com
Area Director is Barry Leiba, barryleiba@computer.org

Shepherd Comments

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.  Example
"urn:ietf:params:xml:ns:rdeObj1-1.0" and "urn:ietf:params:xml:ns:rdeObj2-1.0"
XML schemas were created to fully validate the examples using a
validating XML parser.

The author has confirmed following BCP78 and BCP79 in the document header.

No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML
Registry for the XML namespace and XML schema for this document.

All normative and informative references have been verified.

After carefully reviewing the ire, the non-WG Internet Registration Escrow discussion
list (https://mailarchive.ietf.org/arch/browse/ire), and the regext working group
mailing lists, I found no objections for this document that were not resolved.
I believe that there is broad consensus for this document.

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

Technical Summary

This document describes the Registry Data Escrow Specification
(draft-ietf-regext-data-escrow) that specifies the format and contents
of data escrow deposits primarily for domain name registries.

Working Group Summary

draft-ietf-regext-data-escrow is on standards track.  This document
specifies a format for data escrow deposits independent of the objects
being escrowed.  A specification is required for each type of
registry/set of objects that is expected to be escrowed, such as
draft-ietf-regext-dnrd-objects-mapping for Domain Name Registration
Data (DNRD).

Document Quality

This document has been widely discussed on the ire mailing list,
has been broadly implemented by members
of the domain name industry (registries and data escrow agents), and
has been adopted and discussed in the regext working group.
The author has addressed all comments and many
changes have been incorporated in the document.

The ICANN Base Registry Agreement requires registries, data escrow agents,
and ICANN to implement the document.  ICANN receives daily notifications
from data from data escrow agents confirming that more than 1,200 gTLDs
are sending deposits that comply with this document.  ICANN receives on a
weekly basis per gTLD, from more than 1,200 gTLD registries, a
Bulk Registration Data Access file that also complies with this document.
In addition, ICANN is aware of Registry Service Provider transitions using
data files that conform to this document.


Personnel

Document shepherd is James Gould, jgould@verisign.com
Area Director is Barry Leiba, barryleiba@computer.org

Shepherd Comments

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.  Example
"urn:ietf:params:xml:ns:rdeObj1-1.0" and "urn:ietf:params:xml:ns:rdeObj2-1.0"
XML schemas were created to fully validate the examples using a
validating XML parser.

The author has confirmed following BCP78 and BCP79 in the document header.

No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML
Registry for the XML namespace and XML schema for this document.

All normative and informative references have been verified.

After carefully reviewing the ire, the non-WG Internet Registration Escrow discussion
list (https://mailarchive.ietf.org/arch/browse/ire), and the regext working group
mailing lists, I found no objections for this document that were not resolved.
I believe that there is broad consensus for this document.

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

Technical Summary

This document describes the Registry Data Escrow Specification
(draft-ietf-regext-data-escrow) that specifies the format and contents
of data escrow deposits primarily for domain name registries.

Working Group Summary

draft-ietf-regext-data-escrow is on standards track.  This document
specifies a format for data escrow deposits independent of the objects
being escrowed.  A specification is required for each type of
registry/set of objects that is expected to be escrowed, such as
draft-ietf-regext-dnrd-objects-mapping for Domain Name Registration
Data (DNRD).

Document Quality

This document has been widely discussed on the ire mailing list,
has been broadly implemented by members
of the domain name industry (registries and data escrow agents), and
has been adopted and discussed in the regext working group.
The author has addressed all comments and many
changes have been incorporated in the document.

The ICANN Base Registry Agreement requires registries, data escrow agents,
and ICANN to implement the document.  ICANN receives daily notifications
from data from data escrow agents confirming that more than 1,200 gTLDs
are sending deposits that comply with this document.  ICANN receives on a
weekly basis per gTLD, from more than 1,200 gTLD registries, a
Bulk Registration Data Access file that also complies with this document.
In addition, ICANN is aware of Registry Service Provider transitions using
data files that conform to this document.


Personnel

Document shepherd is James Gould, jgould@verisign.com
Area Director is Barry Leiba, barryleiba@computer.org

Shepherd Comments

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.  Example
"urn:ietf:params:xml:ns:rdeObj1-1.0" and "urn:ietf:params:xml:ns:rdeObj2-1.0"
XML schemas were created to fully validate the examples using a
validating XML parser.

The author has confirmed following BCP78 and BCP79 in the document header.

No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML
Registry for the XML namespace and XML schema for this document.

All normative and informative references have been verified.

After carefully reviewing the ire and the regext working group mailing lists,
I found no objections for this document that were not resolved.
I believe that there is broad consensus for this document.

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