Changes between Version 1 and Version 2 of Year4Ideas


Ignore:
Timestamp:
Feb 2, 2012, 2:48:43 PM (6 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Year4Ideas

    v1 v2  
    1 Focus on one area at a time:
    2 
    3 1. Usability
    4 2. Resolver
    5 3. DNSSEC management
     1= High-Level Goals for Year 4 =
     2
     3With Year 4, we want to focus on making BIND 10 something that people actually use.
     4
     5[[PageOutline]]
     6
     7The big goals for year 4 are:
     81. Make BIND 10 easy to use, including:
     9  a. Intuitive and powerful command-line administration tool
     10  b. Operational transparency, such as:
     11     1. listing zone status, including transfer details
     12     2. trace recursion
     13  c. Migration tools from BIND 9 and other DNS servers (configuration & zones)
     14  d. Support for traditional configuration files
     15  e. Support for configuration history, with restore (apply old configuration)
     16
     172. Improve BIND 10's recursive resolution, including:
     18  a. Port randomization and other anti-Kaminsky measures
     19  b. DNSSEC validation (NSEC and NSEC3)
     20     i. RFC 5011 support
     21  c. EDNS(0) support, including fallback logic
     22  d. Server capability tracking (lameness, EDNS(0) support, and so on)
     23  e. Query tracing
     24  f. Cache as an object
     25      1. Cache control
     26      2. Cache persistence
     27      3. Cache migration
     28  g. Comprehensive functional test suite (as a standalone tool)
     29
     303. DNSSEC zone management, including:
     31  a. Signing
     32     1. Automated, including re-signing
     33     2. "in-line signing"
     34  b. Key management
     35     1. Automated key rollover
     36     2. KSK rollover support
     37  c. Command-line tools for working with DNSSEC
     38
     394. Other goals:
     40  a. Hooks/plugins
     41  b. BIND 9-style views
     42  c. Elegant network interface handling
     43  d. Additional data source support, including:
     44      1. LDAP
     45      2. MySQL
     46      3. PostgreSQL
     47      4. Berkeley database (BDB)
     48  e. IDN support in administrative tools
     49  f. Packages or installers or popular operating systems
     50  g. Performance
     51     1. Recursive no worse than BIND 9
     52     2. Efficient primary and secondary transfer efficiency
     53
     54= Review of Progress So Far =
     55The goal for Year 3 was "production readiness", however that goal will
     56likely only be partially met.
     57
     58At the beginning of the year, two tactics were proposed to get the
     59server production ready:
     60
     611. Continuous addition of new features
     622. Steady introduction into production environments
     63
     64There was some introduction of BIND 10 into production environments,
     65but less than intended. Most of the focus of the year ended up being
     66on adding missing features.
     67
     68One problem is that BIND 9 provides a huge number of features, and
     69that trying to implement a decade's worth of features in 3 years
     70turned out to be a stretch. This difficulty was exacerbated by unknown
     71issue with BIND 10's next-generation approach, and the necessity to
     72guess at the best approaches throughout the design and implementation
     73to date.
     74
     75BIND 10 has not adopted a waterfall model for developing software, due
     76to the well-understood problems with that approach. However, by
     77avoiding this approach the advantages provided by that approach have
     78also been lost. These includes:
     79
     80* A comprehensive list of the goals
     81* Well-defined points to build requirements, design, code, and tests
     82* The documentation produced as a side-effect of those artifacts
     83* Detailed timelines
     84
     85Ultimately BIND 10 needs to look at what can hopefully be a useful
     86fusion of 20th and 21st century software engineering approaches, an
     87"agile waterfall" as it were.
     88
     89BIND 10 should have had some early adopters by the end of year 3,
     90however it looks likely that this will not be the case. Hence the
     91focus in year 4 on attempting to gain those users.
     92
     93
     94= Recommendations =
     95We need to shift slightly from our current approach of adding a
     96user-visible feature every release. We want to make improvements for
     97the users with each release, but new features do not necessarily move
     98us towards our goal of making BIND 10 something people want to use. As
     99an example, Mozilla Firefox was first released as a browser with
     100*less* functionality than Mozilla's main browser. The idea is not that
     101we can remove functionality, but rather that a well-designed feature
     102that a user needs is better than several not-so-polished features.
     103
     104One problem with this strategy is that it is difficult to know when to
     105stop improving a given portion of a system. It also involves
     106significant cost, as it means taking risks and experimenting; any
     107experiment has a chance of failure, but a lot of BIND 10 is an attempt
     108to do things differently from the past.
     109
     110As discussed above, BIND 10 will try to embrace aspects of both
     111waterfall and agile methodologies.
     112
     113    == Stuff from Waterfall ==
     114    * List of requirements/deliverables
     115    * Defined times for written requirements, designs
     116    * Timelines
     117    * Customer sign-off
     118
     119    == Stuff from Scrum ==
     120    * Timeboxed releases
     121    * Feature demos
     122    * Short sprints
     123    * Daily calls
     124    * Team estimates
     125    * User involvement
     126
     127In order to mix these, we need to relax the requirements of both
     128waterfall and scrum. So, for example, revising the
     129deliverables/requirements is a core value of agile development , and
     130MUST NOT be considered a problem or indeed a failure. Likewise,
     131waterfall insists on requirements before coding begins.
     132
     133Estimates are a problem, both for waterfall and scrum methodologies.
     134Scrum development tries to define the problem away, but ultimately the
     135people paying for development insist that they know how much it is
     136gonig to cost, which means that estimates are important. The waterfall
     137methodolgy proscribes a number of techniques to attempt to improve
     138estimation, but it remains a weak point of that approach. In a
     139combined model probably the best that can be said is that with more
     140effort spent estimating perhaps some improved estimates can be made.
     141
     142
     143= Proposed Strategy =
     144We will split Year 4 into three semesters, each concentrating on one
     145of the major goals. We will make three releases within each semester,
     146on our current 6-week cycle. Requirements and design for subsequent
     147releases will occur within the current semester though.
    6148
    7149Suggested timetable:
    8150
    9 || Feature || April || July(-ish) || December(-ish) ||
     151||= Feature =||= April =||= July(-ish) =||= December(-ish) =||
    10152|| Usability || Implementation || Polishing || Maintenance ||
    11153|| Resolver || Design || Implementation || Polishing ||
    12 
     154|| DNSSEC management || Requirements || Design || Implementation ||
     155
     156Increasing emphasis on written requirements and "traditional" project
     157management will mean less time spent producing code. This is a
     158trade-off taken to increase predictability of the project.
     159
     160The rational for the ordering of the major goals is as follows:
     161
     162* Usability must come first. The technical excellence of the rest of the system is meaningless if it is difficult for administrators to get to.
     163* The resolver work is long overdue, and must be completed for the large number of resolver operators to take advantage of BIND 10.
     164* DNSSEC functionality needs a hard look, so simply implementing the feature set of existing DNS servers is not enough. A "back to the
     165  drawing board" approach will yield a big win, but needs time.
     166
     167It is probable that 4 months is nowhere near enough time for
     168implementing everything within a given feature area. That means we
     169need to make decisions.
     170
     171= Proposed Timeline =
     172---------------------------------------------------------------------
     173Y4 release 1 (usability):
     174
     175Here we release some handy tools for users.
     176  1. Usability (implemented)
     177    b. Operational transparency, such as:
     178       1. listing zone status, including transfer details
     179       2. trace recursion
     180    c. Migration tools from BIND 9 and other DNS servers (configuration & zones)
     181    d. Support for traditional configuration files
     182
     183---------------------------------------------------------------------
     184Y4 release 2 (usability):
     185
     186Here we implement configuration history, and start the coding of our
     187command-line administration tool.
     188  1. Usability (implemented)
     189    a. Intuitive and powerful command-line administration tool (begin)
     190    e. Support for configuration history, with restore (apply old configuration)
     191
     192---------------------------------------------------------------------
     193Y4 release 3 (usability):
     194
     195Here we get our command-line administration tool into shape.
     196  1. Usability (implemented)
     197    a. Intuitive and powerful command-line administration tool (done)
     198
     199---------------------------------------------------------------------
     200Y4 release 4 (resolver): Alpha Release for authoritative-only
     201
     202In this release, we have had our shiny new command-line administration
     203tool and a set of helpful utilities for administrators since the last
     204release. With these in place, and the usability goal enters the
     205polishing phase. After 6 weeks of this, we should be able to declare
     206the software in alpha state, that we can suggest for wider real-world
     207testing.
     208
     209The focus shifts to getting the resolver into shape, and we should
     210have some improvements here, such as Kaminsky-resistance.
     211
     212  2. Improve BIND 10's recursive resolution, including:
     213    a. Port randomization and other anti-Kaminsky measures
     214    b. DNSSEC validation (NSEC and NSEC3) (begun)
     215    c. EDNS(0) support, including fallback logic
     216    e. Query tracing
     217    g. Comprehensive functional test suite (as a standalone tool, begun)
     218
     219---------------------------------------------------------------------
     220Y4 release 5 (resolver):
     221  The resolver work continues, the server should become more
     222  sophisticated. RFC 5011 support arrives.
     223
     224  2. Improve BIND 10's recursive resolution, including:
     225    b. DNSSEC validation (NSEC and NSEC3) (continues)
     226       1. RFC 5011 support
     227    d. Server capability tracking (lameness, EDNS(0) support, and so on)
     228    g. Comprehensive functional test suite (as a standalone tool, continues)
     229
     230---------------------------------------------------------------------
     231Y4 release 6 (resolver):
     232  At this point we should have a working resolver.
     233
     234  2. Improve BIND 10's recursive resolution, including:
     235    b. DNSSEC validation (NSEC and NSEC3) (done)
     236    g. Comprehensive functional test suite (as a standalone tool, done)
     237
     238---------------------------------------------------------------------
     239Y4 release 7 (DNSSEC): Beta Release for authoritative-only
     240  The server has had another 3 releases to address usability issues
     241  and problems with operating in an authoritative-only mode, and
     242  should be ready to enter beta phase. We do NOT begin an alpha phase
     243  for the recursive side, both because the code will be quite fresh,
     244  and also because we don't want overlapping alpha/beta for the same
     245  product.
     246
     247  We begin work on the DNSSEC support.
     248
     249  3. DNSSEC zone management, including:
     250    a. Signing
     251       1. Automated, including re-signing
     252    c. Command-line tools for working with DNSSEC
     253
     254---------------------------------------------------------------------
     255Y4 release 8 (DNSSEC):
     256
     257  Work on DNSSEC continues. At this point existing DNSSEC
     258  functionality should be duplicated.
     259
     260  3. DNSSEC zone management, including:
     261       2. "in-line signing"
     262    b. Key management
     263       1. Automated key rollover
     264
     265---------------------------------------------------------------------
     266Y4 release 9 (DNSSEC):
     267
     268  The final release of Year 4. It all comes together.
     269
     270  3. DNSSEC zone management, including:
     271      2. KSK rollover support
     272
     273
     274