Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt

On Tue, Mar 13, 2007 at 06:44:24AM -0600, Thomas Narten wrote:
> I think they (and the IETF as a whole, as I don't think the IETF LC
> has happened) will probably be able to evaluate it better with the
> extra sentence (btw, what will it be?).

  "Such as determining which server in a cluster will respond to the
   client."

Would be my pick.  Simplest one.

> Well, for one thing, the above text makes its sound like a protocol
> violation to implement the spec, but choose not to send the option
> (e.g., even if configured to do so for some reason). That seems a bit
> strong to me.

There is a compatibility matrix here.

If both the SRSN and the flags option are present, then a server
might choose to support the SRSN and copy its contents to the
server-identifier option.

If the SRSN is present, and the flags option isn't, then they
might refuse to copy the contents over, which preserves the
detection of RENEWING vs REBINDING even if the result is all
RENEWs fail (due to filters or topology).

If the flags option itself is present on its own, that's possibly
useless...unless more flags are defined.

So it depends what "compatibility" means.  The middle scenario
will "work" in all cases.  In the scenario where SRSN is trying
to bridge a unicast network gap, it will force clients to rebind
rather than renew...their unicasts to the server will fail.

Certainly, it will still work, but is that compatible?

If we said yes, does this mean that any solution that sends
clients through INIT to retain network connectivity is also
compatible?

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