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

[Wes Hardaker <[e-mail]>]

"Ben Campbell" <[e-mail]> writes:

> - I support Terry's discuss.

Fixed (see response to Terry)

> - 1.2, 2nd paragraph: Is "full non-support" effectively different from
> "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
> life of the RFC?

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

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

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.

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

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

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

Agreed, fixed.

> "short-circuit any unnecessary fallback attempts.":  Does "short circuit"
> 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...":
> Spurious 2119 "MAY"

Yep.

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

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