Skip to main content

Registry Data Escrow Specification
RFC 8909

Revision differences

Document history

Date Rev. By Action
2020-11-17
10 (System)
Received changes through RFC Editor sync (created alias RFC 8909, changed abstract to 'This document specifies the format and contents of data escrow deposits …
Received changes through RFC Editor sync (created alias RFC 8909, changed abstract to '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.', changed pages to 16, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-11-17, changed IESG state to RFC Published)
2020-11-17
10 (System) RFC published
2020-11-03
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-10-26
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-08-19
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-08-07
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-08-07
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-08-07
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-08-06
10 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2020-08-06
10 Tero Kivinen Assignment of request for Last Call review by SECDIR to John Bradley was marked no-response
2020-08-03
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-07-30
10 (System) RFC Editor state changed to EDIT
2020-07-30
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-07-30
10 (System) Announcement was received by RFC Editor
2020-07-30
10 (System) IANA Action state changed to In Progress
2020-07-30
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-07-30
10 Amy Vezza IESG has approved the document
2020-07-30
10 Amy Vezza Closed "Approve" ballot
2020-07-30
10 Amy Vezza Ballot approval text was generated
2020-07-30
10 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-07-28
10 Alissa Cooper [Ballot comment]
Thanks for addressing my DISCUSS.
2020-07-28
10 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2020-06-01
10 Benjamin Kaduk [Ballot comment]
Thank you for the discussion and updates in response to my discuss points!
2020-06-01
10 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-06-01
10 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-10.txt
2020-06-01
10 (System) New version approved
2020-06-01
10 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-06-01
10 Gustavo Lozano Uploaded new revision
2020-05-27
09 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2020-05-13
09 Robert Wilton
[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 …
[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."
2020-05-13
09 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2020-05-13
09 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSS and COMMENT feedback.
2020-05-13
09 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-05-12
09 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-09.txt
2020-05-12
09 (System) New version approved
2020-05-12
09 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-05-12
09 Gustavo Lozano Uploaded new revision
2020-04-29
08 Magnus Westerlund [Ballot comment]
Thanks for addressing my discuss.
2020-04-29
08 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2020-04-28
08 Murray Kucherawy
[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 …
[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.
2020-04-28
08 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2020-04-28
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-04-28
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-04-28
08 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-08.txt
2020-04-28
08 (System) New version approved
2020-04-28
08 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-04-28
08 Gustavo Lozano Uploaded new revision
2020-04-09
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-04-09
07 Alissa Cooper
[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 …
[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.
2020-04-09
07 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2020-04-09
07 Michelle Cotton IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-04-08
07 Murray Kucherawy
[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 …
[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."
2020-04-08
07 Murray Kucherawy
[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 …
[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.
2020-04-08
07 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to Discuss from No Objection
2020-04-08
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-08
07 Robert Wilton
[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 …
[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.
2020-04-08
07 Robert Wilton
[Ballot comment]
Abstract:

  This document specifies the format and contents of data escrow
  deposits targeted primarily for domain name registries.  However, the
  …
[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."
2020-04-08
07 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2020-04-08
07 Benjamin Kaduk
[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 …
[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.
2020-04-08
07 Benjamin Kaduk
[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 …
[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?
2020-04-08
07 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-04-08
07 Éric Vyncke
[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 …
[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
2020-04-08
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-04-07
07 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-04-07
07 Alvaro Retana [Ballot comment]
I support Roman's DISCUSS point about protecting the data at rest.
2020-04-07
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-07
07 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-07.txt
2020-04-07
07 (System) New version approved
2020-04-07
07 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-04-07
07 Gustavo Lozano Uploaded new revision
2020-04-07
06 Magnus Westerlund
[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 …
[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.
2020-04-07
06 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-04-06
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-04-06
06 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-06.txt
2020-04-06
06 (System) New version approved
2020-04-06
06 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-04-06
06 Gustavo Lozano Uploaded new revision
2020-04-05
05 Erik Kline
[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 …
[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.
2020-04-05
05 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-03-30
05 Murray Kucherawy
[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 …
[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.
2020-03-30
05 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record
2020-03-28
05 Murray Kucherawy
[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. …
[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.
2020-03-28
05 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-27
05 Martin Duke [Ballot comment]
+1 to Roman’s concerns on encryption, but I’m happy when he’s happy.
2020-03-27
05 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-03-17
05 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-03-17
05 Carlos Bernardos Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Bernardos. Sent review to list.
2020-03-17
05 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2020-03-16
05 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Carlos Bernardos
2020-03-16
05 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Carlos Bernardos
2020-03-16
05 Éric Vyncke Requested Telechat review by INTDIR
2020-03-08
05 Barry Leiba
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 …
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.
2020-03-08
05 Barry Leiba Telechat date has been changed to 2020-04-09 from 2020-03-12
2020-03-08
05 Roman Danyliw
[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 …
[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.
2020-03-08
05 Roman Danyliw
[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). …
[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?
2020-03-08
05 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2020-03-02
05 Éric Vyncke Requested Telechat review by INTDIR
2020-02-29
05 Susan Hares Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list.
2020-02-28
05 Barry Leiba IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2020-02-28
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-28
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2020-02-28
05 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-05.txt
2020-02-28
05 (System) New version approved
2020-02-28
05 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-02-28
05 Gustavo Lozano Uploaded new revision
2020-02-28
04 Cindy Morgan Placed on agenda for telechat - 2020-03-12
2020-02-28
04 Barry Leiba A new I-D is needed for some very minor editorial comment from the designated expert.
2020-02-28
04 Barry Leiba IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup
2020-02-28
04 Barry Leiba Ballot has been issued
2020-02-28
04 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-02-28
04 Barry Leiba Created "Approve" ballot
2020-02-28
04 Barry Leiba Ballot writeup was changed
2020-02-28
04 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2020-02-28
04 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-02-28
04 Sabrina Tanamal
(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 …
(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
2020-02-28
04 Stewart Bryant Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2020-02-28
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-02-20
04 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2020-02-20
04 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2020-02-20
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2020-02-20
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2020-02-18
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2020-02-18
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2020-02-14
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-02-14
04 Amy Vezza
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, …
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.




2020-02-14
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-02-14
04 Amy Vezza Last call announcement was changed
2020-02-13
04 Barry Leiba Last call was requested
2020-02-13
04 Barry Leiba Last call announcement was generated
2020-02-13
04 Barry Leiba Ballot approval text was generated
2020-02-13
04 Barry Leiba Ballot writeup was generated
2020-02-13
04 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2020-01-17
04 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-01-17
04 James Galvin
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 …
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.
2020-01-17
04 James Galvin Responsible AD changed to Barry Leiba
2020-01-17
04 James Galvin IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-01-17
04 James Galvin IESG state changed to Publication Requested from I-D Exists
2020-01-17
04 James Galvin IESG process started in state Publication Requested
2020-01-10
04 James Gould
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 …
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.
2020-01-09
04 James Gould
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 …
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.
2020-01-09
04 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-04.txt
2020-01-09
04 (System) New version approved
2020-01-09
04 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2020-01-09
04 Gustavo Lozano Uploaded new revision
2019-12-16
03 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-03.txt
2019-12-16
03 (System) New version approved
2019-12-16
03 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2019-12-16
03 Gustavo Lozano Uploaded new revision
2019-11-26
02 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-02.txt
2019-11-26
02 (System) New version approved
2019-11-26
02 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2019-11-26
02 Gustavo Lozano Uploaded new revision
2019-10-25
01 James Galvin Notification list changed to James Gould <jgould@verisign.com>
2019-10-25
01 James Galvin Document shepherd changed to James Gould
2019-09-20
01 James Galvin Paired with draft-ietf-regext-dnrd-objects-mapping
2019-09-20
01 James Galvin IETF WG state changed to In WG Last Call from WG Document
2019-08-26
01 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-01.txt
2019-08-26
01 (System) New version approved
2019-08-26
01 (System) Request for posting confirmation emailed to previous authors: Gustavo Lozano
2019-08-26
01 Gustavo Lozano Uploaded new revision
2019-07-21
00 James Galvin Added to session: IETF-105: regext  Thu-1000
2019-06-21
00 Antoin Verschuren Changed consensus to Yes from Unknown
2019-06-21
00 Antoin Verschuren Intended Status changed to Proposed Standard from None
2019-06-21
00 Antoin Verschuren Working Group adoption
2019-06-21
00 Antoin Verschuren This document now replaces draft-arias-noguchi-registry-data-escrow instead of None
2019-06-18
00 Gustavo Lozano New version available: draft-ietf-regext-data-escrow-00.txt
2019-06-18
00 (System) New version approved
2019-06-18
00 Gustavo Lozano Request for posting confirmation emailed  to submitter and authors: Gustavo Lozano
2019-06-18
00 Gustavo Lozano Uploaded new revision