On 18 Sep 2015, at 13:41, Spencer Dawkins at IETF wrote:
Hi, Paul,
On Fri, Sep 18, 2015 at 2:08 PM, Paul Hoffman <[email protected]>
wrote:
On 16 Sep 2015, at 9:52, Spencer Dawkins wrote:
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!)
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?
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.)".
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.)
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?
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.
These seem like reasonable changes.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
