Subject: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Tue, 05 Jul 2016 21:25:57 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be  a very easy DISCUSS to resolve.

In section 4, the second "Note", I urge you to reconsider using the term
"crap-ware", and words "stupid", "crap".. these make this document look
and sound very poor for an IETF published document. Knowing the
intelligence of the authors I can't see how this was thought of as
passable and made it through WGLC irrespective of how we collectively
view these devices.

Perhaps such words like "protocol naive" are better placed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

small nits and comments:

Abstract: s/outline potential/outlines potential/

s1.1 
  second bullet, perhaps you could just say "not DNSSEC aware" to be
parsimonious with words
  third bullet '"middle-boxes" actively'?
  fourth bullet "Network components" ?

  para after the bullets: "s/perform these test/perform these tests/ and
I don't mean this to sound snide, but what is a regular Validating
Resolver? as opposed to something else? (irregular?)
  last para of s1.1. "not uncommon to get results that are not
consistent" suggest "not uncommon to get results that are inconsistent"

s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully
stable URL?

s1.3 May I suggest moving the 'Notation' section above the background to
better arm the reader?
     By saying "actual validating resolver" I presume you mean a
standalone daemon listening on port 53?

s2 "This document specifies two sets of tests to perform a comprehensive
   one and a fast one." I think you missed a comma.  And is normative
language really needed in the following sentence?

s3, you might like to use a RFC4786 reference for anycast in the first
'Note'

s3.1 second para "SHOULD have the recursive flag", suggest "SHOULD have
the Recursion Desired (RD) flag set"

s3.1.1, please use the example domain for such examples, ie example.com,
and once you have used it do you really need to repeat it for each
'existing' text until you get to the non-existent tests and so on up to
3.1.14. 

And on s3.1.14 Will "alltypes.res.dnssecready.org"  be a stable query
point?

s 3.3 Some formatting might help with the DNS query examples here.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jul 2016 14:17:10 -0700

> passable and made it through WGLC irrespective of how we collectively

Thanks Terry.  I've removed those words that "someone" inserted.  I
agree with the problem.
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jul 2016 16:53:21 -0700

> Abstract: s/outline potential/outlines potential/

Hmm.  My version already has that.  Yay!

>   fourth bullet "Network components" ?

Wording suggestions taken.

> Resolver? as opposed to something else? (irregular?)

As opposed to Host Validators, previously in the sentence.  I'm leaving
it as I do think it provides a touch of clarity.  Though if a bunch of
people want it removed, I'm fine with that too.

> consistent" suggest "not uncommon to get results that are inconsistent"

good suggestion.

> s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully

Per discussion in another thread: probably.  Olafur certainly won't
delete it as the owner, and I doubt github will die anytime soon.

The only other choice is to remove the helpful reference.

> s1.3 May I suggest moving the 'Notation' section above the background to

fair suggestion; done.

> standalone daemon listening on port 53?

I've changed it to "validating resolver daemon" instead.  Make more sense?

>    one and a fast one." I think you missed a comma.

I used a : actually

> And is normative language really needed in the following sentence?

I think the real intent was more (is now more?) this:

     The fast one will detect most
     common problems, thus if the fast one passes then the comprehensive
     MAY be considered passed as well. </t>

which is more reasonable for the normative language.

> s3, you might like to use a RFC4786 reference for anycast in the first

Added.

> the Recursion Desired (RD) flag set"

good catch

> 'existing' text until you get to the non-existent tests and so on up to

Well, here's the deal: example.com won't work and the domain in question
actually does work.  Some of them can probably be replaced with the root
server, but many others require somewhat specialized tests pointing to a
special domain.  That one is known to be the only one that likely will
work for some tests at this point.  The question is, what to do about
that?  Can we list a known one?  Must we list a useless one instead?
Should we pre-declare the problem?  I've been waiting for this to come
up :-)

> And on s3.1.14 Will "alltypes.res.dnssecready.org"  be a stable query

I hope so.

> s 3.3 Some formatting might help with the DNS query examples here.

Good point;  Put into artwork.

Thanks for all your helpful comments!
-- 
Wes Hardaker
Parsons

---

From: Terry Manderson <[email-masked]>
Date: Wed, 13 Jul 2016 05:28:46 +0000

Hi Wes,

Thanks for responding.

I'll trim to only the the remaining items needing a response, and express
my appreciation at the clarified items.

>The only other choice is to remove the helpful reference.

Thanks.

>I've changed it to "validating resolver daemon" instead.  Make more sense?

It does.

>Should we pre-declare the problem?  I've been waiting for this to come

Personally, my advice would be to pre-decalre the issue, and why it's an
issue and why some special domain is needed and describe the semantics of
the FQDNs needed for the appropriate tests (including an appendix zone
file?), and then use example.com as the label which needs to be
substituted by the person constructing the tests/zone. The benefit here is
that some folks might like to replicate such a construct in their own
infrastructure, and this document might give them that guidance.

Does that make sense?

Thanks
Terry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 13 Jul 2016 21:57:21 -0500

This is Not My Yes, but ...

On Wed, Jul 13, 2016 at 12:28 AM, Terry Manderson <[email-masked]
> wrote:

> infrastructure, and this document might give them that guidance.

Terry, I like where you're headed, but just to ask the obvious question,
are you thinking the draft would, or would not, also contain something like
"at the time this document was approved, a domain used for this test was $
someactualworkingdomain.com"?

I didn't mention the domains mentioned in this draft in my ballot, but I
was watching when you brought it up ... so I'm still curious.

Thanks,

Spencer

---

From: Terry Manderson <[email-masked]>
Date: Thu, 14 Jul 2016 05:55:22 +0000

Hi Spencer,

On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
<[email-masked]> wrote:
>are you thinking the draft would, or would not, also contain something
>like "at the time this document was approved, a domain used for this test
>was $someactualworkingdomain.com <http://someactualworkingdomain.com>"?

Sorry I didn't make it obvious, yes I would like to see text like this,
and I think it makes an easy path for the less adventurous in addition to
supplying more in depth guidance.

Cheers
Terry