Domain Name Registration Data (DNRD) Objects Mapping
draft-ietf-regext-dnrd-objects-mapping-11

[Ballot comment]
Thank you for addressing my Discuss (and Comment) points, as well as explaining
to me the ones that are not actually issues.

I think it would be good to make one last pass through the document to confirm that
the "parent" attribute is listed where needed.

[Ballot comment]
[To the IESG: In the IANA Considerations section, the contact for all registrations is "IESG ".  That's not the IESG's address though.  (I remember us discussing this in previous telechats, but it's late and I'm blanking on whether this is the outcome we wanted.)]

My colleagues have made a lot of good suggestions already, so I don't have much to add other than these:

In Section 8, there's this bullet:

  o  If a Differential Deposit is to be tested, the dataset is created
      by using the Differential Deposit plus all the required deposits
      leading to the last previous Full Deposit.

It seems obvious, but should this make clear the order in which the differential deposits are applied?

Totally a nit (which I now see Eric V also mentioned): In a couple of places there's an ASCII expression like "ASCII value 0x002B".  Since ASCII is 7-bit, shouldn't that just be "ASCII value 0x2B"?

[Ballot discuss]
It's possible that I just misunderstand what is required to go where,
but for several (possibly only CSV?) elements, the body text claims that
"[t]he attribute "isRequired" MUST equal "true"." but the corresponding
examples do not consistently list the "isRequired" attribute.
(Sometimes they do, but not always.)  Shouldn't the examples be
consistent with the protocol requirements?  I note some examples in my
COMMENT section but this should not be treated as an exhaustive list.

A similar property (again, if I understand correctly) holds for the
"parent" attribute of various elements (which is definitely only a thing
for the CSV objects)..

The claim in the IANA Considerations regarding "URI assignments have
been registered by the IANA", accompanied by specific URN
namespace/schema values, is codepoint squatting, in the absence of a
disclaimer about being "requested values".  The registration policy is
only Specification Required, so there is no formal guarantee that we can
actually get these values.

At least one of the examples shows RSA/MD5 DNSSEC key records.  RSA/MD5
usage is specifically disallowed (see RFC 6944 and RFC 8624);
please replace with a more modern algorithm.  (One location noted in the
COMMENT, along with some SHA-1 usage that should probably go as well.)

[Ballot comment]
We have at least one example that shows a gurid of 123, which is an
actual value allocated to a real registrar by ICANN (details in the
section-by-section comments).  Please consider using a different value
for the example.

Section 1

  Registry Data Escrow is the process by which a registry periodically

nit: maybe include "(RDE)", since we use the acronym later on before the
definitions section.

  This document defines the following pseudo-objects:
  [...]
  o  EPP parameters: Definition of the specific EPP parameters
      supported by the Registry Operator.

nit: is the pseudo-object containing the "definition of" the specific
parameters or something related, like the values of those parameters?

Section 4.1

  Numerous fields indicate "dates", such as the creation and expiry
  dates for domain names.  These fields SHALL contain timestamps
  indicating the date and time in UTC as specified in [RFC3339], with
  no offset from the zero meridian.

Should we mention anything about leap seconds?

Section 4.4

If I understand correctly from the examples, the actual checksum value
of the CSV file is encoded as an attribute of the corresponding
element in the XML description/schema/thing that
accompanies the CSV files.  Is my understanding correct?

Why is CRC32 the default?  In my opinion SHA-256 is better as a default,
based on the "fail safe" principle.

Section 4.5

  The syntax of IP addresses MUST conform to the text representation of
  either Internet Protocol Version 4 [RFC0791] or Internet Protocol
  Version 6 [RFC4291].

Where exactly in RFC 791 is the text representation discussed?  "text"
only appears three times, none of which are relevant, and
"representation" not at all.  I do note that traditional/historic APIs
involving IPv4 addresses have been quite lenient, allowing even such
things as 18.1179790 (18/8 is a class A network), and I expect the
intent is to limit to "dotted quad" decimal values.

Section 4.6.1

nit: we jump pretty quickly into the example without much introduction
for the concepts and abbreviations it uses; a note about where it will
be explained further might be helpful.

Section 4.6.2

(editorial) I feel like these CSV elements would be more understandable
if they appeared after the XML model (which presents descriptions for
the XML elements that are used in the example CSV elements), though I
don't have a specific proposal for section reorderings that would make
that happen.

