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
* 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
* 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.
* 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.
* 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.
* 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
* 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
* 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.
* 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.
* 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
* 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
* 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
* I believe this section can be removed if the draft is just focused on
terminology and not the disclosure of PII.
8. Internationalization Considerations
* 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
[cid:[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: "Hollenbeck, Scott" <[email protected]>
Date: Tuesday, February 14, 2023 at 12:49 PM
To: "[email protected]" <[email protected]>, James Gould <[email protected]>
Cc: "[email protected]" <[email protected]>
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 <[email protected]>
Sent: Tuesday, February 14, 2023 11:11 AM
To: Gould, James <[email protected]>; Hollenbeck, Scott
<[email protected]>
Cc: [email protected]; Steve Crocker <[email protected]>
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
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
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"
<[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>> on behalf of
[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>>
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
[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
