BIND 10 #3034: DHCP6 Configuration Parameter additions for DDNS
BIND 10 Development
do-not-reply at isc.org
Thu Feb 20 19:21:45 UTC 2014
#3034: DHCP6 Configuration Parameter additions for DDNS
-------------------------------------+-------------------------------------
Reporter: marcin | Owner: tmark
Type: enhancement | Status:
Priority: medium | closed
Component: dhcp-ddns | Milestone: DHCP-
Keywords: | Kea0.9-alpha
Sensitive: 0 | Resolution:
Sub-Project: DHCP | complete
Estimated Difficulty: 32 | CVSS Scoring:
Total Hours: 11 | Defect Severity: N/A
| Feature Depending on Ticket:
| Add Hours to Ticket: 1
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by tmark):
* hours: 2 => 1
* status: reviewing => closed
* resolution: => complete
* totalhours: 10 => 11
Comment:
Replying to [comment:12 tomek]:
> The comments will mostly reflect similar comments made earlier to
similar work in DHCPv4:
>
> '''src/bin/dhcp6/dhcp6.spec'''
> Do we ned ncr-format? For the foreseable future, we'll only support
JSON. The same is true for ncr-protocol. Only UDP for now.
>
I would prefer to leave them in since the support for them is already
there,
at least in them being passed all the way through the appropriate layers.
Or
if you like, we can open a new ticket to not expose them.
> '''src/bin/dhcp6/dhcp6_srv.cc'''
> Please turn this comment in assignIA_NA into a @todo:
> {{{
> // For now, we assert that if we are doing forward we are also
> // doing reverse.
> }}}
>
Done.
> '''src/bin/dhcp6/tests/fqdn_unittest.cc'''
> Why are there bitmasks like ALWAYS_INCLUDE_FQDN defined here?
> Shouldn't they be specified in a header somewhere? If there is a good
explanation,
> why they are defined in cc, not in a header, please add a comment with
that reason.
> If not, please move it to a header.
They are only meaningful to FqdnDhcp6SrvTest which is only defined
fqdn_unittest.cc. I added a comment.
>
> Several tests use generated DHCID. Is there an explanatory comment
somewhere
> that explains how to generate those values by hand (or whatever
technique you
> used to get it)? If not, please add one.
Ok, this is Marcin's doing dang it. The value comes from
dhcp_ddns::D2Dhcid::createDigest() which is using CryptoLink and Botan.
Really the only way to get the value is use that method with the
approriate arguments. I have added an explanatory comment.
>
> ------------------
>
> A question about ChangeLog. It claims that "The parameters
> parse, store and retrieve but do not yet govern behavior."
>
> Is this really true? There are snippets in the code that seem
> to use those parameters, e.g.
>
> {{{
> if (!CfgMgr::instance().ddnsEnabled()) {
> }}}
>
Good point. I was attempting to recycle another entry. I will reword as
follows:
{{{
7xx. [func] tmark
b10-dhcp6 now parses parameters which support DHCP-DDNS updates via
the DHCP-DDNS module, b10-dhcp-ddns. These parameters are part of new
configuration element, dhcp-ddns, defined in dhcp4.spec. These
parameters
influence when and how DDNS updates requests are created but
communicating
them to b10-dhcp-ddns is not yet supported. That will be provided
under
separate ticket, Trac #3222.
(Trac# 3034, git TBD)
}}}
> -------------------
> I assume that the documentation (Guide) will be added in a separate
ticket, right?
>
Yes, this #3283. Coming soon!
> ------------
> The expected changes after this review are sufficiently small, so I
don't need to see
> this ticket again if you address them.
Changes merged git 22c667a66536ff3e3741bc67025d824644ed4e7d
Created !ChangeLog entry 757.
--
Ticket URL: <https://bind10.isc.org/ticket/3034#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list