Subject: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jul 2016 15:26:17 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: No Objection

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/

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

- I support Terry's discuss. 

- 1.2, 2nd paragraph: Is "full non-support" effectively different from
"non-support" in this context?

Do we have reason to expect the github project to be maintained for the
life of the RFC?

- 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org
domain will be maintained for the life of the RFC?

- 5:

The first paragraph seems to say that the document does not accomplish
it’s goal. Is that really the intent? (And doesn't the document at least
do some of that?) 

"... we can determine what MUST be done in order..."
Spurious 2119 MUST

"short-circuit any unnecessary fallback attempts.":  Does "short circuit"
mean the same as "avoid" in this context?

"problems with the name server MAY manifest": Spurious 2119 "MAY"

- 5.1, "It MAY be possible...": Spurious 2119 "MAY"

-5.1.2: s/real/really

- 6: "A newly established network connection MAY change state...":
Spurious 2119 "MAY"

-8: Seems like there could be  more to say about the potential
consequences about the “fail or proceed without security” decision in 6
and 6.1.

---

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

> - I support Terry's discuss.

Fixed (see response to Terry)

> "non-support" in this context?

CHanged to "Detecting complete lack of support", which I hope works for you?

> Do we have reason to expect the github project to be maintained for the

I wondered about including such a URL.  I doubt github or olafur will
ever drop the repository, however.

> domain will be maintained for the life of the RFC?

I think for some of the tests we may be able to use the root of the DNS
instead.  However, in some cases we need specific data types.

I have no intention of ever dropping the signing of dnssec-tools.org,
and my co-workers have backup responsibility for it and the means to
sign it should I get thrown in jail by the protocol police, eg.

> it’s goal. Is that really the intent? (And doesn't the document at least

I'll get back to you after discussing that sentence with its author.

> "... we can determine what MUST be done in order..."

Agreed, fixed.

> mean the same as "avoid" in this context?

Good wording replacement; done.

> "problems with the name server MAY manifest": Spurious 2119 "MAY"

Yep, fixed (someone else caught it too).

> - 5.1, "It MAY be possible...": Spurious 2119 "MAY"

Fixed.

> -5.1.2: s/real/really

Good catch.

> - 6: "A newly established network connection MAY change state...":

Yep.

> consequences about the “fail or proceed without security” decision in 6

I think the world is very much at a loss as to the best thing to do in
that case.  And is likely very case specific.  Military installations
tend to be a bit more strict about continuing through to a unacceptable
security certificate, eg.  I'm not sure we can enumerate every context,
but rather say each local policy will need to do what is appropriate for them.

-- 
Wes Hardaker
Parsons

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 08 Jul 2016 16:56:37 -0500

Thanks for the response. Discussion inline, with things that appear to 
be addressed removed.

Ben.

> "Ben Campbell" <[email-masked]> writes:

[...]

> CHanged to "Detecting complete lack of support", which I hope works 

It answers my question. But don't the described tests detect degrees of 
non-supportness?

> ever drop the repository, however.

I'm okay if the answer is "yes" or even "we hope so"; I just want to 
make sure people thought about it.

> sign it should I get thrown in jail by the protocol police, eg.

(repeat previous comment)

[...]

> but rather say each local policy will need to do what is appropriate 

I think it would be useful to say _that_. (as in "here's a security 
consideration people need to, well, consider")