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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Sep 2015 09:52:12 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-dns-terminology-04: 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-dns-terminology/

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

This is a really great resource. Thank you for putting it together.

I had a few points where I wasn't understanding the text as well as I'd
hoped. I offer them, in case you see better ways to explain things, but
no response is needed if the answer is "Spencer just needs to pay
attention".

If this 

      For example, at the time this document is published, the "au" TLD
      is not considered a public suffix, but the "com.au" domain is.
      (Note that this example might change in the future.)
      
is intended to say that a subdomain may be a public suffix when its
domain is not, that could be stated more clearly. If it's intended to say
something else, I don't know what that is (and "For example" didn't
help!)

In this text

      Some servers do not honor the TTL on an
      RRset from the authoritative servers, such as when the
      authoritative data has a very short TTL.
      
I wasn't sure what "do not honor" meant - discarding the RRset before the
TTL has expired, hanging onto the RRset after the TTL has expired, or
flipping a coin?

In this text

   DNSSEC-aware and DNSSEC-unaware:  Section 2 of [RFC4033] defines many
      types of resolvers and validators, including "non-validating
      security-aware stub resolver", "non-validating stub resolver",
      "security-aware name server", "security-aware recursive name
      server", "security-aware resolver", "security-aware stub
      resolver", and "security-oblivious 'anything'".  However, "DNSSEC-
      aware" and "DNSSEC-unaware" are used in later RFCs, but never
      formally defined.  (Note that the term "validating resolver",
      which is used in some places in those documents, is nevertheless
      not defined in that section.)
      
so, there's no formal definition anywhere? Maybe that could be the first
thing that this list item says? It's somewhat buried under all the terms
that ARE defined, which seems backwards.

I'm also slightly confused about why "validating resolver" is mentioned
in this list item, instead of appearing in a separate list item. Is the
common element that it's not defined anywhere else, either?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 17 Sep 2015 10:03:03 +0200

On Wed, Sep 16, 2015 at 09:52:12AM -0700,
 Spencer Dawkins <[email-masked]> wrote 

> TTL has expired, hanging onto the RRset after the TTL has expired, or

"Discarding the RRset before the TTL has expired" is not a protocol
violation: there are many legitimate reasons why a resolver might do
so (lack of memory, for instance). The text in the draft referred to
"hanging onto the RRset after the TTL has expired" (hence the
reference to "very short TTL") which *is* a protocol violation.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2015 08:10:06 -0500

Hi, Stephane,

> reference to "very short TTL") which *is* a protocol violation.

Right. Your explanantion is clearer than "do not honor".

Thanks,

Spencer

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 18 Sep 2015 12:08:23 -0700

> something else, I don't know what that is (and "For example" didn't

It is just an example of what we already said was an area of 
disagreement.

> TTL has expired, hanging onto the RRset after the TTL has expired, or

Good catch; will fix with different wording.

> that ARE defined, which seems backwards.

We are trying to point out that there are many terms that can be used 
better than these two, not to criticize the use of them.

> common element that it's not defined anywhere else, either?

More the fact that it is another DNSSEC-related term.

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Sep 2015 15:41:07 -0500

Hi, Paul,

On Fri, Sep 18, 2015 at 2:08 PM, Paul Hoffman <[email-masked]> wrote:

> It is just an example of what we already said was an area of disagreement.

Hmmm. I didn't get that from the text. I'm not understanding what the
question is, that people disagree about the answer to. Could you help me
understand that?

> better than these two, not to criticize the use of them.

I wonder if flipping the order would make your point more clearly.

DNSSEC-aware and DNSSEC-unaware:  these two terms are not
    defined in Section 2 of [RFC4033], but many
    types of resolvers and validators, including "non-validating
    security-aware stub resolver", "non-validating stub resolver",
    "security-aware name server", "security-aware recursive name
    server", "security-aware resolver", "security-aware stub
    resolver", and "security-oblivious 'anything'" are defined there.
    "DNSSEC-aware" and "DNSSEC-unaware" are used in later RFCs,
    but the terms that have been formally defined are likely better
    choices for new documents. (Note that the term "validating resolver",
    which is used in some places in those documents, is nevertheless
    not defined in that section.)

> More the fact that it is another DNSSEC-related term.

That helps. Perhaps s/nevertheless/also/ would have made this point more
clearly to me.

Thanks!

Spencer

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 18 Sep 2015 13:59:58 -0700

> question is, that people disagree about the answer to. Could you help 

I think I see the problem now. The text can simply be "For example, at 
the time this document is published, the "com.au" domain is considered a 
public suffix. (Note that this example might change in the future.)".

> That helps. Perhaps s/nevertheless/also/ would have made this point 

These seem like reasonable changes.

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Sep 2015 17:06:22 -0500

Hi, Paul,

Thanks for the followup! That works ...

Spencer

On Fri, Sep 18, 2015 at 3:59 PM, Paul Hoffman <[email-masked]> wrote:

> I think I see the problem now. The text can simply be "For example, at the
> time this document is published, the "com.au" domain is considered a public
> suffix. (Note that this example might change in the future.)".
>