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

[Wes Hardaker <[e-mail]>]

"Terry Manderson" <[e-mail]> writes:

> Abstract: s/outline potential/outlines potential/

Hmm.  My version already has that.  Yay!

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

Wording suggestions taken.

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

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.

>   last para of s1.1. "not uncommon to get results that are not
> 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
> stable URL?

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
> better arm the reader?

fair suggestion; done.

>      By saying "actual validating resolver" I presume you mean a
> standalone daemon listening on port 53?

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

> s2 "This document specifies two sets of tests to perform a comprehensive
>    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
> 'Note'

Added.

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

good catch

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

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

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