BIND 10 #2229: DHCP DDNS Requirements Document

[BIND 10 Development]

#2229: DHCP DDNS Requirements Document
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  sar
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:         |  DHCP-20121004
  medium                             |            Resolution:
                  Component:  dhcp   |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DHCP
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => sar


Comment:

 Changes made - updated version is version 6.

 > 2.1 As I recall we discussed the merits of having the zone server
 information tied to the range ...
 I have in mind that there is a global setting that can be overridden on a
 per-range basis.


 > 2.1.3 would seem to connect a server to a given address range. This
 probably works well for the reverse entries but may not work well for the
 forward entries...
 This has been left as-is, but a new requirement added to allow a set of
 servers to be specified for a zone.


 > Determining how the timeout and retry values are set may not be under
 the control of the DHCP code...
 Timeout and retry count removed from the requirements list.

 > Is there any specific reason for allowing only 1 backup server? ...
 No.  Requirement extended to allow for multiple backup servers.

 > Is there any need or desire for GSSAPI support?
 Added as a SHOULD in requirement 2.5.1.  However, as I don't know anything
 about it, the more detailed requirements have been left "TBC".

 > 2.2.1.4 & 2.2.1.5 The use of should in these statements allow a server
 to ignore the flags ...
 This comes from [http://tools.ietf.org/html/rfc4702 RFC 4702] which used
 the word SHOULD.  However, as [http://tools.ietf.org/html/rfc2119 RFC
 2119] defines SHOULD as:

 ''SHOULD This word, or the adjective "RECOMMENDED", mean that there may
 exist valid reasons in particular circumstances to ignore a particular
 item, but the full implications must be understood and carefully weighed
 before choosing a different course.''

 i.e. "you'd really, really better have good reasons to do something else",
 the easiest course of actions was to promote these "should"s to MUST in
 the requirements.


 > 2.2.1.10 & 2.2.2.5 Presumably there will be some way (for example the
 hooks option) for the administrator to set the host name for the client...
 Modified to add the qualifier "If an entry is to be made into the forward
 zone".  As to hooks, hooks will be able to override more or less anything:
 however, we need to give the user some capability to add a name "out of
 the box".

 > 2.3.1.2 This procedure does not allow for administrator input on the
 process...
 Added requirements that lest an administrator override aspects of the
 process.

 > 2.3.3.1 There seems to be a typo in this statement...
 Corrected.

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