Subject: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf)

From: IESG Secretary <[email-masked]>
Date: Wed, 4 Mar 2009 08:32:57 -0800 (PST)

A modified charter has been submitted for the Ad-Hoc Network
Autoconfiguration working group in the Internet Area of the IETF.  The
IESG has not made any determination as yet.  The modified charter is
provided below for informational purposes only.  Please send your comments
to the IESG mailing list ([email-masked]) by Wednesday, March 11, 2009.

Ad-Hoc Network Autoconfiguration (autoconf) 
------------------------------------------------------------- 
Last Modified: 2009-02-18 
 
Current Status: Active Working Group 
 
Additional information is available at tools.ietf.org/wg/autoconf 
 
Chair(s): 
Ryuji Wakikawa [[email-masked]] 
Thomas Clausen [[email-masked]] 
 
Internet Area Director(s): 
Jari Arkko [[email-masked]] 
Mark Townsley [[email-masked]] 
 
Internet Area Advisor: 
Jari Arkko [[email-masked]] 
 
Mailing Lists: 
General Discussion: [email-masked] 
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf 
Archive: 
http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html 
 
Description of Working Group: 
 
In order to communicate among themselves, ad hoc nodes (refer to RFC 
2501) need to configure their network interface(s) with local addresses 
that are valid within an ad hoc network. Ad hoc nodes may also need to 
configure globally routable addresses, in order to communicate with 
devices on the Internet. From the IP layer perspective, an ad hoc 
network presents itself as a L3 multi-hop network formed over a 
collection of links. 
 
The main purpose of the AUTOCONF WG is to describe the addressing model 
for ad hoc networks and how nodes in these networks configure their 
addresses. It is required that such models do not cause problems for ad 
hoc-unaware parts of the system, such as standard applications running 
on an ad hoc node or regular Internet nodes attached to the ad hoc 
nodes. This group's effort may include the development of new protocol 
mechanisms, should the existing IP autoconfiguration mechanisms be found 
inadequate. However, the first task of the working group is to describe 
one practical addressing model for ad hoc networks. 
 
Once this sole work item is completed, the group can be rechartered to 
work on additional issues. 
 
Goals and Milestones: 
 
Apr 2009 Submit initial draft on address configuration in ad hoc networks
Sep 2009 Submit address configuration draft to IESG as Informational or 
close WG

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 18:35:38 +0100

I would like to suggest: add explicitely that the practical addressing 
model should work at least with manual and static routes.  And that the 
practical addressing model should not be preconditioned by the use of 
OLSR nor DYMO in the ad-hoc network.

Also suggest: specifically mention which link-layers are being 
considered for ad-hoc networks.  I personally consider 802.11, 802.15.4, 
wired Ethernet, USB and eventually 802.16.  If anybody else considers 
other link-layers please mention them.

Alex

IESG Secretary a écrit :
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 20:18:51 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Alexandru Petrescu
|Verzonden: woensdag 4 maart 2009 18:36
|CC: [email-masked]; [email-masked]; [email-masked]
|Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network
|Autoconfiguration (autoconf)
|
|I would like to suggest: add explicitely that the practical addressing
|model should work at least with manual and static routes.  And that the
|practical addressing model should not be preconditioned by the use of
|OLSR nor DYMO in the ad-hoc network.

I think the addressing model has little to do with the method how to assign
and configure the addresses. This is a next step. I wonder if any model
exclude what you are asking for. Worried for some reason???

I would not suggest working with static routes in a mobile ad hoc network.

I agree on the last one, the model should apply to other MANET Routing
Protocols as well. OSPF-MANET is an important one, not forgetting others,
including multicast.
 
|Also suggest: specifically mention which link-layers are being
|considered for ad-hoc networks.  I personally consider 802.11, 802.15.4,
|wired Ethernet, USB and eventually 802.16.  If anybody else considers
|other link-layers please mention them.

I consider other link layers, but I will not mention them. I do not know all
details or even a complete list. And if I would, it doesn't help. I think it
is sufficient and more useful to describe the MANET link characteristics.

Teco.

|
|Alex
|
|IESG Secretary a écrit :
|> A modified charter has been submitted for the Ad-Hoc Network
|> Autoconfiguration working group in the Internet Area of the IETF.  The
|> IESG has not made any determination as yet.  The modified charter is
|> provided below for informational purposes only.  Please send your
|comments
|> to the IESG mailing list ([email-masked]) by Wednesday, March 11, 2009.
|>
|> Ad-Hoc Network Autoconfiguration (autoconf)
|> -------------------------------------------------------------
|> Last Modified: 2009-02-18
|>
|> Current Status: Active Working Group
|>
|> Additional information is available at tools.ietf.org/wg/autoconf
|>
|> Chair(s):
|> Ryuji Wakikawa [[email-masked]]
|> Thomas Clausen [[email-masked]]
|>
|> Internet Area Director(s):
|> Jari Arkko [[email-masked]]
|> Mark Townsley [[email-masked]]
|>
|> Internet Area Advisor:
|> Jari Arkko [[email-masked]]
|>
|> Mailing Lists:
|> General Discussion: [email-masked]
|> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
|> Archive:
|> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html
|>
|> Description of Working Group:
|>
|> In order to communicate among themselves, ad hoc nodes (refer to RFC
|> 2501) need to configure their network interface(s) with local
|addresses
|> that are valid within an ad hoc network. Ad hoc nodes may also need to
|> configure globally routable addresses, in order to communicate with
|> devices on the Internet. From the IP layer perspective, an ad hoc
|> network presents itself as a L3 multi-hop network formed over a
|> collection of links.
|>
|> The main purpose of the AUTOCONF WG is to describe the addressing
|model
|> for ad hoc networks and how nodes in these networks configure their
|> addresses. It is required that such models do not cause problems for
|ad
|> hoc-unaware parts of the system, such as standard applications running
|> on an ad hoc node or regular Internet nodes attached to the ad hoc
|> nodes. This group's effort may include the development of new protocol
|> mechanisms, should the existing IP autoconfiguration mechanisms be
|found
|> inadequate. However, the first task of the working group is to
|describe
|> one practical addressing model for ad hoc networks.
|>
|> Once this sole work item is completed, the group can be rechartered to
|> work on additional issues.
|>
|> Goals and Milestones:
|>
|> Apr 2009 Submit initial draft on address configuration in ad hoc
|networks
|> Sep 2009 Submit address configuration draft to IESG as Informational
|or
|> close WG
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 04 Mar 2009 20:51:17 +0100

Inline

> exclude what you are asking for. Worried for some reason???
I don't see why the charter should explicitly mention that the
addressing model should work with manual and static routes. As Teco
said, this would be part of the solution space, i.e. it could be part of
a draft that describes an autoconf mechanism.

> I would not suggest working with static routes in a mobile ad hoc network.
Well, as said, I don't think that's part of the discussion we lead here
concerning the charter.
> Protocols as well. OSPF-MANET is an important one, not forgetting others,
Yes, but I don't think it should be mentioned in the charter. The
charter does not say anything that the addressing model should have any
preconditions for a particular MANET routing protocol. Otherwise, it
would need to list a large number of routing protocols (OLSR, OLSRv2,
OSPF, AODV,....)
> is sufficient and more useful to describe the MANET link characteristics.

I agree with Teco. MANETs can run on a number of different L2
technologies with certain characteristics. These characteristics should
be mentioned in the document to be written, but not in the charter. In
my opinion, no specific L2 should be mentioned.

Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Mar 2009 16:10:49 -0500

Inline 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ulrich Herberg
> Sent: Wednesday, March 04, 2009 2:51 PM
> To: Teco Boot
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc 
> Network Autoconfiguration (autoconf)
> 
> Inline
> 
> Teco Boot wrote:
> > Inline.
> >
> > |Van: [email-masked] [mailto:[email-masked]] 
> > |Namens Alexandru Petrescu
> > |I would like to suggest: add explicitely that the practical 
> > |addressing model should work at least with manual and 
> static routes.  
> > |And that the practical addressing model should not be 
> preconditioned 
> > |by the use of OLSR nor DYMO in the ad-hoc network.
> >
> > I think the addressing model has little to do with the 
> method how to 
> > assign and configure the addresses. This is a next step. I 
> wonder if 
> > any model exclude what you are asking for. Worried for some 
> reason???
> >   
> I don't see why the charter should explicitly mention that 
> the addressing model should work with manual and static 
> routes. As Teco said, this would be part of the solution 
> space, i.e. it could be part of a draft that describes an 
> autoconf mechanism.
> 
> Well, as said, I don't think that's part of the discussion we 
> lead here concerning the charter.
> > Protocols as well. OSPF-MANET is an important one, not forgetting 
> > others, including multicast.
> >   
> Yes, but I don't think it should be mentioned in the charter. 
> The charter does not say anything that the addressing model 
> should have any preconditions for a particular MANET routing 
> protocol. Otherwise, it would need to list a large number of 
> routing protocols (OLSR, OLSRv2, OSPF, AODV,....)
> >  
> > |considered for ad-hoc networks.  I personally consider 802.11, 
> > |802.15.4, wired Ethernet, USB and eventually 802.16.  If 
> anybody else 
> > |considers other link-layers please mention them.
> >
> > I consider other link layers, but I will not mention them. I do not 
> > know all details or even a complete list. And if I would, 
> it doesn't 
> > help. I think it is sufficient and more useful to describe 
> the MANET link characteristics.
> >   
> 
> technologies with certain characteristics. These 
> characteristics should be mentioned in the document to be 
> written, but not in the charter. In my opinion, no specific 
> L2 should be mentioned.
> 
> Ulrich

Ditto what Ulrich says. I fail to understand why the selection of a Layer 2 technology should impact the assignmnet of Layer 3 addresses, therefore, I see no need to call out any specific L2.

Regards,
Stan

> > |> Autoconfiguration working group in the Internet Area of 
> the IETF.  
> > |> The IESG has not made any determination as yet.  The modified 
> > |> charter is provided below for informational purposes 
> only.  Please 
> > |> send your
> > |comments
> > |> Ryuji Wakikawa [[email-masked]] Thomas Clausen 
> > |> [[email-masked]]
> > |>
> > |> General Discussion: [email-masked] To Subscribe: 
> > |> In order to communicate among themselves, ad hoc nodes (refer to 
> > |> RFC
> > |> that are valid within an ad hoc network. Ad hoc nodes 
> may also need 
> > |> to configure globally routable addresses, in order to 
> communicate 
> > |> with devices on the Internet. From the IP layer 
> perspective, an ad 
> > |> hoc network presents itself as a L3 multi-hop network 
> formed over a 
> > |> collection of links.
> > |>
> > |> addresses. It is required that such models do not cause problems 
> > |> for
> > |ad
> > |> hoc-unaware parts of the system, such as standard applications 
> > |> running on an ad hoc node or regular Internet nodes 
> attached to the 
> > |> ad hoc nodes. This group's effort may include the development of 
> > |> new protocol mechanisms, should the existing IP 
> autoconfiguration 
> > |> mechanisms be
> > |found
> > |> Once this sole work item is completed, the group can be 
> rechartered 
> > |> to work on additional issues.
> > |>
> > |> Goals and Milestones:
> > |>
> > |> Sep 2009 Submit address configuration draft to IESG as 
> > |> Informational
> > |or
> > |> close WG
> > |>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 23:20:10 +0100

I agree on not mentioning an endless list of routing protocols.
I was not precise in my reply, I agreed on not rely on OLSR or DYMO. I
forgot to mention the list should not be in the charter.
Being independent on routing protocols was in the previous charter, that was
OK for me.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Ulrich Herberg [mailto:[email-masked]] Namens Ulrich Herberg
|Verzonden: woensdag 4 maart 2009 20:51
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; [email-masked]; [email-masked];
[email-masked]
|Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network
|Autoconfiguration (autoconf)
|
|Inline
|
|Teco Boot wrote:
|> Inline.
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: [email-masked] [mailto:[email-masked]]
|Namens
|> |Alexandru Petrescu
|> |Verzonden: woensdag 4 maart 2009 18:36
|> |CC: [email-masked]; [email-masked]; [email-masked]
|> |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network
|> |Autoconfiguration (autoconf)
|> |
|> |I would like to suggest: add explicitely that the practical
|addressing
|> |model should work at least with manual and static routes.  And that
|the
|> |practical addressing model should not be preconditioned by the use of
|> |OLSR nor DYMO in the ad-hoc network.
|>
|> I think the addressing model has little to do with the method how to
|assign
|> and configure the addresses. This is a next step. I wonder if any
|model
|> exclude what you are asking for. Worried for some reason???
|>
|I don't see why the charter should explicitly mention that the
|addressing model should work with manual and static routes. As Teco
|said, this would be part of the solution space, i.e. it could be part of
|a draft that describes an autoconf mechanism.
|
|> I would not suggest working with static routes in a mobile ad hoc
|network.
|>
|Well, as said, I don't think that's part of the discussion we lead here
|concerning the charter.
|> I agree on the last one, the model should apply to other MANET Routing
|> Protocols as well. OSPF-MANET is an important one, not forgetting
|others,
|> including multicast.
|>
|Yes, but I don't think it should be mentioned in the charter. The
|charter does not say anything that the addressing model should have any
|preconditions for a particular MANET routing protocol. Otherwise, it
|would need to list a large number of routing protocols (OLSR, OLSRv2,
|OSPF, AODV,....)
|>
|> |Also suggest: specifically mention which link-layers are being
|> |considered for ad-hoc networks.  I personally consider 802.11,
|802.15.4,
|> |wired Ethernet, USB and eventually 802.16.  If anybody else considers
|> |other link-layers please mention them.
|>
|> I consider other link layers, but I will not mention them. I do not
|know all
|> details or even a complete list. And if I would, it doesn't help. I
|think it
|> is sufficient and more useful to describe the MANET link
|characteristics.
|>
|
|I agree with Teco. MANETs can run on a number of different L2
|technologies with certain characteristics. These characteristics should
|be mentioned in the document to be written, but not in the charter. In
|my opinion, no specific L2 should be mentioned.
|
|Ulrich
|> Teco.
|>
|>
|> |
|> |Alex
|> |
|> |IESG Secretary a écrit :
|> |> A modified charter has been submitted for the Ad-Hoc Network
|> |> Autoconfiguration working group in the Internet Area of the IETF.
|The
|> |> IESG has not made any determination as yet.  The modified charter
|is
|> |> provided below for informational purposes only.  Please send your
|> |comments
|> |> to the IESG mailing list ([email-masked]) by Wednesday, March 11,
|2009.
|> |>
|> |> Ad-Hoc Network Autoconfiguration (autoconf)
|> |> -------------------------------------------------------------
|> |> Last Modified: 2009-02-18
|> |>
|> |> Current Status: Active Working Group
|> |>
|> |> Additional information is available at tools.ietf.org/wg/autoconf
|> |>
|> |> Chair(s):
|> |> Ryuji Wakikawa [[email-masked]]
|> |> Thomas Clausen [[email-masked]]
|> |>
|> |> Internet Area Director(s):
|> |> Jari Arkko [[email-masked]]
|> |> Mark Townsley [[email-masked]]
|> |>
|> |> Internet Area Advisor:
|> |> Jari Arkko [[email-masked]]
|> |>
|> |> Mailing Lists:
|> |> General Discussion: [email-masked]
|> |> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
|> |> Archive:
|> |> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html
|> |>
|> |> Description of Working Group:
|> |>
|> |> In order to communicate among themselves, ad hoc nodes (refer to
|RFC
|> |> 2501) need to configure their network interface(s) with local
|> |addresses
|> |> that are valid within an ad hoc network. Ad hoc nodes may also need
|to
|> |> configure globally routable addresses, in order to communicate with
|> |> devices on the Internet. From the IP layer perspective, an ad hoc
|> |> network presents itself as a L3 multi-hop network formed over a
|> |> collection of links.
|> |>
|> |> The main purpose of the AUTOCONF WG is to describe the addressing
|> |model
|> |> for ad hoc networks and how nodes in these networks configure their
|> |> addresses. It is required that such models do not cause problems
|for
|> |ad
|> |> hoc-unaware parts of the system, such as standard applications
|running
|> |> on an ad hoc node or regular Internet nodes attached to the ad hoc
|> |> nodes. This group's effort may include the development of new
|protocol
|> |> mechanisms, should the existing IP autoconfiguration mechanisms be
|> |found
|> |> inadequate. However, the first task of the working group is to
|> |describe
|> |> one practical addressing model for ad hoc networks.
|> |>
|> |> Once this sole work item is completed, the group can be rechartered
|to
|> |> work on additional issues.
|> |>
|> |> Goals and Milestones:
|> |>
|> |> Apr 2009 Submit initial draft on address configuration in ad hoc
|> |networks
|> |> Sep 2009 Submit address configuration draft to IESG as
|Informational
|> |or
|> |> close WG
|> |>
|> |> _______________________________________________
|> |> Autoconf mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/autoconf
|> |>
|> |
|> |_______________________________________________
|> |Autoconf mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>

---

From: HyungJin Lim <[email-masked]>
Date: Thu, 5 Mar 2009 08:52:06 +0900

Inline...

2009/3/5 IESG Secretary <[email-masked]>

> Ad-Hoc Network Autoconfiguration (autoconf)

In here, I have a question !
What's meaning of globally routable addresses ?
I think globally routable addresses should include topologically correct
address and topologically incorrect address.
The reason I address this is that the NEMO basic support should configure
topologically incorrect address in nested NEMO.
But topologically incorrect address is also globally routable addresses if
it a packet forwarding mechanism (e.g., tunneling) is supported, not packet
routing(e.g. OLSR, DYMO, etc.).

> one practical addressing model for ad hoc networks.

What's meaning of practical addressing model ?
Should we consider practical scenarios for practical addressing model in
real world ?
The only simplest scenario can satisfy requirements and other aspects in
more complex scenario which include Internet connectivity, nested pattern,
group mobility, wireless coverage, and so on.

I would like suggest to define some requirements for practical scenarios.
Then, the simplest scenario also can be considered as a base topic I think.

Hyung-Jin, Lim

---

From: HyungJin Lim <[email-masked]>
Date: Thu, 5 Mar 2009 17:14:22 +0900

I'm sorry for correction about the following comment and duplicate comments.
My first language is not English.

---------- Forwarded message ----------
From: HyungJin Lim <[email-masked]>
Date: 2009/3/5
Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network
Autoconfiguration (autoconf)
To: [email-masked]
Cc: [email-masked], [email-masked]

Inline...

What's meaning of practical addressing model ?
*Although we already discussed this issue in MANEMO BoF,* *we should *consider
practical scenarios for practical addressing model in real world I think.
The only simplest scenario *can not* satisfy requirements and other aspects
in more complex scenario which include Internet connectivity, nested
pattern, group mobility, wireless coverage, and so on.

I would like suggest to define some requirements for practical scenarios.
Then, the simplest scenario also can be considered as a base  topic of them
I think.

Hyung-Jin, Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 11:38:23 +0100

HyungJin Lim a écrit :
> From: *HyungJin Lim* <[email-masked] <mailto:[email-masked]>>
> Date: 2009/3/5
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]>
> 
> 
> Inline...
> 
> 2009/3/5 IESG Secretary <[email-masked] 
> <mailto:[email-masked]>>
> 
>     to the IESG mailing list ([email-masked] <mailto:[email-masked]>) by
>     Wednesday, March 11, 2009.
> 
>     <http://tools.ietf.org/wg/autoconf>
> 
>     Chair(s):
>     Ryuji Wakikawa [[email-masked]
>     <mailto:[email-masked]>]
>     Thomas Clausen [[email-masked] <mailto:[email-masked]>]
> 
>     Jari Arkko [[email-masked] <mailto:[email-masked]>]
>     Mark Townsley [[email-masked] <mailto:[email-masked]>]
> 
>     Internet Area Advisor:
>     Jari Arkko [[email-masked] <mailto:[email-masked]>]
> 
>     Mailing Lists:
>     General Discussion: [email-masked] <mailto:[email-masked]>

I think it's a commonly agreed term, in the IPv6 Addressing Architecture 
  RFC.

> address and topologically incorrect address.

Correct relative to what?

> The reason I address this is that the NEMO basic support should 
> configure topologically incorrect address in nested NEMO.

I agree: addresses configured within a nested NEMO moving network are 
probably topologically incorrect with respect to the CoA and subnet 
assigned to the top-level Mobile Router egress interface of a parent 
NEMO moving network.

> But topologically incorrect address is also globally routable addresses 
> if it a packet forwarding mechanism (e.g., tunneling) is supported, not 
> packet routing(e.g. OLSR, DYMO, etc.).

I agree.

> *Although we already discussed this issue in MANEMO BoF,* *we should 
> *consider practical scenarios for practical addressing model in real 
> world I think.
> The only simplest scenario *can not* satisfy requirements and other 
> aspects in more complex scenario which include Internet connectivity, 
> nested pattern, group mobility, wireless coverage, and so on.
>  
> Then, the simplest scenario also can be considered as a base  topic of 
> them I think.

I tend to agree with the approach

I'm just afraid that defining new requirements may lengthen the process 
of coming up with a practical addressing model.  I think the word 
practical is there to just mean that in practice many of us may write an 
addressing model in a very straightforward manner, which would work in 
each one's particular case.

Maybe we could find the practical and easiest simplest most convenient 
way of a common denominator addressing models for some very simple 
dynamic networks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 12:24:07 +0100

Alexandru Petrescu a écrit :
>> I think globally routable addresses should include topologically 
>> correct address and topologically incorrect address.
> 
>> But topologically incorrect address is also globally routable 
>> addresses if it a packet forwarding mechanism (e.g., tunneling) is 
>> supported, not packet routing(e.g. OLSR, DYMO, etc.).
> 
> I agree.
> 

But yes, I agree with you on the necessity to come up with the simplest 
scenario as a base topic for more complex.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Mar 2009 12:14:01 -0000

> considered for ad-hoc networks.

Definitely not.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: HyungJin Lim <[email-masked]>
Date: Thu, 5 Mar 2009 21:30:03 +0900

Hi, Alex,

Inline...

2009/3/5 Alexandru Petrescu <[email-masked]>

>>> 2009/3/5 IESG Secretary <[email-masked] <mailto:
>>> [email-masked]>>
>>>
>>>    Thomas Clausen [[email-masked] <mailto:[email-masked]
>>> >]
>>>
>> probably topologically incorrect with respect to the CoA and subnet assigned
>> to the top-level Mobile Router egress interface of a parent NEMO moving
>> network.
>>
>>> *consider practical scenarios for practical addressing model in real world I
>>> think.
>>> aspects in more complex scenario which include Internet connectivity, nested
>> I'm just afraid that defining new requirements may lengthen the process of
>> coming up with a practical addressing model.  I think the word practical is
>> there to just mean that in practice many of us may write an addressing model
>> in a very straightforward manner, which would work in each one's particular
>> case.
>>
>> Maybe we could find the practical and easiest simplest most convenient way
>> of a common denominator addressing models for some very simple dynamic
>> networks.
>>
>

 If the simplest scenario can cover various aspects from some scenarios
including more complex situations, it's OK.

> scenario as a base topic for more complex.

       In some scenarios Teco addressed in previous comment, we can
meet situations that the simplest scenario do not cover.
     How about considering from the simples scenario to meaningful complex
scenario.
     After defining their requirements such as address configuration models,
some impacts from them, possible situation we will meet due to
wireless coverage, some impacts from group mobility pattern and dynamic
topology change,  we can suggest the addressing model for ad hoc
networks and for future Internet I think.

