Is this draft still alive? It’s active, but don’t see much
discussion, so I’d thought I would present some comments. Some may be
my misunderstanding of the intent, in which case I would argue the text
isn’t clear enough for dummies like me :)
Section 5, last sentence
"...the mechanisms may have to update the time over an unsecure DNSSEC
resolution." change to "...an insecure DNS resolution."?
REQ2:
"SHOULD NOT start validating" - meaning not using that particular TA
that did not verified, or not do any validation? Could be ambiguous as
it is stated now.
Sec 6.2
"Such inspection aims at detecting an non successful..." change to
"...detecting a non-successful..."
REQ8:
"A DNSSEC validator MUST be able to flush the cached RRsets that rely on
a given Trust Anchor." Inserted "given" just to clarify.
Section 7.1
"teh" is used a lot instead of "the". Plus "validte"/validate. The
whole doc could use a copy edit pass.
REQ9:
The requirement says that the "ZSK/KSK database MUST NOT be resilient to
DNSSEC validator reboot", but the paragraph that follows
says that the "ZSK/KSK Data Store is expected to be resilient to
reboot." Are these parts discussing the same thing? If so, that sounds
contradictory.
REQ17:
"A DNSSEC validator MUST be able to flush the cached RRsets associated
with a given KSK/ZSK." Inserted "given", just to clarify.
Section 8, last paragraph
If the child zone is considered bogus, shouldn't the child zone KSK
become a negative trust anchor instead of a trust anchor KSK?
The validator has no way to insure that he child KSK is valid (unless
seen before). If it was previously validated and put in the
KSK/ZSK database I can see adding it to the Trust Anchor store (maybe),
but otherwise, it should become a negative trust anchor.
REQ18:
Wouldn't just any query accomplish that? RFC6975 says that servers must
not strip RRSIGs from responses based on what the client
advertises. It is only used as a signaling mechanism for when to
complete an algorithm rollover.
Let me know if I need to clarify any of the above. I could also do a
more intense copy edit if you would like, but I’m not an expert on
that.
Scott
===================================
Scott Rose
NIST ITL
scott.r...@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
===================================
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