Section 4.6.2.1

  The following is example of the "domain-YYYYMMDD.csv" file with one
  record matching the  definition.

  domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,
  clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
  2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z

Is that last 2015-04-03T22:00:00.0Z the expiration date (now five years
in the past)?  It may be worth making a pass through the examples and
thinking about which dates might be updated to more-current values.

Section 4.6.2.2

    Registrant contact identifier with
      type="eppcom:clIDType".

So the client ID type is used for both clients (registrars, per below)
and registrants (users, as used here)?

    Identifier of the registrar, defined in Section 5.4,
      of the client that created the object with type="eppcom:clIDType".

    Identifier of the client that created the object with
      type="eppcom:clIDType".

Or am I wrong to equate clients and registrars?

    State of the most recent transfer request with
      type="eppcom:trStatusType" and isRequired="true".

We assume that there has always been a most recent transfer request?  I
note that  (and the  it contains) "MUST NOT be
present if a transfer request for the domain name has never been
created".

Section 4.6.3

       

It looks like we don't actually expand this to "globally unique
registrar identifier" anywhere; we just say it's the ID assigned by
ICANN" (in §5.1.2.1.1)?

Section 5.1.1.1

  o  An OPTIONAL  element that contains the fully-qualified
      domain name in Unicode character set.  It MUST be provided if
      available.

Who is tasked with verifying that the  is consistent with the
?  (Similarly for other uName elements, later.)

Section 5.1.2

  include a  field.  All the child CSV
  file definition data for the domain name objects in the parent
  "domain" CSV File Definition (Section 5.1.2.1.1) MUST first be
  deleted and then set using the data in the child CSV files.  The
  deleted domain name object data under the  element
  is a cascade delete starting from the "domain" Deletes CSV File
  Definition (Section 5.1.2.2.1).

I feel like I want to check my understanding here.  When we say "All the
child CSV file definition data [...] MUST first be deleted and then set
[...]", this is not talking about the  stuff, right?
It's just "anything that's listed in  is wiped
clean, so the contents of the  reflect the full and
exact state after the updates"?

Section 5.1.2.1.1

    Identifier of the registrar, defined in Section 5.4,
      of the client that updated the object.

    Identifier of the client that last updated the domain
      name object.

nit: we could probably normalize around "object" vs "domain name object"
and "updated" vs "last updated".  (This seems to occur multiple times in
the document, at least with respect to "updated"/"last updated".)

    UTF8 encoded domain name for the
      field element.

[same question as for CSV about who does the consistency check]

    Date and time of the last update to the domain name
      object.

Should we say anything about the case where the domain object has never
been modified?

    Date and time of the last transfer for the domain
      name object.

[likewise.  I will probably not mention this for subsequent
transfer/update-related elements, though they would presumably be
similarly affected]

Section 5.1.2.1.5

  The "domainNameServersAddresses" CSV File Definition defines the
  fields and CSV file references used for supporting the host as domain
  attributes model.

Is there a typo in here?  Google didn't find much for "host as domain
attributes model".

Section 5.1.2.1.6

  Example of the corresponding dnssec-ds-YYYYMMDD.csv file.  The file
  contains two DS records for domain1.example.

  domain1.example,604800,12345,3,1,49FD46E6C4B45C55D4AC
  domain1.example,604800,12346,3,1,38EC35D5B3A34B44C39B

It would be nice to use SHA-256 rather than SHA-1 for the examples,
given SHA-1's weaknesses.

  Example of the corresponding dnssec-key-YYYYMMDD.csv file.  The file
  contains two key records for domain1.example.

  domain1.example,604800,257,3,1,AQPJ////4Q==
  domain1.example,604800,257,3,1,AQPJ////4QQQ

RSA/MD5, on the other hand, is specifically disallowed (see
RFC 6944 and RFC 8624).
Please replace with a more modern algorithm.

Section 5.2.2.1.1

  Example of the corresponding host-YYYYMMDD.csv file.  The file
  contains six host records with four being internal hosts and two
  being external hosts.

What is an internal (or external) host?

Section 5.2.2.1.2

  The following "rdeCsv" fields, defined in section CSV common field
  elements (Section 4.6.2.2), MAY be used in the "hostStatuses"
    element:

    Host object status description which is
      free form text describing the rationale for the status.  The
      attribute "isRequired" MUST equal "true".

I feel like the "MAY" and "MUST" must be targetted at different parties,
but am not entirely sure I understand the distinction.

And if "isRequired" must be true, why is it not listed as such in the
example that follows or present in the corresponding example csv file?

Section 5.2.2.1.3

    IP addresses associated with the host object with
      type="host:addrStringType".  The attribute "isRequired" MUST equal
      "true".

    IP addresses version associated with the host
      object with type="host:ipType".  "host:ipType" has the enumerated
      values of "v4" or "v6".  The attribute "isRequired" MUST equal
      "true".

Is anyone supposed to do consistency checks that the string
representation of the address matches the claimed address type?

    Host object Registry Object IDentifier (ROID)
      assigned to the host object with isRequired="true".

(I don't see the "isRequired" in the example that follows, though it is
present for fAddr and fAddrVersion.)

Section 5.3.2.1.2

    Server-unique contact identifier of status with
      isRequired="true".

It needs to have parent="true", too, right?

Section 5.3.2.1.3

    Contains the contact's street address line with
      type="contact:fPostalLineType".  An index attribute is required to
      indicate which street address line the field represents with index
      "0" for the first line and index "2" for the last line.  An
      OPTIONAL "isLoc" attribute to used to indicate the localized or
      internationalized form as defined in section Section 4.6.3.

nit(?): pedantically, this would seem to say that if I only have two
lines, I use indices 0 and 2 (not 0 and 1), and leave me in an awkward
situation if there is only one line.  But I don't think anyone will
actually get confused...

    Contains the contact's country code with
      type="contact:ccType" and isRequired="true".  An OPTIONAL "isLoc"
      attribute to used to indicate the localized or internationalized
      form as defined in section Section 4.6.3.

