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

[Joseph Yee <[e-mail]>]

Hi Tobias,

Please see comments inline

On Mon, Jun 21, 2021 at 3:04 PM Tobias Sattler <[e-mail]>
wrote:

> 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.
>

Didn't have time to make this changes for -04, will look into it for the
next revision


>
> 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.
>

Updated in -04


>
>
> 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]”.
>
>
Updated

>
> 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.
>

Checked the RFC and updated to 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."
>

Updated

>
>
> 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>.
>

Updated

>
>
> 2.4.7.  INUSE
>
> Following your naming conventions, would In_Use not be better?
>

Agreed, more consistent.  Updated

>
>
> 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]”.
>
>
Updated

>
> 3.7.  Host Inventory Report
>
> If the name server host has more than one IP address, how should that be
> filled in?
>

There are two ways I can think of.

(1) split by comma for each IP, and put the whole string inside quote
(2) allow multiple rows with each row having one unique IP to the same host

I personally prefer (1) but have no issue if the working group prefer (2)

Best,
Joseph


>
> Best,
> Tobias
>
> > On 22. Feb 2021, at 23:59, [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>