Subject: [nemo] Charter proposal..

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 2 Nov 2006 21:47:15 -0800

Hi folks,

After the latest discussion on the list, I weighed some of our  
options, and then we had a pow-wow between the NEMO chairs, and the  
Area Director. We've come up with a more tightly-constrained charter,  
with goals that I believe are achievable.

http://www.mobilenetworks.org/nemo/charter2_5.txt

This charter focuses on route optimization for two scenarios:  
automotive and aeronautical. Initially, we will gather the  
requirements into documents, and then work on solutions based on that.

The infrastructure-based / distributed home agent type of solution is  
not spelled out in the charter, because I don't want to bias the type  
of solution we can use. However, based on the documents I've seen  
from Will Ivancic, Terry Davis, and their compatriots, that may be a  
good place to start. We need to refine those documents and their  
input into a good requirements doc. I will work with those groups to  
come up with that document.

The automotive industry working on NEMO solutions is primarily  
located in Japan and Europe. They seem to be in the early stages of  
figuring out how to interact with the IETF, so it may take some extra  
communication with them to be able to import meaningful requirements  
data from them. Thierry will work with those groups on that document.

As was mentioned on the list, it's not my goal to have to change the  
charter document very frequently, since it's a long process. However,  
if we do discover some important deployment scenarios that aren't  
covered under these concrete examples, we can definitely investigate  
updating the charter.

Thanks for your patience and see you all soon in San Diego.

TJ

---

From: "James Kempf" <[email-masked]>
Date: Sat, 4 Nov 2006 02:55:14 -0800

TJ,

Looks pretty good. I'd suggest changing "flying community" to "aviation 
community".

A couple of the goals are listed as May 2006 or November 2006. Since there 
dates are already passed or will soon, I'd suggest updating the dates 
appropriately.

            jak

----- Original Message ----- 
From: "T.J. Kniveton" <[email-masked]>
To: "ml-nemo WG" <[email-masked]>
Sent: Thursday, November 02, 2006 9:47 PM
Subject: [nemo] Charter proposal..

> Hi folks,
>
> After the latest discussion on the list, I weighed some of our  options, 
> and then we had a pow-wow between the NEMO chairs, and the  Area Director. 
> We've come up with a more tightly-constrained charter,  with goals that I 
> believe are achievable.
>
> This charter focuses on route optimization for two scenarios:  automotive 
> and aeronautical. Initially, we will gather the  requirements into 
> documents, and then work on solutions based on that.
>
> The infrastructure-based / distributed home agent type of solution is  not 
> spelled out in the charter, because I don't want to bias the type  of 
> solution we can use. However, based on the documents I've seen  from Will 
> Ivancic, Terry Davis, and their compatriots, that may be a  good place to 
> start. We need to refine those documents and their  input into a good 
> requirements doc. I will work with those groups to  come up with that 
> document.
>
> The automotive industry working on NEMO solutions is primarily  located in 
> Japan and Europe. They seem to be in the early stages of  figuring out how 
> to interact with the IETF, so it may take some extra  communication with 
> them to be able to import meaningful requirements  data from them. Thierry 
> will work with those groups on that document.
>
> charter document very frequently, since it's a long process. However,  if 
> we do discover some important deployment scenarios that aren't  covered 
> under these concrete examples, we can definitely investigate  updating the 
> charter.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 5 Nov 2006 07:54:17 +0100

Hi,

i agree with the RO part of the charter.

just a minor comment...

in previous version of the charter was an item about ingress filtering 
for multihomed nemos. I made a comment about the issue being about 
fault tolerance in the link between the MR and the HA rather than only 
ingress filtering. The goal of this comment was to rephrase the item 
rather than remove it. I think it may be worthy to work on this if 
other folks are interested...

Regards, marcelo

El 03/11/2006, a las 6:47, T.J. Kniveton escribió:

> of solution we can use. However, based on the documents I've seen from 
> Will Ivancic, Terry Davis, and their compatriots, that may be a good 
> place to start. We need to refine those documents and their input into 
> a good requirements doc. I will work with those groups to come up with 
> that document.
>
> The automotive industry working on NEMO solutions is primarily located 
> in Japan and Europe. They seem to be in the early stages of figuring 
> out how to interact with the IETF, so it may take some extra

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 5 Nov 2006 00:06:22 -0800

Hi Marcelo,

