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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
