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

["Paul Hoffman" <[e-mail]>]

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