Subject: Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-03.txt

From: Tobias Sattler <[email-masked]>
Date: Mon, 21 Jun 2021 21:04:29 +0200

Hi Joesph,

Thanks for this update.

I reviewed the latest version, and have some feedback:

The header on page 2 and following contains "Abbreviated Title” instead of "Simple Registration Reporting”.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

I would changed that to the newest version:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.1.  TLD

   The string of the top level domain involved that MUST be in A-LABEL
   format as defined by RFC 5890 [RFC5890].

I would change LABEL from upper to lower case.

Furthermore, if you write RFC 5890 [RFC5890], this will generate duplicate reference links. Therefore, only [RFC5890] should be enough. This would also apply to all other RFC references in your draft.

2.1.3.  Domain

   This is the domain name in an EPP RFC 5731 [RFC5731] domain object
   and it SHOULD be in A-Label format.

I would change it from SHOULD to MUST, and add "as defined by [RFC5890]”.

2.1.4.  Transaction_Type

   The type of transform action made to the domain object (CREATE,
   DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730]
   Section 2.9.3.

I am not certain with upper case as the RFC is using lower case.

2.1.6.  DateTime

   The timestamp of the transaction recorded in the system.  The date
   and time format follows the "type=dateTime" specification as defined
   in RFC 5731 [RFC5731].

I would change it to “Dates and Times MUST be expressed as defined in [RFC5731] Section 2.4."

2.1.7.  Term

   The number of units added to the domain registration period in
   "domain:period" RFC 5731 [RFC5731] in create command, renew or
   transfer command.  If there's no "domain:period", it should take the
   default value set out of band by the registry.

I would change “domain:period” to <domain:period>.

2.4.7.  INUSE

Following your naming conventions, would In_Use not be better?

2.4.8.  Nameserver_Host

   The full domain name of the host object as defined in RFC 5732
   [RFC5732] Section 2.1.  The name SHOULD be in A-Label format.

I would change it from SHOULD to MUST, and add  "as defined by [RFC5890]”.

3.7.  Host Inventory Report

If the name server host has more than one IP address, how should that be filled in?

Best,
Tobias

> On 22. Feb 2021, at 23:59, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Registration Protocols Extensions WG of the IETF.
> 
>        Title           : Simple Registration Reporting
>        Authors         : Joseph Yee
>                          James Galvin
> 	Filename        : draft-ietf-regext-simple-registration-reporting-03.txt
> 	Pages           : 34
> 	Date            : 2021-02-22
> 
> Abstract:
>   Domain name registries (the producer) and registrars (the consumer)
>   report to each other by sharing bulk information through files.  This
>   document creates two IANA registries to establish a standard
>   reporting mechanism between domain name registries and registrars.
>   The first IANA registry lists standard data elements and their syntax
>   for inclusion in the files.  The second IANA registry lists standard
>   reports based on the standard data elements.  Each report is a file
>   formatted as a CSV file.  The advantage of this reporting mechanism
>   is that report, each file, can be imported by recipients without any
>   prior knowledge of their contents, although reporting is enhanced
>   with a minimum of knowledge about the files.  The mechanism for the
>   transmission and reception of the files is a matter of local policy.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext