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> 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 > 1. 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 > 1. 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. > 2. 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. > 3. 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. > 4. 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 > 1. 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 > 1. 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. > 2. 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. > 3. 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 > 1. 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 > 1. 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 > 1. I believe this section can be removed if the draft is just > focused on terminology and not the disclosure of PII. > 8. Internationalization Considerations > 1. 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 > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *"Hollenbeck, Scott" <shollenb...@verisign.com> > *Date: *Tuesday, February 14, 2023 at 12:49 PM > *To: *"st...@shinkuro.com" <st...@shinkuro.com>, James Gould < > jgo...@verisign.com> > *Cc: *"regext@ietf.org" <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> > *Sent:* Tuesday, February 14, 2023 11:11 AM > *To:* Gould, James <jgo...@verisign.com>; Hollenbeck, Scott < > shollenb...@verisign.com> > *Cc:* regext@ietf.org; Steve Crocker <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> 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 > <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> on behalf of > shollenbeck=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> > > 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 > 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 > https://www.ietf.org/mailman/listinfo/regext >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
