Subject: [netlmm] PMIPv6 Next Steps

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Apr 2007 14:21:54 -0700

All,
In the interest of meeting our goals in a timely manner, I propose that
the base protocol document be in accordance with our charter and other
things be written up separately. I have discussed this with our AD and
we are in agreement that this would allow us to make faster and better
progress. Some of this can proceed parallely and we can ensure timely
completion of those as well. This would also allow better work
distribution to allow parallel operation. 

Specifically, here are the next steps. 

Decided actions: 
----------------
* The protocol document will progress with the base PMIPv6 specification
(draft-ietf-netlmm-pmip6-00)

* IPv4 support to be specified in a companion document, which will
progress in parallel. We will add a separate goal to the charter to
ensure this gets done. Consensus for doing the IPv4 work has already
been established in the WG. 

* A discussion of the PMIP6-MIP6 interactions in Prague indicated
several points that need to be documented and some issues that need to
be flushed out. A separate document is needed to describe the details
clearly. The base document can proceed with an informative reference to
this document. We do need to make sure we are cognizant of the
interactions in the PMIP6 design. So, the hope is that we can flush out
the details more or less in parallel as well. 

To-be-decided based on WG consensus:
------------------------------------

* If there is WG consensus to standardize the anchoring approach, we
will work on a separate document that describes that. I will soon send
out an email asking for WG opinion on this. 

To-be-decided based on further investigation and interest:
----------------------------------------------------------

* In Prague, we decided that the base document will not support any
shared link behavior, including last-hop shared links for link-local
addresses, due to lingering questions on DNAv6 dependency and the
potential need for domain-wide uniqueness for link-local addresses. This
topic can continue to be flushed out by the WG and we will revisit it
when we have a better idea on how to add this support to the protocol. 

Thanks,
Vidya

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 6 Apr 2007 16:36:25 -0500

Hi Vidya,
Comments inline.

> * IPv4 support to be specified in a companion document, which 
> will progress in parallel. We will add a separate goal to the 
> charter to ensure this gets done. Consensus for doing the 
> IPv4 work has already been established in the WG.

[Ahmad]
I believe that a base PMIPv6 protocol which does not address IPv4
support has no significant use. There has been a consensus for PMIPv6 to
address IPv4 support. Taking IPv4 support out of the base PMIPv6
protocol will only delay the process of getting a PMIPv6 standard
protocol that can be used and deployed. The current PMIPv6 base protocol
addresses this issue and I do not see why we need to skin that off the
base protocol document.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Apr 2007 15:25:00 -0700

> been established in the WG. 

Strongly disagree here. We are mostly re-using DS-MIPv6 concepts
here. Not much new stuff here. IMO, IPv4 support must stay in
the base specification.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Apr 2007 15:55:17 -0700

Hi Ahmad, all,
Jari and I are very much aware of the need to publish the IPv4 support
in close alignment with the base specification timeline. We have
definitely taken this aspect into serious consideration and in fact, one
of the main motivations for the work separation is to ensure that all of
this can be done in parallel. We fully realize that IPv4 support needs
to be there right away for the protocol to be useful and don't intend
delaying the publication. 

Regards,
Vidya

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Friday, April 06, 2007 2:36 PM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] PMIPv6 Next Steps
> 
> Hi Vidya,
> Comments inline.
> 
> > 
> > ensure this gets done. Consensus for doing the
> I believe that a base PMIPv6 protocol which does not address 
> IPv4 support has no significant use. There has been a 
> consensus for PMIPv6 to address IPv4 support. Taking IPv4 
> support out of the base PMIPv6 protocol will only delay the 
> process of getting a PMIPv6 standard protocol that can be 
> used and deployed. The current PMIPv6 base protocol addresses 
> this issue and I do not see why we need to skin that off the 
> base protocol document.
> 
> 
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 6 Apr 2007 16:35:46 -0700

Vidya:

> Jari and I are very much aware of the need to publish the IPv4

If this is Jari's (AD's) decision, I cannot argue. But, I just
want to make sure, Jari is aware of the scope of the IPv4 efforts
and he hears both the versions.

1.) We are not re-inventing any thing specific to IPv4 support.  Like
    we said before, we are creating a normative reference to DSMIP6
    spec. We are just stating, the scheme that is defined in DSMIP6,
    the two options that needs to be carried in PMIP6 BU/BA, can be
    carried in PMIP6. 

2.) No operator is going to deploy PMIP6 with out IPv4 support. It is
    a base problem that falls in the scope of the base document. I
    do realize your commitment to move both the documents at the same
    time, but my point is, when there is no *good* reason to split a 
    document that got overwhelming consensus and when there are no
    technical issues and when the scope of the efforts are so minimum,
    there is no reason to go for that split.

3.) From the discussions in the ML, you can do a quick poll, majority
    of the people wanted IPv4 support in the base. IMO, there is 
    consensus.

4.) Also, from the document management or efforts point of view, we
    have completed the IPv4 work and by splitting the work, we are 
    creating more work. Additional reviews, one more RFC number ..
    why ?

5.) Lastly, when the group is least polarized now, a draft that has
    IPv4 support, is chosen, why bring the arguments back in to the
    mailing list ?

Sri

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 3:25 PM
To: Narayanan, Vidya
Cc: [email-masked]
Subject: Re: [netlmm] PMIPv6 Next Steps

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Apr 2007 17:12:35 -0700

Narayanan, Vidya wrote:
> this can be done in parallel. 

Does not follow. If there is lot more work that needs to
be done, then yes, having a separate specification might
make sense. But that is not the case here. Having to take
something out, write a separate spec on it, have a WG
last call, IETF last call and the RFC editor editing the
separate document only *adds* to the delay. How does it
speed it up?

Vijay

We fully realize that IPv4 support needs

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 6 Apr 2007 22:51:10 -0400

Hi, Vidya, 

Looks like a good plan to me. It will definitely expedite PMIPv6
standardization. 

Regards,
Ajoy 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 4:22 PM
To: [email-masked]
Subject: [netlmm] PMIPv6 Next Steps

All,

Decided actions: 
----------------

Thanks,
Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 7 Apr 2007 01:09:21 -0700

Ajoy:

*Please* state your reason why you think this will expedite
the process. I do realize this is not your favorite document,
rightfully from your point of view. No issues !!. But, lets be
objective here. When there is text that is already present in
the document and when the document is written with the possible
assumption of IPv4 transport and addressing, how will the
document split going to speed up the process and specifically
when the scope of the work is so minimal ? 

IPv4 Addressing and Transport is a basic property. It is not
a feature that can go into an add-on document. Even under
the consideration of modularity, it belongs to the base
module. Keeping it in one document, preserves the readability
and keeps the base protocol detail and operation in one
place. Splitting the document, leads to duplication of text,
requires elaborate context specific explanations in protocol
operation one for IPv4 and one for IPv6. This is not efficient
from the document management point of view or from the point
of view of the effort management. 

Lets do the right thing and spend this time and energy on the
reviewing the current work and fixing the issues there and not
on this argument or on deleting the completed work. Please
think again.

Regards
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 7:51 PM
To: Narayanan, Vidya; [email-masked]
Subject: RE: [netlmm] PMIPv6 Next Steps

Hi, Vidya, 

Regards,
Ajoy 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 4:22 PM
To: [email-masked]
Subject: [netlmm] PMIPv6 Next Steps

All,

Decided actions: 
----------------

Thanks,
Vidya

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Sat, 7 Apr 2007 11:26:24 -0400

Hi, Sri, 
 
I very much like your document. IMHO, it is in our interest to get the 
work done as soon as possible rather than arguing silly thing. 
As long as there is commitment to complete both IPv4 support 
and IPv6 support in same timeline, I do not see any reason to argue on
this. 
In my opinion modular design is always better than 
monolithic design. Please find inline. 
 
Regards,
Ajoy 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Saturday, April 07, 2007 3:09 AM
To: Singh Ajoy-ASINGH1; 'Narayanan, Vidya'; [email-masked]
Subject: RE: [netlmm] PMIPv6 Next Steps

Ajoy:

*Please* state your reason why you think this will expedite the process.
I do realize this is not your favorite document, rightfully from your
point of view. No issues !!. But, lets be objective here. When there is
text that is already present in the document and when the document is
written with the possible assumption of IPv4 transport and addressing,
how will the document split going to speed up the process and
specifically when the scope of the work is so minimal ? 

IPv4 Addressing and Transport is a basic property. It is not a feature
that can go into an add-on document. Even under the consideration of
modularity, it belongs to the base module. 

Ajoy-> Why does it belong to base module? IPv4 support is a transition
scenario and only needed under following scenario:
(1) When there is no support available for PMIPv4 or CMIPv4. If such
support is available in the access network, 
why will anyone deploy IPv4 support along with PMIPv6 support? I do
agree, however, that it is important to 
complete IPv4 support in timely manner along with PMIPv6 so that someone
wanting to implement IPV4 support would be able to 
deploy it along with PMIPv6 when PMIPv4 or CMIPv4 support is not
available.   

Keeping it in one document, preserves the readability and keeps the base
protocol detail and operation in one place. 

Splitting the document, leads to duplication of text, requires elaborate
context specific explanations in protocol operation one for IPv4 and one
for IPv6. This is not efficient from the document management point of
view or from the point of view of the effort management. 

Lets do the right thing and spend this time and energy on the reviewing
the current work and fixing the issues there and not on this argument or
on deleting the completed work. Please think again.

Ajoy-> Let us work on publishing base working document so that we can
start reviewing the doc and get the work done in timely manner.  
Let me know if you need any help to expediate the editing work. 

Regards
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Friday, April 06, 2007 7:51 PM
To: Narayanan, Vidya; [email-masked]
Subject: RE: [netlmm] PMIPv6 Next Steps

Hi, Vidya, 

Regards,
Ajoy 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]]
Sent: Friday, April 06, 2007 4:22 PM
To: [email-masked]
Subject: [netlmm] PMIPv6 Next Steps

All,

Decided actions: 
----------------

Thanks,
Vidya

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 7 Apr 2007 10:35:06 -0500

Hi Vidya,

I failed to understand how this will speed the process! Supporting IPv4
has already been discussed and captured in the base protocol and all
those who voted for this document has that in mind. IMO, removing IPv4
support which is essential for the usability of base PMIPv6 protocol,
could contradict with the WG consensus.

There are already some people doubting the schedule of PMIPv6 base
protocol (before removing IPv4 support!!) as an excuse to justify the
use of other protocols. IMO, this move, of separating IPv4 support, only
enforces that doubt.

Regards,
Ahmad

> Sent: Friday, April 06, 2007 5:55 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Jari and I are very much aware of the need to publish the 
> IPv4 support in close alignment with the base specification 
> timeline. We have definitely taken this aspect into serious 
> consideration and in fact, one of the main motivations for 
> the work separation is to ensure that all of this can be done 
> in parallel. We fully realize that IPv4 support needs to be 
> there right away for the protocol to be useful and don't 
> intend delaying the publication. 
> 
> Regards,
> Vidya
> 
> > IPv4 support has no significant use. There has been a consensus for 
> > PMIPv6 to address IPv4 support. Taking IPv4 support out of the base 
> > PMIPv6 protocol will only delay the process of getting a PMIPv6 
> > standard protocol that can be used and deployed. The current PMIPv6 
> > base protocol addresses this issue and I do not see why we need to 
> > skin that off the base protocol document.
> > 
> > 
> > >

---

From: Katsutoshi Nishida <[email-masked]>
Date: Mon, 09 Apr 2007 14:52:01 +0900

Hi Vidya

I have comment on the treatment of the IPv4 issue.

> been established in the WG. 

As already commented by others, I also think splitting IPv4 issue out of
base draft is only required if we identifies any issues that we need to
take more time to discuss for coming up with a technically good solution.

As far as I understood, no serious technical issue has been identified
by now. (But, please correct me if I am wrong.)

Thus, I am in favor of keeping the IPv4 specification in the scope of
base spec.

Best Regards,
Katsutoshi

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 9 Apr 2007 11:17:25 -0400

> been established in the WG.

I do not think this is necessary. If it is a matter of revising the
charter to include IPv4 support, we need to do that rather than taking
out IPv4 support from the base spec. We need to get the base spec with
IPv4 support done ASAP so that the SDOs can make use of it soon.

> the details more or less in parallel as well.

I was at the Prague meeting too. I did not find any compelling argument
to do this separate "clarifying" work. The main thing that we heard was
"if the network node gets compromised..."!! Well, there are so many
things can happen if a network node such as a router, AAA Client, NAS,
etc. get compromised. We are not trying to boil the ocean, I guess.

-Kuntal

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Apr 2007 00:15:57 +0300

On the topic of IPv4:

I hear the concerns people have raised about this. I wanted to share
what I think. But let me start by listing some things that we have
an agreement on:

o  IPv4 support is essential for the success of NETLMM.
o  IPv4 support needs to be published timely, at the same time as
    the rest of the protocol.
o  The WG should decide whether IPv4 feature (or any other
    feature for that matter) is a mandatory-to-implement part
    of the specification.
o  We should not develop a lot of new technology to support
    IPv4, pointing to DSMIP is the right approach.
o  The current text we have is a good start -- needs some adjustment
    but is not fundamentally broken.
o  The current starting point text from draft-sgundave has
    WG backing to go into WG draft(s) as soon as it can be
    submitted.

No one is suggesting we compromise on any of these, so lets take
those worries off the table from the start.

Then to my opinion.

What Vidya is suggesting is not a change to to the above, but only
a document organization matter. Namely whether we have a single
document or the base plus another one to explain the IPv4 aspects.
Generally speaking its the chairs' job in a WG to worry about the
project management. This includes things like breaking tasks into
smaller ones, picking people who are responsible for the tasks,
thinking how to serialize/parallelize  tasks, managing risks of what
happens when there's a problem in a task, etc. I would suggest the
WG concentrates on the substance of what should go into the
documents, reviewing and improving the specifications, and
lets the chairs do the project management part. We have already
spent the last months in debating which one of the very similar
drafts we pick for going forward -- lets not spend the next months
by arguing what the documentation structure should be. No matter
what the structure is, revving the current IPv4 text to whatever
shape is going to take less time than we have already spent
on this thread.

Clearly you can handle this feature either within the base or in
another document. The world is not going to end either way.
But I do see some advantages in separate modular drafts, and
I support the plan. The advantages include some parallelization
of editor efforts (based on my review at least some editing will
be needed), smaller documents for reviewers, possibly some
advantages with normative reference delays if something like that
would happen, etc.

So, given the list from the top of my e-mail and a plan to take
these two parts to the WG draft, WGLC, IESG etc. at the same
time -- do people still see problems?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 Apr 2007 15:15:34 -0700

Hi Jari,

> those worries off the table from the start.

One of the best ways to make sure we don't compromise on any
of these is to leave the IPv4 support in the base document.

> time -- do people still see problems?

This may work. But why bother? The question is why split the
IPv4 support it into a separate document? In most cases,
progressing two drafts is going to take more time than one
draft. We can clean up the IPv4-related text in base protocol
draft in a couple of hours. So this is not an issue.

Personally, I am not convinced that having IPv4 support in a
separate spec will speed up everything.

One issue I can see is delay in DS-MIPv6 would affect PMIPv6.
But I don't see DS-MIPv6 getting delayed so much that it
actually affects PMIPv6.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 10 Apr 2007 17:39:40 -0500

Hi Jari,
Please see my comments inline.
Thanks in advance for your patience and understanding.

Regards,
Ahmad

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, April 10, 2007 4:16 PM
> To: [email-masked]
> I hear the concerns people have raised about this. I wanted 
> to share what I think. But let me start by listing some 
> things that we have an agreement on:
> 
> No one is suggesting we compromise on any of these, so lets 
> take those worries off the table from the start.
> 
> Then to my opinion.
> 
> What Vidya is suggesting is not a change to to the above, but 
> only a document organization matter. Namely whether we have a 
> single document or the base plus another one to explain the 
> IPv4 aspects.
> Generally speaking its the chairs' job in a WG to worry about 
> the project management. This includes things like breaking 
> tasks into smaller ones, picking people who are responsible 
> for the tasks, thinking how to serialize/parallelize  tasks, 
> managing risks of what happens when there's a problem in a 
> task, etc. 

[Ahmad]
Is there any RFC or IETF document which capture this. I appreciate a
pointer for my own education.

> I would suggest the WG concentrates on the 
> substance of what should go into the documents, reviewing and 
> improving the specifications, and lets the chairs do the 
> project management part. 

[Ahmad]
I do not believe that splitting the WG consensus into pieces falls under
project management. My understanding of project management is how the WG
chair(s) will make sure that the WG consensus is advanced into a
standard document according to the agreed upon schedule and plan.

> We have already spent the last 
> months in debating which one of the very similar drafts we 
> pick for going forward -- lets not spend the next months by 
> arguing what the documentation structure should be. No matter 
> what the structure is, revving the current IPv4 text to 
> whatever shape is going to take less time than we have 
> already spent on this thread. 
> Clearly you can handle this feature either within the base or 
> in another document. The world is not going to end either way.

[Ahmad]
Well, why then the AD and chair believe that going against the WG
consensus is a good thing for the group. Should not these decisions be
based on the WG consensus?

> I support the plan. The advantages include some 
> parallelization of editor efforts (based on my review at 
> least some editing will be needed), smaller documents for 
> reviewers, possibly some advantages with normative reference 
> delays if something like that would happen, etc.

[Ahmad]
The question is, where to draw the line? Someone else can go and suggest
that what PMIPv6 base protocol should do is just defining a 'P' bit in
the BU/BA and the base protocol is ready to go. IMO, that is why
decisions has to be based on consensus of the WG rather than personal
preference with my respect to the AD and the chair(s) preference.

> 
> So, given the list from the top of my e-mail and a plan to 
> take these two parts to the WG draft, WGLC, IESG etc. at the 
> same time -- do people still see problems?

[Ahmad]
Yes, I do and please see my comments above. Thanks again.

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 11 Apr 2007 13:34:06 +0900

Hi Jari,

I value your analysis in a separate thread about the document 
organization regarding IPv4 support and I agree that the specifications 
about the IPv4 support should be consolidated as much as possible for 
readability; however, if the IPv4 support part is separated from the 
base document, it may become more cumbersome to keep consistency between 
the two documents; changes in the base document may affect the other and 
people would have to look at them back and forth. It is sometimes 
painful especially if the authors are different:-). I gather that many 
forks think the use of PMIPv6 together with IPv4 support from day 1. 
Until we find the IPv4 support becomes so controversial that it has a 
risk of delaying the whole process, I think it would be better to keep 
it in the base document. We need to discuss more and clean up the IPv4 
part based on your comments anyway.

Regards,
--
Hidetoshi

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 11 Apr 2007 09:42:43 -0500

Hi Jari,

Thank you very much for your feedback. I disagree with you that
splitting the document into two documents is a management issue but it
is in my opinion is a technical issue. The management aspect is to put a
deadline to when this work should be concluded and proceed to be
standard. I believe we should leave the technical part to the consensus
of the members of this group, and the management part to the co-chairs. 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 4:16 PM
To: [email-masked]
Subject: Re: [netlmm] PMIPv6 Next Steps

On the topic of IPv4:

I hear the concerns people have raised about this. I wanted to share
what I think. But let me start by listing some things that we have an
agreement on:

No one is suggesting we compromise on any of these, so lets take those
worries off the table from the start.

Then to my opinion.

What Vidya is suggesting is not a change to to the above, but only a
document organization matter. Namely whether we have a single document
or the base plus another one to explain the IPv4 aspects. Generally
speaking its the chairs' job in a WG to worry about the project
management. This includes things like breaking tasks into smaller ones,
picking people who are responsible for the tasks, thinking how to
serialize/parallelize  tasks, managing risks of what happens when
there's a problem in a task, etc. I would suggest the WG concentrates on
the substance of what should go into the documents, reviewing and
improving the specifications, and lets the chairs do the project
management part. We have already spent the last months in debating which
one of the very similar drafts we pick for going forward -- lets not
spend the next months by arguing what the documentation structure should
be. No matter what the structure is, revving the current IPv4 text to
whatever shape is going to take less time than we have already spent on
this thread.

Clearly you can handle this feature either within the base or in another
document. The world is not going to end either way. But I do see some
advantages in separate modular drafts, and I support the plan. The
advantages include some parallelization of editor efforts (based on my
review at least some editing will be needed), smaller documents for
reviewers, possibly some advantages with normative reference delays if
something like that would happen, etc.

