Subject: [dhcwg] Status of draft-ietf-dhc-relay-agent-flags-02.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Apr 2007 18:36:52 +0300

I have made my AD review of this specification. I saw
no issues, but I would the authors to prepare a new
version in response to Thomas Narten's comments
before we go to IETF Last Call.

Jari

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

---

From: Mark Stapp <[email-masked]>
Date: Mon, 30 Apr 2007 11:56:07 -0400

Jari,

I've prepared a revised draft - just checking with the other authors to 
confirm they're ok with the changes.

Thanks,
Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 30 Apr 2007 09:48:41 -0700

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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Mon, 30 Apr 2007 12:40:52 -0400

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