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

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

David:

In 6.5, this is much simpler sequence so why do we need multiple steps?

If the first query fails (even with NXDOMAIN), you're done. If the
second query fails, you're done as well?

The first update query removes just the client's A or AAAA records
(provided the DHCID RR exists). So what can happen:
- No RRs present for domain name, nothing more to do.
- DHCID RR is present, but the client's specific A/AAAA aren't, then do
we really want to continue? The text says that one reason you don't is
that if may well be another server has added an A record. While we COULD
have the updater do the second update (if DHCID present and no A/AAAA,
delete all RRs), I don't see how this can normally happen and so why
waste the time?

So, I'm inclined to leave the text alone unless you can come up with an
error condition that makes sense to do something more complicated?

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David W. Hankins
> Sent: Tuesday, July 12, 2005 1:32 PM
> To: [email-masked]
> Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-09.txt
> 
> 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: Fri, 22 Jul 2005 12:20:42 -0700

> error condition that makes sense to do something more complicated?

I'm also inclined you leave the text alone.

I'm sorry this portion of my comments were scatterbrained, I was trying
to get dressed and run out the door for an appointment, but didn't want
to lose them to the bitbucket.

My first thought was that not having each rcode you might expect from
either update clearly defined, as it was in 6.3, made it appear that it
simply hadn't been investigated...that this was being left up to
implementors to blunder into.  Certainly there are 'failure' conditions
that an implementor would want to silently treat as 'success', and not
inform the user about (or inform them at a different level of logging).

I think I wouldn't have thought to comment if instead of "fails" the
document said "not no_error."

As for subsections...I didn't say that because it needed a procedural
flow, but rather because subsections nicely punctuate one event from
another.

At that particular moment when I wrote those comments, my mind was stuck
on the idea that a reader be 'conditioned' to expect 6.3's layout by the
time they had reached that point reading the draft.  Continuing to write
the document with the same process - events the implementor is
responsible for punctuated by sections - just tends to naturally follow.

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