I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Docume
Scott raises an interesting point about identifying the source of
options when delivered to clients.
BTW, Scott - what is "DHS"?
The usual case - almost the only case today - is that there is a
single upstream service provider and a single source of DHCP options
to be passed along to the c
Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:
> Scott raises an interesting point about identifying the source of
> options when delivered to clients.
>
> BTW, Scott - what is "DHS"?
Sorry, DHCP server
> The usual case - almost the only case today - is that there is a single
Scott - even knowing "which interface which DHCP information came
from" may not be enough for a device with multiple interfaces. Can
policies for merging information be written just based on the
characteristics of the interface - say, 3GPP versus 802.11, or IP
address of the interface - or
Sorry to stick my oar in, but does this or could this interact with the options
specified in RFC3046 in an unexpected way?
At 01:41 PM 4/11/2009, Ralph Droms wrote:
>Scott - even knowing "which interface which DHCP information came
>from" may not be enough for a device with multiple interfaces
Hi, Scott,
Based on the current MIF charter proposal, it consider only host.
http://www.ietf.org/mail-archive/web/mif/current/msg00367.html
I am wondering whether RG is a kind of host?
Anyhow, this discussion benefit MIF for the future consideration how
to identify the source.
Many thanks
-Hui
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
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
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
Ted - I think it's just as likely for the RG to get different
information from different interfaces (or different "administrative
domains") as it is for a host to get get different information
directly. Traffic from the host, which is then forwarded by the RG to
one of more than one possib
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
ph Droms (rdroms)
Sent: Friday, April 10, 2009 3:26 PM
To: Scott Brim
Cc: dhc WG; gen-...@ietf.org; black_da...@emc.com; ietf@ietf.org
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Scott raises an interesting point about identifying the source of
options when delivered to
On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote:
Now, I admit I'm describing a hypothetical and abstract scenario. I
don't have a specific example of a situation in which a host might
make decisions - either in the stack or in an application or ??? -
about outbound traffic based on knowledge of
Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700:
> I don't mean to minimize this issue - if in fact there is some
> future real-world scenario where this would be a serious problem,
> it would be good if we could anticipate it.
I'm just saying the WG should make an explicit deci
On Apr 15, 2009, at 2:12 PM, Bernie Volz (volz) wrote:
My "vote" would be no change. But, I'd be OK if Ralph wanted to
state it
is TBD and outside the scope of this document and perhaps indicate
that
it is an issue whether the RG gets options to pass on from either the
container option or fro
-Original Message-
From: Scott Brim [mailto:s...@employees.org]
Sent: Wednesday, April 15, 2009 4:52 PM
To: Ted Lemon
Cc: Ralph Droms (rdroms); Bernie Volz (volz); dhc WG; gen-...@ietf.org;
black_da...@emc.com; ietf@ietf.org; mif
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
I would be in favor of stating explicitly that this issue is outside the
scope of the specification at hand.
Jari
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi, Ted,
Excuse me for my late comment, I try to catch this thread.
For the case of the device has two interfaces which originate query.
Your suggestion looks quite interesting: try every plausible way.
I guess this is interesting topic in MIF future work.
And you talked about Stuart Cheshire des
>> And you talked about Stuart Cheshire described a couple of IETFs ago,
>> Could you help to point out the link?
>
> Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's
> reading this.
Thanks, let's see whether he is going to talk here.
> The gist of what he was saying is
On Apr 19, 2009, at 7:46 AM, Hui Deng wrote:
And you talked about Stuart Cheshire described a couple of IETFs ago,
Could you help to point out the link?
Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure
he's reading this.
The gist of what he was saying is that if you ha
rg] On Behalf Of Hui Deng
Sent: April 13, 2009 11:24 AM
To: Ralph Droms
Cc: mif; ietf@ietf.org; gen-...@ietf.org; black_da...@emc.com; dhc WG
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Hi, Ralph,
I agree what you said here, Scott raised the possible issue how to
diff
Son [mailto:g...@rim.com]
Sent: Wednesday, April 15, 2009 9:53 AM
To: Ted Lemon; Ralph Droms (rdroms)
Cc: mif; ietf@ietf.org; black_da...@emc.com; dhc WG; gen-...@ietf.org;
Bernie Volz (volz)
Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
I think Ted pointed out ver
On Apr 15, 2009, at 7:11 AM, Bernie Volz (volz) wrote:
How realistic is that most RGs with multiple interface will connect to
DIFFERENT service providers? And, in the case where they do, this
likely
means someone (the owner of the RG) has to make some decisions --
requiring appropriate configu
Yup ... there is currently no way to provide authenticated, meaningful
identification of the network(s) to which a host is attached. Without
that identification, it's pretty hard to write any reasonable policies.
- Ralph
On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:
On 2009/4/13 R
...@cisco.com]
Sent: April 16, 2009 1:32 PM
To: Ted Lemon
Cc: Giyeong Son; Hui Deng; dhc WG; gen-...@ietf.org; mif; ietf@ietf.org;
black_da...@emc.com
Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
Yup ... there is currently no way to provide authenticated, meaningful
On 2009/4/13 Ralph Droms wrote:
For example, would a host process
information received from a Starbucks network over its 802.11
interface differently from information received a home network over
the 802.11 interface?
It's even more fun than that. How do we reliably know that we are at
S
802.11i authentication, if enabled, provides mutual authentication, but
that's only between the client and the _home_ network. You know that the
home network trusts the access network because it was given the session
key, but you have no idea if the access network is, say, CheapAccessInc
or Wor
> -Original Message-
> From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Hui Deng
> Sent: April 13, 2009 11:24 AM
> To: Ralph Droms
> Cc: mif; ietf@ietf.org; gen-...@ietf.org; black_da...@emc.com; dhc WG
> Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc
reliably
> and efficiently.
>
>
> Giyeong
>
> -Original Message-
> From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of
> Ted Lemon
> Sent: April 14, 2009 5:48 PM
> To: Ralph Droms
> Cc: mif; ietf@ietf.org; black_da...@emc.com; dhc WG; gen-...@ietf.org
yeong
>
> -Original Message-
> From: Ralph Droms [mailto:rdr...@cisco.com]
> Sent: April 16, 2009 1:32 PM
> To: Ted Lemon
> Cc: Giyeong Son; Hui Deng; dhc WG; gen-...@ietf.org; mif; ietf@ietf.org;
> black_da...@emc.com
> Subject: Re: [dhcwg] [mif] Gen-ART review of
dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Hi, Giyeong,
At least those are not in the current charter scope.
but Ted gave a one potential solution on one problem.
Regarding to Money et al, I think IETF is not going to talk about it.
which is more operational recommendation. Opera
f multiple interfaces
>> reliably and efficiently.
>>
>>
>> Giyeong
>>
>> -Original Message-
>> From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of
>> Ted Lemon
>> Sent: April 14, 2009 5:48 PM
>> To: Ralph Droms
>&
Excerpts from Giyeong Son on Mon, Apr 20, 2009 11:35:14AM -0400:
> For instance, for a dual-mode device at home with WiFi and IP over
> cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of
> various network characteristics in it would be the major factors to
> determine either WiFi or cel
34 matches
Mail list logo