Is there really localization available for ISO-3166-1 country codes?
(I didn't follow the reference.)

    Server-unique contact identifier for the contact
      object with isRequired="true".

"parent", too, right?  I will stop reporting additional cases where
"parent" seems to be needed.

Section 5.3.2.1.5

    Exceptional disclosure preference flag
      for the localized form of the contact name with type="boolean".

    Exceptional disclosure preference flag
      for the internationalized form of the contact name with
      type="boolean".

What happens if both 'Loc' and 'Int' are set?
(Similarly for the other fields.)

Section 5.4.1.1

  o  An OPTIONAL  element that contains the date and time of
      the most recent RDE registrar-object modification.  This element

Is the "RDE" part here correct?  It feels weird for me for the escrow
data format contents to include information that is more properly
metadata about the escrow data; we do not seem to mention "RDE" when
talking about other modification times.

  Example of  object:

  ...
    123

"123" seems to be a real registrar ID, listed at
https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml as
corresponding to "The Registry at Info Avenue, LLC d/b/a Spirit
Communications".  Perhaps a reserved value (e.g., 1) could be used
instead?

Section 5.4.2

  Definition (Section 5.4.2.1.1).  The child CSV file definitions
  include a  field.  All the child CSV

(this is probably applicable to previous models as well, but) we seem to
allow either fId or fGurid, so this text is inconsistent with the actual
practice.

Section 5.4.2.1.1

We list  in both the "MUST" (as part of the choice)
and "MAY" sections.  My reading of the "choice" part was that you had to
pick one or the other, so it's not entirely clear to me how internally
consistent this treatment is.

Section 5.4.2.2.1

        Contains the server-unique registrar
        identifier with type="eppcom:clIDType" and isRequired="true".

        Contains the ID assigned by ICANN with
        type="positiveInteger".  The attribute "isRequired" MUST equal
        "true".

nit: we could use the same sentence structure for these two elements'
descriptions.

Section 5.5.2.1.1

    URL that defines the character code points that can be
      used for the language defined by the  field element.

A pointer to which  element(s) this is might be helpful,
since it's not local to this section.

Section 5.6

  A domain name can only exist as a domain name object or an NNDN
  object, but not both.

What entities are charged with enforcing this invariant?

Section 5.6.1.1

      *  If an NNDN is considered a mirrored IDN variant of a domain
        object, then the NNDN will be tagged as "mirrored".  A

Where is "NS mirroring" defined?  This seems particularly poingant since
it defaults to "true".

Section 5.7

  registry supports EPP.  Only one EPP Parameters Object MUST exist at
  a certain point in time (watermark).

nit: Is "only one" a maximum or a synonym for "exactly one"?

Section 5.9.1

  o  A  element that contains the number of objects in the SRS
      at a specific point in time (watermark) regardless of the type of
      deposit: Differential, Full or Incremental.  The  element
      supports the following attributes:

If the count is supposed to be for objects in the SRS, why do we have
the "uri" that distinguishes between the XML and CSV models?  What model
is used for escrow seems independent of what the state of the SRS is.

Section 5.10

I feel like I'm left without a proper understanding of what the DNRD
Common Objects Collection actually does.

Section 8

I had asked in a few previously places what entity is tasked with
verifying some property (usually that an A-name and U-name are actually
equivalent); would that be something that could/should be done by a data
escrow agent during this sort of validation process?

Section 9

(I am only spot-checking that min/maxOccurs in the schema matches with
the prose descriptions, etc., not doing an in-depth review.)

Section 9.1

Some of the indentation seems inconsistent, e.g., around:

   
   
   

Section 9.2

           

11 is an interesting number (§5.1.1.1 has in prose just "one or more
elements"); is there a story behind it?

Section 9.3

   
   

Where is the "variant group" usage specified?

Section 9.4

           

And here we have maxOccurs of 7; interesting.

Section 9.7

   

nit: why do all these comments have a question mark?

Section 9.8

   
     
       
       

Where does the line-length limit of 255 come from?

Section 9.10

Some whitespace niggles here as well, e.g.:

         
           
       

Section 9.14

   
   

How common is the ACE abbreviation/term?  It does not seem to be used
elsewhere in this document (and it is a little distracting to me, as the
name of a security-area WG).

   
   

Where is the "variant group" usage specified?

Section 11

  This document uses URNs to describe XML namespaces and XML schemas
  conforming to a registry mechanism described in [RFC3688].  Fourteen
  URI assignments have been registered by the IANA.

"Fourteen" does not seem accurate any more.

(Also, it is maybe a bit overzealous to use the generic "csv" prefix
for the RDE CSV usage, though I do not specifically object to doing so.)

Section 13

Thanks for what's here already; it covers a lot of good stuff.

We should also say something about the level of trust placed in the
escrow agent.  One might imagine a scenario where the data placed in
escrow is signed by the registry in a way that can be verified
post-facto by not only the escrow agent but other entities as well; in
this case the escrow agent is trusted only to preserve an accurate copy
and provide "new enough" data.  That does not seem to be the trust model
used by this scheme, since we also must trust the escrow agent to
provide a faithful copy of what the registry gave it, in the case when a
recovery is needed.  Whether or not this presents significant risk is a
policy and perhaps contractual matter, so it's not problematic from the
specification point of view, but we should document that we make this
strong assumption of trust of the escrow agent.  (This is particularly
true due to the number of things that are negotiated out of band between
registry and escrow agent, which would of course not be covered by any
in-protocol indication of source authenticity.)

In a similar vein, we might mention that there's no protocol mechanism
to detect a registry providing bogus data to an escrow agent.  (I'm sure
there are legal/contractual mechanisms in place to do so, though!)

It's also important to discuss the vagaries of quoting/escaping in the
CSV format, especially so since we allow for the separator to be
specified manually.  The parser needs to ensure that only the intended
separators are treated as separators and ignore that character when it
is quoted or escaped (as appropriate) for appearance in the body of a
given field.

I would suggest some mention that the various datastructures include a
few places that have some internal redundancy, and that if the values
become inconsistent there can be harmful consequences (e.g., if
different entities use different fields as their reference).

  Note: if Transport Layer Security (TLS) is used when providing an
  escrow services, the recommendations in [RFC7525] MUST be
  implemented.

Please cite this as BCP 195.

Section 19

Perhaps the YYYYMMDD could be replaced with non-placeholder values to
make the example more realistic?

Should there also be examples for the CSV contents of the indicated
files?  (This would also give the opportunity to show that the checksum
of the content matches the value indicated in the example XML.)

Section 21.1

If it is not needed for the textual representation of an IPv4 address,
RFC 791 seems to otherwise not be referenced.

Section 21.2

Since SHA-256 is a "MAY", that might qualify RFC 6234 as a normative
reference (per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/)

Likewise for RFC 7525, which is a MUST when TLS is used.

[Ballot comment]
[ section 4.5 ]

* For text representations you want RFC 5952 rather than 4291.

[ section 5.1.2.1.5, 5.2.2.1.3 ]

* It's not clear that ",v4" or ",v6" are adding anything. The IP address
  family should be unambiguous without the hint.

  No change necessary, it just seems like this isn't really needed.  (For
  example, if there's even a remote possibility someone might try to list
  IPv4-mapped IPv6 addresses -- or even worse, compat addresses -- then
  there are going some other, much bigger problems ahead.)


[ section 5.4.1.1 ]

* Is it recommended at all that rdeRegistrar:url be https whenever possible?

* In addition to whois name/url should there RDAP information?  Or is the
  http/https whois URL expected to handle RDAP?

[Ballot comment]
Thank you for the work put into this document. Due to my heavy workload, I did not review in details the model itself.

Please find below a couple of non-blocking COMMENTs (a reply to  my COMMENTs will be welcome).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic question about the point (5) of the document shepherd write-up:
"The AD is asking for further review from the Internationalization
Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
UTF-16.  The working group cites RFC 5730, Section 5, and aligns with that.
The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
well over 10 years old.  Other opinions will be useful."

Did the WG receive any other opinions ? It is not clear from the write-up.

-- Section 4.3 --
Just curious here, why are the ASCII code expressed as a 16-bit unit while ASCII codes are 7-bit long ? E.g., '("+", ASCII value 0x002B)'

-- Section 4.4 --
Are you sure that CRC32 and SHA-256 belongs to a section named 'checksum' ? Those 2 techniques are different than checksums and much stronger for integrity checks. Suggest to renamed this section.

In addition, should the algorithm be identified ?

-- Section 4.5 --
RFC 4291 is about the addressing structure of IPv6 (i.e., semantic), please replace this reference to RFC 5952 that is about how to write an IPv6 address (i.e., syntax).

-- Section 4.6.1 --
Just curious again... why not using plain SQL data definition language 'create table()' statements rather than using XML to describe relational tables? Of course, the XML file contains other information than the SQL data definition language but it is lacking some information from SQL.

Also, it seems that using XML rather than SQL forces the primary key and foreign key to have the same name (e.g., )

-- Section 5.3.2.1.3 --
Should the postal ZIP code be included ?

== NITS ==

-- Section 5.1.1.1 --
Really cosmetic, but, having an expiration date in 2015 in the example in a document published in 2020 ;-)

