Hello Heather, Steve, Overall, this doc should prove useful to anyone embarking on creating or evolving a registration protocol. While reviewing the latest draft, had some observations/feedback (sorry for the delay):
Unless this doc, as-is, is intended for just the DNRs (Domain Name Registries/Registrars), should it not include data elements that cover the RIRs (Regional Internet Registries) side semantics as well? If so, including the IP Address and Autonomous System (AS) Number data elements would be a good start. Further, unless the "A security principle to keep in mind as new reports are developed is that it is considered a bad practice to report or disclose security information." statement in the Security Considerations section is the reason why we have presently no elements related with the DNSSEC, would be good to include the DNSSEC related elements. EPP has a related extension mapping ([1]), and the RIRs have related payloads in their registration APIs (e.g. [2]). Similarly, specific to the RIRs, the registration APIs have RPKI related payloads (e.g. [3]). If the DNSSEC related elements are defined, would be good to include relevant RPKI related elements for the RIRs side. Some minor feedback for the current content: Section 1. Introduction: "The Registration Data Dictionary provides a common set of names and definitions for data element that may be used in any registration protocol, including the DNS." Should it be "data elements"? Further, should it be "including for the DNS" since DNS is itself not a registration protocol, AFAIK? Section 2.13. Element name: Source & Method: Do we need to elaborate on the "Method" part here? Section 2.15. Element name: Name: Since role entities exist in registries, do we need to expand the definition to account for a role name, or create another data element for it? Section 3.1.2.1.1. Data Element Definition: Is "Name of data element type" moot now, per the "-02: Removed all format syntax guidance." change log? If not, the description for "Name of data element type" reads the same as that for "Name of data element"; is that intended? Section 3.2.1. Data Element Definition in IANA Registry: Is the "This RFC Section 2.1." in the first "BEGIN FORM/END FORM" section intended? Further, why 2 "BEGIN FORM/END FORM" sections? Regards, Jasdip [1] https://www.rfc-editor.org/rfc/rfc5910 [2] https://www.arin.net/resources/manage/regrws/payloads/#delegation-key-payload [3] https://www.arin.net/resources/manage/regrws/payloads/#route-origin-authorization-roa-payload On 2/13/23, 9:03 AM, "regext on behalf of James Galvin" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of gal...@elistx.com <mailto:gal...@elistx.com>> wrote: This is a reminder to please indicate your support or no objection to the publication of this document. The Document Shepherd should take note that the WGLC for this document was noted on the DNSOP mailing list. Thanks to Scott Hollenbeck for doing this and making it relevant for them to consider. The WGLC is scheduled to end on Monday, 20 February 2023. Thanks, Antoin and Jim REGEXT WG Co-Chairs On 6 Feb 2023, at 9:40, James Galvin wrote: > The document editors have indicated that the following document is ready for > submission to the IESG to be considered for publication as a Proposed > Standard: > > Registration Data Dictionary > https://datatracker.ietf.org/doc/draft-ietf-regext-datadictionary/03/ > <https://datatracker.ietf.org/doc/draft-ietf-regext-datadictionary/03/> > > Please indicate your support or no objection for the publication of this > document by replying to this message on list (a simple “+1” is sufficient). > > If any working group member has questions regarding the the publication of > this document please respond on the list with your concerns by close of > business everywhere, Monday, 20 February 2023. If there are no objections the > document will be submitted to the IESG. > > The Document Shepherd for this document is Stéphane Bortzmeyer. > > Thanks, > > Antoin and Jim > REGEXT WG Co-Chairs _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