I removed it not only because of your comment, but also because it's  
not clear to me (a) what work would be done to address n,n,n ingress  
filtering, and (b) who is committed to do it. In light of this, I  
removed it until those things can be clarified.

TJ

On Nov 4, 2006, at 10:54 PM, marcelo bagnulo braun wrote:

> in previous version of the charter was an item about ingress  
> filtering for multihomed nemos. I made a comment about the issue  
> being about fault tolerance in the link between the MR and the HA  
> rather than only ingress filtering. The goal of this comment was to  
> rephrase the item rather than remove it. I think it may be worthy  
> to work on this if other folks are interested...
>
> Regards, marcelo
>
>> options, and then we had a pow-wow between the NEMO chairs, and  
>> the Area Director. We've come up with a more tightly-constrained  
>> charter, with goals that I believe are achievable.
>>
>> The infrastructure-based / distributed home agent type of solution  
>> is not spelled out in the charter, because I don't want to bias  
>> the type of solution we can use. However, based on the documents  
>> I've seen from Will Ivancic, Terry Davis, and their compatriots,  
>> that may be a good place to start. We need to refine those  
>> documents and their input into a good requirements doc. I will  
>> work with those groups to come up with that document.
>>
>> located in Japan and Europe. They seem to be in the early stages  
>> of figuring out how to interact with the IETF, so it may take some  
>> extra communication with them to be able to import meaningful  
>> requirements data from them. Thierry will work with those groups  
>> on that document.
>>
>> As was mentioned on the list, it's not my goal to have to change  
>> the charter document very frequently, since it's a long process.  
>> However, if we do discover some important deployment scenarios  
>> that aren't covered under these concrete examples, we can  
>> definitely investigate updating the charter.
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Nov 2006 08:54:56 -0800

T.J. Kniveton wrote:
> Hi Marcelo,
> 
> I removed it not only because of your comment, but also because it's not 
> clear to me (a) what work would be done to address n,n,n ingress 
> filtering

it could be a BCP like document where we describe
how to do the ingress filtering in (n,n,n) case.

> and (b) who is committed to do it. 

oh.. finding people to do the work on the NEMO WG
has never been issue. :) on the contrary people
got tired of waiting for things to move.

> In light of this, I 

I think a short document to address this would be
good.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 5 Nov 2006 23:18:21 +0100

Hi T.J.

El 05/11/2006, a las 9:06, T.J. Kniveton escribió:

> filtering,

my understanding was that the goal was to have a more detailed  
description of what is included in the appendix of the multihoming 
document and see if we need some additional work to make the appraoch 
described work...

>  and (b) who is committed to do it.

I personally i am willing to work on this and i think that some (if not 
all) other authors from the multihoming docuemtn are also interested in 
working on this...

but again, this only makes sense if some other folks of the wg think 
this is relevant/interesting

regards, marcelo

>  In light of this, I removed it until those things can be clarified.
>
> TJ
>
>> rephrase the item rather than remove it. I think it may be worthy to 
>> work on this if other folks are interested...
>>
>> Regards, marcelo
>>
>>> Area Director. We've come up with a more tightly-constrained 
>>> is not spelled out in the charter, because I don't want to bias the 
>>> type of solution we can use. However, based on the documents I've 
>>> seen from Will Ivancic, Terry Davis, and their compatriots, that may 
>>> be a good place to start. We need to refine those documents and 
>>> their input into a good requirements doc. I will work with those 
>>> groups to come up with that document.
>>>
>>> figuring out how to interact with the IETF, so it may take some 
>>> requirements data from them. Thierry will work with those groups on 
>>> that document.
>>>
>>> charter document very frequently, since it's a long process. 
>>> However, if we do discover some important deployment scenarios that 
>>> aren't covered under these concrete examples, we can definitely 
>>> investigate updating the charter.
>>>

---

From: Chan-Wah NG <[email-masked]>
Date: Mon, 06 Nov 2006 08:32:30 +0800

Hello all,

> document and see if we need some additional work to make the appraoch 

That's my understanding as well ...  The base idea is already there in
the appendix, all we need to do is to formalize it, and polish it abit
on some of the rough edges.

I am pretty surpised by the omission of the work from the charter as
well ...  it has been raised a few times, there is no objections I can
see.

> this is relevant/interesting

What Vijay says (in another response) on "people geeting tired of
waiting" is quite true too ... ;)

I am definitely committed to doing this work if the WG thinks it is
worthwhile.

/rgds
/cwng