[Ballot comment]
Thanks to Joe Clarke for his OpsDir comments, and thanks the authors for addressing them; this has improved the document noticeably (it's nice when the Directorate process works so well).

Some minor nits / comments:
1: 'Version compatibility: versions 03 - 08 are known to be implemented.' -- probably this should bump to -09
2: Wrapping the BEGIN  END in file "some_file_name.xml"  as used by e.g. rfc6087 S3.1 (or use the v3 RFC tools) -- this will allow standard tools to extract the schemas more easily and with less errors.

[Ballot comment]
Thank you for this document and the various XLS/CSV examples related to particular elements of the data model.

** Section 4.4.  Per the use of SHA-256 as a checksum algorithm, what identifier should be used in the cksumAlg attribute?

** Section 4.4.  I concur with the OPSDIR reviewer (Joe Clarke), it would seem like native support (in the format itself) for a more robust checksum algorithm would be desirable.

** Section 4.6.2.1.  Per “The  child element defines a reference to the CSV file name”, is any file path information permitted, or are do all referenced files in dump need to be unique?

** Section 5.8.1.  Please add a normative reference to XPath

** Section 7.  If one had a business model requiring that checksums  be computed using SHA-384 (set @cksumAlg) or using 7z compression (set @compression), how would one specify that in the profile per the defined steps in this section – nothing needs to be extended (step 1, step 3) or  doesn’t seem to support specifying a particular attribute (step 2), so would one hard-code that into a custom schema (step 4)? 

** Editorial Nits
- Section 9.1  Typo. s/Seperated/Separated/

- Section 11.  Typos.  A few repeated instances.  s/section Section/Section/g

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

The IANA Functions Operator has completed its review of draft-ietf-regext-dnrd-objects-mapping-06. 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/

fourteen registrations will be made as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As this document requests registrations in a 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 on the IETF XML Registry page located at:

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

fourteen registrations will be made as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As this also requests registrations in a 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 this is the only action required to be completed upon approval of this document.

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

The working group request is to publish this document as a Proposed
Standard RFC, and the title page header notes that the intended status is
"Standards Track". This is the proper type of RFC because this document
describes the format, contents, and semantics of Domain Name Registration
Data (DNRD) escrow deposits for a domain name registry and
interoperability is required between producers and consumers of these
escrow deposits.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name
Registration Data (DNRD) escrow deposits for a domain name registry.
These escrow deposists are intended to provide a source of backup data to
reconstitute a domain name registry in the unlikely situation of
unrecoverable data loss.

Working Group Summary

This document was first published as an individual submission
Internet-Draft in March, 2012. It was adopted by the REGEXT working group
in June, 2019. A working group last call was started on 20 September,
2019. Multiple people expressed support for progression of the document.
The authors of the document found interoperability issues during the
working group last call and had to produce a new version. The authors
thought that the changes were not substantive, but there were enough of
them to warrant a second working group last call. That last call was
initiated on 26 October and ended on 8 November. This second last call
was extended to 22 November due to a lack of last call feedback. The
second last call was completed successfully with multiple expressions of
support and no expressions of concern.

Document Quality

The data format specifications contained in this document have been
implemented in support of more than 1,200 generic Top-Level Domains. In
addition, domain registry service provider transitions using data files
that conform to this specification have been completed.

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director
is Barry Leiba.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I read the document in detail and provided my review to the working group
on 2 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/TjRlL9OygsrZ_BXjnJDs7UeHRJk

All of my review feedback has been addressed as of January 10, 2020.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been
implemented by a large number of domain registry operators who produce
escrow deposits for ICANN. The document completed a working group last
call on 4 October 2019. Eight individuals expressed support for
publication of the document and no dissent was recorded. This last call
identified an interoperability issue and a number of editorial issues, so
a new version of the document was produced and a second working group
last call was started on 26 October 2019. There were no expressions of
concern raised during the working group last call process.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

The AD is asking for further review from the Internationalization
Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
UTF-16.  The working group cites RFC 5730, Section 5, and aligns with that.
The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
well over 10 years old.  Other opinions will be useful.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano:
https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould:
https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy:
https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page
(https://datatracker.ietf.org/ipr/). Given that there are no known
disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

Multiple people expressed support for the document, but it's more of a
"concurrence of a few individuals" situation (primarily those associated
with ICANN's generic Top-Level Domain program) than the WG as a whole.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits tool notes normative references to non-RFC documents. These
are to ISO and ITU documents for which a normative reference is
appropriate.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML
schema. These are subject to expert review.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are no normative references to documents that are not ready for
advancement or are otherwise in an unclear state.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

The document includes normative references to an ISO specification (ISO
Standard 3166) and an ITU specification (ITU-T Recommendation E.164). The
document also includes a normative reference to BCP 14. All other
normative references are to Standards Track documents.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML
schema. These are subject to expert review. I've reviewed the
registration requests and suggested a modification:

"The IANA Considerations section requests registration of multiple XML
namespaces and XML schemas. For example,
urn:ietf:params:xml:ns:rdeCsv-1.0 and
urn:ietf:params:xml:schema:rdeCsv-1.0. Recent convention has been to
include “epp” in the URIs for EPP-associated namespaces and schemas, e.g.
urn:ietf:params:xml:ns:epp:. That convention should be
followed here, making the requested values
urn:ietf:params:xml:ns:epp:rdeCsv-1.0 and
urn:ietf:params:xml:schema:epp:rdeCsv-1.0."

The authors have declined to make this change due to the large number of
deployed, operational implementations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I worked with one of the authors to perform automated checks of the
examples and schema specifications. The result of those checks was posted
to the working group mailing list on 10 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s

All of the needed updates have been completed.

The following Last Call announcement was sent out (ends 2020-03-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-dnrd-objects-mapping@ietf.org, shollenbeck@verisign.com, Scott Hollenbeck , regext@ietf.org, barryleiba@gmail.com, regext-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Domain Name Registration Data (DNRD) Objects Mapping) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Domain Name Registration Data
(DNRD) Objects Mapping'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-09. 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, contents and semantics of Domain
  Name Registration Data (DNRD) Escrow deposits for a Domain Name
  Registry.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry. These escrow deposists are intended to provide a source of backup data to reconstitute a domain name registry in the unlikely situation of unrecoverable data loss.

Working Group Summary

This document was first published as an individual submission Internet-Draft in March, 2012. It was adopted by the REGEXT working group in June, 2019. A working group last call was started on 20 September, 2019. Multiple people expressed support for progression of the document. The authors of the document found interoperability issues during the working group last call and had to produce a new version. The authors thought that the changes were not substantive, but there were enough of them to warrant a second working group last call. That last call was initiated on 26 October and ended on 8 November. This second last call was extended to 22 November due to a lack of last call feedback. The second last call was completed successfully with multiple expressions of support and no expressions of concern.

Document Quality

The data format specifications contained in this document have been implemented in support of more than 1,200 generic Top-Level Domains. In addition, domain registry service provider transitions using data files that conform to this specification have been completed.

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I read the document in detail and provided my review to the working group on 2 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/TjRlL9OygsrZ_BXjnJDs7UeHRJk

All of my review feedback has been addressed as of January 10, 2020.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019. There were no expressions of concern raised during the working group last call process.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Multiple people expressed support for the document, but it's more of a "concurrence of a few individuals" situation (primarily those associated with ICANN's generic Top-Level Domain program) than the WG as a whole.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool notes normative references to non-RFC documents. These are to ISO and ITU documents for which a normative reference is appropriate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references to documents that are not ready for advancement or are otherwise in an unclear state.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The document includes normative references to an ISO specification (ISO Standard 3166) and an ITU specification (ITU-T Recommendation E.164). The document also includes a normative reference to BCP 14. All other normative references are to Standards Track documents.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification:

"The IANA Considerations section requests registration of multiple XML namespaces and XML schemas. For example, urn:ietf:params:xml:ns:rdeCsv-1.0 and urn:ietf:params:xml:schema:rdeCsv-1.0. Recent convention has been to include “epp” in the URIs for EPP-associated namespaces and schemas, e.g. urn:ietf:params:xml:ns:epp:. That convention should be followed here, making the requested values urn:ietf:params:xml:ns:epp:rdeCsv-1.0 and urn:ietf:params:xml:schema:epp:rdeCsv-1.0."

The authors have declined to make this change due to the large number of deployed, operational implementations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

I worked with one of the authors to perform automated checks of the examples and schema specifications. The result of those checks was posted to the working group mailing list on 10 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s

All of the needed updates have been completed.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry. These escrow deposists are intended to provide a source of backup data to reconstitute a domain name registry in the unlikely situation of unrecoverable data loss.

Working Group Summary

This document was first published as an individual submission Internet-Draft in March, 2012. It was adopted by the REGEXT working group in June, 2019. A working group last call was started on 20 September, 2019. Multiple people expressed support for progression of the document. The authors of the document found interoperability issues during the working group last call and had to produce a new version. The authors thought that the changes were not substantive, but there were enough of them to warrant a second working group last call. That last call was initiated on 26 October and ended on 8 November. This second last call was extended to 22 November due to a lack of last call feedback. The second last call was completed successfully with multiple expressions of support and no expressions of concern.

Document Quality

The data format specifications contained in this document have been implemented in support of more than 1,200 generic Top-Level Domains. In addition, domain registry service provider transitions using data files that conform to this specification have been completed.

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I read the document in detail and provided my review to the working group on 2 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/TjRlL9OygsrZ_BXjnJDs7UeHRJk

All of my review feedback has been addressed as of January 10, 2020.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019. There were no expressions of concern raised during the working group last call process.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Multiple people expressed support for the document, but it's more of a "concurrence of a few individuals" situation (primarily those associated with ICANN's generic Top-Level Domain program) than the WG as a whole.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool notes normative references to non-RFC documents. These are to ISO and ITU documents for which a normative reference is appropriate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references to documents that are not ready for advancement or are otherwise in an unclear state.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The document includes normative references to an ISO specification (ISO Standard 3166) and an ITU specification (ITU-T Recommendation E.164). The document also includes a normative reference to BCP 14. All other normative references are to Standards Track documents.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification:

"The IANA Considerations section requests registration of multiple XML namespaces and XML schemas. For example, urn:ietf:params:xml:ns:rdeCsv-1.0 and urn:ietf:params:xml:schema:rdeCsv-1.0. Recent convention has been to include “epp” in the URIs for EPP-associated namespaces and schemas, e.g. urn:ietf:params:xml:ns:epp:. That convention should be followed here, making the requested values urn:ietf:params:xml:ns:epp:rdeCsv-1.0 and urn:ietf:params:xml:schema:epp:rdeCsv-1.0."

The authors have declined to make this change due to the large number of deployed, operational implementations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

I worked with one of the authors to perform automated checks of the examples and schema specifications. The result of those checks was posted to the working group mailing list on 10 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s

All of the needed updates have been completed.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry. These escrow deposists are intended to provide a source of backup data to reconstitute a domain name registry in the unlikely situation of unrecoverable data loss.

Working Group Summary

This document was first published as an individual submission Internet-Draft in March, 2012. It was adopted by the REGEXT working group in June, 2019. A working group last call was started on 20 September, 2019. Multiple people expressed support for progression of the document. The authors of the document found interoperability issues during the working group last call and had to produce a new version. The authors thought that the changes were not substantive, but there were enough of them to warrant a second working group last call. That last call was initiated on 26 October and ended on 8 November. This second last call was extended to 22 November due to a lack of repeated expressions of support for progression. More TBD...

Document Quality

The data format specifications contained in this document have been implemented in support of more than 1,200 generic Top-Level Domains. In addition, domain registry service provider transitions using data files that conform to this specification have been completed.

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I read the document in detail and provided my review to the working group on 2 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/TjRlL9OygsrZ_BXjnJDs7UeHRJk

As of 11 December 2019, there has been no response from the authors and the suggested updates have not been made. The document will be ready for submission to the IESG once the actions recommened in my review have been completed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Multiple people expressed support for the document, but it's more of a "concurrence of a few individuals" situation (primarily those associated with ICANN's generic Top-Level Domain program) than the WG as a whole.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

