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.
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?
Good catch; will fix with different wording.
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.
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.
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.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
