[Netext] next steps for netext

Hello 

Here are two comments.

1, Basically, I agree with Rajeev's view there may need a requirement
document/section for 'modified host' if it happens (or is needed). In my
mind, RFC5213 refered mobile node is a general IP node, which is JUST not
required to participate in any IP mobility related signaling for achieving
mobility. It means two things:
i) we should avoid to define special mobile signalling on PMIPv6 mobile
node;
ii) we do not exclude that PMIPv6 solution is using PMIPv6 mobile node's
general L2/L3 signalling or its extension(, although which may lead to some
modifications on host). In fact, RFC5213 has implicitly used such
signalling, for example, value of Handoff Indicator Option is coming from
attach type in 3GPP/WiMAX.

2, Further, following node's capability enhancement, there reflects some
limitations in basis RFC5213 spec for multihoming support, such as absence
of flow mobility, only per-interface-prefix model supported, etc.
Fortunately, some drafts/guys are focusing on that. In this instance, I
think, it is valuable to catch them into the scope of Netext charter.

Regards.  
Yungui

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> Sent: Tuesday, April 07, 2009 1:24 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
>  
> I tend to agree that host configurations cannot be ruled out. 
> Case in point: if IPv6 is disabled by default, does enabling 
> it count as host change here? It should not be. Similarly, if 
> folks use a particular technique (e.g., virtual i/f support) 
> provided by host OS, that should be acceptable. If the 
> mechanism is not supported, the feature will not be 
> available, and this can be stated in a 'Requirement' section 
> of the appropriate document.
>  
> -Rajeev
>  
> 
> ________________________________
> 
> From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
> Sent: Mon 4/6/2009 10:11 AM
> To: teemu.savolainen at nokia.com
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> 
> Hi Teemu,
> 
> 
> On Mon, 6 Apr 2009, teemu.savolainen at nokia.com wrote:
> 
> > Hi Sri,
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp
> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> >> Gundavelli
> >> Sent: 06 April, 2009 19:11
> >> "unmodified host" can leverage that feature. As we discussed
> >> earlier, we have a major terminology problem, on what is
> >> "modified" vs "un modified". If I use Windows SDK and
> >> implement a virtual interface, no one can claim the host is
> >> now modified. Its an application, or a configuration such as
> >> using bridge ctl utuility in Linux. Its not changing any of
> >
> > At least in my vocabulary that counts as modified host - 
> things are changed in a host to make it behave differently.
> 
> Perfectly fine, if that is the definition of "modified host". I'd
> ask, show me a reference implementation of a host, which tells
> me what is the basic software that is standard and beyond which
> is considered a modified host. Where is that sacred host stack
> definition.
> 
> When I install a OS on my PC, I will install 20 other applications and
> this action is not resulting in my host not inter-operating with any
> other host. That should be our interest and not on what applications I
> install.
> 
> Also, if this is indeed the definition, 5213 already requires 
> this change
> on the host and we have to live with it.
> 
> Regards
> Sri
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 