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

[Joseph Yee <[e-mail]>]

Noted, like the idea to make the name more consistent.

Thanks
Joseph


On Mon, May 23, 2022 at 3:09 PM Gould, James <[e-mail]> 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
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext <[e-mail]> on behalf of Joseph Yee
> <[e-mail]>
> *Date: *Monday, April 11, 2022 at 9:01 AM
> *To: *"Gould, James" <jgould=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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=
> [e-mail]> 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
>
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>
>
> 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 [e-mail]" <
> [e-mail] on behalf of [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-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
>
>     [e-mail]
>
>
> 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
> [e-mail]
> 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>
>
>