So, given the list from the top of my e-mail and a plan to take these
two parts to the WG draft, WGLC, IESG etc. at the same time -- do people
still see problems?

Jari

---

From: Anand Bedekar <[email-masked]>
Date: Wed, 11 Apr 2007 13:37:55 -0500

I agree with Jari's rationale for a modular approach.

Beyond the reasons he has mentioned, here's another one. I think it is 
quite likely that in several deployments, v6 itself will be deployed as 
an overlay on top of an existing v4 network, with the underlying v4 
network already providing its own mobility mechanism for v4 mobiles. I 
believe this will be the case for several WiMAX operators. In such 
situations, it is beneficial to be able to select the NetLMM/PMIPv6 
mechanism for just v6 mobiles, without the need to support v4 on top of 
PMIPv6. Of course, the flip side is also true - clearly the ability to 
choose to support v4 on top of PMIPv6 is also beneficial, especially in 
those deployments which have gone "native" v6 with no v4 underlay. I 
think the modular approach will ease the simultaneous application of 
NetLMM to both situations.

-Anand

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Apr 2007 11:46:04 -0700

Anand,

> NetLMM to both situations.

However we structure the documents, we have to still decide
whether the IPv4 support should be mandatory on the LMA and
the MAG. Having the IPv4 support in a separate document does
not mean that it becomes optional for implementation. Having
it in the base spec does not mean it becomes mandatory to
implement.

Whoever is deploying PMIPv6 would need to decide what IPv4
support, if at all any, is needed for that particular
deployment.

Vijay

---

From: Anand Bedekar <[email-masked]>
Date: Wed, 11 Apr 2007 18:57:14 -0500

Hi Vijay,

Please see below.

Thanks,
Anand

On 4/11/2007 1:46 PM, Vijay Devarapalli wrote:
>> quite likely that in several deployments, v6 itself will be deployed 
>> as an overlay on top of an existing v4 network, with the underlying v4 
>> mechanism for just v6 mobiles, without the need to support v4 on top 
>> of PMIPv6. Of course, the flip side is also true - clearly the ability 
>> to choose to support v4 on top of PMIPv6 is also beneficial, 
>> especially in those deployments which have gone "native" v6 with no v4 
>> underlay. I think the modular approach will ease the simultaneous 
>> application of NetLMM to both situations.
> 

[Anand] I agree with this.

> support, if at all any, is needed for that particular

[Anand] Agree with this too - the ability to choose is going to be 
important. My point was that in the case of this feature, the choice may 
depend on the underlying characteristics of the network deployment - so 
I think it is likely to be a "must have" for some deployments and "no 
use for it" in others.  Hence I feel that having a modular specification 
would be better in this case.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Apr 2007 16:31:50 +0300

Ahmad,

> pointer for my own education.

RFC 2418 and our education materials at
http://edu.ietf.org/download/66/WGLeadership-IETF-68-final.pdf
are good starting points.

Its clear that the WG is responsible for technical content. Its clear
that the chairs are responsible for management issues, such
as assigning tasks, session planning, making forward progress
with technical discussions, workload distribution, verifying
WG opinion is reflected in the editor outputs, etc.

> based on the WG consensus?

I think it would be a bad situation if the group disagreed with the
plan. This is why you are having this thread; to talk about the plan
and its rationale and discuss if people have issues.

(But we're about to have a delay, because WG document submission
and contents depends on this issue.)

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Apr 2007 08:42:33 -0500

Thanks Jari. Appreciate it.

With the WG milestones already defined and published, I hope that we all
will focus on making this plan happen and meet these milestones.

Regards,
Ahmad

> Sent: Thursday, April 12, 2007 8:32 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Its clear that the WG is responsible for technical content. 
> Its clear that the chairs are responsible for management 
> issues, such as assigning tasks, session planning, making 
> forward progress with technical discussions, workload 
> distribution, verifying WG opinion is reflected in the editor 
> outputs, etc.
> 
> I think it would be a bad situation if the group disagreed 
> with the plan. This is why you are having this thread; to 
> talk about the plan and its rationale and discuss if people 
> have issues.
> 
> (But we're about to have a delay, because WG document 
> submission and contents depends on this issue.)
> 
> Jari
> 
>