Subject: [dhcwg] dhc WG last call on <draft-ietf-dhc-ddns-resolution-09.txt>

From: Ralph Droms <[email-masked]>
Date: Sat, 09 Jul 2005 17:32:00 -0400

This message announces a WG last call on "Resolution of DNS
Name Conflicts among DHCP Clients"
<draft-ietf-dhc-ddns-resolution-09.txt>.  The last call will
conclude at 1700 EST (USA) on 2005-07-22.

Please respond to this WG last call.  If you support
acceptance of the document without change, respond with a
simple acknowledgment, so that support for the document can
be assessed.  Lack of discussion does not represent positive
support.  If there is no expression of support for
acceptance during the WG last call, the document will not be
advanced to the IESG.

The -09 revision of this document includes changes based on feedback
received during the previous last call on the document.  Please be
sure to confirm that you agree with the changes, which are summarized
in http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05160.html
In particular, confirm that you are in agreement with the change to
the update sequence as specified by the new text added to section
6.3.

SUMMARY:
There are options in DHCP that can be used for transmitting
information about updating DNS. However, these do not
explicitly control updating the name to address and address
to name mappings maintained in the DNS, as performed by
hosts acting as DHCP clients and servers.
draft-ietf-dhc-ddns-resolution-09.txt describes techniques
for the resolution of DNS name conflicts among DHCP clients
and servers.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-
resolution-09.txt

- Ralph Droms 

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

---

From: Ralph Droms <[email-masked]>
Date: Sat, 09 Jul 2005 18:42:50 -0400

Two comments on revision -09:

I think section 6.2 is not clear that the DUID used by DHCPv4 in a dual-
stack client is a subfield of the client identifier defined in draft-
ietf-dhc-3315id-for-v4.  Here's is some suggested text:

   Sites that wish to permit a single FQDN to contain both A and AAAA
   RRs MUST make use of DHCPv4 clients and servers that support using
   the form of client identifier defined in "Node-Specific Client
   Identifiers for DHCPv4" [6].  A DHCPv4 client that implements this
   form of DHCPv4 client identifier uses the same DUID used in the
   DUID field of the the client identifier to compute the RDATA in the
   DHCID RR.  A DHCPv4 server uses the DUID of the client identifier
   received from the DHCPv4 client to compute the RDATA in the DHCID
   RR.  Otherwise, a dual-stack client that uses older-style DHCPv4
   client identifiers (see [8] and [9]) will only be able to have
   either its A or AAAA records in DNS under a single FQDN because of
   the DHCID RR conflicts that result.

In the Terminology section, I think the document would be better served
by referring DNS terms to the DNS RFCs, DHCP terms to the DHCP RFCs,
etc.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jul 2005 15:31:58 -0500

I don't agree with the changed text about the order in which updates  
should be done.   The draft should specify one or the other.   I  
agree that my long rationale (rationalization) shouldn't be  
included.   The reason for specifying one or the other is not that  
one is more correct than the other - as my rationalization  
demonstrated, they are largely equivalent.   The reason for  
specifying one is to avoid saying "just do what you want."   We  
shouldn't say things like that in a protocol specification, because  
the reader may not understand the problem sufficiently to do what is  
required.

The change regarding secure DNS is fine.   You could also just take  
that out - I think it's self-evident.   But don't - the fewer changes  
that are made to the draft, the better.

Agree that it's unlikely that the A and AAAA will be updated at the  
same time, even if you have a dual-stack DHCP client, because the  
DHCPv4 and DHCPv6 responses will naturally come at different times.    
It is, however, possible, particularly during the transition to v6,  
that there will be both an A and an AAAA record, albeit as a result  
of separate updates.

Anyway, much as I hate to say it, I think that the change to the  
protocol I talked about at the beginning of this message needs to be  
fixed before this draft can proceed through last call.   I really  
hate to say that, because I think this spec needs to move forward.    
Please let this be a lesson to the last minute tweakers in the studio  
audience - a change that makes no difference should not be made,  
because it might be made wrong, and this creates delay.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Jul 2005 14:30:02 -0700

I would like to see section 6.3.4, when describing the policy for
'replacement' of fqdn's by the latest dhcp speaker claiming to have
that name, to state there must be a prerequisite for the over-riding
update...although implementations might do this update without a prereq,
I think the document should be consistent about suggesting DHCP servers
only touch names that either have DHCID's on them, or don't exist at all.

eg:

    ... If the configured policy allows
   replacement of existing records, the updater submits a query that
   deletes all RRs for the FQDN and adds the A and/or AAAA and DHCID RRs
   that represent the IP address and client identity of the new client.

becomes:

    ... If the configured policy allows
    replacement of existing records, the updater submits a query which
    contains:

	o A prerequisite that a DHCID RR of any value exist for this FQDN.
	o The deletion of all RRs for the FQDN.
	o The addition of the A and/or AAAA RR
	o The addition of the new DHCID RR.

Or something like that.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Jul 2005 15:10:24 -0700

> should be done.   The draft should specify one or the other.   I  

Actually, it's funny you should say that.  I harbor the opposite
opinion.

I was thinking that it shouldn't limit the implementor to start at
6.3.1 vs 6.3.2, because I think it would be useful in some environs
to start straight at 6.3.3 and let prereq failures lead you back to
6.3.2 if necessary.

Deleting the first paragraph of 6.3 would read the way I wanted it to,
jump straight into 'you MAY use other implementations'.

Since the first step the document outlines is the query, I think most
under-educated implementors would follow it.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jul 2005 17:21:50 -0500

> under-educated implementors would follow it.

Anytime you say "just do it however you like" in a protocol  
specification, you can bank on the fact that someone is going to do  
it completely wrong.   The whole point of specifying a protocol is  
not so that implementors can pick and choose what they want to do,  
but so that implementors have a specific way of doing things that  
will definitely produce the right result.   Implementors are always  
free to not follow the specification, and as long as what they do  
works, that's fine, but if there's a need for a protocol  
specification, the protocol specification should specify a  
protocol.   So while it's always true the implementations MAY not  
follow the protocol, there's no need to encourage them.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Jul 2005 16:02:25 -0700

On Tue, Jul 12, 2005 at 05:21:50PM -0500, Ted Lemon wrote:
> it completely wrong.

I don't see section 6.3 as making anything near that kind of statement,
which is why I disagree.

I can see where you're coming from, I think.  You're worried that
the current wording encourages people to exceed the protocol.

I didn't get the same feel you are from those words.

>  The whole point of specifying a protocol is  

...and the only thing this document needs to do to ensure that is to
outline that full-nonpresence or matching-DHCID-presence is mandatory
for the dynamic update prerequisites.

See where I'm coming from?

It's a 'how you wear your pants' issue.  Do we really need to specify
which leg goes first?  So long as you get around to all of them in
the end, and we describe how those steps might differ, and to mind the
slot for your tail (if equipped), it's all good in the end.

I don't see the order of these dynamic update operations as needing to
be part of this protocol's specification, so much as at least one
plausible order of operations, and each of the updates that comprise it.

It does that now.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 21 Jul 2005 09:36:40 -0700

> Name Conflicts among DHCP Clients"

I've taken some time to consider my own, Ralph's, and Ted's comments,
and I don't think the three of us have unearthed anything that would
measurably improve the draft if we delayed it.

So I support advancing this draft.