Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

[Tony Finch <[e-mail]>]

Paul Hoffman <[e-mail]> wrote:

Sorry for being slow to respond - other work intruded.

> The indexing tools for RFCs suck in many ways. We assume that if someone
> is looking at the RFC and wonders if a term in defined, they'll use the
> search function of their text editor or web browser.

Yes, totally. But I was thinking about people browsing without a specific
question, who want to get a quick idea of which terms are included or not.

> > "recursive mode" and "iterative mode". No-one uses those phrases.
>
> However, RFC 1034 uses those terms, and there was disagreement on what
> else to use. It would be great for the -bis of this document to have
> specific definitions for the terms people do use, but we doubt we can
> get this now, other than by through exhaustion.

Right, but my point was that the RFC 1034 terminology is not used any
more, so people aren't going to be using the search function of their text
editor to look for them.

Regarding specific definitions, what about my suggestions under "more
definitions" at
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

> > The definition of "authoritative data" is still wrong.
>
> We have done the best we can with this, given that RFC 1034's definition
> is in dispute.

I thought we had cleared it up. Why not adopt my corrected definition at
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html ?

> > I am still unhappy about the description of referrals. (I found them
> > surprisingly slippery when I was writing my suggestions.)
>
> So are we. Again, we hope that we can get consensus for this and other
> slippery terms when we do the -bis.

Grumble. If we just punt this down the field we'll end up with an
annoying and slightly-wrong RFC which is too boring to fix.

I suggested a clearer, less confused definition, based on quotes from
existing RFCs.

> > Under SEP, "RRdata" should be "RDATA".
>
> Fully disagree. If we are quoting an RFC, we should not change the
> words, even the spelling.

There are plenty of other quotes in your draft that have been fixed up so
that they make more sense.

> > Also, I think this sentence from RFC 6781 section 3.2.3 is important
> > because most key management tooling implements it - "It is suggested
> > that the SEP flag be set on keys that are used as KSKs and not on keys
> > that are used as ZSKs."
>
> That is good advice, but not really part of the definition of the
> definition of SEP, is it?

I think it's the whole point. Abstract of RFC 3757:

   With the Delegation Signer (DS) resource record (RR), the concept of
   a public key acting as a secure entry point (SEP) has been
   introduced.  During exchanges of public keys with the parent there is
   a need to differentiate SEP keys from other public keys in the Domain
   Name System KEY (DNSKEY) resource record set.

i.e. the SEP bit was invented to distinguish KSK and ZSK.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Viking, North Utsire: Southerly or southwesterly 4 or 5, becoming variable 3
or 4. Slight or moderate. Rain or drizzle at times. Good, occasionally poor.