On Jun 11, 2015, at 6:37 PM, Tony Finch <d...@dotat.at> wrote: > Sorry for being slow to respond - other work intruded.
No problem. We're still hoping to get as much substantiative review as we can before the chairs send this off to IETF Last Call. > >> 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. There is no good way to do that in the current, or future, RFC format without splitting each term into its own sub-section. That could work, but at the expense of a lot more vertical space due to the dozens of extra headers. Our current format (with your earlier suggestion of better indenting) allows skimming fairly well, I think. > >>> "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 Some of those definitions were speculative, and I think it is better to defer them. However, I can probably see adding the first two, which are the ones most strongly backed-up by the RFCs: Recursive query -- A query with the Recursion Desired bit set in the header. (RD=1) (See RFC 1035 section 4.1.1) If recursive service is available and requested via the RD bit in the query, the server uses its resolver to answer the query. (RFC 1034 section 4.3.2) Non-recursive query -- A query with the Recursion Desired bit unset in the header. (RD=0) A server can answer non-recursive queries using only local information: the response contains an error, the answer, or a referral to some other server "closer" to the answer. (RFC 1034 section 4.3.1) Does anyone object to us adding those two? > >>> 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 ? There was disagreement on the list about your statement: In RFC 1034, zone cuts are clearly defined to occur between labels, above each delegation point, so it is correct to define authoritative data as being above the zone cut, and this unambiguously excludes delegation NS RRsets. This topic *should* be revisited in the -bis document, but probably with a few paragraphs of "some people interpreted RFC 1034 as X, while others interpreted it as Y or Z, and here are side-effects of those different interpretations". >>> 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. The authors do not find this boring, and apparently neither do you. :-) The real question is whether or not we can come up with -bis wording about different interpretations that is helpful to the reader (whom we don't know, and who might be advanced or novice). > I suggested a clearer, less confused definition, based on quotes from > existing RFCs. Without more agreement from the WG, we can't go with them. We don't have that yet. > >>> 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. This one makes sense in both spellings. The other fixups are (hopefully) only for grammatical or contextual sense. I apologize for being too strong above in my disagreement reasoning. > >>> 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. Good point. I took the "it is suggested" in the RFC as really being a suggestion, but it is more "it will only make sense to others if". We will add that extension to the quotation from RFC 6781. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
