Re: Re: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR?

Thank you Ted - that's an excellent response.

We're trying to solve a specific problem, a problem we believe we 
understand. We took some steps towards generalizing the rr, in that we made 
the type codes within the rr data an iana-managed space, and described what 
it would take for someone to have a new code allocated. That's really all 
the generality that's justified by the experience we have right now.

-- Mark

At 10:19 PM 6/5/2003 -0700, Ted Lemon wrote:
>Issues one and two are basically the same issue - should we extend DHCID to
>make it work for things other than DHCP.   The answer is, flatly, no.   This
>would be a disaster.
>
>The reason is that DHCID specifies a DHCP-specific format for the hash.   If
>you aren't doing DHCP, you don't have enough information to create a hash
>that interoperates.   Discussion point one says "shouldn't we do this?"   The
>answer is no.
>
>Discussion point two says "here's how we should do this."   The problem is
>that if you have other applications using the DHCID with different
>information, then DHCID's intended use is broken - the DHCP server can't use
>DHCID records it's inserted if some other thing is also inserting records,
>because the DHCP server depends on the DHCID working correctly in update
>prerequisites.
>
>So either option 1 or option 2 breaks interoperability, and can't be allowed.
>
>If some other application needs to do something similar to DHCID (I can't
>think of any reason why one would, but stipulating that one would), it could
>just define a new RRtype.   There is no shortage of RRtype codes.
>
>Adding complexity to DHCID to support theoretical new protocols we haven't
>even designed yet is a false economy - it breaks the DHCP/DNS interaction
>model, and it does not add value.   It is a solution in search of a problem.
>
>Simple Is Good.
>
>_______________________________________________
>dhcwg mailing list
>dhcwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg