Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01
On Sun, Dec 19, 2021, at 21:23, Jiankang Yao wrote: > How about renaming "DNS Data Dictionary" to "DNS Registration Data > 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 p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01
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 wrote: > > 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 > > ___ > 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
Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01
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 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01
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 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 Edgemoor Research Institute ___ 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
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 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 > Edgemoor Research Institute > ___ > 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
[regext] Request to adopt draft-flanagan-regext-datadictionary-01
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 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
