[dhcwg] More on failed WGLC for draft-ietf-dhc-addr-registration-07.txt

["Bernie Volz (volz)" <[e-mail]>]

Here are my particular reasons for believing that this work is not yet ready. This is primarily to help the authors focus on updating the draft and to provide motivation for those in the WG that feel this is important but did not 'speak up'.

First, I believe this draft has a higher bar than usual because it is standard track work, defines a "new" protocol, and one that is a grey area for the DHC WG - it being done here mostly because it uses the DHCPv6 protocol message and option format (and relay support). It was adopted by the DHC WG as there was support for doing this work, so it is important that we make sure it concludes.

Jinmei raised some very good points about this work and whether it was needed (see http://www.ietf.org/mail-archive/web/dhcwg/current/msg15849.html and this thread as this not the first message). I did chime in during this discussion to help explain why having clients update DNS directly was an issue.

I also think the draft needs to answer why networks that won't or can't use DHCPv6 to resolve the DNS issue would actually make use of this solution. The abstract states "One of the most important issues in this regard is the inability to register such addresses in DNS." Why is this such an important issue; if it isn't happening today, why is this needed now (or in the future)? In the introduction there is "One such limitation is related to the inability of nodes with self-generated addresses to register their IPv6-address-to-FQDN bindings in DNS." It goes on to explain the limitation, but not say WHY this is a problem that needs to be solved. Sure, the "problem" being solved is adding these mappings to DNS; but why is that needed in the first place? What will this DNS information be used for (i.e., to allow incoming connections, to help administrators, for 'primitive' security - if the host is in DNS it must be OK, or)? The Introduction does say "In several tightly controlled networks ..." - so is this a solution for just a few networks?

I had also raised a concern about the lack of addressing the multi-server solution. Sure, RFC 3315 wasn't complete on this (i.e. the failover work). And, certainly one option is to say it is out of scope, but that has its own issues. There is an individual submission draft which I had missed (it is in the "Related Internet-Drafts" section at the bottom of http://datatracker.ietf.org/wg/dhc/documents/) - the draft-que-dhc-dns-multi-dhcp-servers-00 document. This is an individual submission (not adopted by the WG); it attempts to address the multiple servers issue. It is very preliminary. But it does open the question of whether more could be done in the addr-registration draft for this or whether the addr-registration, by declaring it out of scope, might restrict possible solutions? I'm not saying that this work needs to be folded into the addr-registration draft, but it may be worth a few cycles to consider how this may be solved?

An additional nit found in re-reading parts of the draft:

   Also, there is no way to propagate the
   address of authoritative name server by any protocols.

DNS can be used for this so I think this statement is incorrect - query for the SOA? (Yes, there may be cases where this isn't the 'real' server that will accept DNS updates - i.e., hidden primary/master.)


-          Bernie