Subject: [dhcwg] draft-yan-dhc-dhcpv6-opt-dnszone-02.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 08 Feb 2005 14:15:07 -0500

draft-yan-dhc-dhcpv6-opt-dnszone-02.txt has been published as a revision to
the draft we discussed at the WG meeting in DC.  The notes from WG
discussion of the draft in DC are:

    The key idea is to send the DNS domain from which a host should
    form its FQDN to the host.  Ted Lemon noted that the mechanism in
    this specification supposes that the host will then use DDNS to
    update its DNS information.  This use of DDNS will require
    management of authorization information for individual hosts, which
    won't scale.  The RA-based mechanism in
    draft-jeong-ipv6-ra-dns-autoconf has similar issues of scale.
    Further discussion will take place on the WG mailing list before
    coming to a decision about taking this draft on as a WG work item.

The revision suggests a somewhat different use for the DNS zone option that
addresses the issues of scale.  Please review this revision and post any
discussion to the WG mailing list.

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Feb 2005 12:18:31 -0800

This draft uses the term "zone" when it really should use the term 
"domain".   In DNS, a zone is a container for a hierarchy of labels.   
Not every string of labels represents a zone.   So for example, it's 
quite possible to have a domain like "eng.example.com" which is a valid 
suffix for a hostname like "foo.eng.example.com", but where there is no 
zone cut at "eng.example.com", so the *zone* for "foo.eng.example.com" 
is "example.com", whereas the domain suffix is "eng.example.com."

So the option should be the "domain suffix" option, not the "zone 
suffix" option.

I don't understand why the section entitled "Example and applicability" 
is there - I don't think the example will help the reader to understand 
what this option is for, and in fact it is likely to mislead the reader 
into thinking this option isn't one that they can use.   I would 
suggest simply removing this section.

Also, in several places in the draft the following statement is made:

     This can avoid frequent domain name conflicts when performing DNS 
update in large network.

I don't think it's helpful to say this, first because I don't think 
this is a very good strategy for avoiding domain name conflicts, and 
second because, again, this is a very narrow view of what the option 
does, and might tend to lead the reader away from using the option.   I 
would just take this out.

I would change the Usage text as follows:

     In stateful DHCPv6 [RFC3315], the DHCPv6 server MAY place a domain
     suffix option in the options field of any IA or IA_PD option in an
     outgoing DHCPv6 message.   The DHCPv6 server MUST NOT place a domain
     suffix option in any other portion of a stateful DHCPv6 message.

     In stateless DHCPv6 [??], the DHCPv6 server MAY place a domain 
suffix
     option in the main option buffer of any DHCPv6 message sent to a 
client.

     A DHCPv6 server may provide different values for the domain suffix
     option to different clients.   The mechanism for choosing which 
suffix
     to assign to which client is a matter of implementation and 
administrative
     policy, and is therefore not specified in this document.

One thing I noticed in tweaking this section is that you refer only to 
the IA_PD option, but you actually never talk about prefix delegation  
in the introduction - in the introduction you talk only about regular 
DHCPv6 clients.   This inconsistency creates a bit of confusion for me 
- I think mentioning both IA_PD and IA options in the Usage section 
helps, but you might also want to tweak the introduction.