On Apr 29, 2015, at 4:56 PM, Edward Lewis <edward.le...@icann.org> wrote: > The above responses give me a confused idea of what the guidelines of the > draft is following.
Yep. We have some guidelines at the front of the document, and we generally try to follow them. However, this is now an WG consensus document, not an individual submission from Andrew/Kazunori/Paul. Given that, if the WG wants something added that doesn't exactly follow the guidelines, the answer should usually be "yes". > I'll start with an observation that does not directly relate to the draft > which does put me in an awkward position. The language used in the RFCs > is not exactly the language used in operations. Yes, most words are the > same but not all. Fully agree. If the DNSEXT WG still existed now, this document would have been in that WG, not here. However, that's not the reality we are given. > If the draft is going to "firm up" RFC terminology, it should do so > consistently. That was never a goal of the document. There has been some value in giving definitions from RFCs more explanation, but we never intended to limit to only terms defined in RFCs. > If the term is not in any RFC, leave it out. If the draft > is going to "firm up" the language used to describe the DNS, then it > should capture more operational jargon and note when some RFC language has > fallen by the wayside. That's more what we want. > E.g., NODATA - I've never heard that outside of "NOERROR/NODATA". From > that I would have never associated NODATA with any meaning of the RCODE. > As for gTLD - that is as much an ICANN term as sTLD. RFC 2308, a standards-track document, uses the term as "NODATA" by itself. So does RFC 3971, 5617, and 7129. RFCs 4956 and 6840 use NOERROR/NODATA. > I'm not arguing the point of any of the definitions, it's just that from > the responses I don't see consistency. Fully agree. > Clarifying the words in RFCs is fine and that can be done by a document > search. Clarifying the words used in operations ought to include a survey > of operators (outside of the IETF), which may expose conflicting uses of > terminology because in-house operations don't always communicate > externally. For example, on one environment where I worked "the resolver" > was an authoritative server. The name came that way because it was > "resolving" the query from a database backend. This caused a lot of > confusion amongst young recruits who tried to learn from RFCs. Proposing that we stop work on this document until someone does such a survey is fine. Clearly, I don't favor that approach, but others might. > This puzzles me ... if the term isn't described anywhere, why define it? Because it is wide use in the press, and because the WG asked us to. > For "fastflux" this was a term that seemed to have jumped the shark, it > has more historical meaning that current use. I still hear it in use. > My sympathies with all this. I'm just registering that to help, I'd need > a clearer idea of where you want to take this. Or the WG want to take > this. If I could give you a clearer idea, I would. The best I can say is "this is a WG consensus document, and the authors try to read the consensus; if we do that wrong, we assume the chairs will correct us". --Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
