Subject: [mif] Charter Updated Ver. 2

From: Hui Deng <[email-masked]>
Date: Tue, 17 Feb 2009 14:12:29 +0800

Hello, all

The charter has been updated based on the comments from the mailing list:
Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierrick,
Qin, Jacni, Gerardo, Tao, Kai for their comments.

Please help to comment on it,

thanks

-Hui

----------------------------------------------------------------------------------------------------------------------
Background and Motivation

   A multi-homed host has multiple network interfaces (physical and/or
   logical).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces.
   A multi-homed host doesn't have any IP mobility function supported like
   the mobile node specified in the RFC 3775.

   RFC 1122 has speicify the strong model and the weak model for a
   multi-homed host, the weak model has been widely implemented by
   the major OSs, but it treat the source and destination of the connection
   as a host other than interfaces. Strong model recently has been
   implemented in new OSs. Some mobile OSs has implemented a connection
   manager which could help the application select which interfaces based
   on the strong model. The policy used by the connection manager could
   be configured by the host user from the UI interface, and it also can be
   acquired from the network side either by the operator or the enterprise.
   Anyhow, what kind of policies and how those policies will be delivered
   to the host are still under-specified in IETF.

   A multi-homed host receives node configuration information from each
   of its access networks.  Some configuration objects are global to the
   node, some are local to the interface.  Various issues arise when
   multiple configuration objects that are global to the node are
   received on the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behaviors of an IPv4 and IPv6
   stack and possibly extend the existing protocols to manage these cases.
   It is noted that even after received those network policies, user could
   still decide how to discover and which interface will be selected based
   on RFC 5113.

   It is also notable that the general host and site multihoming designs
   (SHIM6 and RRG) is different from the work (policy of the connection
   manager) to be done here. And the difference between Monami and work
   here is that there is no agent in the network side to hide the
   interface's address.

Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:

 Problem statement

   o A document describing the problems caused by the multiple
   interfaces in the host. (Informaitonal)
 Current Practices

   o What the current major host vendors do regarding to multiple
   interfaces.(Informational)

 Split DNS:
   o A solution for optimal behaviour of multi-homed host when
   one or more of its interfaces is facing a DNS service providing
   interface-local information.
   (Best Current Practice/Proposed Standard)

 Routing of multiple interfaces:

   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose
   the best interfaces for different applications/flows in the host.
   Thus a IPv4/IPv6 host would need to be provided with more application
   related specific routing information for interface selection based
   on DHCP. (Proposed Standard)

 Merging of IP layer autoconfiguration:
   o A multi-homed host received IP layer autoconfiguration information
   across multiple access networks. Thus it need to merge all those
   configuration information. (Best Current Practice)

The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.

The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.

Approximate Timeline for Deliverables:
-------------------------------------
    * April 2009 WG approved by IESG
    * 2H09 Submit problem statement I-D to IESG
    * 1H10 Submit current practices I-D to IESG
    * 2H10 Submit Split DNS I-D to IESG
    * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG
    * 2H10 Submit Routing of multiple interfaces I-D to IESG
    * 2H10 Recharter or close WG

---

From: [email-masked]
Date: Tue, 17 Feb 2009 15:35:09 +0800

hi hui:
 
  I read the Charter v2. and I have one question.
 
  1. shall we keep the service continuity When some of interfaces is down 
?
 
  2. shall this MIF consider the effect on application layer ? since I 
only find the influence on routing, DNS and IP layer... 

  thanks

  Best Regards

Terry(HongYan) Wang

---------------------------------------------------
Address: System Architecture Department, Central Institute, ZTE 
Corporation
Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipcode: 210012
Office Telephone: 
Mobile Telephone: +86-15905178852
Fax: +86-25-52878008
MSN: [email-masked]

Hui Deng <[email-masked]> 
发件人:  [email-masked]
2009-02-17 14:12

收件人
mif <[email-masked]>
抄送

主题
[mif] Charter Updated Ver. 2

Hello, all
 
The charter has been updated based on the comments from the mailing list:
Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, 
Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments.

thanks
 
-Hui

 
   RFC 1122 has speicify the strong model and the weak model for a 
   multi-homed host, the weak model has been widely implemented by 
   the major OSs, but it treat the source and destination of the 
connection
   as a host other than interfaces. Strong model recently has been 
   implemented in new OSs. Some mobile OSs has implemented a connection 
   manager which could help the application select which interfaces based 
   on the strong model. The policy used by the connection manager could 
   be configured by the host user from the UI interface, and it also can 
be
   acquired from the network side either by the operator or the 
enterprise.
   Anyhow, what kind of policies and how those policies will be delivered 
   to the host are still under-specified in IETF.

 
Proposed Work:
-------------
 
 Problem statement

 
 Split DNS:

 

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Yungui Wang <[email-masked]>
Date: Tue, 17 Feb 2009 16:14:14 +0800

Hello Hui

>   on DHCP. (Proposed Standard)

Here is one comment: why is it limited to DHCP only? Maybe there are
some else mechanisms needed. Thanks.

B.R.  / Yungui

----- Original Message ----- 
From: "Hui Deng" <[email-masked]>
To: "mif" <[email-masked]>
Sent: Tuesday, February 17, 2009 2:12 PM
Subject: [mif] Charter Updated Ver. 2

> Pierrick,

--------------------------------------------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 09:46:20 +0100

Hi Hui,

the charter is in much better shape now
some comments below...

> Please help to comment on it,

I would rephrase the last sentence.
I mean, a multihomed node can have MIPv6 support, but  this case is 
simply out of the scope of the work you are proposing
Moreover, you only mntion MIPv6, i think you should also state that 
MIPv4 is not supported neither
>    here is that there is no agent in the network side to hide the
this is clear to me now....
I am still not sure this is a good idea
do you have any draft that describes how this would look like?

>    configuration information. (Best Current Practice)

i am not sure i fully understand this last one.
wouldn't the split DNS work above be related to this?
What about the work on routing on multiple interfaces?

I mean, is this work item about how to merge the DNS information and the 
multiple route information of the two previous bullets or is it about 
merging some other information?
If it is some other information, what information do you have in mind?

> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 09:50:56 +0100

Hi,

Please see inline.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Yungui Wang
> Envoyé : mardi 17 février 2009 09:14
> À : Hui Deng
> Cc : mif
> Objet : Re: [mif] Charter Updated Ver. 2
> 
> Hello Hui
> 

I agree, maybe we should simply rephrase as: 

   related specific routing information for interface selection. (Proposed  
   Standard)

BR,
Pierrick

> ----------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 10:02:41 +0100

>    related specific routing information for interface selection. (Proposed  

i am not sure about that
i think it is better to have a narrow scope.
Do you have other methods in mind for this? which are those?

regards, marcelo

>>>   A multi-homed host doesn't have any IP mobility function supported
>>>       
>> like
>>     
>>>   there is a need to define the appropriate behaviors of an IPv4 and
>>>       
>> IPv6
>>     
>>>   It is noted that even after received those network policies, user
>>>       
>> could
>>     
>>>   still decide how to discover and which interface will be selected
>>>       
>> based
>>     
>>>   on RFC 5113.
>>>

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 10:36:26 +0100

> De : marcelo bagnulo braun [mailto:[email-masked]]
> Envoyé : mardi 17 février 2009 10:03
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]; [email-masked]

I have in mind architecture where the core network hosts a policy server; so independent from access networks.
Protocols used by the server to provide policies to the node may be 802.21 in push mode or OMA-DM.

Hope it clarifies.

BR,
Pierrick

> >> -----------------------------------------------------------------------
> ---
> >> ------
> >>
> >>
> >>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 10:49:12 +0100

[email-masked] escribió:
>>>>>   Thus a IPv4/IPv6 host would need to be provided with more
>>>>>           
>> application
>>     
>>>    related specific routing information for interface selection.
>>>       
>> (Proposed
>>     
>>>    Standard)
>>>
>>>       
>> i am not sure about that

how would that be in the scope of the work in IETF?

regards, marcelo

>>>>> The charter has been updated based on the comments from the mailing
>>>>>           
>> list:
>>     
>>>>> ----------------------------------------------------------------------
>>>>>           
>> --
>>     
>>>>>   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN
>>>>>           
>> connections
>>     
>>>>>   manager which could help the application select which interfaces
>>>>>           
>> based
>>     
>>>>>   be configured by the host user from the UI interface, and it also
>>>>>           
>> can
>>     
>>>> be
>>>>
>>>>         
>>>>>   Anyhow, what kind of policies and how those policies will be
>>>>>           
>> delivered
>>     
>>>>>   of its access networks.  Some configuration objects are global to
>>>>>           
>> the
>>     
>>>>>   stack and possibly extend the existing protocols to manage these
>>>>>           
>> cases.
>>     
>>>>>   It is also notable that the general host and site multihoming
>>>>>           
>> designs
>>     
>>>>>   Thus a IPv4/IPv6 host would need to be provided with more
>>>>>           
>> application
>>

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 11:01:24 +0100

> Envoyé : mardi 17 février 2009 10:49

I gave 802.21 and OMA-DM only as example. But, here the scope of MIF could be:
 
1. specify or reuse, if any, IETF mechanisms to meet above requirement 
or
2. specify how we could use 802.21 to transport routing/selection policies (not sure about relevance of this...)

Regards,
Pierrick

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 11:06:36 +0100

[email-masked] escribió:
>>> I have in mind architecture where the core network hosts a policy server;
>>>       
>> so independent from access networks.
>>     
>>> Protocols used by the server to provide policies to the node may be
>>>       
>> 802.21 in push mode or OMA-DM.
>>     
so coming back to my original question
do you have any other IETF methods in mind for this? which are those?

> 2. specify how we could use 802.21 to transport routing/selection policies (not sure about relevance of this...)

mmm, i am not sure it is in the scope of the ietf to define how 802.21 
transports information....

Regards, marcelo

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 11:37:21 +0100

> Envoyé : mardi 17 février 2009 11:07

Except DHCP, which remains a valid solution in some use-cases, COPS (RFC 2748) could be candidate for that purpose. But maybe it is not the best way to do in our context, maybe there are other means that I don't know. Maybe other MIF's contributors have other clues for protocols... I mean, it seems to me that this item is worth deeper analysis before concluding that DHCP is the only solution. However, if MIF WG is fine with DHCP only, I'm fine too.

> > or
> > 2. specify how we could use 802.21 to transport routing/selection
> policies (not sure about relevance of this...)
> >
> >
>

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 11:44:17 +0100

Hi,

Please see inline,

Regards,
Pierrick

> marcelo bagnulo braun
> Envoyé : mardi 17 février 2009 09:46
> À : Hui Deng
> Cc : mif

You're right. Actually, whatever is the mobility protocol, mobility support is out of MIF scope. So, here, I'd simply remove the last sentence. 

Then, to clarify, the last section of "Background and Motivation" could mention:  

It is also notable that the general host and site multihoming designs
 (SHIM6 and RRG) is different from the work (policy of the connection
 manager) to be done here. And the difference between Monami and work
here is that there is no agent in the network side to hide the interface's address. Finally, it should be noted that support of mobility management protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF.

Regards,
Pierrick

> > can be

---

From: Jacni Qin <[email-masked]>
Date: Wed, 18 Feb 2009 02:31:18 +0800

hi hongyan,

let me try to answer your questions according to my understanding...

2009/2/17 <[email-masked]>

>   1. shall we keep the service continuity When some of interfaces is down ?

this case should be considered, i think. concurrently, the policy and
information related to interface selection should be updated.

>
>
>   2. shall this MIF consider the effect on application layer ? since I only
> find the influence on routing, DNS and IP layer...

the host user should be aware of the multiple interfaces, and may be capable
of configuring a tool like connection manager if there is one.

while, hui, mif would be transparent to the applications?

thanks,

Jacni

---

From: Jacni Qin <[email-masked]>
Date: Wed, 18 Feb 2009 03:00:25 +0800

hi hui & marcelo,

thanks for your update. some comments...

>>   (Best Current Practice/Proposed Standard)
it is much more clear.

>>   related specific routing information for interface selection based   on
>> DHCP. (Proposed Standard)
>>
>>

in your text, "more application related specific routing information for
interface selection", may i ask what it would be?

> wouldn't the split DNS work above be related to this?

i don't think so. :-) the information metioned here that will be merged may
be node-scope and for the same use, while within split DNS section the
optimization is for DNS behaviours in the context of that, for instance,
there are global DNS queries and DNS queries in some vpn, let them go in
right way.

thanks,

Jacni

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 17 Feb 2009 19:05:03 +0000

Hi Hui et.al.,

This looks like an interesting BOF so thanks for taking the initiative.

I have two main comments with respect to the charter.

I think it is unusual for a charter of this type (i.e., new work
rather than explicit update of a specific protocol) to identify the
exact protocol on which the solution is going to be based (you are
talking about using DHCP below). I would think that protocol selection
is something that the WG (if formed) is going to have to talk about.

Having said that, I think the charter and the presentations during the
BOF, should be very specific on exactly what approach the work should
take.
At the moment the charter and the people posting here seem to be torn between:
- a protocol-free host requirements type work (this includes the split
DNS work), and
- protocol-based policy work (e.g., DHCP/COPS or whatever based),
the two things requiring rather different way of thinking.

I think this BOF will improve its chances of success if it is clear on
which of the two approaches it might want to take.

Best Regards
George

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Feb 2009 10:49:58 -0500

>    (Best Current Practice/Proposed Standard)

Could you explain this one?  A host either uses the information
provided or it doesn't.  How does that change based on whether it came
from split DNS or otherwise?

Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM
+0100:
>>>   However, by default, it may not have enough information to
>>>   choose the best interfaces for different applications/flows in
>>>   the host.  Thus a IPv4/IPv6 host would need to be provided with
>>>   more application related specific routing information for
>>>   interface selection based on DHCP. (Proposed Standard)       

>> application related specific routing information for interface
>> selection. 

> mmm, i am not sure it is in the scope of the ietf to define how
> 802.21  transports information....

True, but it is in scope to define how the IETF _uses_ that
information.  I prefer allowing information from multiple layers, even
transport.  This overlaps with other groups.  We can sort out which
group will do what at the meeting.

Cheers ... Scott

---

From: Kevin Chin <[email-masked]>
Date: Tue, 17 Feb 2009 17:44:21 -0800

"I have in mind architecture where the core network hosts a policy server;

so independent from access networks"

Is the assumption there is a single "core network" that dictates policy?
I am not sure we need such a solution if there is clear, defined, and
centralized policy.

Or is the policy server purely "informational"?
The end user should have control (or at least influence) on path taken.
There are cases, e.g. pre-provisioning, where defaults may have been
established.

Q: Assumption of "single policy"  provider?
Q: Is information provided by policy provider purely informational
(recommendations)?
Q: Is DHCP only policy mechanism (even in IPv6 deployments)?
Let's clarify scope to IETF domain.

thanks,
Kevin

---

From: Yungui Wang <[email-masked]>
Date: Wed, 18 Feb 2009 12:21:08 +0800

Hello

In my understanding, the hiberarchy structure in the UE looks like
App (flow1, flow2...)   -------\
    IP, MIP                                 [connection manager]
         MIF (IF1, IF2...)  -------/

As mentioned before, here is a connection manager may be
responsible for the communication between MIF and
application/flow specific routing.
I wonder if the connection manager is just based on IP,
not MIP, or IP layer passed by? Thanks.

B.R.  / Yungui

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 17, 2009 6:44 PM
Subject: Re: [mif] Charter Updated Ver. 2

Hi,

Please see inline,

Regards,
Pierrick

> > Please help to comment on it,

You're right. Actually, whatever is the mobility protocol, mobility support
is out of MIF scope. So, here, I'd simply remove the last sentence.

Then, to clarify, the last section of "Background and Motivation" could
mention:

It is also notable that the general host and site multihoming designs
 (SHIM6 and RRG) is different from the work (policy of the connection
 manager) to be done here. And the difference between Monami and work
here is that there is no agent in the network side to hide the interface's
address. Finally, it should be noted that support of mobility management
protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF.

Regards,
Pierrick

---

From: Hui Deng <[email-masked]>
Date: Wed, 18 Feb 2009 17:56:00 +0800

Hi, Hongyan

>   1. shall we keep the service continuity When some of interfaces is down ?

It's hard for MIF to think about service continuity, it is more related IP
mobility or 3GPP core network.

> find the influence on routing, DNS and IP layer...

Current MIF charter will not touch the interface between the connection
manager and the applications.

thanks,

-Hui

> Address: System Architecture Department, Central Institute, ZTE Corporation
>   *Hui Deng <[email-masked]>*
> mif <[email-masked]>  抄送

---

From: Lars Eggert <[email-masked]>
Date: Wed, 18 Feb 2009 14:52:51 +0200

Hi,

so I'm reasonably OK with the current charter text. But some of the  
current discussion makes me wonder if I have misunderstood the scope  
for MIF. As an example:

On 2009-2-17, at 9:35, [email-masked] wrote:
>  2. shall this MIF consider the effect on application layer ? since  
> I only find the influence on routing, DNS and IP layer...

This sounds like there is interest in making MIF the "Seamless  
Handover WG", which in my understanding is fully out of scope.

I though the idea was that MIF would be limited to making  
recommendations on how multi-homed end systems made sense of and used  
the maybe conflicting network-layer configuration information they  
obtain via different interfaces.

Lars

---

From: Jacni Qin <[email-masked]>
Date: Wed, 18 Feb 2009 21:16:17 +0800

i'm confused again :(

2009/2/18 Hui Deng <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:28:33 +0800

Hello, Yungui,

2009/2/17 Yungui Wang <[email-masked]>

> some else mechanisms needed. Thanks.

We don't have any other proposal at the moment, it could recharter in the
future.

thanks

-Hui

>
>
> B.R.  / Yungui
>
> ----- Original Message ----- From: "Hui Deng" <[email-masked]>
> To: "mif" <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:31:11 +0800

Hi, Marcelo,
Thanks always for your comments, reply inline below:
2009/2/17 marcelo bagnulo braun <[email-masked]>

> I mean, a multihomed node can have MIPv6 support, but  this case is simply
> out of the scope of the work you are proposing
> Moreover, you only mntion MIPv6, i think you should also state that MIPv4
> is not supported neither

make sense, will reword on this.

> do you have any draft that describes how this would look like?

Yes, we have and are updating now, will post it and let u know asap. thanks

> If it is some other information, what information do you have in mind?

previous two items are more how to transmit those informaiton to the
terminal
but this item is about how to merge them together.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:33:50 +0800

Thanks Pierrick.
Reply inline.
2009/2/17 <[email-masked]>

> > choose
> choose
> Except DHCP, which remains a valid solution in some use-cases, COPS (RFC
> 2748) could be candidate for that purpose. But maybe it is not the best way
> to do in our context, maybe there are other means that I don't know. Maybe
> other MIF's contributors have other clues for protocols... I mean, it seems
> to me that this item is worth deeper analysis before concluding that DHCP is
> the only solution. However, if MIF WG is fine with DHCP only, I'm fine too.

==> As you said here, there are other way to do it,
Let's consider recharter after the working group formed firstly.

Thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:36:18 +0800

Hi, Pierrick,

Thanks for your suggestions, reply inline.

> protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF.

==> This looks much better than I wrote :)

thanks again

-Hui

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Feb 2009 11:37:03 -0500

Excerpts from Lars Eggert on Wed, Feb 18, 2009 02:52:51PM +0200:
> This sounds like there is interest in making MIF the "Seamless Handover 
> WG", which in my understanding is fully out of scope.
>

A multi-connected node needs all the information it can get that might
affect goodput in order to decide which interface(s) to use, even if
those interfaces are statically connected.

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:38:41 +0800

Inline please,

2009/2/18 Jacni Qin <[email-masked]>

> the host user should be aware of the multiple interfaces, and may be
> capable of configuring a tool like connection manager if there is one.
>
==> There are two implementation ways to do it,
we may need avoid to touch this,

thanks

-Hui

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Feb 2009 11:38:46 -0500

> mobility or 3GPP core network.

Service continuity is an issue of changing how interfaces are used in
response to changes in reachability and/or performance.  I thought MIF
was supposed to be about _initial_ choices, not about dynamic changes
to those choices during the course of a session.

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:45:47 +0800

Thanks, George,

Your comments are good remindness. reply inline please

2009/2/18 George Tsirtsis <[email-masked]>

> is something that the WG (if formed) is going to have to talk about.
At the moment, there are no suggestions to use other protocol, and
some people prefer would like to use it, could this be OK?

> - a protocol-free host requirements type work, and
> - protocol-based policy work,

I haven't see a protocol-free work proposed here, can you help to elaborate
a little more.
thanks

> which of the two approaches it might want to take.

yes, as you said, thanks for your remindness.

Regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:47:43 +0800

Thanks Jacni,
reply inline

> interface selection", may i ask what it would be?
Per-application routing policy.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:50:03 +0800

Thanks Scott,

Can Teemu help to reply DNS question?

thanks

-Hui

2009/2/17 Scott Brim <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:50:54 +0800

The bottom line, please,

> group will do what at the meeting.

It looks interesting suggestion.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:56:28 +0800

Hello, Kevin,

Your comments are appreciated, inline please.

2009/2/18 Kevin Chin <[email-masked]>

> I am not sure we need such a solution if there is clear, defined, and
We don't require a single policy server at the moment, that lead to our
merging work item proposal.

> Or is the policy server purely "informational"?
IETF normally not talking about network models and architectures.
We here focus on the protocols.

> There are cases, e.g. pre-provisioning, where defaults may have been
Agree you here, user can configure this control.
As teemu said before, there are some special use cases, user may not allow
to do it.

> Q: Assumption of "single policy"  provider?
We dont' assume it.

>  Q: Is information provided by policy provider purely informational
At the moment, it is a kind of recommendations.

> Let's clarify scope to IETF domain.
We plan to allow other mechanism based on re-charter if and after working
group could be formed.

Appreciate your comments.

-Hui

>
> thanks,
> Kevin
>
>
>   On Tue, Feb 17, 2009 at 2:06 AM, marcelo bagnulo braun <
> [email-masked]> wrote:
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 18 Feb 2009 18:56:58 +0200

Hi,

On 2009-2-18, at 18:37, Scott Brim wrote:
>> Handover

it wasn't clear to me that optimizing performance (vs. just preventing  
incorrect operation, such as sending stuff to a destination out the  
wrong interface) was in scope. If it is, I think the charter needs to  
be much clearer on what the goals are related to that.

Lars

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:57:22 +0800

Thanks Lars,

You are absolutely correct with this.

Regards,

-Hui

2009/2/18 Lars Eggert <[email-masked]>

> Hi,
>
> so I'm reasonably OK with the current charter text. But some of the current
> discussion makes me wonder if I have misunderstood the scope for MIF. As an
> example:
>
> I though the idea was that MIF would be limited to making recommendations
> on how multi-homed end systems made sense of and used the maybe conflicting
> network-layer configuration information they obtain via different
> interfaces.
>
> Lars

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 00:58:07 +0800

I will reply you this in another email thread.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 01:04:41 +0800

Thanks Scott,

Initial choice makes point.

-Hui

2009/2/19 Scott Brim <[email-masked]>

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 09:27:14 +0100

________________________________

De : Hui Deng [mailto:[email-masked]] 
Envoyé : mercredi 18 février 2009 17:34
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [mif] Charter Updated Ver. 2
 
Thanks Pierrick.
Reply inline.

That sounds good,
 
Regards,
Pierrick 
 
Thanks
 
-Hui