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

David,

unless I read Thomas's emails wrong, he wasn't really trying to point 
out some subtle state-machine issue. he was just talking about a MUST 
terminology issue that he'd like clarified. I think it's just a text 
change ... coming soon ...

-- Mark

David W. Hankins wrote:
> 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?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg