Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
"Paul Hoffman" <paul.hoffman@vpnc.org> Tue, 14 July 2015 16:00 UTC
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8B1A1B6B for <dnsop@ietfa.amsl.com>; Tue, 14 Jul 2015 09:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULimLCk51yVN for <dnsop@ietfa.amsl.com>; Tue, 14 Jul 2015 09:00:05 -0700 (PDT)
Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D975F1A1B7D for <dnsop@ietf.org>; Tue, 14 Jul 2015 09:00:05 -0700 (PDT)
Received: from [10.32.60.76] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t6EG02v1088012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 09:00:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.76]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Casey Deccio <casey@deccio.net>
Date: Tue, 14 Jul 2015 09:00:01 -0700
Message-ID: <83A64168-3510-4E0B-AA23-54547C05990B@vpnc.org>
In-Reply-To: <CAEKtLiQWPM6yJZZASQ5k1bzsbHc3jv5FRsJ6ifgUdj9TRLCmRg@mail.gmail.com>
References: <CAEKtLiQWPM6yJZZASQ5k1bzsbHc3jv5FRsJ6ifgUdj9TRLCmRg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/j-c61p4MQCJefmo4hiclAV0jTIA>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 16:00:07 -0000
On 13 Jul 2015, at 14:20, Casey Deccio wrote: > 1. (stylistic) There are a number of definitions that quote > terminology and > then parenthetically state "quoted from". It seems more intuitive, > precise, and consistent to mark quoted text using quotation marks > instead, > as in other definitions. Some examples (there are probably more): > - Canonical name > - CNAME > - NODATA > - Resolver Yes, the document does not use a consistent style to say what is quoted. I did this to make it more readable. In specific, I think using quotation marks will make it less readable. If there are specific places where the style makes it unclear what is quoted, we should correct that, but trying to be completely consistent will make some parts harder to read. > > 2. For the public suffix definition, I suggest the following: > > "A domain that is controlled by a public registry" (RFC 6265, 5.3). > "For > security reasons many user agents are configured to reject Domain > attributes that correspond to 'public suffixes'" (RFC 6265, section > 4.1.2.3). I like using the direct definition; I don't like discussing things outside HTTP (such as web browsers) unless it is really needed. > > There is nothing inherent in a domain name to indicate whether or not > it is > a public suffix; that can only be determined by outside means. One > resource for identifying public suffixes is the Public Suffix List > (PSL) > maintained by Mozilla (http://publicsuffix.org/) I kinda like the idea of adding the reference to the Mozilla list as "one resource". Do others agree? > > (optional) > The IETF DBOUND Working Group was chartered to solve the more general > issue > of identifying or repudiating relationships between domain names, > outside > of the DNS namespace itself, which could change the role of a public > suffix. > > 3. The current text for referral is incomprehensible. I suggest the > following: > > A response "generated using local data" which contains no answer but > rather > includes "name servers which have zones which are closer ancestors to > the > name than the server sending the reply" (RFC 1034, sections 4.1 and > 4.3.1). These name servers take the form of NS records in the > authority > section of the response and come from the "NS RRs marking cuts along > the > bottom of a zone" when "a match would take us out of the authoritative > data" (RFC 1034, section 4.3.2). Referrals are only associated with > non-recursive (i.e., iterative) queries (RFC 1034 section 4.3.1). In > general, a referral is a way for a server to send an answer saying > that the > server does not know the answer, but knows where the resolver should > direct > its query should be directed in order to eventually get an answer. > > Historically, many authoritative servers answered with a referral to > the > root zone when queried for a name for which they were not > authoritative, > but this practice has declined. > > See also Glue Records. This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. > > 4. In the definition of RRset, the bit about TTLs needing to be the > same > seems out of place for this terminology document. That is an > operational > requirement. Disagree. To some people, TTLs are operational, to others they are part of the master file format. For the latter, this sameness applies to the definition. --Paul Hoffman
- [DNSOP] comments on draft-ietf-dnsop-dns-terminol… Casey Deccio
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Chris Thompson
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Paul Hoffman
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Casey Deccio
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Tony Finch
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Tim Wicinski
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Casey Deccio
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… John Dickinson
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… John Dickinson
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Stephane Bortzmeyer
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Andrew Sullivan
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Andrew Sullivan
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Paul Hoffman
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Tim Wicinski
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Shane Kerr
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Sara Dickinson
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Warren Kumari
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Andrew Sullivan
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Suzanne Woolf
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Jim Reid
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… Warren Kumari
- Re: [DNSOP] comments on draft-ietf-dnsop-dns-term… joel jaeggli