Hi,
I did a detailed review of draft-ietf-regext-simple-registration-reporting-06
and below is my feedback:
1. Introduction
* I’m not sure whether there have been “a number of best practice
reports that have evolved”, but I do agree that there have been “a number of
best practices that have evolved”.
* Nit – “data element aforementioned data element registry” to “data
element registry”.
2. Data Element Specification
* Nit – “printed report” could simply be “report”. I don’t believe
printed is relevant.
* There is no definition of the format used for the data element names
(e.g., upper case, lower case, camel case, snake case). The names are
inconsistent, but they primarily support the use of upper-case leading words,
with the use of underbars as a word separator. My recommendation is to
formally define the expected data element names and ensure that all the data
element names follow the defined format.
* Overall
* We need to ensure that only elements that are standard elements
(non-proprietary) are pre-defined.
* We need to ensure to use a consistent naming convention.
* We need to look to support a candidate list of registration
elements that are in line with the elements defined and the naming conventions
used in the relevant EPP RFCs.
3. General Data Elements
* Transaction_Type
* How do you deal with extensions to the commands outlined in RFC
5730, such as the restore request, restore response, or operations that are not
defined in RFC 5730, such as auto renew?
* Object_Type
* Since EPP extension can define a new object, then the Object_Type
also needs to be extensible, such as the definition of an Email Forwarding,
Defensive Registration, or NameWatch objects for .NAME.
* DateTime
* Shouldn’t this be Date_Time to be consistent with the format of the
other data elements?
* Term
* Why not use Period instead of Term to be consistent with the
element used in EPP?
* Fee
* I would reference the use of “decimal” for the format, since
referencing “balanceType” is unrelated to representing a fee. The
“balanceType” is a decimal value to support a positive (fee) or negative
(credit) value, so referencing “decimal” is best.
* Status
* A status is an individual value. How do you handle a report that
has more than one status? Does that mean adding multiple rows to the report,
each with a different status value? How do you handle representing additional
statuses, such as the RGP statuses?
* My recommendation is to add a Statuses element that supports a list
of statuses that is an encoded element in double quotes, such as
“clientUpdateProhibited,clientRenewProhibited”.
* Registrar
* There is the chance that the free-form registrar name could include
the delimiter, so the use of quoting will be needed.
* Period
* Why not call this Unit to be consistent with the EPP term? The
term is reflected using the pUnitType in RFC 5731.
4. Domain Price Data Elements
* Same feedback on the use of the unrelated “balanceType” in RFC 8748.
The recommendation is to simply refer to the type “decimal” to support positive
and negative values. The alternative for fees is to only support positive
values with the “nonNegativeDecimal” type in RFC 8748, since I don’t believe
the price values should be negative.
* I believe all the Price Data Element should include an indication that
it’s a price or a fee, such as prefixing “Price_” for each of them. So, it
would be “Price_Domain_Create”, “Price_Domain_Renew”, “Price_Domain_Transfer”,
“Price_Domain_Restore”, and “Price_Domain_Trade”. All the elements should
include the object, since there are additional EPP objects that support
billable commands.
* I assume that other billable commands could be supported by defining
new custom elements with the pattern “Price_”<Object>”_”<Command>, such as the
“Price_Domain_Sync” element for the proprietary sync command defined in
https://www.verisign.com/assets/consolidate-mapping.txt.
* Trade
* Where is a trade defined? The concept of a trade seems like a
proprietary feature that should be moved outside the draft.
5. Timestamp Data Elements
* Start_Date
* Why not call this Available_Date to match its meaning? Where is
this element used since it overlaps with the Purge_Date element for domains in
RGP?
* RGP_Date
* RGP_Date is not descriptive enough. I believe this should be
Redemption_End_Date.
* Purge_Date
1. This could be Pending_Delete_End_Date, which is when the purge occurs,
and the domain becomes available.
* Where is Transfer_Date?
* I believe that all the dates in RFC 5731 should be supported at a
minimum.
1. Registration Information Data Elements
* Registrar_ID
* You may want to separate Registrar_ID from IANA_ID or GURID to
enable inclusion of both.
* Server_Registrant_ID
* Where is a server registrant ID defined? RFC 5733 defines the use
of client assigned identifiers. This is a proprietary feature that should be
moved outside the draft.
* My recommendation is to define a Registrant_ID element that should
be defined by the client, per RFC 5733.
* Server_Contact_ID
* Where is the contact ID defined? RFC 5733 defines the use of
client assigned identifiers. This is a proprietary feature that should be
moved outside the draft.
* My recommendation is to define a Contact_ID element that should be
defined by the client, per RFC 5733.
* In_Use
* How about using Linked, which matches the language used in RFC 5733?
* Nameserver_Host
* How about Host_Name to be in line with the naming in RFC 5732?
* Nameserver_IP
* How about Host_IP or Host_IPs to be in line with the naming in RFC
5732?
* How is the list of IPs handled in the report?
* Client_Contact_ID
* I recommend changing this to Contact_ID, which is assigned by the
client (registrar), per RFC 5733.
2. Report Definition Specification
* “The remaining rows of the file are the unordered sets of data
elements, one set per row, where each row is one transaction in the report.”
* The data elements are ordered based on the order defined in the
header row. Each row is a record and not a transaction in the report.
* I would not refer to them as “transaction rows”, but instead “record
rows”.
* High-level, each report definition needs to include a description of
the report that defines its purpose. I assume the frequency of the report
would be up to server policy. As noted in a prior message on the list, I
believe the draft needs to focus only on the framework and not the concrete
reports. The first step is to have the capability to formally define the
existing reports in a consistent manner and have the reports follow some
predefined requirements.
* Domain Transaction
* I would only include the Registrar_ID in place of including the
verbose Registrar for all the transactions, since there could be a very large
set of transactions and the Registrar Name can be derived from the Registrar_ID
when needed.
* Would it be good to include the domain ROID to uniquely identify
the domain name instance?
* The Transaction_Type values will need to support a broader set of
types. We need to take a closer look on how to handle extensibility of
Transaction_Type values, since transactions that the registrar does not
recognize can be ignored, but at least they have the information available.
* The Period, Term, Fee, and Currency will only apply to certain
Transaction_Types.
* I’m not exactly sure what the purpose is for the Description for an
automated report that can have many transaction records. I recommend removing
the Description unless there is a driving use case for it.
* Additional element to consider:
1. Session_ID, Updated_By (could match to Registrar_ID where the
Updated_By is more fine-grained to an individual user), ROID (Instance of a
domain name), Parent_Transaction_ID if there is a composite transaction.
* Premium Name
* What is the purpose of the Status element?
* What is the purpose of the Description element? My recommendation
is to remove this element unless there is a concrete reason for it.
* Can the Start_Date be described?
* Domain RGP
* I assume that is all domain names in RGP. Are domain names that
are pendingRestore included in this report or only domain names in the RGP
redemptionPeriod or pendingDelete? A description of the purpose of the report
and what domain names are included would help.
* As noted previously, the RGP_Date should be named to something like
Redemption_End_Date and Purge_Date should be named to something like
Pending_Delete_End_Date.
* Reserved Domain
* How does a reserved domain name have a Status since it should be
reserved? Is the Status meant to indicate whether the reserved domain exists
or not, which could happen if an existing domain name is added to the reserved
list?
* Domain Inventory
* Is this the entire inventory of domain names replicated to all
registrars or is it a registrar-specific report for domains under management?
Based on the elements shown, it looks more like a report used to assist with
name spinning than a report to support reconciliation of domain data in the
registrar database with the registry database. The name spinning use case
would include the same inventory report to all registrars, and the
reconciliation use case would need to include more attributes to fully support
syncing the data.
* Contact Inventory
* There is a need for a description of the purpose of the report,
since it’s unclear whether this is generated per registrar and if so, which
contacts are included. Is it all the contacts that is sponsored by the
registrar of the report or is it all contacts linked to domain names sponsored
by the registrar of the report?
* It’s not clear whether this report is generated per registrar and
if it is why would the Registrar_ID element be needed.
* I don’t get the purpose of the Server_Contact_ID, since that
doesn’t match RFC 5733.
* I don’t get Domain since a contact can be linked to many domain
names. My recommendation is to remove the Domain element for the many-to-many
relationship between domains and contacts.
* What is the purpose of the Contact_Type unless this is meant to
represent the linkage of the domains to the contacts?
* Is the Registrar_ID associated with the Domain or the Contact. I
would assume the Contact, but I’m not sure.
* Host Inventory
* I recommend changing the Nameserer_Host to Host_Name, and the
Nameserver_IP to Host_IPs. The IPs can be a list, so the element should be
defined to support a list, with the assumption that they are included in double
quotes as in “192.0.2.2,192.0.2.29,1080:0:0:0:8:800:200C:417A”.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 3/7/22, 6:14 PM, "regext on behalf of internet-dra...@ietf.org"
<regext-boun...@ietf.org on behalf of internet-dra...@ietf.org> 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-06.txt
Pages : 34
Date : 2022-03-07
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 a 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
distribution of and access of the files is a matter of local policy.
The IETF datatracker status page for this draft is:
https://secure-web.cisco.com/1tuLsav6fXdwNwkI2hRgrcTAmGb46y63uhOddhrLcnDRGZ04vkpVWG6XoEjQ8_x2s_P_iQdnjHFea6CHfHkUea9osOV_kHBtQMFGIxT45AwpWJh9IA-C4bv530agFP_80lDJgaDI3nUgVmG3hvcyjKL6BfO3xU7UdsNlCTPpck9A7fEvmanTd-eu4x0g-N0r03uLNUmz0F-PgkmjOmwJokxKJYjvUEOokgBsMlZfUnF45hnDd16y5xfYS3qoPA_JL/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-simple-registration-reporting%2F
There is also an HTML version available at:
https://secure-web.cisco.com/1cxkfGzIwwaxtrPBc-dKkzTbrcM43rhKbUcgKnf4ju60UpDfHrfFurvadAKy0HYgtE8JPliw0q9wk-4yhfizxiU0C9ax9YTm50fwsT_HLO7i6Ziivb8mMUatBWzHgKF1KmXqVhYBeqkq8qWurYZJiexEGtpN8U5rG3agQe9aMpX3tdJcv6v8OAHLFqMSnwQhFiUz9gqtdugbT5HzzZZT6PSNHPgUuTkpB7ip3gjdPHXcizW_RFsz70xqT-k5jkQ4r/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-simple-registration-reporting-06.html
A diff from the previous version is available at:
https://secure-web.cisco.com/1teV5_jYUfeW36P3uKs-wspFDm4tcZ3UcJREdHCcRKa1FyVsVaWoYz8HQ7TpgpTwJEWNlZHTuqMjOuY4PBr8qrbjZgiwD3-W0TydVlriSfv0cfMT0sE9tAAbmyTuZW5GL6R5NSxkF1xkAFOaTaBc08zroZa5Hb7fW8Zr1A_LsAfWvP8gU5LrKQp_MXoPiSZnq06QFiklpvqkq-EJNSExS4aYBCuMWha3oqkK64W48o98SVZpmMKuIXorVAWTbCZIm/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-simple-registration-reporting-06
Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts
_______________________________________________
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/1TWl_oSRF_6eFhgvki-ekeEEj_SaNZQscbHffcoWm5-7LPs33AxYAh6Dw1XyY-mzQLxkWiJF5mjSqCa6f0rTnKSmyYg_ytTWYAWt9Vwlfk0bfDfb0cCqdkm_bLYOWePsWzHqIB3SJEppnIYca5RbTb0Dweh83zA8VNM4wkq_aF5TsgAYjKpRf8VAPCCADGpsQ5eCHsgTIefjUQJIEXgUNIf11pBPngYHc-8DQ4tYshc7RyzLoVu7QiG0FzsKuni69/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
