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

[Joachim Wackerow <[e-mail]>]

Dear RFC Editor,

Thank you for the careful editorial work. This is very helpful. All 
looks good.

My answers to the questions are below in the text. Please come back if 
the answers are not clear enough.

Please note the IANA considerations at question 9 below.

I noticed one additional typo; it is described in the attachment. An 
updated diagram regarding question 5 is also in the attachment.

I approve this RFC for publication on the assumption that some changes 
will be made according to this email exchange.

Kind regards
Joachim

On 4 Dec 2023 22: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 onhttps://www.rfc-editor.org/search.
> -->
> JW: URN resolution (in addition to the ones in the title)
>
> 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].
> -->
> JW: this is fine.
>
> 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.
> -->
> JW: This is fine.
>
> 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.
> -->
> JW: This is fine.
>
>
>
> 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
>       |       |               |               |               |
> -->
> JW: There are two wrong line breaks. See attachment for a new approach. See also 6) below
>
> 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").
>          *****************************************************
> -->
> JW: see attachment. The diagram is made more clear and therefore the related descriptions.
>
> 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].
> -->
> JW: This is correct.
>
>
> 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).
> JW: The suggestion is correct.
>
> 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.
JW: The suggestion is correct.
>
> 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.
> -->

JW: Yes. Suggestion:

The DDI Alliance promotes software for service discovery for identifying 
available services connected to DDI agencies using the Domain Name 
System (DNS). See also Section 3.6 on "Process for Identifier Resolution".

>
>
> 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.
> -->

> JW:The following NAPTR record has been registered in the urn.arpa zone:
>
> Key: ddi
> Authority: DDI Alliance as specified in the document 'draft-urn-ddi-
> 00', available athttps://datatracker.ietf.org/doc/draft-urn-ddi/00/
> [datatracker.ietf.org].
> Record: ddi IN NAPTR 100 10 "" "" "" registry.ddialliance.org.

The above is from a message from IANA. It might be necessary that the 
reference to the document should be updated at IANA to the upcoming RFC 
9517. The same applies to the IANA Registry of URN Namespaces at 
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml 
regarding the URN Namespace "ddi".

I'm not sure who is responsible for that.

Suggested new text:

The following NAPTR record for the key "ddi" has been registered in the 
urn.arpa zone:

     ddi IN NAPTR 100 10 "" "" "" registry.ddialliance.org.

Requests for the domain ddi.urn.arpa will be delegated to the name 
servers of the DDI Alliance.

(the type of syntax is the syntax for DNS records, here for NAPTR, 
described in the section 4. NAPTR RR Format of RFC 3403.)

>
> 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.
> -->
> JW: This is fine.
>
> 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 thathttps://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].
> -->

JW: Thank you for spotting this. The web page is outdated.

Suggested new reference:

[DDIC]    DDI Codebook 2.5, DDI Alliance 2014,
              <https://ddialliance.org/Specification/DDI-Codebook/2.5/>.

>
>
> 12) <!-- [rfced] Please note the reference for [ABNFPFE] to reflect what
> appears onhttps://author-tools.ietf.org/abnf.  This page is a replacement
> forhttp://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>.
> -->
JW: This looks fine to me. I'm not sure what the question is.
>
>
> 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/>.
> -->

JW:

Suggested new reference below according to the note of Sandy Ginoza. 
This is fine.

    [IS11179]  ISO, "Information technology - Metadata registries (MDR) 
- Part
               6: Registration", ISO/IEC 11179-6:2023, January 2023,
<https://www.iso.org/standard/78916.html>.

>
>
> 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].
> -->
> JW: This is fine.
>
> 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]
> -->
> JW: This is fine.
>
> 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>.
> -->
> JW:

  3.1.1. Description

The type is a generic layout form using the order of components and 
component separators, also described as first syntax notation in section 
1.6. Syntax Notation and Common Elements of RFC 2396.

  3.1.2. ABNF Grammar

The type is correct: abnf.

  3.1.3. Regular Expression

The type is a generic regular expression syntax used in XML Schema, see 
https://www.w3.org/TR/xmlschema11-2/#regexs. Regular expression syntax 
is sometimes abbreviated as regex.

  3.1.4. Examples of DDI URNs

Three times: The type is the URN syntax for DDI.

  3.7. Rules for Lexical Equivalence

The type is a generic layout form using the order of components and 
component separators, also described as first syntax notation in section 
1.6. Syntax Notation and Common Elements of RFC 2396.

  Appendix A. Example DNS Records

Type: The three examples A.1, A.2, A.3 use the syntax for DNS records, 
here for NAPTR, described in the section 4. NAPTR RR Format of RFC 3403.

> 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
> -->
> JW:

REST and UML are fine.

Thanks for spotting N2C and N2R. These were used in an older version of 
the document. All three occurrences of N2C should be replaced by I2C in 
the section A.3. DDI Services. All six occurrences of N2R should be 
replaced by I2R in the section A.3. DDI Services. Both, I2C and I2R are 
explained in the section 4.4. Type of Services.

>
> 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
> -->
> JW: Only the hyphenated versions should be used to avoid misunderstanding.
>
> 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
> -->
> JW: The term seems to be established, see:https://en.wikipedia.org/wiki/Man-in-the-middle_attack. I'm not aware of any inclusive version.
>
> 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) :
>
>