Subject: re: [dhcwg] Re: Last Call: 'Domain Suffix Option for DHCPv6' toProposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

From: "CTO YAN Renxiang" <[email-masked]>
Date: Thu, 28 Sep 2006 09:28:53 +0800

Hi, Bill and Keith,

Thanks for your comments.

As Ted has stated before, the initial motivation of this draft is for IPv6
access network, in which an IPv6 home gateway (acting as a prefix 
requesting router) can be configured with a domain suffix automatically
using DHCP.  The domain suffix info can then be used to configure the
domain name of the host in home network, via mechanism such as 
FQDN option or others. Currently, we have developed a demo system 
and plan to use it in operator's trial IPv6 network.
In order not to limit the usage in this specific scenario, I removed the 
use case statement from the draft as discussed in several past IETF 
meetings. 
It's the architecture issue that the DHCP is used to configure host info 
or network info. I would prefer to say domain suffix is the network info. 
However, I don't think that is the most important issue.  
As David mentioned in last mail, any client that doesn't want this option 
(or any other) merely needs to neglect to include it on the ORO.  
Moreover, even if the user if mobile, host can still get the configuration 
information from it's home network using the extension of MIP 
mechanism. 

Regards,
-Renxiang

> -----原始邮件-----
> 发件人: Bill Fenner [mailto:[email-masked]]
> 发送时间: 2006年9月27日 13:41
> 收件人: Keith Moore
> 抄送: [email-masked]; Ted Lemon; [email-masked]
> 主题: Re: [dhcwg] Re: Last Call: 'Domain Suffix Option for DHCPv6'
> toProposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
> 
> 
> 
> >Certainly the document would be much improved by 
> >stating the intended purpose(s) of the domain suffix.  Is it for 
> >searches or something else?  And if it's for searches why 
> can there be 
> >only a single domain?
> 
> This was my biggest question when this came up - what's it for?
> DHCPv6 already has a domain search list (option 24).
> 
>   Bill
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Sep 2006 00:48:34 -0400

> information from it's home network using the extension of MIP 

As far as I can tell there are two major issues with this proposal:

1. What does the domain suffix (or for that matter an FQDN) supplied by
a DHCP server actually mean?

It sounds like you are expecting this "home gateway" to manage not only
DHCP for the home network but also DNS, so you need for the "home
gateway" to know the name of the parent DNS zone.  But shouldn't the
customer get to register his own DNS name(s) rather than be constrained
to use the one assigned by the ISP's DHCP server?

Assuming I understand the use case, I don't see any problem with
defining a DHCPv6 option that says "this is a default domain name suffix
to be used by a customer's IPv6 DNS server and/or DHCP server, in the
case where a customer has not provided its own domain name(s)".  But I
think it should be clear in the specification for the DHCPv6 option that
the customer MUST be able to override the domain name assigned by the
ISP's DHCP server.  I also think it should be clear that this option is
not intended to be used by ordinary hosts.

What would bother me is to define a vague "domain suffix" option that
would likely be used in very different ways between hosts, customer
gateways, and appliances, and perhaps even be used differently from one
router to another.

2. Does it make sense to have a general domain suffix DHCPv6 option in a
world where hosts routinely have multiple domains?

Frankly, no.  But for the specific use case you seem to have in mind (if
I understand it), it does make sense.  The problem with trying to make
the option more general is that it introduces all kinds of potential for
conflict (between different sources of domain information) and poor
interoperability (as different kinds of clients interpret the available
information from DNS, DHCP, and other sources in different ways).  If
you want to make the option more general, there needs to be a lot more
analysis of the different possible use cases with regard to the
potential for conflicts between different ways to use this option.

(Though I realize that the DHCP server is free to return different
values for the option to different hosts, I don't think that it's
appropriate to define an option like this one in which the network
administrator would likely need to explicitly configure the DHCP server
to return different values for this option to different hosts just to
get each host to work properly.)

So it looks to me like simplest way to move forward with this is to:

a) rename the option to something like "DHCPv6 option to supply a
default domain suffix for a customer's network"
b) clarify that this only a default domain suffix and the customer is
free to use his own registered domain
c) explain what "domain suffix" means for the purpose of this option
d) clarify that this is not intended for use by ordinary hosts, and give
examples of things that are reasonable uses
(e.g. customer DHCP server, customer DNS server)
e) distinguish this DHCPv6 option from other options that return
hostnames or FQDNs or DNS search path

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Sep 2006 12:01:17 -0700

> So it looks to me like simplest way to move forward with this is to:

The simplest way to move forward is to simply leave the option as it is.
     You state your simplest way forward based on the notion that there
is consensus that your view of this option is the correct view, but in
fact there is no such consensus, at least as far as I can see.   There
was broad consensus in the working group to advance the draft as
written, and we actually considered the main point you raised and
decided not to follow the path you are now recommending.

Many of the issues you raise here are actually DHCPv6 protocol issues,
not issues relevant only to this particular draft.   If it needs to be
said that options provided by the server are advisory and not mandatory,
then the place to do so is not in this draft, but in an update to
RFC3315.   I agree that your assertion that this option is advisory is
true, by the way, although since you only get this option if you request
it, I don't see that as a reason to make the changes you're proposing,
at least to this particular draft.

This is an issue that we've been dancing around in the working group for
quite some time, and it would be very helpful if you had some new ideas
for how to address it - it's actually part of the larger issue of what
to do in a dual-stack situation, and what to do in a dual-interface
situation where the two interfaces find themselves connected to
different administrative domains.   The answer to this question isn't
simple, and I really don't think we have any business at all attempting
to address it in a draft whose sole purpose is to describe a DHCPv6
option and document its format.

So to me, it appears to be the case that the simplest way forward is to
simply advance the document as agreed upon by the DHC working group
consensus.   The less simple way is to try to add a paragraph generally
describing possible uses for the option, in a non-exclusionary way.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Sep 2006 15:44:42 -0400

> decided not to follow the path you are now recommending.

Ted,

WG consensus is (for a WG document) a necessary
condition, but not a sufficient condition, for advancement of a document
to PS status.  "No known technical omissions" is another necessary
condition.  If the WG consensus is to advance a specification with
identified flaws, the IESG has an obligation to reject it (unless it is
useful and _necessary_ (and timely) to advance it as-is. [emphasis
mine]).   I don't think necessity of advancing this document quickly
has been established in this case.

Of course, it would be better if the WG were willing to admit that the
several Last Call comments are in fact a good indicator that the
document as currently written is ambiguous at best, and revise the
specifications in light of those comments (certainly not just my
comments) before presenting it again to IESG.   My suggestions
for the best way to move forward were just that - suggestions.  It is
up to the WG to decide what path it wants to take.

Thankfully, Ralph Droms has assured us that the necessary consideration
will be made, and I have every confidence that this will be done.

> RFC3315. 

I agree with that statement.  However, there's an important difference
between saying that an option is advisory, and saying that a client
MUST be able to be configured to ignore a specific option.  The latter
statement, if approved, belongs in this document.  I doubt that such a
statement would apply uniformly to all DHCPv6 options. OTOH, if the WG
were to insist that standards-conforming customer premises routers
should be able to impose the ISP's domain name on a customer, I'd call
that a serious technical flaw in the document which would warrant
further pushback from the community.  (At this point I have no idea
what the WG intends.)

> option and document its format.

I certainly agree on the desirability of keeping this document's scope
narrow, and also - though you didn't say this explicitly - of not
delaying the document unduly until the broader issues can all be
entirely understood.  But because this document happens to touch on
those issues, I think it's worthwhile to take the opportunity to raise
awareness of them - in addition to asking that the document be revised
to remove the problems that have been identified. 

> consensus. 

If I had thought that were acceptable I would not have sent in a last
call comment, and I've seen nothing to change my recommendation.