I am fine with this too. (the new boilerplate that incorporates rfc3578
verbiage.)
Thanks
Mitesh
-Original Message-
From: Randall Stewart [mailto:r...@lakerest.net]
Sent: Saturday, April 11, 2009 3:02 AM
To: Brian E Carpenter
Cc: Anantha Ramaiah (ananth); draft-ietf-tcpm-tcpsec...@tools
While this is certainly an interesting point, I don't really see that it
is specific to the container option or that the container option adds
any new or different issues?
I don't see why this would hold up this draft (perhaps it is not holding
it up)? Perhaps at most some statement(s) about the i
How realistic is it anyway that an RG would get different *relevant*
options on its different interfaces? This would seem to me to be an
administrative error. Of course the broadcast address and subnet
mask options might be different, but it doesn't make sense to send the
RG, e.g., diff
Hi Ralph -
Yup.. we've been at this way too long.
On the matter at hand:
Both of these documents allow a bit of twiddling with what gets sent to the
ultimate end client. The DHCP relay agent does this indirectly by signally
which branch of the network tree it exist in so the upstream DHCP ser
Hi, Ralph,
I agree what you said here, Scott raised the possible issue how to
differentiate the source.
One instant thinking about the two different 802.11 interface is that
the principal source policy selection will not be able to tell the
diffference, we could allow high level policy to recomme
Hui - I think there is an issue for hosts with multiple interfaces
triggered by Scott's comments about the container option: even if a
host is physically aware that it has multiple interfaces, how does it
take the characteristics of the networks behind those interfaces into
account when it
Mike - Can you give a little more detail? I'm not sure I see how the
RFC 3046 options - passed between a relay agent and a server - would
interact with the container option.
BTW, please feel free to join the conversation at any time. The SF
meeting marked the 20th year anniversary of the
