Ben Campbell has entered the following ballot position for draft-ietf-dnsop-negative-trust-anchors-10: 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-negative-trust-anchors/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- General: This is just an observation, since this is informational draft. I do not expect or suggest any action on it. (But if it had been standards or BCP track, I might have made it a discuss.) If I understand this correctly, it suggests that resolvers be configured to stop validating known broken names. This of course has the risk of circumventing the protection that a domain intended by using DNSSEC in the first place. The draft does discuss those risks. But I would have been happier to have seen something with a tone more along "We know you are going to do this thing, and it's probably better than globally switching to a non-validating resolver-- so here's the risks, and here's some ways to minimize those risks" (which I think might have been good BCP material) rather than "This is a good practice to work around broken DNSSEC configurations." -- section 1.2, last paragraph, last sentence: Out of curiosity, has this been an issue? -- 2, 2nd paragraph: Can an operator be reasonably expected to be able to confirm that a domain is being operated by its rightful owner? -- 2, 2nd to last paragraph: Since the requirement to limit the time an NTA is used is a MUST, it seems like the ability to configure that time should also be a MUST. -- 2, last paragraph: Why is the requirement not to affect another branch weaker than the requirement not to affect other names higher up the same branch? -- 4, first paragraph, last sentence: This seems to favor erring on the side of keeping the NTA. I think security would suggest erring on the side of removing the NTA. Editorial and Nits: -- If you plan to use capitalized 2119 terms, please add the appropriate boilerplate and a 2119 reference. -- section 4, first paragraph: "It is therefore RECOMMENDED that NTA implementors SHOULD" redundant 2119 keywords (RECOMMENDED and SHOULD ) -- 7, paragraph 4, last sentence: I suggest adding “At the time of this writing…”, and add additional text to remind people these may change over time. -- 7: This section jumps into 2nd person. I don’t want to stand on formality, but it would be good to keep a consistent tone across the draft. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
