Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[Warren Kumari <[e-mail]>]

On Wed, May 6, 2015 at 6:51 PM, 神明達哉 <[e-mail]> wrote:
> At Tue, 5 May 2015 17:06:04 -0400,
> Warren Kumari <[e-mail]> 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.


Excellent, thank you...


>
> 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.

Fair -- I also have put text at the bottom of section 2 explaining this.

>
> 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.


I have spent some time trying to figure out some text that explains
this without becoming really complex and wordy. If anyone has some
text that they would be willing to send I'd appreciate it...

>
> 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.

DONE.
Oooh. Good point. I believe that this is (probably) something that
implementations should warn about, or refuse. I'll add some text to
say this.

How is:
"It is RECOMMENDED that implementations warn operators (or treat as an
error) if they attempt to add an NTA for a domain that has a
configured positive trust anchor."


>
> 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/

DONE.
Good catch. Thank you!
>
> - Appendix B: s/do this/to do this/ ?
>    There are several tools do this, an incomplete list includes:

DONE.
Nice. Thanks.

>
> - 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).

DONE.
Whooo! It does! Fixed...


>
> --
> JINMEI, Tatuya



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf