Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-09.txt

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Jul 2005 17:31:46 +0000

On Wed, Jun 29, 2005 at 03:50:02PM -0400, [email-masked] wrote:
> 	Title		: Resolution of FQDN Conflicts among DHCP Clients
> 	Author(s)	: M. Stapp, B. Volz
> 	Filename	: draft-ietf-dhc-ddns-resolution-09.txt
> 	Pages		: 15
> 	Date		: 2005-6-29

Bernie,

Section 6.5 (removing records from dns),

   If either query fails, the updater MUST NOT delete the FQDN.  It may
   ...

'fails' is funny language.  Several of what would be 'failure' RCODEs
are in my mind success for these steps (certainly if you get NXDOMAIN
when you try to delete your A/AAAA, you're done).  And since the FQDN
is only deleted after a prereq, as defined in the draft, I hardly see
why it's necessary to explicitly state that the updater not delete the
FQDN?  Perhaps 'under no circumstances should the updater attempt to
delete the FQDN without these prerequisites?'

I think this could use being formatted similarly to 6.3 (mostly because
I just finished reading that section, so section 6.5 is a rather sudden
contrast).  Put each query in a section, point the implementor through
the process by explicitly naming RCODEs (explain the NXDOMAIN
possibility on the second query for example).

I also rather wonder if we should include any words that allows for
'claim staking' within the namespace.  Eg, an updater may choose not
to delete their DHCID, even though they've deleted the last A/AAAA.
This keeps other clients from getting 'their' name for some grace
period.  Squatters rights kinds of policies.

A simple delay between the first and second queries is all that is,
which may be minutes days or months.

Thoughts?

Also at the tail end of 6.5, 

   ... In these cases, the DHCID RR
   will no longer match the updater's notion of the client identity of
   the client pointed to by the FQDN.

But in only one of the two named cases is that certainly true.

Sorry this isn't a full review of the document, these are the thoughts
I was left with reading this all before a morning appointment I have to
get to presently.

-- 
David W. Hankins		"If you don't do it right the first time,
Operations 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 13:40:40 -0700

> which may be minutes days or months.

Disregard, bad idea.  There's no way for an updating agent to know if
there have been one or more address additions and deletions between
the time it deleted its own A's and the time it choose to see if
the DHCID was ready.

So let's not go down this rathole after all.

Software Engineer			you'll just have to do it again."

---

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

> So let's not go down this rathole after all.
Let's not go down any ratholes.   Objections should be of the form  
"the protocol as described in the draft doesn't work because of X,"  
not "I think it would be useful if we added Y."   We can always add Y  
in a follow-on draft.   :')