Re: [DNSOP] [Ext] Spencer Dawkins' Yes on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Paul Hoffman <[e-mail]>]

On Aug 27, 2018, at 8:55 PM, Spencer Dawkins <[e-mail]> wrote:
> In this text,
> 
> 2.  Names
> 
> ...
> 
>      The common display format is used in applications and free text.
>      It is the same as the presentation format, but showing the root
>      label and the "." before it is optional and is rarely done.  For
>      example, in common display format, a fully-qualified domain name
>      with two non-root labels is usually shown as "example.tld" instead
>      of "example.tld.".  Names in the common display format are
>      normally written such that the directionality of the writing
>      system presents labels by decreasing distance from the root (so,
>      in both English and C the root or TLD label in the ordered list is
>      right-most; but in Arabic it may be left-most, depending on local
>      conventions).
> 
> I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth
> providing a reference, for all the Javascript and Python programmers who
> skipped over C?

We can change this to "the C programming language". I don't think an actual reference is going to help anyone who doesn't recognize the language.

> I'm looking at
> 
>     Administration of names -- Administration is specified by
>      delegation (see the definition of "delegation" in Section 7).
>      Policies for administration of the root zone in the global DNS are
>      determined by the names operational community, which convenes
>      itself in the Internet Corporation for Assigned Names and Numbers
>      (ICANN).  The names operational community selects the IANA
>      Functions Operator for the global DNS root zone.  At the time this
>      document is published, that operator is Public Technical
>      Identifiers (PTI).  (See <https://pti.icann.org/> for more
>      information about PTI operating the IANA Functions.)  The name
>      servers that serve the root zone are provided by independent root
>      operators.  Other zones in the global DNS have their own policies
>      for administration.
> 
> and wondering what the stability of an ICANN URL that refers to the name of the
> current IANA Functions Operator will be in 5-10 years. I'm not sure what else
> you can do to make that more useful if a different operator is selected, but if
> you can do something, maybe that would be useful.

We already say "At the time this document is published". And it's not like documents like RFC 7868 are titled "Cisco's (or Whoever Purchases Them Later) Enhanced Interior Gateway Routing Protocol (EIGRP)". :-)

> I'm looking at this text:
> 
>  Passive DNS:  A mechanism to collect DNS data by storing DNS
>      responses from name servers.  Some of these systems also collect
>      the DNS queries associated with the responses, although doing so
>      raises some privacy concerns.
> 
> and thinking that the problem isn't collecting DNS queries associated with
> responses, it's that it's possible to collect DNS queries associated with
> responses (so, if one of these systems stops collecting DNS queries, you still
> have an exposure; it's just not happening now). Is that wrong?

Yes. Although this definition was well-discussed in the WG, I can see where you missed the salient bit. With RFC 7871, the query gives more information about the user making the request than the response does.

> 
> I'm looking at this text:
> 
>  Privacy-enabling DNS server:  "A DNS server that implements DNS over
>      TLS [RFC7858] and may optionally implement DNS over DTLS
>      [RFC8094]."  (Quoted from [RFC8310], Section 2)
> 
> and seeing a race condition with
> https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which isn't
> news to the authors who contributed to both specifications). Is it worth a
> mention here, given that the DOH draft is already in the RFC Editor queue?

As I said earlier, we are hesitant to change direct quotations from other RFCs. Those same authors might update the definition in the future.

> I may be misreading this text:
> 
>  Parent:  "The domain in which the Child is registered."  (Quoted from
>      [RFC7344], Section 1.1) Earlier, "parent name server" was defined
>      in [RFC0882] as "the name server that has authority over the place
>      in the domain name space that will hold the new domain".  (Note
>      that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
>      [RFC0819] also has some description of the relationship between
>      parents and children.
> 
> but I'm reading it as "the definition in RFC 882 was obsoleted by RFC 1034-5 in
> 1987, and there was no definition until RFC 7344 in 2014". If that's what's
> intended, great, but if that's not your point, perhaps we should talk …

It is indeed what was intended. There are history lessons even in terminology documents.

> "Ostensive" is a perfectly good word according to
> https://www.merriam-webster.com/dictionary/ostensive, but I didn't know what it
> meant without Googling it. You guys know your intended audience, of course …

We like using perfectly good words. 

> In this text,
> 
>  Closest provable encloser:  "The longest ancestor of a name that can
>      be proven to exist.  Note that this is only different from the
>      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
>      Section 1.3)
> 
> "Opt-Out zone" wasn't familiar to me, but it's defined later in the document.
> Perhaps adding a pointer to Section 10 would be helpful to readers who lack
> clue as I do.

We will add that pointer.

--Paul Hoffman