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

From: Spencer Dawkins <[email-masked]>
Date: Mon, 27 Aug 2018 20:55:13 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is definitively a labor of love. Thanks for doing the work!

I have some musings. Do the right thing, of course.

Thank you for producing this valuable doc.

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?

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.

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?

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?

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 …

"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 …

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.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Aug 2018 19:52:01 +0000

> providing a reference, for all the Javascript and Python programmers who

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.

> 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)". :-)

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

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

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

> meant without Googling it. You guys know your intended audience, of course …

We like using perfectly good words. 

> Perhaps adding a pointer to Section 10 would be helpful to readers who lack

We will add that pointer.

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 28 Aug 2018 16:31:11 -0500

Hi, Paul,

On Tue, Aug 28, 2018 at 2:52 PM Paul Hoffman <[email-masked]> wrote:

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

That's better than anything I was thinking about (I've been reviewing
drafts for too long. Sorry!)

> 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)". :-)
>

Right. Emphasizing that this may not be a solvable problem, my point was
that I can easily imagine that what was once "<https://pti.icann.org/> "
would disappear and something like "<https://tcifo.icann.org/>" would pop
up when The Competing IANA Functions Operator takes over, which is more
drastic, so you get 404 Not Found.

In a perfect world, ICANN would return 301 Moved Permanently, I suppose.
Mumble. Moving on.

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

Yes, exactly. If you guys think you might have readers that don't realize
that, perhaps

 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, because the query reveals more
      information about the user making the request than the response does.

would be helpful. Do the right thing, of course.

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

Sure. I wouldn't ask you to change the direct quotation. I noted that the
document does make some comments about how the quote maps onto current
practice.

Do the right thing, of course.

> We will add that pointer.

Thanks for that, of course.

Spencer