Re: Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]