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

[Terry Manderson]

That works for me.

Cheers
Terry

On 4/08/2016, 8:53 AM, "Wes Hardaker"  wrote:

>Terry Manderson  writes:
>
>> Hi Spencer,
>>
>> On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
>>  wrote:
>>>
>>>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 "?
>>
>> 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.
>
>How does this text work to be dropped into the end of the
>"Implementation experiences" section (1.3):
>
>  
> In this document, the "test.example.com" domain is
> used to refer to DNS records which contain test records
> that have known DNSSEC properties associated with them.
> For example, the "badsign-a.test.example.com" domain is
> used below to refer to a DNS A record where the
> signatures published for it are invalid (i.e., they are
> "bad signatures" that should cause a validation
> failure).
>
> At the time of this publication, the
> "test.dnssec-tools.org" domain implements all of these
> test records.  Thus, it may be possible to replace
> "test.example.com" in this document with
> "test.dnssec-tools.org" when performing real-world
> tests.
>  
>
>And then everywhere that test.dnssec-tools.org exists in the document,
>I'll replace it with "test.example.com".
>-- 
>Wes Hardaker
>Parsons


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wes Hardaker]

Terry Manderson  writes:

> Hi Spencer,
>
> On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
>  wrote:
>>
>>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 "?
>
> 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.

How does this text work to be dropped into the end of the
"Implementation experiences" section (1.3):

  
  In this document, the "test.example.com" domain is
  used to refer to DNS records which contain test records
  that have known DNSSEC properties associated with them.
  For example, the "badsign-a.test.example.com" domain is
  used below to refer to a DNS A record where the
  signatures published for it are invalid (i.e., they are
  "bad signatures" that should cause a validation
  failure).

  At the time of this publication, the
  "test.dnssec-tools.org" domain implements all of these
  test records.  Thus, it may be possible to replace
  "test.example.com" in this document with
  "test.dnssec-tools.org" when performing real-world
  tests.
  

And then everywhere that test.dnssec-tools.org exists in the document,
I'll replace it with "test.example.com".
-- 
Wes Hardaker
Parsons

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Terry Manderson]

Hi Spencer,

On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
 wrote:
>
>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 "?

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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Spencer Dawkins at IETF]

This is Not My Yes, but ...

On Wed, Jul 13, 2016 at 12:28 AM, Terry Manderson  wrote:

> 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.
>
> On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker"
>  wrote:
>
> >"Terry Manderson"  writes:
> >
> >
> >> 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.
>
> Thanks.
>
> >
> >I've changed it to "validating resolver daemon" instead.  Make more sense?
>
> It does.
>
>
> >
> >> 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 :-)
>
> 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?


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


> Thanks
> Terry
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Terry Manderson]

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.

On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker"
 wrote:

>"Terry Manderson"  writes:
>
>
>> 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.

Thanks.

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

It does.


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

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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wes Hardaker]

"Terry Manderson"  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. 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wes Hardaker]

"Terry Manderson"  writes:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Terry Manderson]

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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop