On 11 Sep 2015, at 13:45, Black, David wrote:
The -04 version of this draft addresses most of the concerns noted in
the
Gen-ART and OPS-Dir review of the -03 version. In particular, both of
the major process-related issues have been addressed by retargeting
the
draft to be an Informational RFC instead of a Best Current Practice
RFC.
The following two minor issues still merit attention:
[C] 2. Names - p.5, end of Public suffix definition:
One example of the difficulty of calling a domain a
public suffix is that designation can change over time as the
registration policy for the zone changes, such as the case of the
.uk zone around the time this document is published.
That calls for either an explanation or citation of a reference where
further info can be found on this situation. This seems editorial,
but
RFCs are archival documents, and this sentence is likely to be lost
on
readers in some future decade.
".uk zone" is changed to ".uk TLD" in -04. Additional info should be
provided to explain "the case of the .uk TLD around the time this
document
is published." What is going on with .uk ?
For a document on terminology, this level of detail about an example
seems unwarranted, particularly for an example of a difficulty of using
a term. The reader of the document can easily understand the difficulty
without having to know about .uk's changes.
[D] 8. General DNSSEC - p.16
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'". (Note that the
term "validating resolver", which is used in some places in those
documents, is nevertheless not defined in that section.)
That doesn't seem to actually define anything.
What do those two terms mean?
The -04 version adds the following text before the parenthetical note:
However, "DNSSEC-
aware" and "DNSSEC-unaware" are used in later RFCs, but never
formally defined.
The resulting modified definition still doesn't define anything :-).
Correct. This document says that they are not formally defined, which
should be sufficient for the reader to understand that later RFCs that
used those terms did so without any formal definition.
Is it trying to say that these two terms are undefined and should not
be
used, with use of the more specific terms in RFC 4033 being
preferable?
If so, that's not clear.
We are not making any judgement on RFCs that used those undefined terms.
What happened happened. It is useful to the readers of this document to
know that there are other terms, and that these are not defined.
--Paul Hoffman