[bind10-dev] Year 4 resolver goals

[JINMEI Tatuya / 神明達哉]

At Thu, 22 Mar 2012 16:16:46 +0100,
Shane Kerr <shane at isc.org> wrote:

> I've put together a set of goals regarding the resolver work in year 4.
> This is similar to the ones for usability that went out some weeks ago.

[...]

> We have less flexibility here than with the usability work, I think.
> Given the amount of work here, it is likely to take the entire rest of
> year 4, after we finish our usability work.

I think our goals need to be able to answer the question "why yet
another resolver implementation?" or in other words what are unique
(and needed by users) in this implementation.  That will affect some
fundamental level of design and priority.  From a quick look, the
following two can be considered such unique things.

7. Query tracing
8. Cache-specific improvements

Maybe related to item 7, it would also be very nice if the
administrator can see detailed information of important internal
states of the resolver, such as a list of queries (from clients), a
list of outstanding queries from the resolver, detailed memory usage,
etc.

On the other hand, some things that may look mandatory for DNS purists
may not matter much or even at all for most of ordinary users, like
DNSSEC validation, much less trust anchor management.  Sure, as one of
such purists ISC will have to support these in BIND 10 some day, but I
think we should be careful about when to do it.  (On the other hand,
regarding DNSSEC I see stronger need for providing a sophisticated
C++/Python library framework that can be used for DNSSEC signing and
verification).

Regarding time estimates, frankly, I don't believe them:-)  Just
to pick up something specific, this is quite likely to be too
optimistic:

  2.1 Query port randomization [10d]

I don't know the exact plan of mixing the "water fall style" and
"agile style", but I wonder whether we can use our past experiences of
planning and its results.  For example, we know how many weeks we
needed to complete a specific major features like IXFR (in/out).  If
we can get a reasonably reliable estimation of the size of future
features compared to the completed ones, I guess we can say more
reliably, e.g., we'll need X weeks for EDNS0 enhancements.

I suspect estimates for things with a finer granularity will be just
too untrustworthy unless we break the features into bitable tasks and
give them estimates as we do for every sprint.

---
JINMEI, Tatuya