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

[Tim Wicinski <[e-mail]>]

On Fri, Feb 17, 2023 at 11:38 AM Gould, James <[e-mail]> wrote:

> Tim,
>
>
>
> It would be good to learn from the experience with the DNS Terminology
> RFC 8499 on how to handle Registration Terminology.  Was the use of an IANA
> Registry brought up for the DNS Terminology and if so, what drove the
> approach taken?  Does DNSOP see the need for creating an IANA Registry now?
>
>
>

James

There is no discussion of a registry but also many of the definitions are
still textual, while the data dictionary looks
to be more formal.

Thanks for bringing up RFC8499 - in the updated document now in WGLC, the
definitions of Glue records needing wordsmithing.
But one thing I heard from folks who operate DNS infrastructure,
especially non-DNS folks (think Windows Admins), the one
thing they found the most helpful in discussing what are Glue records was
not the normative language in 8499, but the
table that we included explaining the types of glue record.  Here:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8499bis-05#section-7-2.26

Also, from Implementors we would hear feedback about implementing DNSSEC
algorithms, and guidance on such.
In this case, in RFC8624, the two things which we received great feedback
were the tables on implementation
recommendations.   Here:

https://datatracker.ietf.org/doc/html/rfc8624#section-3
The Tables are being updated relating to the addition of new algorithms,
and we are discussing
generating a 8624-bis document.  However, I have been pushing the point
that these tables/recommendations
should become an IANA registry, with expert review via the working groups.

(I'm skipping the entire _underscore IANA registry we created to
document/formalize the use of using such DNS names,
and have been successful).

So if the WG doesn't want to make a registry, this document should
structure all the data in a very easily
read/references/searched table, to complement any normative language.  I
feel the readers of RFCs are not
IETF RFC writers/editors as much as operators/implementers/etc.  I am
always happy to be proven wrong

tim




Thanks,
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *Tim Wicinski <[e-mail]>
> *Date: *Friday, February 17, 2023 at 11:01 AM
> *To: *James Gould <[e-mail]>
> *Cc: *"Hollenbeck, Scott" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: Re: [regext] WGLC:
> draft-ietf-regext-datadictionary-03
>
>
>
>
>
>
>
> On Fri, Feb 17, 2023 at 10:28 AM Gould, James <[e-mail]> wrote:
>
> Tim,
>
>
>
> The terms could change, but I have a concern that a “small group of
> experts” will not reflect consensus of the broader community on the use of
> terms that may have conflict with other uses.  I believe the approach taken
> by the DNS Terminology RFC 8499 found the right balance without the need
> for an IANA Registry.  What makes registration data terms that much
> different from DNS terms to justify the need for an IANA Registry?
>
>
>
>
>
> I agree with that, and I guess the question is - how often does the
> working group think this list will get updated?
>
> Additions to this list would mean a -bis version of this document in my
> opinion.  That's what we're doing with the DNS
>
> Terminology document (currently in WGLC with some additional updates
> around Glue Records! Comment now!)
>
>
>
> tim
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
> <http://secure-web.cisco.com/1TurI78_IoOJ5UjUOIVGQoaW-EJELi_G83ByA4v1dkOKA30jYOojML0QBh2TMg5o-BoyS9MvCuFNmF7yGoyPo12p3ojmMPz6ngHcSuRB1vRACv96K34ERltWelSl-WZpDDwhECagopkQr7DGo-sM4F1Qk8hwIHCuU2yWxV6-x8CzEwSCflsnGym1iB0tVF3QaNu_TWB8D-46Qqj2CDuiQ-eLVTEHGUHKlsGk8-p-8gAYerHAEGYuCSjfJHNGrvViftzThX5f6DvzQACsllNAPQQ8E6-IyEfEP-oSR4IP-f7g/http%3A%2F%2Fverisigninc.com%2F>
>
>
>
> *From: *Tim Wicinski <[e-mail]>
> *Date: *Friday, February 17, 2023 at 10:10 AM
> *To: *James Gould <[e-mail]>
> *Cc: *"Hollenbeck, Scott" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] WGLC:
> draft-ietf-regext-datadictionary-03
>
>
>
> 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
>
> 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
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
> <http://secure-web.cisco.com/1AeK59eptjmg85flLNbY8YbsQCnUKz5EZhmxUFVFwfXFd2dIzgcxeo6FehJqaZmyKcpyl63QAA3W4fzQuzB6h0sig_Q8ob2pijqSM6lmyKZ2LfRLI70QN8CM3VCaOOaGHX1YmRHq4BQMU68EXf13QHC205gaLA_9oBWYDzZRSHGZP3E3CdtxC3_qTI2zsyKIOkuk6EXiM6HrCOoPg_IRWwCuCutYMv7N-UL2M6RpwRQvoj-zFNof_8WXM3a7Fz0CcZsDx7WYg8I5E-MViPVfPpJ3VIPB3ZVum-UbK_rJfQeI/http%3A%2F%2Fverisigninc.com%2F>
>
>
>
> *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
> <https://secure-web.cisco.com/1Fj-LXC20lQhLSib-yq5xsSMKi-o3cBT4GdUnjwQ0OPUDz8Tj7O3azty68yNIcRCz0qWHzEqI5MikNyD2dsw7Untz0GW7BHjDs5wkaYkIruKunFWpMX_jIjBLPk2p533u06yrikXcP6WZkhYVfGcnJZc-eyTkpWQUkZG7QbTKO-7CZXdjFlEX-XGsSjq8tnbkjMzA4FlGqGKJkk-OEDys_UpikC8NphRkChYaCvX091p8eBDuserTMrxkhab1JVmxeB-f-ejiAkwjqu34vI_CV2O-eBtfo-PjUcuISAScQOg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>