RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

I agree on Hui's and Ralpha's thoughts. 

There may be a necessary or worthy study that identifies and classifies what 
kind of information or network characteristics of/from the interfaces are 
necessary and helpful in order to judge active and valid routable interfaces 
for the destination (I am not sure the meaning and scope of "routable" with a 
destination in terms of MIF though) and determine an efficient/best one among 
them for the destination endpoint for the moment. 

Giyeong

 

-----Original Message-----
From: mif-bounces(_at_)ietf(_dot_)org [mailto:mif-bounces(_at_)ietf(_dot_)org] 
On Behalf Of Hui Deng
Sent: April 13, 2009 11:24 AM
To: Ralph Droms
Cc: mif; ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org; 
Black_David(_at_)emc(_dot_)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 
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 recommend how to handle it, give a example, we 
may prioritize some wifi apn policy, and make others as just a category of 
normal wifi.

Anyhow, those thing need to be further studied based on the current practice.
Thanks for the discussion.

-Hui


2009/4/13 Ralph Droms <rdroms(_at_)cisco(_dot_)com>:

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 merges information?  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?

- Ralph

On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote:

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

2009/4/11 Scott Brim <swb(_at_)employees(_dot_)org>:


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 upstream service provider and a single source of DHCP 
options to be passed along to the client.  In this scenario, 
there's no need to pass along any information identifying the source of 
the options.

To allow for a multihomed subscriber network, I can imagine adding 
a tag that would be passed along with the options so the subscriber 
client can identify the source of each option.  But, what would the 
client do with that information?  How would the client interpret 
it?  What is the syntax and semantics of the tagging?

Taken a step farther, sourcing information might be required even 
if there is no intermediate RG and the contained option is not in 
use.  How does a device with multiple interfaces make policy 
decisions about information received on those multiple interfaces 
(which is pretty much the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be 
merged.  The case where a single RG client connected to multiple SP 
servers is essentially already covered by MIF/6man, they just need 
to document it.  If the information is merged at the RG server, then 
the RG server should somehow know which interface which DHCP 
information came from.  If all of the information is transparently 
passed to the consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP 
server's IP address doesn't sound like a good idea.  The WG should 
decide if tagging should be included in the container syntax or 
added later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott


On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:

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.

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date:         7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

 I am concerned about multiple interface scenarios as are being
 discussed in MIF and 6MAN, where either the RG is multiply 
connected
 or the end device is.  For a discussion of the sort of problems 
that
 lead to this concern, see (for example) notes from the MIF BOF at
 IETF74.

 - There must be a way to associate options with a particular
   upstream DHS they were obtained from, when the container is 
passed
   to the RG server and perhaps to the end device.  This source
   information may or may not be in the container itself -- that's 
up
   to the WG to decide.  If it is decided that the source 
information
   will not be part of the container syntax, at least the fact 
that
   it is necessary should be documented for people who ultimately 
do
   specify how container options are passed.

 - The SP server may have its ideas of how a consumer device 
should
   be configured, but it is not appropriate to say that the "SP
   server MUST be able to control which DHCP options are 
transmitted
   to the consumer device".  The RG server may need to make 
decisions
   about information from multiple DHCP servers.  Perhaps you 
could
   say that the SP server MUST be able to "provide information" to
   the RG server.

Less significant:

 5.1 and 5.2

   Alignment between the v4 and v6 descriptions would be better. 
The
   v4 description has "code" in the diagram and says that "code" 
is
   OPTION_CONTAINER_V4.  The v6 description has "OPTION_CONTAINER_V6"
   in the diagram and says that "option-code" is OPTION_CONTAINER_V6.


_______________________________________________
dhcwg mailing list
dhcwg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
mif mailing list
mif(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mif

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf