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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 22 Jul 2005 13:23:16 -0400

David:

There are two ways you can end up in section 6.3.4, either from 6.3.1 or
6.3.3. If from 6.3.1, there is no DHCID RR associated with the name.

So, we can't require the DHCID RR prereq (or at least have to condition
it).

Do you really think the complexity of saying this is worth it? If the
server's policy is to overwrite entries, what does it matter what it
overwrites? (I can't see many servers ever doing this, except perhaps in
an exception case where a server is the only server and has losts its
stable storage.)

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David W. Hankins
> Sent: Tuesday, July 12, 2005 5:30 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-09.txt>
> 
> 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: Fri, 22 Jul 2005 11:39:23 -0700

On Fri, Jul 22, 2005 at 01:23:16PM -0400, Bernie Volz (volz) wrote:
> 6.3.3.

Since it's a "may", I didn't pay particular attention to that clause
in 6.3.1.

If you integrated something like the changes I discussed, I would
append;

...matter of local administrative policy.  Or, the updater may proceed
   similarly to Section 6.3.4, except without the prerequisites section.

Which is easier and more readable than double-talk within 6.3.4.

Personally I'd leave that whole bit as an excercise to the reader and
just not say anything about going to 6.3.4 from 6.3.1.  This is not
only a matter of "replacement policy" you're describing, it's a matter
of playing fast and loose with the zone...where people mix DHCP-managed
and adminstrator mananaged namespaces (www.mydomain and fredsbox.mydomain),
this won't fly.

> If from 6.3.1, there is no DHCID RR associated with the name.

No, you only think there isn't a DHCID...only the master(s) know for
certain.

1) 6.3.1 is a regular DNS query.  It may be through a recursive nameserver.
	That recursive nameserver may cache both positive (existence) and
	negative (non-existence) results.

2) You also might just as easily get an answer from an authoritative server
	which has an older copy of the zone (that is, you or your recursive
	server might have...).

3) You might be in a race condition, where after your query proving there
	is no DHCID, one was added.

So I think you should encourage the DHCID prerequisite, to at least
make people think about why.

> an exception case where a server is the only server and has losts its

I do, but as I later mentioned, I don't think this is worth delaying
the draft.  I think it's implicit the way the draft is currently worded,
the spirit of the DHCID record, and since we have so many different name
policies floating around people need to keep track of theirs.  That in the
general case, and not the 'may' conditional, 6.3.4 is entered into as a
matter of policy to replace an entry owned by another dhcp-managed entity.

Ensuring that the name is dhcp-managed is just good practice, if that's
your policy.

Saying it out loud in the draft is just my preference.

-- 
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