Subject: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

From: Casey Deccio <[email-masked]>
Date: Mon, 13 Jul 2015 17:20:04 -0400

Hi all,

I have a few comments on the latest draft-ietf-dnsop-dns-terminology
(-03).  There will be more; I'm part way through a review.

Thanks,
Casey

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

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).

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/).

(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.

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.

---

From: Chris Thompson <[email-masked]>
Date: 14 Jul 2015 15:43:13 +0100

>(-03).  There will be more; I'm part way through a review.

[snip]

>>3. The current text for referral is incomprehensible.  I suggest the

[snip again]

>but this practice has declined.

[I know this part was copied from the existing draft, but ...]

Surely this should be "for a name for which they were not authoritative,
nor for any of its ancestors" ?

Also, as such a response is undoubtedly still legal, maybe this ought
to mention what the common(er) practice now is - presumably REFUSED.

-- 
Chris Thompson
Email: [email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 14 Jul 2015 09:00:01 -0700

> as in other definitions.  Some examples (there are probably more):

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.

> attributes that correspond to 'public suffixes'" (RFC 6265, section

I like using the direct definition; I don't like discussing things 
outside HTTP (such as web browsers) unless it is really needed.

> 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?

> but this practice has declined.

This is still contentious, and I think it really should be deferred to 
the -bis document for longer discussion and hopefully consensus.

> seems out of place for this terminology document.  That is an 

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

---

From: Casey Deccio <[email-masked]>
Date: Tue, 14 Jul 2015 12:26:00 -0400

On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman <[email-masked]>
wrote:

> 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.

I'm not sure how adding quotation marks makes things less readable.  If
we're saying that we're quoting text, I'd really like to know what the text
is that we're quoting.  If we're paraphrasing, no quotation marks are
necessary.  This is a fairly standard practice.

> This is still contentious, and I think it really should be deferred to the
> -bis document for longer discussion and hopefully consensus.
>

Could you help me understand which parts of the (reworded) paragraph are
contentious?  Independent of the current intended definitions for
"referral", the current text really is unreadable and (in my opinion)
unsuitable for an initial document.

> 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.

What I am saying is that whether the TTLs are the same (correct) or the
TTLs are different (incorrect), it doesn't change the definition of RRset,
which is the set of RRs with the same name/class/type.  Therefore the
requirement that the TTL be the same is not a useful statement for the
definitions doc, whether it's operational or standards-based.

Regards,
Casey

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Jul 2015 17:26:17 +0100

> -bis document for longer discussion and hopefully consensus.

As far as I can tell from the last few months there is a fairly clear
consensus that the current draft is not good enough. Brushing off
suggestions by saying that we'll publish a turkey then fix it up later is
not a good way to encourage people to contribute.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Fitzroy: Northerly 5 to 7. Moderate, occasionally rough in south.
Fair. Good.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 14 Jul 2015 13:15:57 -0400

> not a good way to encourage people to contribute.

Tony

I would have to disagree with you on the consensus.  There was many 
comments on the draft, and the authors did an admirable job addressing 
them and attempting to find common ground.

The decision was made to first document all existing terminology in one 
place, regardless of how accurate it is to the world today; and then 
take time to generate a revised document where many definitions would be 
updated, and other documents partially obsoleted.  But I would not call 
it a turkey.

tim

---

From: Casey Deccio <[email-masked]>
Date: Tue, 14 Jul 2015 15:43:12 -0400

On Tue, Jul 14, 2015 at 1:15 PM, Tim Wicinski <[email-masked]> wrote:

>>> the
> comments on the draft, and the authors did an admirable job addressing them
> and attempting to find common ground.
>

Hi Tim,

You'll excuse my lack of familiarity with the process, but what is the
current status of this draft (not a -bis version), in terms of
opportunities for continued feedback and modification by the WG?  I realize
that it has been in the WG for a while, has been sent to the AD, and WG
comments have tapered off some.  But your wording sounds somewhat definite.

I do understand that the authors have done a great job addressing comments
and attempting to get consensus and common ground.  That being said, this
document covers a lot of ground, and it has been noted that there are
points on which there is not consensus--even points that are contentious.
Perhaps what would be helpful is to identify which definitions in the
document don't have consensus--and (if possible) even which parts of those
definitions are problematic.  Focusing on those points, rather than the
document as a whole, will allow the WG to determine whether consensus can
be found on those definitions or whether they should be minimized
sufficiently to avoid the contention and fleshed out at a later time (i.e.,
in a -bis document).  I feel like there is a difference between settling on
"what's there" and settling on something "minimal".

> place, regardless of how accurate it is to the world today; and then take
> time to generate a revised document where many definitions would be
> updated, and other documents partially obsoleted.  But I would not call it
> a turkey.
>

I am also concerned about the apparent urgency to get the initial document
out with points that admittedly remain contentious and/or where there isn't
WG consensus.  I don't think it needs perfection, but it seems unnecessary
to get the document published without further explicitly identifying and
considering the standing issues.  We've haven't had this document
before--I'm not sure what the rush is now.

Best regards,
Casey

---

From: John Dickinson <[email-masked]>
Date: Wed, 15 Jul 2015 10:55:19 +0100

> updated, and other documents partially obsoleted.  But I would not call

Tim,

After a quick read of -03 I would saay the draft is in much better shape 
than last time I read it. I wouldn't call it a turkey, but I do agree 
with Tony that deferring anything contentious to a -bis is a bad way 
forward, especially for a draft that is only 3 months old (since the -00).

regards
John

---

From: John Dickinson <[email-masked]>
Date: Wed, 15 Jul 2015 11:00:41 +0100

On 14/07/2015 17:26, Casey Deccio wrote:
> On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>

No, the zone file can contain different TTLs. As far as I know most 
implementations choose to reduce the TTLs for all RRs in an RRSet to the 
lowest value.

> TTLs are different (incorrect), it doesn't change the definition of
> RRset, which is the set of RRs with the same name/class/type.  Therefore
> the requirement that the TTL be the same is not a useful statement for
> the definitions doc, whether it's operational or standards-based.
>

I agree.
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Jul 2015 16:18:08 +0200

On Wed, Jul 15, 2015 at 10:55:19AM +0100,
 John Dickinson <[email-masked]> wrote 
 a message of 47 lines which said:

> I wouldn't call it a turkey, but I do agree with Tony that deferring
> anything contentious to a -bis is a bad way forward,

It's harsh to say that "everything contentious" have been deferred. A
lot of complicated issues (with strong disagreements) were solved in
this working group and I would sadly regret that we lose this work
because other issues are not yet solved.

> especially for a draft that is only 3 months old (since the -00).

7.5 months (since draft-hoffman-dns-terminology-00)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Jul 2015 20:33:59 -0400

Hi,

> before--I'm not sure what the rush is now.

Just on this issue, and speaking only for myself (but as one of the
people behind this document), my view is that this WG has historically
been one of the places where documents go to die, and I am unwilling
to go through the exercise of proving again how great an enemy of the
good the perfect can be.  I'd be much more inclined to remove the
contentious definitions and publish that document than to try to get
things perfect.

I agree and acknowledge that there remain some definitions in there
that are contentious.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Jul 2015 21:21:54 -0400

Sorry for the top-post. As I understand things, this is more than a "choice". RFC 2181 requires it, I think, no?

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Jul 15, 2015, at 06:00, John Dickinson <[email-masked]> wrote:
> 
> 
> 
> No, the zone file can contain different TTLs. As far as I know most implementations choose to reduce the TTLs for all RRs in an RRSet to the lowest value.
> 
>> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 15 Jul 2015 19:15:26 -0700

> I agree and acknowledge that there remain some definitions in there

Not only do you agree and acknowledge that, *so does the document*. 
Based on the contention and lack of consensus for some of the 
definitions, the Introduction now says:

During the development of this document, it became clear that some 
DNS-related terms are interpreted quite differently by different DNS 
experts. Further, some terms that are defined in early DNS RFCs now have 
definitions that are generally agreed to that are different from the 
original definitions. Therefore, the authors intend to follow this 
document with a substantial revision in the not-distant future. That 
revision will probably have more in-depth discussion of some terms as 
well as new terms; it will also update some of the RFCs with new 
definitions.

If there is something more that can be said in the document, by all 
means let us know.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 15 Jul 2015 22:52:02 -0400

> If there is something more that can be said in the document, by all

Also, the document took the approach early on of documenting what 
existing RFCs said in one place.  When it became clear that what the 
RFCs say may not be how people currently use the term, the consensus in 
the working group was to document the existing definition, and flag it 
as in disagreement.  Once this document was pushed out, *then* the 
revised draft could actually update old RFCs.

As chair, I also felt that once this draft is published (and all 
contention removed), it would become something that would be part of the 
document shepherding process - to make sure new RFCs actually used 
accurate terminology.  But that may be a pipe dream.

I do think the authors have done an impressive job considering the scope 
of the document and the depth and breath of comments.

tim

---

From: Shane Kerr <[email-masked]>
Date: Thu, 16 Jul 2015 09:15:19 +0000

All,

On Wed, 15 Jul 2015 20:33:59 -0400

> contentious definitions and publish that document than to try to get

I totally agree, on all counts.

Cheers,

--
Shane

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 16 Jul 2015 11:01:54 +0100

> On 16 Jul 2015, at 03:15, Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> 

Firstly to say that I think this is a very worthy effort and the document will be of great value to the DNS community.  It should be published and I support the proposal that removing contentious definitions to get the draft published is the a best way to proceed.

> Not only do you agree and acknowledge that, *so does the document*. 

I have to disagree that the document goes that far - the first sentence of the third paragraph in the introduction states:

“The definitions here are believed to be the consensus definition of
   the DNS community, both protocol developers and operators.”

and paragraph 5 

“In this document, where the consensus definition is the same as the
   one in an RFC, that RFC is quoted.  Where the consensus definition
   has changed somewhat, the RFC is mentioned but the new stand-alone
   definition is given."

so I don’t believe any definitions that are considered contentious should be in the document if this wording is to be retained.

> Based on the contention and lack of consensus for some of the definitions, the Introduction now says:
> 
> During the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions.

Since this paragraph appears after the first statement about consensus I read it as indicating the bis is likely to refine and extend the original document (fine) but not that readers should expect some definitions presented here to substantially change in a later revision. 

Sara.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 16 Jul 2015 13:30:03 +0200

> I totally agree, on all counts.

+1 on getting it published.

I should point out that the emphasis should be on the "historically"
in "WG has historically been one of the places where documents go to
die".

Recently this working group has been munching though and getting
documents published.

2012: 1 RFC
2013: 1 RFC
2014: 1 RFC
2015: 3 RFC, 4 documents are with the IESG / RFC Ed.

We shouldn't be figuring out how useful a WG is by the number of
documents published, but I don't think DNSOP is still where documents
go to die...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Jul 2015 14:23:24 +0200

> documents published, but I don't think DNSOP is still where documents

Agreed, but I also don't want to return to that bleak past where we
could never get anything published because it wasn't perfect, and then
the number of recycles got high enough that nobody would review, so
the draft wasn't perfect, and so on.  The editors will put their heads
together once more on the basis of the most recent comments.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 16 Jul 2015 09:14:00 -0400

Hi,

This is a good time to remind ourselves of how we got here.

This draft came into the WG as an individual submission, with the authors seeking comment but not asking for it to be a WG work item. We eventually adopted it in the expectation that handling it as a WG draft would lead to higher quality review and higher credibility for the resulting document. There has seemed consistently to be very strong support that this document is needed.

The chairs were in full understanding of the editors' views on the purpose of the document, and thought the WG was too: the intention was to get a good reference out in the field where people who aren’t necessarily as sophisticated as DNSOP regulars can use it, and then tackle the more difficult issues— where definitions aren’t fully consistent within the standard, or implementers and operators have diverged from the standard, or the standard is silent on some important aspect of the protocol.

At this stage, I don’t think it’s a good use of the WG’s time to revisit the basis for adopting the draft. Nor do I think we’re going to resolve all possible contentions, no matter how much more time or how many more review cycles we insist on. Some will be noted as part of this document; some will be removed to wait for the next one.

Not speaking for the editors, it does seem to me that it would be helpful for reviews to separate critiques of the form “I don’t think this accurately captures the definition of this term in existing documents” or “I think documentation and implementation/practice have diverged” from critiques of the form “I don’t like this definition or this aspect of the protocol.”

We have been through extensive review and a Working Group Last Call on this draft. The next revision should go ahead to the IESG.

best,
Suzanne

> On Jul 16, 2015, at 8:23 AM, Andrew Sullivan <[email-masked]> wrote:
>

---

From: Jim Reid <[email-masked]>
Date: Thu, 16 Jul 2015 14:13:48 +0100

> We have been through extensive review and a Working Group Last Call on this draft. The next revision should go ahead to the IESG.

+1

---

From: Warren Kumari <[email-masked]>
Date: Thu, 16 Jul 2015 15:44:17 +0200

On Thu, Jul 16, 2015 at 2:23 PM, Andrew Sullivan <[email-masked]> wrote:
> the draft wasn't perfect, and so on.

+very many much lots.

I just wanted to acknowledge the fact that our chairs are now getting
documents pushed through....

W

> The editors will put their heads

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Jul 2015 20:39:19 -0700

>> the draft wasn't perfect, and so on.

good enough is a substantiallly different  bar then good.

If there are things that folks really cannot live with I think that's
really what I want to know about.