BIND 10 #1261: IXFR-in protocol handling

[BIND 10 Development]

#1261: IXFR-in protocol handling
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20111011
  blocker                            |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 I took the liberty of correcting a few typos, see commit
 cf136247fad510f55ba230f746558274fada1de6

 Code looks good, i like the use of the state design pattern.

 Just a few comments:

 xfrin.py.in:

 just a note about the doc on line 215:
 handle_rr() technically, should it not be overridden, it returns None due
 to the pass in the default implementation. (i think it could even raise an
 exception if we don't expect the superclass to be called)

 232: s/given/received/ ?

 Wouldn't XfrinFirstData fail (or rather, behave strangely and NOT fail) if
 the second RR in the response is a SOA with a different serial than we
 currently have?

 Should we also make a note somewhere on which errors we should fall back
 to AXFR (and how such errors fall into the design pattern)?

 I wonder (line 444), that if we find that we have a clearly inconsistent
 database, whether it is acceptable to just drop it and AXFR-in a fresh
 one.

 Come to think of it, should the exception we raise when we don't have the
 zone or its SOA at all be a more specific one (so we don't need to fall
 back on any xfrinexception)? Technically this may not even be enough of an
 exceptional case to warrant an exception in the first place, though I
 don't feel to strongly about that.

 xfrin.py.in:550  logstr is never used? leftover from old logging?

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