Noted, like the idea to make the name more consistent. Thanks Joseph
On Mon, May 23, 2022 at 3:09 PM Gould, James <jgo...@verisign.com> wrote: > Joseph, > > > > As you’re working on the feedback, one additional feedback item is making > the Timestamp Data Elements more consistent. For example, there is the use > of Create_Date and Updated_Date, where it would be more consistent to use > Created_Date and Updated_Date for the data elements. The Expiry_Date > should be called Expiration_Date to match better with the terminology used > in the EPP Domain Name RFC 5731 (validity periods reference to “expiration” > instead of “expiry”) and the Domain Name Registration Data (DNRD) RFC 9022 > (reference to expiration instead of expiry for <exDate> and > <rdeCsv:fExDate>). > > > > Let me know if you have any questions. > > > > Thanks, > > > > -- > > > > JG > > > > > > *James Gould *Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <regext-boun...@ietf.org> on behalf of Joseph Yee > <jyee@donuts.email> > *Date: *Monday, April 11, 2022 at 9:01 AM > *To: *"Gould, James" <jgould=40verisign....@dmarc.ietf.org> > *Cc: *"regext@ietf.org" <regext@ietf.org> > *Subject: *[EXTERNAL] Re: [regext] I-D Action: > draft-ietf-regext-simple-registration-reporting-06.txt > > > > 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 > > a. 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”. > > b. Nit – “data element aforementioned data element registry” to “data > element registry”. > > 2. Data Element Specification > > a. Nit – “printed report” could simply be “report”. I don’t believe > printed is relevant. > > b. 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. > > c. Overall > > > i. We need to ensure that only elements that are standard elements > (non-proprietary) are pre-defined. > > > ii. We need to ensure to use a consistent naming convention. > > > iii. 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 > > a. Transaction_Type > > > i. 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? > > b. Object_Type > > > i. 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. > > c. DateTime > > > i. Shouldn’t this be Date_Time to be consistent with the format of the > other data elements? > > d. Term > > > i. Why not use Period instead of Term to be consistent with the element > used in EPP? > > e. Fee > > > i. 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. > > f. Status > > > i. 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? > > > ii. 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”. > > g. Registrar > > > i. There is the chance that the free-form registrar name could include > the delimiter, so the use of quoting will be needed. > > h. Period > > > i. 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 > > a. 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. > > b. 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. > > c. 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. > > d. Trade > > > i. 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 > > a. Start_Date > > > i. 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? > > b. RGP_Date > > > i. RGP_Date is not descriptive enough. I believe this should be > Redemption_End_Date. > > > ii. Purge_Date > > 1. This could be Pending_Delete_End_Date, which is when the purge > occurs, and the domain becomes available. > > c. Where is Transfer_Date? > > > i. I believe that all the dates in RFC 5731 should be supported at a > minimum. > > 2. Registration Information Data Elements > > a. Registrar_ID > > > i. You may want to separate Registrar_ID from IANA_ID or GURID to > enable inclusion of both. > > b. Server_Registrant_ID > > > i. 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. > > > ii. My recommendation is to define a Registrant_ID element that should > be defined by the client, per RFC 5733. > > c. Server_Contact_ID > > > i. 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. > > > ii. My recommendation is to define a Contact_ID element that should be > defined by the client, per RFC 5733. > > d. In_Use > > > i. How about using Linked, which matches the language used in RFC 5733? > > e. Nameserver_Host > > > i. How about Host_Name to be in line with the naming in RFC 5732? > > f. Nameserver_IP > > > i. How about Host_IP or Host_IPs to be in line with the naming in RFC > 5732? > > > ii. How is the list of IPs handled in the report? > > g. Client_Contact_ID > > > i. I recommend changing this to Contact_ID, which is assigned by the > client (registrar), per RFC 5733. > > 3. Report Definition Specification > > a. “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.” > > > i. 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. > > b. I would not refer to them as “transaction rows”, but instead “record > rows”. > > c. 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. > > d. Domain Transaction > > > i. 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. > > > ii. Would it be good to include the domain ROID to uniquely identify > the domain name instance? > > > iii. 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. > > > iv. The Period, Term, Fee, and Currency will only apply to certain > Transaction_Types. > > > v. 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. > > > vi. 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. > > e. Premium Name > > > i. What is the purpose of the Status element? > > > ii. What is the purpose of the Description element? My recommendation > is to remove this element unless there is a concrete reason for it. > > > iii. Can the Start_Date be described? > > f. Domain RGP > > > i. 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. > > > ii. 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. > > g. Reserved Domain > > > i. 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? > > h. Domain Inventory > > > i. 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. > > i. Contact Inventory > > > i. 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? > > > ii. It’s not clear whether this report is generated per registrar and > if it is why would the Registrar_ID element be needed. > > > iii. I don’t get the purpose of the Server_Contact_ID, since that > doesn’t match RFC 5733. > > > iv. 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. > > > v. What is the purpose of the Contact_Type unless this is meant to > represent the linkage of the domains to the contacts? > > > vi. Is the Registrar_ID associated with the Domain or the Contact. I > would assume the Contact, but I’m not sure. > > j. Host Inventory > > > i. 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/ > <http://secure-web.cisco.com/1RbMfcU_WmdM7bb-Ct6l_ifNi8ddlLU-IxAwLypkMxNt2bQSN8mh3ii9PxsOfL3huRSoQHRJ_ZOUoDeO9M6G1o2IN7JnBuWe5kMzYwo9xd4swHDgvxgdDmY3bSBfDGQmuMVQBatVUzyBaif50F6x7y-3IxK3NHxyJCTONrGmRZ2yAxa_7s3gA3MxJEHhFOAUEOZwbjhYLMgY_R7ssWBIVpx1fmm0zvHq01RwZAXoSu6WJuZFvDD0r6EoGdvaUKABT/http%3A%2F%2Fverisigninc.com%2F> > > > > > > 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 > <https://secure-web.cisco.com/11l_Q7yeUjRETjXrFOHGL5EfKl0L2CifceebuuKBMwnmaTG6QmBQ6n2ai7H9fWWkAzgGhe9xbUA82jDaAWB-wZClGsYZ0-0M6bR_2Dp2-lSJVur8x2Jc5KnvpYqWdm6f_45N22H8tFkLb5Yr9zgRoE2Vi0_aXroDD1cIzPjYyN9pn16jxHAWQNZdpDxmzgsP4SZVVFNFvULlXHN5TXuYVMasLLoqEEtow_KPrqZAoID6sskMoglBEslOW4K2t9oUz/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
