Re: [auth48] AUTH48: RFC-to-be 9517 <draft-urn-ddi-06> for your review

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Hi Joachim

Please provide timely answers to the issues the RFC Editor has raised.

Thanks,

Eliot

On 04.12.2023 16:44, [e-mail] wrote:
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search.
> -->
>
>
> 2) <!-- [rfced] To avoid repetition, we removed the first in-text citation
> to [RFC8141].  Please let us know if any corrections are required.
>
> Original:
>     This document registers a formal namespace identifier (NID) for
>     Uniform Resource Names [RFC8141] associated with DDI resources in
>     accordance with the process defined in [RFC8141].
>
> Current:
>     This document registers a formal Namespace Identifier (NID) for
>     URNs associated with DDI resources in accordance with the process
>     defined in [RFC8141].
> -->
>
>
> 3) <!-- [rfced] FYI - to make this sentence clearer, we updated the text as
> shown below. Please let us know of any objections.
>
> Original:
>     The specifications DDI Codebook [DDIC] and DDI Lifecycle [DDIL]
>     are expressed in XML Schema, DDI XKOS - Extended Knowledge
>     Organization System [DDIXKOS] in OWL/RDF, SDTL - Structured Data
>     Transformation Language [SDTL] in JSON Schema, and the upcoming
>     DDI - Cross Domain Integration (DDI-CDI) in UML.
>
> Current:
>     The specifications DDI Codebook [DDI-C] and DDI Lifecycle [DDI-L] are
>     expressed in XML Schema; DDI Extended Knowledge Organization System
>     (XKOS) [DDI-XKOS] in OWL/RDF; Structured Data Transformation
>     Language (SDTL) [DDI-SDTL] in JSON Schema; and the upcoming DDI Cross
>     Domain Integration (DDI-CDI) in UML.
> -->
>
>
> 4) <!-- [rfced] May we remove the entry for DDI Alliance from Section 2?
> The definition is cyclical, as it essentially states "DDI Alliance:
> Alliance for the DDI".  In addition, DDI Alliance is explained in the
> introduction as follows:
>
>     The DDI Alliance is an international collaboration dedicated to
>     establishing metadata standards and semantic products for
>     describing social science data, data covering human activity, and
>     other data based on observational methods.
> -->
>
>
> 5) <!-- [rfced] Would re-arranging the top of this diagram to make it
> easier to read retain the original meaning, or is there another way to
> re-arrange?
>
> Original:
>     Client  NS for       NS for             NS for         DDI
>     services
>             urn.arpa     ddialliance.org    example1.edu   for
>     us.ddia1
>       |       |               |               |               |
>
> Perhaps:
>     Client   NS          NS                NS            DDI
>     services for         for               for           for
>              urn.arpa    ddialliance.org   example1.edu  us.ddia1
>       |       |               |               |               |
> -->
>
>
> 6) <!-- [rfced] FYI - The ordered list element uses only one number per
> step.  Therefore, previously combined steps are now repeated as two
> separate steps.  Does the following update retain the original meaning, or
> is there another way this text should be updated?  Please review, as the
> same text is used for steps in which the arrows point in opposite
> directions.
>
> Original:
>       1.  The name server (NS) of IANA for the domain "urn.arpa."
>             is reached with the request "ddia1.us.ddi.urn.arpa." for
>             the DDI agency "us.ddia1".
>
>       2./3. The request is delegated to the name server for
>             "ddialliance.org".
>
>       4./5. The request is delegated to the name server for
>             "example1.edu" (domain of the DDI agency "us.ddia1").
>          *****************************************************
>
> Current:
>     1.  The name server (NS) of IANA for the domain "urn.arpa." is
>         reached with the request "ddia1.us.ddi.urn.arpa." for the DDI
>         agency "us.ddia1".
>
>     2.  The request is delegated to the name server for
>         "ddialliance.org".
>
>     3.  The request is delegated to the name server for
>         "ddialliance.org".
>
>     4.  The request is delegated to the name server for "example1.edu"
>         (domain of the DDI agency "us.ddia1").
>
>     5.  The request is delegated to the name server for "example1.edu"
>         (domain of the DDI agency "us.ddia1").
>          *****************************************************
> -->
>
>
> 7) <!-- [rfced] RFC 2483 was cited in the text but was not included in the
> references section. RFC 2843 (Proxy-PAR) was referenced, but not cited in
> the body of the document.  We believe the numbers may have been tranposed,
> so we updated the reference to point to 2483.  Please let us know if any
> corrections are needed.
>
> Original:
>     Examples of potential services are listed below. The services and
>     appropriate service tags need to be defined in future. The
>     mentioned service tags are from [RFC2483].
> -->
>
>
> 8) <!-- [rfced] Are the following still expected to happen, or have they
> already happened?
>
> A) Original (Section 3.6):
>     The DDI Alliance will promote a service discovery system for
>     identifying available services connected to DDI agencies using the
>     Domain Name System (DNS).
>
> Perhaps:
>     The DDI Alliance promotes a service discovery system for
>     identifying available services connected to DDI agencies using the
>     Domain Name System (DNS).
>
>
> B) Original (Section 5.1):
>     The
>     DDI Alliance will maintain a registry of the assigned values for
>     the DDI agency identifier used in the NSS.
>
> Perhaps:
>     The
>     DDI Alliance maintains a registry of the assigned values for
>     the DDI agency identifier used in the NSS.
>
>
> C) Original (Section 5.3):
>     The DDI Alliance will promote software for the resolution of DDI
>     agency identifiers and service discovery.
>
> Perhaps:
>     The DDI Alliance promotes software for the resolution of DDI
>     agency identifiers and service discovery.
>
> Is the "software" the same as the "service discovery system" mentioned
> earlier (in A above)?  We are having trouble parsng "the resolution of DDI
> agency identifiers and service discovery" - please consider whether the
> text can be clarified.
> -->
>
>
> 9) <!-- [rfced] Is this an IANA action?  We see urn.arpa registered at
> https://www.iana.org/domains/arpa, but the refernce is RFC 3405.
> Normally, we verify that the actions described in the document match what
> appears in the IANA registries.  If this is an IANA-related action, please
> point us to the relevant registry.  If this is not an IANA-related action,
> may we move this text outside of the IANA Considerations section?
> Additionally, would you like to include a link to
> <https://registry.ddialliance.org/> for clarity?
>
> Original:
>     The registration for "ddi" in the "URN.ARPA" zone is approved.
>     Requests for the domain ddi.urn.arpa will be delegated to the name
>     servers of the DDI Alliance.
> -->
>
>
> 10) <!-- [rfced] Note that we have updated DDI-related citation tags for
> readability.  For example:
>
> [DDIC] -> [DDI-C]
> [DDIL] -> [DDI-L]
> [DDIXKOS] -> [DDI-XKOS]
> [DDIID] -> [DDI-ID]
> [DDIALL] -> [DDI-ALL]
>
> Please let us know any concerns.
> -->
>
>
> 11) <!-- [rfced] It is unclear which version of the DDI Codebook is
> intended by this reference.
>
>     [DDIC]    DDI Codebook, DDI Alliance 2000-2014,
>               <https://ddialliance.org/Specification/DDI-Codebook/>.
>
> We see the the following between 2000-2014.  Do you intend to refer to all
> of these?  Or perhaps you want to always refer to the most current version
> of the document?
>
> - Version 1.0 was released in 2000
> - Version 2.0 was released in 2003
> - Version 2.1 was released in 2006
> - Version 2.5
> https://ddialliance.org/Specification/DDI-Codebook/ shows "DDI Codebook 2.5 (under review)."
> https://ddialliance.org/Specification/DDI-Codebook/2.5/ shows
> "Published: 2012-01-17."  This page also mentions "Version 2.6 REVIEW PERIOD through 2022-10-31."
>
> Note that https://ddialliance.org/Specification/DDI-Codebook/ only provides
> entry points for versions 2.1 and 2.5.  Please clarify.  If you intend to
> refer to more than one version, perhaps this can be clarified in the text.
>
> This document is cited/mentioned as follows:
>
> Current:
>     The specifications DDI Codebook [DDI-C] and DDI Lifecycle [DDI-L] are
>     expressed in XML Schema; DDI Extended Knowledge Organization System
>     (XKOS) [DDI-XKOS] in OWL/RDF; Structured Data Transformation Language
>     (SDTL) [DDI-SDTL] in JSON Schema; and the upcoming DDI Cross Domain
>     Integration (DDI-CDI) in UML.
>
>     Information on the DDI specifications (DDI-C, DDI-L, XKOS, Controlled
>     Vocabularies, and SDTL) can be found in the standards section of the
>     DDI Alliance website [DDI-ALL].
> -->
>
>
> 12) <!-- [rfced] Please note the reference for [ABNFPFE] to reflect what
> appears on https://author-tools.ietf.org/abnf.  This page is a replacement
> for http://tools.ietf.org/tools/bap/abnf.cgi.  (Note that
> http://tools.ietf.org/tools/bap/abnf.cgi redirects to
> https://authors.ietf.org/).
>
> Current:
>     [ABNFPFE]  IETF, "IETF Author Tools - ABNF Tools",
>                <https://author-tools.ietf.org/abnf>.
> -->
>
>
> 13) <!-- [rfced] For reference [IS11179], the provided URL resulted in
> "Oops! That page can’t be found." We have updated as follows.  Please let us know any objections.
>
> Original:
>     [IS11179] ISO/IEC 11179 Information technology - Metadata
>               registries (MDR) - Part 6: Registration,
>               <http://metadata-standards.org/11179/>.
>
> Current:
>     [IS11179]  ISO, "Information technology - Metadata registries (MDR) - Part
>                6: Registration", ISO/IEC 11179-6:2023, January 2023,
>                <http://metadata-standards.org/11179/>.
> -->
>
>
> 14) <!-- [rfced] We have removed the following text and corresponding
> referenced, as the RFC was prepared using XML.
>
> Original:
>     This document was prepared using the Word template 2-Word-
>     v2.0.template.dot [RFC5385].
> -->
>
>
> 15) <!-- [rfced] The following references were not cited in the text. We
> have removed the reference entries.  Please let us know if any corrections
> are needed.
>
>     [RFC2026]
>     [RFC5378]
>     [RFC8179]
> -->
>
>
> 16) <!-- [rfced] Please review the "type" attribute of each sourcecode
> element in the XML file to ensure correctness. If the current list of
> preferred values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
> does not contain an applicable type, then feel free to let us
> know. Also, it is acceptable to leave the "type" attribute not
> set.
>
> Also, let us know if any items marked as <sourcecode> should instead by
> <artwork>.
> -->
>
>
> 17) <!-- [rfced] The following abbreviations were not expanded in the document.  Please let us know if the expansion on the right is correct and/or if you would like to add a reference for any of these.
>
>     N2C - URN to URC
>     N2R - URN to Resource
>     REST - Representational State Transfer
>     UML - Unified Modeling Language
> -->
>
>
> 18) <!-- [rfced] It is unclear whether there is a difference between the
> hyphenated and nonhyphenated forms in cases of the terms below (outside of
> sourcecode).  Please review these occurrences in the body of the document
> and let us know any updates consistency updates are needed.
>
>     agency-identifier vs. agency identifier
>     resource-identifier vs. resource identifier
>     version-identifier vs. version identifier
> -->
>
>
> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.
>
> For example, please consider whether the following should be updated:
>     man-in-the-middle
> -->
>
>
> Thank you.
>
> RFC Editor
>
>
>
> On Dec 4, 2023, at 1:40 PM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2023/12/04
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>     Please review and resolve any questions raised by the RFC Editor
>     that have been included in the XML file as comments marked as
>     follows:
>
>     <!-- [rfced] ... -->
>
>     These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>     Please ensure that you review any changes submitted by your
>     coauthors.  We assume that if you do not speak up that you
>     agree to changes submitted by your coauthors.
>
> *  Content
>
>     Please review the full content of the document, as this cannot
>     change once the RFC is published.  Please pay particular attention to:
>     - IANA considerations updates (if applicable)
>     - contact information
>     - references
>
> *  Copyright notices and legends
>
>     Please review the copyright notice and legends as defined in
>     RFC 5378 and the Trust Legal Provisions
>     (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>     Please review the markup in the XML file to ensure that elements of
>     content are correctly tagged.  For example, ensure that <sourcecode>
>     and <artwork> are set correctly.  See details at
>     <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>     Please review the PDF, HTML, and TXT files to ensure that the
>     formatted output, as generated from the markup in the XML file, is
>     reasonable.  Please note that the TXT will have formatting
>     limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>     *  your coauthors
>     
>     *  [e-mail] (the RPC team)
>
>     *  other document participants, depending on the stream (e.g.,
>        IETF Stream participants are your working group chairs, the
>        responsible ADs, and the document shepherd).
>       
>     *  [e-mail], which is a new archival mailing list
>        to preserve AUTH48 conversations; it is not an active discussion
>        list:
>       
>       *  More info:
>          https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>       
>       *  The archive itself:
>          https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>       *  Note: If only absolutely necessary, you may temporarily opt out
>          of the archiving of messages (e.g., to discuss a sensitive matter).
>          If needed, please add a note at the top of the message that you
>          have dropped the address. When the discussion is concluded,
>          [e-mail] will be re-added to the CC list and
>          its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
>   — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>     https://www.rfc-editor.org/authors/rfc9517.xml
>     https://www.rfc-editor.org/authors/rfc9517.html
>     https://www.rfc-editor.org/authors/rfc9517.pdf
>     https://www.rfc-editor.org/authors/rfc9517.txt
>
> Diff file of the text:
>     https://www.rfc-editor.org/authors/rfc9517-diff.html
>     https://www.rfc-editor.org/authors/rfc9517-rfcdiff.html (side by side)
>
> Diff of the XML:
>     https://www.rfc-editor.org/authors/rfc9517-xmldiff1.html
>
> The following files are provided to facilitate creation of your own
> diff files of the XML.
>
> Initial XMLv3 created using XMLv2 as input:
>     https://www.rfc-editor.org/authors/rfc9517.original.v2v3.xml
>
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>     https://www.rfc-editor.org/authors/rfc9517.form.xml
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>     https://www.rfc-editor.org/auth48/rfc9517
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9517 (draft-urn-ddi-06)
>
> Title            : A Uniform Resource Name (URN) Namespace for the Data Documentation Initiative (DDI)
> Author(s)        : J. Wackerow
> WG Chair(s)      :
> Area Director(s) :
>
>