I agree that there *could* be value in a registry, but I’d prefer that it point to reference definitions that exist in standards track specifications as opposed to trying to re-specify every term. That way we’d have a single source of information that makes it easier to find definitions, but the chance of those definitions conflicting with standards track specifications approaches zero.
Scott From: Tim Wicinski <tjw.i...@gmail.com> Sent: Friday, February 17, 2023 10:10 AM To: Gould, James <jgould=40verisign....@dmarc.ietf.org> Cc: Hollenbeck, Scott <shollenb...@verisign.com>; st...@shinkuro.com; regext@ietf.org Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-datadictionary-03 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. James I see the value in the registry as I expect this set of information will change over time. Having this structured data/information in one place for all to refer feels simpler than multiple RFCs. tim On Fri, Feb 17, 2023 at 9:02 AM Gould, James <jgould=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> wrote: Steve, To follow-on to Scott’s reply, I personally don’t see the need for the IANA registry. I do see value in defining registration terms and groupings in line with the DNS Terminology of RFC 8499. If an IANA registry is necessary, I agree with Scott that the basis for the IANA registry needs to be clearly defined. This draft does not look to be ready for WGLC. Below I include more detailed feedback on the existing draft (draft-ietf-regext-datadictionary-03): 1. Introduction a. I would not reference “standard data elements”, but simply “data elements”. I would not attempt to classify the terms as “standard”. I also prefer the use of term(s) over data element(s), since data element(s) sounds more related to protocol definition as opposed to general terminology that can be used in defining protocol. 2. Data Element Specification a. If the intent is to strictly define the format of the IANA Registry and to pre-register a set of data elements, formally define the format of the registration fields (e.g., like what exists in section 3.1.2.1.1), and then include an IANA Considerations sub-section with all the formal registrations. This would provide an example for others that want to register data elements to follow. b. Currently, the data elements include a subset of the fields required for the data element registrations. The fields of the data elements that are missing include: Name of data element type and Reference document. My assumption is that the Registrant and Status fields would be included in the IANA Considerations sub-section. I recommend all data elements being fully defined based on the pre-defined format. c. The data elements defined don’t include very unique names (e.g., “Name”), don’t include enough description text in general, and use inconsistent names (acronyms such as NS and use of snake case with “Email_or_phone”). I recommend the inclusion of specific terms that follow a consistent format. d. Some of the data elements are completely new to me, such as “Protection”, “Source & Method”, “User Account ID”, “Person”, “Personal”, “Status & Locks” (locks are statuses), Email_or_phone, Registry UniqueID (do you mean GURID or IANA ID). It would be good for the working group to first off decide on the candidate set of data elements to include. The Domain Name Registration Data (DNRD) Objects Mapping in RFC 9022 includes a full set of registration data elements that can be referenced with groupings in the XML namespaces and data elements within the groupings. At what level of granularity do we want to be? I recommend re-evaluating the set of data elements to include based on the existing registration data RFCs (e.g., EPP 5730 – 5733, DNRD 9022, RDAP 9083). 3. IANA Considerations a. Nit – there looks like a copy paste issue with draft-ietf-regext-simple-registration-reporting in referencing “IANA Registration Report Registry”. 4. Data Element Definition a. It’s unclear what the “Name of data element type” is and how it differs from the “Name of data element”. My recommendation is to just include the “Name of data element”, which must be unique. b. I believe Description is missing. There should be a full description of the data element, including examples of uses of the data element in other RFCs. The “Reference document” should provide a listing of the relevant documents using the data element, even by a different name. c. The “Status” values need to be defined. I’m unclear of the status value of “unknown” and what does an “inactive” status indicate to the client. I see the status references in the “Updating Report Definition Registry Entries” section, but I’m unclear what it means by “lack of implementation” or “a specification becomes consistently unavailable”. Shouldn’t the registration stand on its own and be a stable reference from other locations (e.g., Internet Drafts)? 5. Registration Processing a. I’m not sure what would define a qualified expert for evaluating the registration of general registration terms. I have a concern that new entries can get added that conflict with other uses of the term without having sufficient review by a broad set of industry participants. I recommend focusing on defining the terms in the draft like RFC 8499 to enable the consensus process to be leveraged in what terms are included and what the term definitions are. 6. Security Considerations a. Looks like a copy paste issue from draft-ietf-regext-simple-registration-reporting. The Security Considerations should be similar to the DNS Terminology RFC 8499, as in “These definitions do not change any security considerations for the registration protocols.” 7. Privacy Considerations a. I believe this section can be removed if the draft is just focused on terminology and not the disclosure of PII. 8. Internationalization Considerations a. Looks like a copy paste issue from draft-ietf-regext-simple-registration-reporting. I don’t see the applicability of this section for defining the registration terms. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com<mailto:jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1XJYnyt83jbkYZx2WYF-D1ELYOACHfx2rMPeTh-o8nTQF14zC5JguOL6h-T2ChrqvKSELyPVNW2M095wOJsGQ3s844U-15d2gNcsb7Ft2r1tV0lZ8fkGtzHYaUOXnAXtroRoFerebVvOU4t-HtIO65SjcQbExw2TvxzIBMkqOIcGWfEVEJhiAg3y_joVtuGcRU6qIgNRfvpUhXQpVKXghSuMRowmVVEYfSQz4HFTCXMTfVXdkPcveXoZU8RyUupjIow4k4p-YAI5GKjxArJTDStOh79zvIFhrUwVKLF0hhAilgOMHYQdX0vWgV_IblGGY/http%3A%2F%2Fverisigninc.com%2F> From: "Hollenbeck, Scott" <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Date: Tuesday, February 14, 2023 at 12:49 PM To: "st...@shinkuro.com<mailto:st...@shinkuro.com>" <st...@shinkuro.com<mailto:st...@shinkuro.com>>, James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: RE: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-datadictionary-03 Steve, if the draft gives IANA instructions to create a registry, that’ll happen if the IESG approves the draft for publication as an RFC. The fact that it’s Informational won’t mean that IANA can’t do it. There is no “protocol” in the draft. As such, Standards Track makes no sense. As I said earlier, though, the IETF has RFC precedents for data dictionaries where no IANA registry was needed or used. If the draft is going to deviate from existing practice, it needs to explain why that deviation is necessary. It doesn’t currently do that. Your note below could be a good starting point for text to be added to the draft. Scott From: Steve Crocker <st...@shinkuro.com<mailto:st...@shinkuro.com>> Sent: Tuesday, February 14, 2023 11:11 AM To: Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>>; Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Cc: regext@ietf.org<mailto:regext@ietf.org>; Steve Crocker <st...@shinkuro.com<mailto:st...@shinkuro.com>> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-datadictionary-03 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. James, Scott, et al, The motivation for this proposal was to have a registry of available data elements for everyone who is managing an Internet based registration system to draw upon. An informational RFC would be a way to communicate the idea of having such a registry but would not actually cause one to come into existence. At present, each registration system defines its own terms. There is a huge amount of overlap in terminology and meaning. The point of having a registry of terms is to eliminate or reduce duplication. The existence of a registry of available data elements does not mean that every registry has to use all of the data elements. Thanks, Steve On Tue, Feb 14, 2023 at 11:02 AM Gould, James <jgould=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> wrote: I agree with Scott's feedback on the track being changed to Informational and removal of the IANA Registry. Why doesn't this draft match the approach taken io RFC 8499 for DNS Terminology? The Registration System terms can certainly have overlap with the DNS terms in RFC 8499, where the RFC 8499 reference can be made, but the definition is catered to registration systems. I see value with the terms in RFC 8499 for reference within drafts. I would like to see the same value of terms defined in draft-ietf-regext-datadictionary. The term definitions need to have adequate detail with relevant references made to the registration RFCs (e.g., RFC 5730 - 5733. 9022), which is not currently the case. My recommendation is to refer to this as Registration Terminology instead of Registration Data Dictionary, following the approach taken in RFC 8499 for DNS terminology, and removing the definition of an IANA registry. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com<mailto: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/1d--D6WlFs1EPO4svm_N-UYEoHFRaiMN0kCos51s1uCaXVmte63Oth4oB-3HqpVxaKDyracVHwCHfTR7GhzPla6yE_s6hJVgzLAh3jLSJsyxIoks7ev0TTFvjaBuPSHjhQKymwCNc5wkSyIWx5F30kr3Z45SJNAtBVhjn-dl--acuZTViepx48T83dOiHHI5m7dl87KLc39rjCMRjVXmuBAkFi5Mgw_sKotW1iyjoajyzhqsubqT1k28oASVGC3yaWJ9DrORBmasyrrEZ9GMbmfp_4JR71uBI21i-hMdOHuSuJjDcE-1mvU6-VTmGj4Ve/http%3A%2F%2Fverisigninc.com%2F>> On 2/14/23, 8:14 AM, "regext on behalf of Hollenbeck, Scott" <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of shollenbeck=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org> <mailto:40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>>> wrote: I'm aware of two other RFCs that also define terms like this: 4949 (security) and 8499 (DNS). The intended status for this draft is "Standards Track". At best, this should be Informational in the same way that 4949 is informational. Neither of these RFCs creates a registry. As such, I don't see the need for the registry described in Section 3. If a registry is really needed, it would be helpful to include text that describes why the registry is needed. If a case can be made for the registry I'm also confused by the initial assignment described in Section 3.2. It includes a data element "Name", with a reference to Section 2.1 of the draft, but there is no data element "Name" in Section 2.1. Scott _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> <mailto:regext@ietf.org<mailto:regext@ietf.org>> https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1GVjmKKZ9dScEitOB9E6_UdCLI_Bwpvzs_1vpdFFVTQvaV9DBXlagkQws1sVQyossGUG6PoCD-fsqh0rlsFoElP9ak3KYHQlzVJVBWEyOGEyIrtEIXQ1vXL3N9gyV6l2wpy5VpX7-x9E97cqIMqVv_58UPYW_MDmFTyvG1FWFG4HvmHiS3nBViAjuBOY0HGBlRvXx8K1uks7STwfM7kocTRPdlKstcslBERC8tIb4sAwNKhzXJclASHzJDuW_YAHsJsfgt-n30V-VogCVWyWtYgPacLsaZPEHU8bUM_o483t6qygodwgJOUFp41S3ituf/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1EfI-fAmsJHBVB0nAZmYNjbg4L3y4OoSywrdoz33zWiL3NAnjXjbxXjr_JX7MKDLtqAgFXlxkp8Xc72GziSdHSv5D57WzjKfYzyqcT6UXpGfu_e6tl1Zflxn9jfDgcW9-a-JEi31JddnjtgaojkW4c2i3D6bWu1b_r4tSDdDqy3OJqmAy2Qbh2rgVnu43GeAM9AgzQfknUUFbew8ykbNNzx7O3mqh00J60PvJcqlm5Uf6wsvoXFsc1zAk63lKHSQxOTWaMLxaZ3a5lLO_8J3PWD2fqFP8I5MmU3LGwfLr_apDg9zyU9OsW5xISamvnjUs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