The following URL shows a representative scenario we can meet for example.

We already have discussed about the practical scenario several times in
NEMO. and MANEMO. This is not a new issue but we did not define this I
think.
http://tools.ietf.org/html/draft-wakikawa-manemoarch-00

Is it right that MANET includes MANEMO ?

Hyung-Jin, Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 15:03:26 +0100

HyungJin Lim a écrit :
> Hi, Alex,
>  
> Inline...
> 
> 2009/3/5 Alexandru Petrescu <[email-masked] 
> <mailto:[email-masked]>>
> 
>             From: *HyungJin Lim* <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>>
>             Date: 2009/3/5
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             Cc: [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>,
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>
> 
> 
>             Inline...
> 
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>>
> 
>                provided below for informational purposes only.  Please
>             send your
>                comments
>                to the IESG mailing list ([email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>) by
>                Additional information is available at
>             tools.ietf.org/wg/autoconf <http://tools.ietf.org/wg/autoconf>
>             <mailto:[email-masked]>
>                <mailto:[email-masked]
>             <mailto:[email-masked]>>]
>                Thomas Clausen [[email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>]
> 
>                Jari Arkko [[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>]
>                Mark Townsley [[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>]
> 
>                Internet Area Advisor:
>                Jari Arkko [[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>]
> 
>                Mailing Lists:
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>         I think it's a commonly agreed term, in the IPv6 Addressing
>         Architecture  RFC.
> 
>             I think globally routable addresses should include
>             topologically correct address and topologically incorrect
>             address.
> 
> 
>             The reason I address this is that the NEMO basic support
>             should configure topologically incorrect address in nested NEMO.
> 
> 
>         I agree: addresses configured within a nested NEMO moving
>         network are probably topologically incorrect with respect to the
>         CoA and subnet assigned to the top-level Mobile Router egress
>         interface of a parent NEMO moving network.
> 
>             But topologically incorrect address is also globally
>             routable addresses if it a packet forwarding mechanism
>             (e.g., tunneling) is supported, not packet routing(e.g.
>             OLSR, DYMO, etc.).
> 
> 
>         I agree.
> 
>             *Although we already discussed this issue in MANEMO BoF,*
>             *we should *consider practical scenarios for practical
>             addressing model in real world I think.
>             The only simplest scenario *can not* satisfy requirements
>             and other aspects in more complex scenario which include
>             Internet connectivity, nested pattern, group mobility,
>             wireless coverage, and so on.
>             Then, the simplest scenario also can be considered as a base
>              topic of them I think.
> 
> 
>         I'm just afraid that defining new requirements may lengthen the
>         process of coming up with a practical addressing model.  I think
>         the word practical is there to just mean that in practice many
>         of us may write an addressing model in a very straightforward
>         manner, which would work in each one's particular case.
> 
>         Maybe we could find the practical and easiest simplest most
>         convenient way of a common denominator addressing models for
>         some very simple dynamic networks.
> 
>  
>  
>     But yes, I agree with you on the necessity to come up with the
>     simplest scenario as a base topic for more complex.
> 
>  
>  
>      How about considering from the simples scenario to meaningful 
> complex scenario.
>      After defining their requirements such as address configuration 
> models, some impacts from them, possible situation we will meet due to 

Well yes I tend to agree but I currently can't understand the 
requirements as stated until now.

> The following URL shows a representative scenario we can meet for example.

But the URL shows several scenarios :-)  Which one do you think?  I 
myself prefer the left diagram in Figure 5 (egress-to-egress).

> NEMO. and MANEMO. 

I agree.

> This is not a new issue but we did not define this I 
> think.

Well if the answer were yes, and said so in the Charter, then I'd 
certainly have a higher interest in AUTOCONF.

Ever since the MANEMO BoF was re-directed to AUTOCONF never was there 
any sign of "NEMO" neither in the old nor new Charter.

Whereas previous Charter was saying "MANET" the current proposal only 
says "ad-hoc network" and "ad-hoc unaware" - is this freedom to 
interpret it as including NEMO?

Alex