BIND 10 #1587: auth::Query NSEC3 support: cleanup

[BIND 10 Development]

#1587: auth::Query NSEC3 support: cleanup
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120306
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by kevin_tes):

 * owner:  kevin_tes => jinmei


Comment:

 Replying to [comment:15 jinmei]:
 > Replying to [comment:12 kevin_tes]:
 >
 > Thanks for the prompt review.
 >
 > > Hello,all seems good to me.
 > >
 > > For one thing I am not sure. In this method:
 > > + uint8_t
 > > + Query::addClosestEncloserProof(ZoneFinder& finder, const Name& name,
 > > +                                bool exact_ok, bool add_closest)
 > >
 > > For opt-out,should we valid the opt-out flag been set? If not, I do
 not think we need "bool exact_ok" this parameter.
 >
 > I'm not sure if I understand the concern, but if you mean whether it's
 > okay if we skip checking the NSEC3 optout bit when optout is allowed
 > (exact_ok = true) and we get both closest and next NSEC3 (in which
 > case the "next" NSEC3 should have the optout bit set), the policy here
 > is to basically trust the zone signer, and if it's a broken zone we'll
 > let the validator detect the error.  This is documented in the header
 > file description.  This policy itself could be discussed if you don't
 > like it, but it was derived from the pre-refactoring implementation;
 Oh, it is ok to me if it was derived from the pre-refactoring
 implementation.

 > this branch doesn't change that semantics.  So, if you want to
 > continue the discussion I'd suggest doing it separately from this
 > ticket (so we can close it sooner).
 >
 > As for the changelog, I simply listed the developer in alphabetical
 > order, which I think is quite normal in cases like this.  You don't
 > have to be too humble:-) but if you really want to reorder them, I'm
 > okay with that, too.
 yeah,i really want to reorder them,please.


 All is ok to me, i think it can be merged. Thanks.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1587#comment:17>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development