[DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

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

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.