Hi Jim, Thanks for your feedback, and I am working on the revision (but also busy from the day job). Will send a follow up email with details about edits and possibly questions for further discussion.
Thanks Joseph On Fri, Mar 25, 2022 at 10:44 AM Gould, James <jgould= 40verisign....@dmarc.ietf.org> wrote: > Hi, > > > > I did a detailed review of > draft-ietf-regext-simple-registration-reporting-06 and below is my feedback: > > > > 1. Introduction > 1. 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”. > 2. Nit – “data element aforementioned data element registry” to > “data element registry”. > 2. Data Element Specification > 1. Nit – “printed report” could simply be “report”. I don’t > believe printed is relevant. > 2. 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. > 3. Overall > 1. We need to ensure that only elements that are standard > elements (non-proprietary) are pre-defined. > 2. We need to ensure to use a consistent naming convention. > 3. 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 > 1. Transaction_Type > 1. 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? > 2. Object_Type > 1. 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. > 3. DateTime > 1. Shouldn’t this be Date_Time to be consistent with the format > of the other data elements? > 4. Term > 1. Why not use Period instead of Term to be consistent with the > element used in EPP? > 5. Fee > 1. 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. > 6. Status > 1. 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? > 2. 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”. > 7. Registrar > 1. There is the chance that the free-form registrar name could > include the delimiter, so the use of quoting will be needed. > 8. Period > 1. 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 > 1. 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. > 2. 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. > 3. 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. > > 4. Trade > 1. 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 > 1. Start_Date > 1. 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? > 2. RGP_Date > 1. RGP_Date is not descriptive enough. I believe this should be > Redemption_End_Date. > 2. Purge_Date > > 1. This could be Pending_Delete_End_Date, which is when the purge > occurs, and the domain becomes available. > > 1. Where is Transfer_Date? > 1. I believe that all the dates in RFC 5731 should be supported > at a minimum. > 1. Registration Information Data Elements > 1. Registrar_ID > 1. You may want to separate Registrar_ID from IANA_ID or GURID > to enable inclusion of both. > 2. Server_Registrant_ID > 1. 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. > 2. My recommendation is to define a Registrant_ID element that > should be defined by the client, per RFC 5733. > 3. Server_Contact_ID > 1. 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. > 2. My recommendation is to define a Contact_ID element that > should be defined by the client, per RFC 5733. > 4. In_Use > 1. How about using Linked, which matches the language used in > RFC 5733? > 5. Nameserver_Host > 1. How about Host_Name to be in line with the naming in RFC > 5732? > 6. Nameserver_IP > 1. How about Host_IP or Host_IPs to be in line with the naming > in RFC 5732? > 2. How is the list of IPs handled in the report? > 7. Client_Contact_ID > 1. I recommend changing this to Contact_ID, which is assigned by > the client (registrar), per RFC 5733. > 2. Report Definition Specification > 1. “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.” > 1. 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. > 2. I would not refer to them as “transaction rows”, but instead > “record rows”. > 3. 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. > 4. Domain Transaction > 1. 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. > 2. Would it be good to include the domain ROID to uniquely > identify the domain name instance? > 3. 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. > 4. The Period, Term, Fee, and Currency will only apply to > certain Transaction_Types. > 5. 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. > 6. 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. > > 1. Premium Name > 1. What is the purpose of the Status element? > 2. What is the purpose of the Description element? My > recommendation is to remove this element unless there is a concrete > reason > for it. > 3. Can the Start_Date be described? > 2. Domain RGP > 1. 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. > 2. 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. > 3. Reserved Domain > 1. 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? > 4. Domain Inventory > 1. 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. > 5. Contact Inventory > 1. 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? > 2. It’s not clear whether this report is generated per registrar > and if it is why would the Registrar_ID element be needed. > 3. I don’t get the purpose of the Server_Contact_ID, since that > doesn’t match RFC 5733. > 4. 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. > 5. What is the purpose of the Contact_Type unless this is meant > to represent the linkage of the domains to the contacts? > 6. Is the Registrar_ID associated with the Domain or the > Contact. I would assume the Contact, but I’m not sure. > 6. Host Inventory > 1. 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 >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
