Thanks, Joseph. Please see my comments inline.
Additionally, in Section 8.1. some references are missing the DOI reference, such as RFC5732. You can see at the RFC editor the full cite: https://www.rfc-editor.org/refs/ref5732.txt <https://www.rfc-editor.org/refs/ref5732.txt>. There are also some unused and obsolete RFC references in the draft. Best, Tobias > On 13. Jul 2021, at 17:02, Joseph Yee <[email protected]> wrote: > > Hi Tobias, > > Please see comments inline > > On Mon, Jun 21, 2021 at 3:04 PM Tobias Sattler <[email protected] > <mailto:[email protected]>> 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 TS: In 4.1.2.1.2 and 7. I would change LABEL from upper to lower case, too. > > > > 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) TS: I would prefer (1), too, because (2) seems like an overhead to me. > > Best, > Joseph > > > > Best, > Tobias > > > On 22. Feb 2021, at 23:59, [email protected] > > <mailto:[email protected]> 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/ > > > > <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 > > > > <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 > > > > <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 > > <http://tools.ietf.org/>. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > > > > > _______________________________________________ > > regext mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/regext > > <https://www.ietf.org/mailman/listinfo/regext> > > _______________________________________________ > regext mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
