Subject: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

From: Steve Crocker <[email-masked]>
Date: Sat, 18 Dec 2021 09:38:49 -0500

We request the REGEXT WG adopt draft-flanagan-regext-datadictionary-01 as a
work item.  The goal is to establish a IANA registry of data elements that
are commonly used in multiple applications that handle registration data.

We anticipate this dictionary will be overseen by an IESG-appointed set of
experts.  The existence of this dictionary will not impose any requirements
that all of these data elements will be collected nor that any particular
set of these will be made available in response to requests.  Rather, the
intent here is simply to provide a common list of possible data elements
and a publicly visible set of names for the data elements.

We expect there will be additions to the dictionary, so the list of data
elements in the current draft is most likely not complete.  That said, we
feel it is useful to move forward with the review and adoption process.  If
and when other data elements are proposed, they can be included through the
usual process.

Thank you,

Heather Flanagan
Steve Crocker
Edgemoor Research Institute

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 18 Dec 2021 21:36:33 -0500

REGEXT chairs

Please count this as my +1 for adopting this work. I find this highly
relevant to not just create this dictionary, but offer precise definitions
for terms to avoid any "squishness" which seems to come back to bite up
when we least expect it.  The work in DNSOP on DNS Terminology is a good
example of doing something a little dull provides benefits elsewhere.

Tim

On Sat, Dec 18, 2021 at 9:39 AM Steve Crocker <[email-masked]> wrote:

> We request the REGEXT WG adopt draft-flanagan-regext-datadictionary-01 as
> a work item.  The goal is to establish a IANA registry of data elements
> that are commonly used in multiple applications that handle registration
> data.
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 20 Dec 2021 10:23:09 +0800

Hello all,

  I agree with Tim's point. Support +1
 RFC8499 provides the DNS terminology, which provides a list of DNS protocol related terminology.
  This document can provide a neutral DNS Data Dictionary related to Domain name registered data. I think that it will be useful for registry, registrar and registrant.

One suggestion:
  RFC8499 is named with "DNS terminology" while this document is named with "DNS Data Dictionary".
  Just having a quick look at these two names, it seems it is not easy to distinguish between them.

  How about renaming "DNS Data Dictionary" to "DNS Registration Data Dictionary" or seome else?

Best Regard.

Jiankang Yao
 
From: Tim Wicinski
Date: 2021-12-19 10:36
To: regext
Subject: Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

REGEXT chairs

Please count this as my +1 for adopting this work. I find this highly relevant to not just create this dictionary, but offer precise definitions for terms to avoid any "squishness" which seems to come back to bite up when we least expect it.  The work in DNSOP on DNS Terminology is a good example of doing something a little dull provides benefits elsewhere.

Tim

On Sat, Dec 18, 2021 at 9:39 AM Steve Crocker <[email-masked]> wrote:
We request the REGEXT WG adopt draft-flanagan-regext-datadictionary-01 as a work item.  The goal is to establish a IANA registry of data elements that are commonly used in multiple applications that handle registration data.

We anticipate this dictionary will be overseen by an IESG-appointed set of experts.  The existence of this dictionary will not impose any requirements that all of these data elements will be collected nor that any particular set of these will be made available in response to requests.  Rather, the intent here is simply to provide a common list of possible data elements and a publicly visible set of names for the data elements.

We expect there will be additions to the dictionary, so the list of data elements in the current draft is most likely not complete.  That said, we feel it is useful to move forward with the review and adoption process.  If and when other data elements are proposed, they can be included through the usual process.

Thank you,

Heather Flanagan
Steve Crocker

---

From: George Michaelson <[email-masked]>
Date: Mon, 20 Dec 2021 12:42:01 +1000

I think this work is worth pursuing. But with a couple of caveats.

1) it's hard to change the wider community around "normative language"
and so we have to set realistic goals for actually moving the marker
in the wider community to what words people use. That doesn't mean it
isn't worth being clear, but it would have to be taken as read people
will continue to expect to use other language. Lets document terms but
not expect there to be agreement in the wide to use them?

2) some marginalia in how the RIRs discuss things is hyper specific to
one RIR even if the concept is similar in another RIR. The term "Local
Internet Registry" or LIR really only has specific meaning in the RIPE
region even if we all use it from time to time. The Term NIR only has
specific meaning in APNIC, bound into how we structure. The analogous
concept in the LACNIC region is really not identical. And, concepts
like "portable" and "non-portable" addresses, PI/PI,
Assignment/Allocation are not always well understood. I have some
concerns these kinds of things will cause problems, and like cases
exist inside the domain-registry world. I admit that from time to time
I struggle with some nuances in "Registrar lock" -was it something I
chose, or something done to me against my will (for instance)

I agree with Jiankang that the similarity to the DNS terminology draft
is unfortunate. I would stick to registration, distinct from DNS.
REGEXT is about more than DNS registry, so the ontology here has to be
about more than DNS too.

What would it do to charter? Does it require consideration against
charter goals?

What would it do to the RDAP/EPP pace of work? This work spans both. I
continue to find the pace of document movement between the two
sub-classes confusing. This adds to the confusion perhaps?

cheers

-george

---

From: Steve Crocker <[email-masked]>
Date: Sun, 19 Dec 2021 22:02:51 -0500

George,

Thanks for your thoughtful comments.  I look forward to responses from others.  I’m certainly open to changes that improve clarity and/or usability.

Steve

Sent from my iPhone

> On Dec 19, 2021, at 9:42 PM, George Michaelson <[email-masked]> wrote:
>

---

From: "Patrick Mevzek" <[email-masked]>
Date: Sun, 19 Dec 2021 23:21:26 -0500

> Dictionary" or seome else?

You could even drop "DNS" from "DNS Registration Data Dictionary". 

First because even today by domain name registrars and registries, EPP/RDAP
are used for things that are not related to the DNS at all (ex: contacts).

Second because EPP was created as a generic provisioning protocol that
technically could handle things completely unrelated to domain names,
even if it is its only major public generic use.

-- 
  Patrick Mevzek
  [email-masked]