[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Is there some text that someone would like to add to the
draft to address this issue?
On Thu, 3 May 2001, Scott G. Kelly wrote:
> Hi Thomas,
> Thomas Narten wrote:
> > > The text in the latest rev (11) has been modified to suggest using the
> > > relay option, but I wonder if this doesn't raise backward compatibility
> > > issues. A large number of deployed dhcp servers do not support the relay
> > > agent option, and in these cases, per-client state must be maintained. I
> > > wonder if we shouldn't have some language to this effect. Does anyone
> > > disagree?
> > I would spin the backwards compatability issue differently. In both
> > cases, it would seem that new code needs to be written, since neither
> > approach is presumably widely deployed today. Do we recommend that
> > implementors implement an existing standard that *is* being
> > implemented in deployed in some environments because it meets a need
> > (i.e., the reason the relay agent option was defined in the first
> > place) or do we recommend a different and non-standard way? The choice
> > seems obvious to me.
> I think I understand your position, and I agree from a philosophical
> standpoint. I have always thought the relay agent option was the best
> way to implement this. However, from a practical standpoint, we could
> not have deployed the units we have out there which use DHCP (in the
> thousands, I think) if we had relied upon the relay agent option. I am
> not advocating that we suggest an alternative method which may be used
> even if the relay option is available; I am suggesting adding text (an
> implementation note?) explaining that if the relay agent option is not
> supported, that state must be maintained in order for this to work. This
> might help to avoid implementer confusion.
> I don't feel strongly about this, but thought (based on years of
> implementing protocols based upon RFC's) that some clarifying language
> might be useful.