->There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document.

The examples in question use names of the form "ns*.domain*.test". The "test" TLD is described as reserved in Section 2 of RFC 2606, but it's described as being reserved for use in testing. The "example" TLD is described as reserved for use to describe examples.

The idnits tool notes normative references to non-RFC documents. These are to ISO and ITU documents for which a normative reference is appropriate. There is also a warning associated with a URI reference to a Internet-Draft document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references to documents that are not ready for advancement or are otherwise in an unclear state.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The document includes normative references to an ISO specification (ISO Standard 3166) and an ITU specification (ITU-T Recommendation E.164). The document also includes a normative reference to BCP 14. All other normative references are to Standards Track documents.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification:

"The IANA Considerations section requests registration of multiple XML namespaces and XML schemas. For example, urn:ietf:params:xml:ns:rdeCsv-1.0 and urn:ietf:params:xml:schema:rdeCsv-1.0. Recent convention has been to include “epp” in the URIs for EPP-associated namespaces and schemas, e.g. urn:ietf:params:xml:ns:epp:. That convention should be followed here, making the requested values urn:ietf:params:xml:ns:epp:rdeCsv-1.0 and urn:ietf:params:xml:schema:epp:rdeCsv-1.0."

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

I worked with one of the authors to perform automated checks of the examples and schema specifications. The result of those checks was posted to the working group mailing list on 10 December 2019:

https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s

As of 11 December 2019, the needed updates have not been made.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

->There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document.

The examples in question use names of the form "ns*.domain*.test". The "test" TLD is described as reserved in Section 2 of RFC 2606, but it's described as being reserved for use in testing. The "example" TLD is described as reserved for use to describe examples.

The idnits tool notes normative references to non-RFC documents. These are to ISO and ITU documents for which a normative reference is appropriate. There is also a warning associated with a URI reference to a Internet-Draft document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

->There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document.

The idnits tool notes normative references to non-RFC documents. These are to ISO and ITU documents for which a normative reference is appropriate. There is also a warning associated with a URI reference to a Internet-Draft document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, each author has provided their confirmation:

Gustavo Lozano: https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould: https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy: https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests IANA registration of an XML namespace and an XML schema. These are subject to expert review. I've reviewed the registration requests and suggested a modification.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The working group request is to publish this document as a Proposed Standard RFC, and the title page header notes that the intended status is "Standards Track". This is the proper type of RFC because this document describes the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry and interoperability is required between producers and consumers of these escrow deposits.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

The Document Shepherd is Scott Hollenbeck. The Responsible Area Director is Barry Leiba.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document was first written in March 2012 and it has been implemented by a large number of domain registry operators who produce escrow deposits for ICANN. The document completed a working group last call on 4 October 2019. Eight individuals expressed support for publication of the document and no dissent was recorded. This last call identified an interoperability issue and a number of editorial issues, so a new version of the document was produced and a second working group last call was started on 26 October 2019.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional reviews are required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

I could not find any IPR disclosures on the IETF IPR disclosure page (https://datatracker.ietf.org/ipr/). Given that there are no known disclosures, there has been no discussion of IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.