At Tue, 5 May 2015 17:06:04 -0400,
Warren Kumari <war...@kumari.net> wrote:
> ... and now I'm replying to the rest of the comments.
Thanks, I've confirmed that my major and minor points are addressed in
the 05 version. So I'm now basically fine with shipping it.
Some non-blocking comments follow...
> I've integrated them and posted a new version with the clarifications
> on a *positive* **trust anchor** under an NTA.
> I'm not very happy with the text I added, if others have better text
> happy to consider it...
The added text looks good enough to me. If you don't like it
yourself, I might suggest something else, but I'm not sure if it's
obviously better than the current one. In any case, I think Section 2
is probably a better place to clarify this, partly because that
section has example cases. But it's not a strong opinion.
Two more related points:
1. In my very original comment on this matter:
www.ietf.org/mail-archive/web/dnsop/current/msg12614.html
I noted one other corner case, which we might also want to clarify:
On a related note, there are some corner cases which may also be
worth noting: queries for DS or DLV (or anything similar to that).
So, for example, zone1.example.com/DS should still be validated even
if there's an NTA for zone1.example.com. Again, this might sound
obvious, but I think it's worthwhile.
2. What if both positive and negative trust anchors are specified for
the same name at the same time? Maybe it's just implementation
dependent, and it may or may not be something that is worth
discussing in this document.
And, here are some other editorial points I happened to notice in this
round of read:
- (this is technical rather than editorial in some sense) Section 4:
When removing the NTA, the implementation SHOULD remove all cached
entries below the NTA node.
Probably s/below/at and below/
- Appendix B: s/do this/to do this/ ?
There are several tools do this, an incomplete list includes:
- Appendix B: It's better if we can use a different level of bullets
for these:
o DS pointing to a non existent key in the child zone. Questions...
o DS pointing to an existent key, but no signatures are made with...
o Data in DS or DNSKEY doesn't match the other. This is more common...
since they are sub-bullets of this one:
o DNSKEYs in child zone don't match the DS record in the parent
zone. [...] Common Variations of
this can be:
(I don't know if I-D xml allows nested listing though).
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
