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 20:55:56 -0400

Ok, but either approach works so why not let people pick where they want
to start. We are suggesting they start at 6.3.1 and most people that
implement this will do that? Why do you assume this will confuse them?
Even if they start at 6.3.2, what's the problem?

Or are you just objecting to the second paragraph:

   Implementers MAY use other algorithms, provided that the algorithm
   assures that the DNS updates are done with the proper prerequisites
   to prevent incorrect or incomplete updates should multiple updaters
   be updating the same FQDN at once.

- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, July 22, 2005 7:40 PM
> To: Bernie Volz (volz)
> Cc: David W. Hankins; [email-masked]
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-09.txt>
> 
> On Jul 23, 2005, at 2:09 AM, Bernie Volz (volz) wrote:
> > I think RFCs should generally not dictate how something is done.
> 
> This is precisely what all RFCs do.
> 
> > There are several RFCs that provide algorithms to calculate  
> > checksums, but
> > there is no requirement that anyone use that specific algorithm.
> 
> On the other hand, there's the DHCP load balancing algorithm, where  
> if you get it wrong, some clients will never hear from the 
> DHCP server.
> 
> I think this falls into a grey area.   I don't think it's necessary  
> to say that the client MUST do it a certain way.   However, I also  
> don't agree that it's necessary to *suggest* that the client can do  
> it in a variety of ways, because you have not given the reader  
> sufficient guidance as to which ways will be okay, and which will  
> not.   And, indeed, I don't think it's the place of an RFC to give  
> such detailed guidance, nor the duty of the reader to have to spend  
> the time it would take to understand it.   The reader should be free  
> to simply verify that his or her code complies with the  
> specification, and should be able to feel confident that by 
> complying  
> with the specification, the code will work as expected.
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Jul 2005 11:29:26 +0900

I am suggesting that we think of this as an interesting intellectual  
problem, which we understand well, but the typical implementor thinks  
of it as something to get done, and we should oblige them by telling  
them clearly what to do.   If they want to get fancy, I don't mind  
leaving the language in such a way that they are not forbidden to do  
so, but the text should give them clear guidance as what to do, not  
teach them the general understanding of how it works.

But yes, the main thing to which I am objecting is the paragraph that  
you quoted.   You don't have to tell them they can invent other  
algorithms - if they are predisposed to do so, the absence of a MUST  
in the language describing how to do the update will suffice.    
Whereas if you volunteer that one MAY use some other algorithm, then  
you leave the average reader with unanswered questions and a sinking  
feeling in their gut, and this could very well result in an incorrect  
implementation, or at the very least a lot of worries questions on  
the dhcwg mailing list.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 26 Jul 2005 14:42:13 +0200

> Even if they start at 6.3.2, what's the problem?

Currently it says in 6.3:

   When a DHCP client or server intends to update A and/or AAAA RRs, it
   has two choices as to where to start the update sequence.  The choice
   of whether to start with the lookup query in Section 6.3.1 or to
   start directly with the update in Section 6.3.2 is left to the
   implementer.

So based on this it appears to be totally arbitrary what one should do.
As an implementer I would find it helpful to have some guidance (e.g.
pros and cons, when one is better than the other). Can't we say that
one should generally start with 6.3.1, but may.... Or something along
those lines? That is, stating one alternative, but saying that the
other is also perfectly fine. So that if I as an implementor don't
have a preference, the draft can tell me which to go for.

I don't see this as a big issue, but this is my view anyway.

>    be updating the same FQDN at once.

I think this one is fine. It is obvious that you MAY use other algs if
there are no MUSTs saying that you need to use the one specified, but
it's good to emphasize the prerequisites.

Stig