Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

[Tim Wicinski <[e-mail]>]

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=
[e-mail]> 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
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *"Hollenbeck, Scott" <[e-mail]>
> *Date: *Tuesday, February 14, 2023 at 12:49 PM
> *To: *"[e-mail]" <[e-mail]>, James Gould <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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 <[e-mail]>
> *Sent:* Tuesday, February 14, 2023 11:11 AM
> *To:* Gould, James <[e-mail]>; Hollenbeck, Scott <
> [e-mail]>
> *Cc:* [e-mail]; Steve Crocker <[e-mail]>
> *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=
> [e-mail]> 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
> [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/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" <
> [e-mail] <mailto:[e-mail]> on behalf of
> shollenbeck=[e-mail] <mailto:
> [e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
>
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>