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:09:50 -0400

I guess it is time I commented as no one else seems to have expressed an
opinion.

I think RFCs should generally not dictate how something is done. Yet,
providing a sequence of steps that is known to be good as an example and
to communicate the complexity of the issue is, I think, proper. There
are several RFCs that provide algorithms to calculate checksums, but
there is no requirement that anyone use that specific algorithm. So, I
would like to keep the ability for implementers to use different
sequences of operations to effect updates.

If there is some text that should be added to clarify any specific
requirements that other sequence of steps must follow, please let me
know.

Section 6.3 currently reads:

6.3  Adding A and/or AAAA RRs to DNS

   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.

   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.

   As the update sequence below can result in loops, implementers SHOULD
   limit the total number of attempts for a single transaction.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, July 12, 2005 6:22 PM
> To: David W. Hankins
> Cc: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-09.txt>
> 
> On Jul 12, 2005, at 5:10 PM, David W. Hankins wrote:
> > Since the first step the document outlines is the query, I 
> think most
> > 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.
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Jul 2005 08:40:10 +0900

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.