On 4/29/15, 16:02, "Paul Hoffman" <paul.hoff...@vpnc.org> wrote: > >I think "sTLD" is a term used in ICANN, not in the DNS, whereas gTLD has >definitely slipped into DNS language.
>This confuses me, given the definition in RFC 2308. Are you saying that a >NODATA response might have an RCODE that is not 0? If so, what are the >allowed values for RCODE in a NODATA response? >That definition is at odds with RFC 2308, which says: >... >I'm not seeing any use of those terms in RFCs, but I might have missed >them. >There were a few requests from the WG earlier. I'm happy to take it out, >given that it doesn't appear in any RFC. The above responses give me a confused idea of what the guidelines of the draft is following. 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. If the draft is going to "firm up" RFC terminology, it should do so consistently. 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. 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. I'm not arguing the point of any of the definitions, it's just that from the responses I don't see consistency. 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. >I agree with you about "delegated" being a better word, but if we're >going to quote from RFCs, particularly recent ones that were vetted in >this WG, we shouldn't be changing the words. >Fully agree, but I failed to find anything. There was enough interest in >the WG to add the term; I would rather not remove it just because we >can't give a definitive pointer to a definition. This puzzles me ... if the term isn't described anywhere, why define it? For "fastflux" this was a term that seemed to have jumped the shark, it has more historical meaning that current 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
