Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

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

On 26 Jun 2018, at 10:09, Vladimír Čunát wrote:

> Greetings!
>
> I really like the draft, and I'm sorry to be so late. 

This is not late, especially if you really like the draft. :-)

> I see one minor
> issue just below and then a few nitpicks that I don't feel strongly 
> about.

I'm marking these in the GitHub repo.

>
>
>> NXDOMAIN:
>>     "Name Error - Meaningful only for responses from an 
>> authoritative
>> name server, this code signifies that the domain name referenced in
>> the query does not exist." (Quoted from [RFC1035], Section 4.1.1.)
>> [RFC2308] established NXDOMAIN as a synonym for Name Error.
>
> I dislike keeping this formulation; it might confuse people.  It 
> seems
> to imply that NXDOMAIN from a resolver isn't "meaningful", and
> that's clearly not true, at least not nowadays.  (I develop a 
> resolver.)

The quoted definition makes sense without the "Meaningful only for 
responses from an authoritative name server" phrase, so we can remove it 
and still have it be useful.

> "Resolver" definition: I don't think the word really implies it runs 
> on
> the same machine as the program asking it.  In particular, the 
> purpose
> of stub resolvers is to ask a recursive *resolver* that is typically 
> on
> another machine.  Perhaps I misunderstand that RFC1034 part.  I 
> found
> one comment on this particular point but no reactions:
> https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w

We did indeed miss this. In staring at that longer, I agree that the 
quote from 1034 is not true for the current understanding of a resolver. 
We can remove it.

> "Authoritative-only server" definition: "ignores requests for 
> recursion"
> might mislead into thinking the DNS request is not replied to, whereas 
> the
> server is supposed to return either REFUSED or a referral.
> Maybe I'd say something like "ignores the RD bit being set to 1".

Well, the authoritative server doesn't ignore the RD bit, either: it 
just doesn't do the recursion that was asked for. Thus you want the 
terminology document to (a) update an RFC that (b) is a BCP that (c) was 
co-written by my boss. Trifecta!

Instead of changing the wording of the BCP, we can instead add "In this 
case 'ignores requests for recursion' means 'responds to requests for 
recursion with responses indicating that recursion was not performed'". 
Does this work for you?

> "Slave server", "Master server": I'm surprised to read that current
> common usage has shifted to "secondary" and "primary" instead, but 
> that
> is better judged by people working with authoritative servers (and not 
> me).
>
>
>> Open resolver: A full-service resolver that accepts and processes
>> queries from any (or nearly any) stub resolver. [...]
>
> Perhaps not from any "stub resolver" but from any "client".  *Who* 
> asks
> really isn't the point.

Very good point! In fact, many open resolvers allow forwarding from 
other recursive resolvers.

> "Authoritative data" definition: there might be a mention of special
> cases added later or perhaps switch quotation to one from 
> rfc4033#section-2

Yes; will add pointer there.

> "Bailiwick" definition: I have (also) seen use like "in-bailiwick
> records" in the sense being in a subdomain.  I can't really judge how
> common that usage is, but it has already been discussed wrt. this 
> draft:
> https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io 
> My understanding of that thread is that the meaning was planned to be 
> extended
> in the draft, but the current text seems still restricted to name 
> servers.

We opened a discussion for bailiwick and incorporated what we could from 
that discussion.

> "NSEC3" definition, this is clearly a typo (missing "3"):
>
>> NSEC resource records require associated NSEC3PARAM resource records.

Good catch!

> I'm not really sure if a best-practice RFC is really allowed to 
> "update"
> a standards-track RFC (2308), but I assume the authors and chairs know
> the process much better than me.  (From my point of view it's OK.)

It is indeed OK. BCPs are considered "standards track" themselves.

--Paul Hoffman