DNSDIR Review: DNS Considerations Update

[kyzer-davis]

From Email:

Reviewer: Florian Obser
Review result: Ready with Issues

I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir

This document reference the DNS as one of multiple possible name spaces for Name-Based UUID Generation. It has no considerations that reflect on the DNS.

Issue:

The document does not reference any DNS RFCs.

Section 5.3, 5.5 and 6.5 refer to "a canonical sequence of octets in network byte order". It is not specified what that canonical sequence is nor is there a reference to a document that specifies the canonical sequence for any of the name spaces.

Section 6.5 also has this:
   *  UUIDs generated at different times from the same name in the same
      namespace MUST be equal.

It is unclear to me how to implement that MUST if there is not a single canonical sequence specified for a given name space, as is the case for DNS.

For DNS RFC 8499 has this:
      Format of names: Names in the global DNS are domain names.  There
      are three formats: wire format, presentation format, and common
      display.

The test vectors in Appendix C use the common display format, i.e. they leave off the root label and the "." before it.

I'm not sure how best to address this issue, options include:
- refer to specifications for all the name spaces and point at the
  canonical sequence (in case of DNS this means RFC 8499 and choosing
  common display)
- mark it out of scope, like is done for "uniqueness within their name
  spaces".
- mark it out of scope, but point out that applications must (MUST?)
  agree on what the canonical sequence is.

Author comment:

• Option 1: at first seems logical way to solve this. We can also note the same for URL, OID, X500 and add a "Note on Names" section to "6.5. Name-Based UUID Generation"
• Option 2: also seems logical, can provide an example citing RFC 8499 and show that there are 3 possible ways to ways to represent DNS (Common: www.example.com, Presentation: www.example.com., Wire: 3www7example3com0) and the one selected for "name" input is up to the implementor.
• Option 3: similar to option 2 but much more hand waving

Personal Preference:

• Leaning Option 2, may also need to back out ISO OID acronym #117/Fix errata 6225 (again); GitHub issue #117 #118 which added OID dot notation guidance e.g "Object Identifiers (OIDs) in dot-notation without leading dot"

Reasoning:

• Current Name-space UUID generators allow arbitrary input from my most resent testing. (uuidgen, python, uuidtools.com, etc.)
• I would like to be able to cite URL, OID, X500, DNS as informative references.

[danielmarschall]

Personally, I would be glad if all four namespaces would receive a notation guidance, for example

• URL => FQDN
• OID => dot-notation without leading dot
• X500 => text representation [but I think this breaks RFC4122 backwards compatibility where it says text or DER notation?]
• DNS => common format

This way, we can assume that equal UUID means that the same name was used, and in general I think it is always good to have canonical formats

[danielmarschall]

In case you decide to rollback #117 and #118, please make sure that the term "ISO OID" (errata 6225) don't get reintroduced. It should be "OID" or "Object Identifier (OID)". Thank you.

[kyzer-davis]

In case you decide to rollback #117 and #118, please make sure that the term "ISO OID" (errata 6225) don't get reintroduced. It should be "OID" or "Object Identifier (OID)". Thank you.

Yeah, understood on the point.

[LiosK]

Taking Option 2 to keep them as ambiguous as were in RFC 4122 but also adding another set of namespace identifiers with strict notation guidance to ensure future interoperability?

[kyzer-davis]

@LiosK, @bradleypeabody, @danielmarschall:
I took a stab at this in 7c6026b

Let me know what you think.

[bradleypeabody]

Looks good to me, I have no objection.

[danielmarschall]

I have a few requests for the OIDs in the section "A note on names":

• The Cisco OID (1.3.6.1.4.1.9) should not be used as an example, since there is a special example OID (2.999) for the purpose of documentation.

• Besides the dot notation (2.999 or .2.999), there are two other important notations:

  • There is also the Abstract Syntax Notation One (ASN.1) notation in various forms, e.g. (including but not limited to):
    { 2 999 }, { joint-iso-itu-t(2) example(999) }, or { joint-iso-itu-t example(999) }.

  • As well as the Internationalized Resource Identifier (OID-IRI) notation in various forms, e.g. (including but not limited to):
    /2/999, /Joint-ISO-ITU-T/Example, or /Example.

  • The reference for ASN.1 and OID-IRI notation is Rec. ITU-T X.680 | ISO/IEC 8824-1.

I am unsure about creating a pull request, because I want to avoid that you have trouble with a change conflict if I change something that already has a pull request.

Can you please make these two changes for me? Thank you very much.

[LiosK]

LGTM!

[kyzer-davis]

@danielmarschall, yeah I can switch it to 2.999 and .2.999 I wasn't aware of that Example OID but I know the Cisco one by heart :)

As for the second item, I will see what I can do to cite X.680 but I dont' know if we need any further examples since the text is already getting long and the point that "these things can be represented in many different ways" is sufficiently detailed.

Edit: done Check below, added a single X.680 example since we got some space back from removing the Cisco OID.
972e2e4

Edit2: X.660 > X.680

[danielmarschall]

@danielmarschall, yeah I can switch it to 2.999 and .2.999 I wasn't aware of that Example OID but I know the Cisco one by heart :)

I haven't seen 2.999 often, but I am very proud of it, because I was literally its inventor 12 years ago :)

As for the second item, I will see what I can do to cite X.680 but I dont' know if we need any further examples since the text is already getting long and the point that "these things can be represented in many different ways" is sufficiently detailed.

Edit: done Check below, added a single X.660 example since we got some space back from removing the Cisco OID. 972e2e4

Thank you very much. It is compact and your wording includes all possible notations of X.680, so it's perfect. 👍