"Ben Campbell" <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
