Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-09.txt

From: "Bernie Volz" <[email-masked]>
Date: Tue, 8 Feb 2005 16:49:35 -0500

Ted:

I'd like to the the two FQDN drafts to WG Last Call ASAP. But, Ralph wanted
me to resolve any open issues first. So, I believe yours are the only open
issuses?

I'm confused regarding your suggestion of the changes in section 4.2
(fqdn-option-09) and 5.1 (dhcpv6-fqdn-01).

First, you're suggesting that the status of the "S" bit returned from the
server should be ignored completely (your revised text has nothing about
checking that bit).

Second, if the server's returned domain name doesn't equal the client's sent
domain name, you're suggesting that the client not do any update for the
returned name - period. This is even true if the client sent "host1" and the
server returned "host1.domain.com".

Is this because the client would have no chance to perform the update since
it doesn't hold the necessary key? While it is unlikely, it could always be
that the DNS is not protected against updates? And, there's no general
prohibition against doing updates without keys -- for example, we don't have
any text that prohibits doing any update if no key is available.

Or, what is the rational for this?

Do others agree with this?

Third, why prohibit updates for 10/8 and 192.168/16 addresses? While this is
valid IF the updates are going to the Internet DNS, this is not necessarily
the case for all environments. There may be valid reasons to allow updates
for these clients. I further assume that if updates are being done for 10/8
and 192.168/16 address, it is hard to believe they would be going to
Internet DNS servers in the first place -- since the host is definitely
talking with a local DNS server (since it doesn't have a globally reachable
address).

How do others feel about this prohibition?

I'm concerned that these changes limit the utility of the FQDN options.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Thursday, January 27, 2005 4:35 PM
> To: [email-masked]
> Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-09.txt
> 
> 
> I gave this draft a read as well, since it's in last call 
> already.   It 
> seems to have the same problem as the DHCPv6 FQDN draft.   
> I'm copying 
> the text of my previous message so you don't have to refer to it; I 
> apologize for the repetition.   The suggested replacement text is 
> different in accordance with the differences between v4 and v6 
> addressing.
> 
> On page 8, section 4.2, it says "the client MAY originate an 
> update for 
> the A RR (..) unless the server has set the S bit to one.   
> If the "S" 
> is 1, the DHCP client MUST NOT initiate an update for the name in the 
> Domain Name field."
> 
> As with the DHCPv6 client FQDN draft, I don't think this is valid.   
> The one case where I am willing to accept this is valid is where the 
> name is different than the name provided by the client.   However, if 
> the name is the same as the one supplied by the client, and 
> the client 
> is configured to update the A record on that name, the client 
> should be 
> entitled to update it regardless of what the server says.   The only 
> exception I can think of to this is that if the name is in a 
> non-global 
> IP address space such as 10.* or 192.168.*.   In this case, I 
> think it 
> shouldn't do the update, regardless of the setting of the 'S' bit.
> 
> So I would suggest changing the text to read this way:
> 
>     If a client that owns/maintains its own FQDN wants to be 
> responsible
>     for updating the FQDN to IPv6 address mapping for the FQDN and
>     address(es) used by the client, the client MUST include the Client
>     FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and
>     REBIND message originated by the client.  A client MAY choose to
>     include the Client FQDN option in its SOLICIT messages.  
> The "S" bit
>     in the Flags field in the option MUST be 0.  The "O" and "N" bits
>     MUST be 0.
> 
>     Once the client's DHCPv6 configuration is completed (the client
>     receives a REPLY message and successfully completes a 
> final check on
>     the parameters passed in the message), the client MAY originate an
>     update for the AAAA RRs (associated with the client's 
> FQDN), with the
>     following restrictions:
> 
>      1. If the name returned by the server in the Client FQDN 
> option is
>         not identical to the name send by the client, the 
> client MUST NOT
>         use the name returned by the server in its update.   This 
> includes,
>         for example, the case where a client sends an 
> unqualified name, 
> and
>         the server returns a fully-qualified name.
>      2. If the IP address that the client received is not global in 
> scope,
>         for example because it is in the 10.0.0.0/8 subnet or the 
> 192.168/16
>         subnet, the client MUST NOT insert an A record in the DNS for 
> that IP
>         address.
> 
> In section 6 on page 11, it says "conflicts SHOULD NOT occur."   This 
> is a prediction of what will happen, not a requirement, so it 
> would be 
> better to say "will not occur".   If you want to say "should not" it 
> shouldn't be uppercased.
> 
> Otherwise it looks good - thanks for the hard work on this!   
> If we can 
> fix these two issues (I don't really care about the second one, but 
> it's trivial, so might as well get fixed) in last call, I'm happy to 
> see the draft advance.
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2005 15:16:30 -0700

> server should be ignored completely (your revised text has nothing 

Right.   It's not the server's business to tell the client not to 
update a name the client has the right to update.   DHCP servers and 
DHCP clients don't have a hierarchical administrative relationship.   
Mechanism, not policy.

> server returned "host1.domain.com".
Right.   In this case, the client doesn't know its FQDN, so it would be 
nonsensical for it to update the FQDN.   Sure, there are scenarios 
where the update would do the right thing, but there aren't any 
scenarios where it's the case both that the client *could* do the 
update and the server *could not* do the update.  It therefore makes 
the most sense to put the onus on the server to do the update, since it 
is *not* nonsensical for the server to update names within the local 
administrative domain.

> Or, what is the rational for this?
It's the nonsensical issue, not the key issue, although the key issue 
is certainly a real issue as well.

> Do others agree with this?
I don't know - you could ask.

> talking with a local DNS server (since it doesn't have a globally 
You could allow the user to override this, but clients definitely 
shouldn't do it automatically.   The classic scenario would be that I 
connect behind a NAT (most of the Internet, these days), and issue a 
DNS update to my server, signed with my TSIG or SIG(0) key.   The 
server does the update - why shouldn't it?   Now if you want to reach 
my computer, using my domain name, which is registered in the global 
DNS, your computer will try to connect to 10.0.1.7 (to pull a private 
address out of my hat).   Unless your computer is behind the same NAT 
as my computer, it is going to try to connect to a *different* computer 
- not my computer, with potentially hilarious or disastrous results.

> How do others feel about this prohibition?
Ask Paul Vixie.   I'm sure he can give you the names of a dozen active 
DNSEXT/DNSOP folks who'd agree with this prohibition.

> I'm concerned that these changes limit the utility of the FQDN options.
I can't think of a legitimate scenario for either of the two cases you 
mention where it's as good or better for the client to do the update.   
Can you?   I can definitely think of cases where the *server* in a NAT 
box or a NATted domain should do an update to a NAT-internal name 
server - this is something I fully intend to do on my local network 
when I get around to it.   But there is no way for the client to know 
what NAT it's connected to, so it doesn't make sense for the client to 
update its global domain name when it's behind a NAT.

Bear in mind that when I do a DNS update, I send the update to the name 
server that owns the zone I'm updating, not to the name server in the 
dns-servers DHCP option.   So it's generally not possible for the DHCP 
server to make sure that my update winds up going to a particular DNS 
server - e.g., one that is behind the NAT.   The only way to do it is 
to trap the update on the way through the NAT.   This is only possible 
if the DHCP server and the NAT server are the same device, and even 
then it's very hard to get right.   The standard shouldn't assume the 
presence of such a device.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 8 Feb 2005 18:31:35 -0500

Ted:

The DHCPv4 Client FQDN option draft is attempting to document the existing
behavior used by many implementations. And, we're working within that
framework (ie, we don't want to change the option format or redefine bits).

If we're discussing the DHCPv6 draft, we can certainly make more radical
changes.

I'm assuming that this discussion is primarily around the existing DHCPv4
option.

Regarding the "S" bit, I have assumed that this bit refers to the domain
name that the server returned -- not the domain name that the client
initially sent (unless of course they are the same).

So, if your client is configured to use "ted.fugue.com" and sends that to
the server and you're connecting somewhere that isn't home, the server will
likely return a completely different domain name (for example, if you're
connecting via a cable modem, you're likely to get a name from the service
provider). Now, if the S bit is set, the server is telling the client don't
send any updates for this (completely different) name. And, if the S bit is
clear, the server is telling the client that it MAY send updates for that
(completely different) name (if the client doesn't have rights to perform
the update -- which is very likely, it will fail).

That says NOTHING about whether the client does an update for
"ted.fugue.com". The server is just setting the LOCAL administrative policy,
not the global one.

Perhaps the language in the draft should state "for the name in the Server's
returned Domain Name field" or some such verbiage to make this clear? (And I
also have no issue in changing "MUST NOT" to "SHOULD NOT".)

Note also that the server COULD have policy to register both names in the
reserve DNS. And, it likely would have registered the A under the name it
returned (since it has no authority to update the fugue.com zone).

---

Regarding the private address issue, this really isn't a DHCP Client FQDN
option issue but a general DNS update issue. And, IMHO, this is the wrong
document to state this restriction. And, there are instances where this
should be allowed, such as when the clients are truly on a private network
and not connected to the DNS. (I guess one way a client could reasonable
figure this out is to resolve the address of the DNS server it will update
and if that address is also a private address, it should be safe to perform
the update -- if the DNS server is multi-homed, it presumably has some means
to prevent leakage of the information into the public DNS.)

> DNSEXT/DNSOP folks who'd agree with this prohibition.

Yes, I'm sure Paul would agree when the update is to Public DNS. And, if
they want to make it a general prohibition, they should take it to the
DNSEXT or some other WG. This isn't unique to DHCP. If there's some "best
practices" IETF document, I'd be happy to add a reference to it.

And, again, the DHCP server is setting the local policy and likely would
tell the client NOT to perform DNS updates -- for *the name the server
returned to the client*.

But, this is where your laptop better not attempt to register
"ted.fugue.com" if you're on a 10/8 network and that is, IMHO, outside the
scope of the FQDN draft.

Regarding the DHCPv6 draft as we're free to do radical changes, would you
like the flag field dropped or completley different flags?

- Bernie

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Tuesday, February 08, 2005 5:17 PM
> To: Bernie Volz
> Cc: [email-masked]
> > First, you're suggesting that the status of the "S" bit 
> returned from
> > the
> > domain name, you're suggesting that the client not do any 
> update for 
> > the
> > returned name - period. This is even true if the client 
> sent "host1" 
> > and the
> > Is this because the client would have no chance to perform 
> the update
> > since
> > for these clients. I further assume that if updates are 
> being done for 
> > 10/8

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2005 17:19:00 -0700

> framework (ie, we don't want to change the option format or redefine 
The DHCPv4 Client FQDN draft is defining how conforming clients should 
behave, and is being written so as to avoid creating interoperability 
problems with existing clients.   A subtle but important distinction.   
For example, if we say that clients must not do updates on non-global 
addresses, a client that nevertheless *does* updates when it gets a 
non-global address will not conform to the draft, but will still 
interoperate with conforming implementations.   The draft should not 
deliberately break existing implementations, but neither should it 
encourage new, bad implementations.

> If we're discussing the DHCPv6 draft, we can certainly make more 
I don't think the changes I'm proposing are radical.

> I'm assuming that this discussion is primarily around the existing 
Okay.

> initially sent (unless of course they are the same).
Okay, I can see why you are having trouble with my proposed change, 
then.   My change deals with the case where the server attempts to tell 
the client not to update its own name by sending back that same name 
with the 'S' bit set.   It's my understanding that at least some 
proponents of this draft have in the past argued that this is a valid 
thing to do and that clients should honor the server's wishes in this 
case; it is my position that they should not.   I think if you look at 
my proposed new language, it actually has the effect you desire, but 
it's written with a different set of assumptions, so it sounds wrong to 
you.   Probably the right thing to do is to come up with new text that 
takes into account our different ways of understanding how the the 'S' 
bit might be used.

> the update -- which is very likely, it will fail).
The language I proposed would mandate that the client never update in 
this case, which I think would actually be the correct thing to do.   
Why would you *want* the client to update if the name the server sent 
back wasn't the one the client sent to it?   If the server wants *that* 
name in the DNS, why not just put it there?

> "ted.fugue.com". The server is just setting the LOCAL administrative 
Right, but the language in the draft can easily be read differently, 
and in fact I think that as it is currently written, my interpretation 
of it is actually a more likely one.   Admittedly, I'm biased... :')

> also have no issue in changing "MUST NOT" to "SHOULD NOT".)
That still doesn't work, because the server can still return the same 
domain name the client sent, and in that case the client, according to 
the draft, MUST NOT or SHOULD NOT update its own name.   The draft 
shouldn't make any kind of prohibition at all about what the client 
should do to its own name.

> returned (since it has no authority to update the fugue.com zone).
What's a reserve DNS?

> document to state this restriction.
Why?   DHCP client DNS updates seem to be the case where it is most 
likely - I'd be willing to bet that better than 50% of all DHCP 
transactions return a private IP address, and that in almost every 
single case where a private address is returned, the client is _not_ on 
a completely disconnected network, and _can_ actually reach the name 
server for the domain name it wants to update.

> And, there are instances where this should be allowed, such as when 
> the clients are truly on a private network and not connected to the 
> DNS. (I guess one way a client could reasonable figure this out is to 
> resolve the address of the DNS server it will update and if that 
> address is also a private address, it should be safe to perform the 
> update -- if the DNS server is multi-homed, it presumably has some 
> means to prevent leakage of the information into the public DNS.)
It is true that you can imagine a case where (a) it might make sense 
for the client to do the update and (b) it's possible for the client to 
know that it is in a situation where it should do the update.   
However, this unlikely scenario can be handled by making it possible to 
configure the client so as to override the prohibition against updating 
the DNS with a private address.   I think allowing the client to be 
configured to behave this way is fine; I am merely saying that by 
default, the client must not behave this way.

> tell the client NOT to perform DNS updates -- for *the name the server
Again, you're misstating how DNS works.   The DNS server address or 
addresses returned to the client via DHCP are unrelated to the DNS 
server that the client will want to update, unless by pure coincidence 
they happen to be the same name server.

> "ted.fugue.com" if you're on a 10/8 network and that is, IMHO, outside 
Why is this outside the scope of the FQDN draft?   The FQDN draft 
already states cases where the client should not do an update; this is 
just another such case, and IMHO a very important one.

> like the flag field dropped or completley different flags?
I already sent you changes that do precisely what I want.   If you 
don't like the changes as I proposed them, I'm happy to work with you 
on text that satisfies you, or even write up a new version of the 
changes myself if you tell me what you don't like about the current set 
of changes.   In general, I think similarity between the two drafts 
where it does no harm is a good thing.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 9 Feb 2005 09:44:04 -0500

How about we make the following text changes to
http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-09.txt.

In section 4.2, Client Desires to Update A RRs:

Change:

   Once the client's DHCP configuration is completed (the client
   receives a DHCPACK message and successfully completes a final check
   on the parameters passed in the message), the client MAY originate an
   update for the A RR (associated with the client's FQDN) unless the
   server has set the "S" bit to 1.  If the "S" is 1, the DHCP client
   MUST NOT initiate an update for the name in the Domain Name field.

To:

   Once the client's DHCP configuration is completed (the client
   receives a DHCPACK message and successfully completes a final check
   on the parameters passed in the message), the client MAY originate an
   update for the A RR (associated with the client's FQDN) unless the
   server has set the "S" bit to 1.  If the "S" is 1, the DHCP client
   SHOULD NOT initiate an update for the name in the server's returned
   Client FQDN option Domain Name field. However, a DHCP client that is
   explicitly configured with a FQDN MAY ignore the state of the "S"
   bit if the server's returned name matches the client's configured
   name.

And, in section 4.5, Domain Name and DNS Update Issues:

Add to the end of the section the following new paragraph:

   A client that desires to perform DNS updates to A RRs SHOULD NOT
   do so if the client's address is a private address [RFC1918].

And, add RFC1918 to the Informative References.

---

For http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-01.txt,
section 5.1 would have a similar change as the above change to 4.2.

And, I'm less certain how to word a change for section 5.4, Domain Name and
DNS Update Issues. How about:

   A client SHOULD NOT perform DNS updates to AAAA RRs for
   its non-Global Unicast addresses [RFC3513] or
   temporary addresses [RFC3041].

I think the above uses of "SHOULD NOT" are consistent with RFC2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

- Bernie

> Sent: Tuesday, February 08, 2005 7:19 PM
> To: <[email-masked]> <[email-masked]>
> > framework (ie, we don't want to change the option format or 
> redefine 
> > bits).
> > So, if your client is configured to use "ted.fugue.com" and 
> sends that 
> > to
> > the server and you're connecting somewhere that isn't home, 
> the server 
> > will
> > provider). Now, if the S bit is set, the server is telling 
> the client 
> > don't
> > send any updates for this (completely different) name. And, 
> if the S 
> > bit is
> > clear, the server is telling the client that it MAY send 
> updates for 
> > that
> > "ted.fugue.com". The server is just setting the LOCAL 
> administrative 
> > policy,
> > not the global one.
> > returned Domain Name field" or some such verbiage to make 
> this clear? 
> > (And I
> > Note also that the server COULD have policy to register 
> both names in 
> > the
> > reserve DNS. And, it likely would have registered the A 
> under the name 
> > it
> > Regarding the private address issue, this really isn't a 
> DHCP Client 
> > FQDN
> > "ted.fugue.com" if you're on a 10/8 network and that is, 
> IMHO, outside 
> > the
> > scope of the FQDN draft.
> > Regarding the DHCPv6 draft as we're free to do radical 
> changes, would 
> > you

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Feb 2005 16:22:37 +0100

> I don't think the changes I'm proposing are radical.

I'm slightly concerned of having very different behaviours for v4 and
v6. So personally I would prefer them to behave the same unless there
are good reasons not to.

> should do to its own name.

So maybe the S bit should just be advisory. Generally I would think
that a client may be able to update A record (forward mapping) in its
home domain(s) but not in others. Maybe a laptop is configured with keys
to do this for the domain used in the office and at home. Let's say it's
laptop.office.com and laptop.home.com. When the laptop makes a request
in one of these environments it's quite likely that the laptop only
uses the label "laptop" for the option, or uses the wrong FQDN. It still
would be able to (and probably should) do the updates (even if server
returns a different FQDN from the one the client sent).

The client could tell home or office DHCP server that it wants to do
the update itself, but initially the client doesn't know if it's in one
of these two domains or a third one where it can't do updates.

But I'm not sure I understand the issue. I would think that either the
DHCP server does the update (or somehow can assume that name and address
in DNS are correct) in which case there is no point in having the
client doing any updates, or the server does not, in which case it
should allow the client to take care of it (depending on site policy).

If we look at office.com above and the DHCP server there. It seems
reasonable to me that the administrator of the office DHCP server can
control whether clients try to do updates in office.com zone. So for
laptop.office.com it seems the laptop should do as the server says.
The client should still be free to do whatever it wants with other
domains. Maybe the user of the laptop wants to register the IP
address it has in the office for laptop.home.com. The DHCP server
at the office shouldn't control that.

Not so sure what my picture of things above matches what you're
discussing. Anyway, I'm wondering if it's sufficient to replace
some musts with shoulds...

> server for the domain name it wants to update.

Yes, and a host in another network using private addresses might very
well end up talking to the wrong host (a host in the local network
using the same private address as our host in that other network).

I still think it's sensible to allow it in isolated networks and
maybe in some environments with two-faced DNS. Isn't it okay for the
DHCP server administrator to control this? I would definitely say
that default should be not to do this. That is, client should only
do it if told by server, and server should only tell the client if
explicitly configured to do so.

Stig

---

From: "Charles R. Anderson" <[email-masked]>
Date: Wed, 9 Feb 2005 10:51:41 -0500

>    bit if the server's returned name matches the client's configured

It is my opinion that the DHCP client MUST NOT update if the "S" is 1
and the server's returned Client FQDN matches the DHCP client's
explicitly configured FQDN.  The server is telling the client not to
update the zone for that Domain Name, usually in my experience because
the client would not have permission to do so.  Allowing the client to
optionally do that would just allow clients to hammer the DNS server
for that zone needlessly.

Perhaps this is what was intended:

    ...
    server has set the "S" bit to 1.  If the "S" is 1, the DHCP client
    SHOULD NOT initiate an update for the name in the server's returned
    Client FQDN option Domain Name field. However, a DHCP client that is
    explicitly configured with a FQDN MAY ignore the state of the "S"
    bit if the server's returned Client FQDN option Domain Name field
    does not match the client's configured FQDN option Domain Name 
    field.

This would allow a client to optionally ignore the "S" bit if it is
going to update a different zone than the one that is in the
administrative domain of the DHCP server.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 9 Feb 2005 13:35:36 -0500

Perhaps I'm wrong, but I thought the "S" bit was only indicating what the
server did/or will do in terms of A updates for the domain name it returns
in the FQDN. This may be the same as the client sent, or it could be
completely different.

If a client is configured with "laptop.domain.com" and sends that FQDN,
there are four cases FOR WHAT THE SERVER RETURNS TO THE CLIENT:

1. S bit clear, "laptop.domain.com" -> client MAY do A update.
2. S bit set, "laptop.domain.com" -> client MUST/SHOULD NOT do A update.
(See below for the reason.)
3. S bit clear, domain other than "laptop.domain.com" -> client MAY do A
update for returned domain (and MAY do update for "laptop.domain.com".
4. S bit set, domain other than "laptop.domain.com" -> client MUST/SHOULD
NOT do A update for returned domain (and MAY do update for
"laptop.domain.com".

I believe Ted is not happy about case 2 because it may be that the server
just echoed the client's domain name (and set the "S" bit to 1). Also, the
text wasn't clear about case 4.

Stated another way, the server is telling the client WHAT IT DID or WHAT IT
WILL do in terms of the domain name returned in the FQDN. That is why if the
server says "I'm going to update the A for the returned domain name", why
should the client ALSO do the update?

The text in Section 3.1 states:

   The "S" bit indicates whether the server SHOULD or SHOULD NOT perform
   the A RR (FQDN to address) DNS updates.  A client sets the bit to 0
   to indicate the server SHOULD NOT perform the updates and 1 to
   indicate the server SHOULD perform the updates.  The state of the bit
   in the reply from the server indicates the action to be taken by the
   server; if 1, the server has taken responsibility for A RR updates
   for the FQDN.

So, this really says nothing about what the client should or should not do -
it is indicating what the server DID (or WILL DO as it may not have updated
DNS yet).

And, that is exactly why for case 2 above, there's no need for the client to
also send an update.

- Bernie

> On Behalf Of Charles R. Anderson
> Sent: Wednesday, February 09, 2005 10:52 AM
> To: [email-masked]
> It is my opinion that the DHCP client MUST NOT update if the 
> "S" is 1 and the server's returned Client FQDN matches the 
> DHCP client's explicitly configured FQDN.  The server is 
> telling the client not to update the zone for that Domain 
> Name, usually in my experience because the client would not 
> have permission to do so.  Allowing the client to optionally 
> do that would just allow clients to hammer the DNS server for 
> that zone needlessly.
> 
> This would allow a client to optionally ignore the "S" bit if 
> it is going to update a different zone than the one that is 
> in the administrative domain of the DHCP server.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Feb 2005 14:06:20 -0800

> for that zone needlessly.

Charles, the problem with what you're saying is that if a client is 
explicitly configured with an FQDN and the credentials it needs to do 
an update on that FQDN, then it is no business of the owner of the 
administrative domain containing the DHCP server to tell the client 
that it shouldn't do the update - the two are in separate 
administrative domains.   If they are not in separate administrative 
domains, the administrator shouldn't give the client an FQDN and the 
credentials required to update it.

So the case you're talking about prevents the right thing from 
happening in all the cases where doing the update is the right thing, 
and adds no needed capability in the case where doing the update is the 
wrong thing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Feb 2005 14:10:55 -0800

> And, that is exactly why for case 2 above, there's no need for the 
The situation I'm worried about is where the server is configured by an 
administrator who is trying to force a certain behavior on the client, 
and that's why I want the change in the language that specifies what 
the client must do.   I agree that in the abstract, your way of looking 
at the meaning of the 'S' bit is valid - it's just that it's not the 
only way to look at it, as Charles has so kindly illustrated.  :')

The changes you proposed are quite satisfactory to me, BTW, so if 
you're willing to put them in, and Charles is mollified by my response 
to his arguments, I've got no further objections to advancing the 
draft.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 15 Feb 2005 00:38:59 -0500

I've just requested new versions of the FQDN drafts to be published. They
are available at
ftp://ftp-eng.cisco.com/volz/draft-ietf-dhc-dhcpv6-fqdn-02.txt and
ftp://ftp-eng.cisco.com/volz/draft-ietf-dhc-fqdn-option-10.txt.

The following are the changes for the DHCPv4 draft (almost identical changes
were made to the DHCPv6 draft, adjusting for differences appropriately):

- I changed "conflicts SHOULD NOT occur" in the "DNS Update Conflicts"
section (6).

- In section 4.2, Client Desires to Update A RRs:

Changed:

To:

- In section 4.5, Domain Name and DNS Update Issues, I added to the end of
the section the following new paragraph:

- And, added RFC1918 to the References.

These changes were from comments Ted Lemon made to the DHC WG mailing list.

- Bernie