Hi Don, and All, I would like to know your opinion about why we don't define subnets for MANET? On 6/3/12, Don Sturek <d.sturek@xxxxxxx> wrote: > +1 > > On 6/2/12 11:21 PM, "Charles E. Perkins" <charliep@xxxxxxxxxxxx> wrote: Could we discuss why we don't define subnets models? I don't understand adding (+1). I hope the chair does not ask me to close this thread too :) The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 so living for about 6 years only. What was the reason for the proposed close of it? please read the DA Jari's reasons below. IMO it because it had low/no useful discussions and only produced one RFC which is RFC5889, why only one? what happend within 6 years? IMO any WG should have more discussions, discussions are mandatory activity for WG. Not discussing issues is like ignoring the value input to group progress. Healthy discussions are more important than producing more documents produced, because discussions are really the source of correct documents (don't mean it has to be perfect, but should not be misleading). WGs should be compared in terms of the amount of discussions not in amount of documents forwarded/submitted. According to Chakeres and Maker (2006) [1] quoated below: [The autoconf WG is chartered to initially develop two documents. The first document is a document defining the MANET architecture and how MANET relates to IP networks and the Internet. The second document is to define the terminology, problem statement and goals for autoconf. These autoconf documents will be discussed on the autoconf mailing list.] That WG did not produce the definition of MANET architecture. Which I think is related to the subnet-model definition importance for MANET. So i understand the authors see the importance of defining something for MANET in 2006. Now, Do we have a network architecture definition of MANET in one RFC? > On 6/2/12 11:21 PM, "Charles E. Perkins" <charliep@xxxxxxxxxxxx> wrote: >>Hello folks, >> >>I would be opposed to requiring the subnet model as a mandatory >>component of any current [manet] working group charter item. >> >>We have had at least ten years of experience showing that requiring >>subnets can derail practically any wireless network discussion within >>the sphere of applicability of manet protocols. The reasons are many >>and varied -- and, I must admit, really very interesting. >> >>It was the death of another working group which really should have >>been allowed to go forward except for disagreements about certain >>subnet-related constructs. Let's not consign ourselves to the same >>fate. In future the death of the WG will be because they don't discuss things on the list, or don't have what to discuss, please read the reasons mentioned by Jari Arkko below. IMO for the future, some day any WGs possibly will close and other days new WGs comes. >> >>Regards, >>Charlie P. References: [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the IETF', Mobile Computing and communication review, volume 1, Number 2, 2006. Best regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: "autoconf at ietf.org" <autoconf at ietf.org> Subject: [Autoconf] closing the working group? From: Jari Arkko <jari.arkko at piuha.net> Date: Tue, 29 Mar 2011 08:48:47 +0200 -------------------------------------------------------------------------------- I have looked at the discussions on the list (or lack thereof). I also cannot see too many internet drafts on the topics belonging to the group's charter. I am very happy with the RFC that has been produced by the working group, but we also seem to have some actual protocol work happening elsewhere (e.g., in the context of the ROLL WG). I discussed this matter with the chairs and my co-AD, and we are wondering if it would be time to close the working group. I do know that there is at least one implementation team that is still in the process of describing their DHCP-based solution, maybe there are similar efforts on the distributed solution space. My proposal is that we close the working group and I'be VERY happy to AD sponsor all such solutions to Experimental RFCs as soon as we have those proposals in some reasonable shape. Thoughts? Jari +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: IETF-Announce at ietf.org Subject: WG Review: Ad Hoc Network configuration (autoconf) From: The IESG <iesg-secretary at ietf.org> Date: Wed, 27 Jul 2005 14:28:49 -0400 Cc: manetautoconf at ml.free.fr List-help: <mailto:ietf-announce-request@xxxxxxxx?subject=help> List-id: ietf-announce.ietf.org List-post: <mailto:ietf-announce@xxxxxxxx> List-subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@xxxxxxxx?subject=subscribe> List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@xxxxxxxx?subject=unsubscribe> Reply-to: iesg at ietf.org Sender: ietf-announce-bounces at ietf.org -------------------------------------------------------------------------------- A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by August 3rd. +++++++++++++ Ad Hoc Network configuration (autoconf) ======================================== Current Status: Proposed Working Group Chairs: TBD Internet Area Director(s): Mark Townsley <townsley at cisco.com> Margaret Wasserman <margaret at thingmagic.com> Internet Area Advisor: Margaret Wasserman <margaret at thingmagic.com> Mailing Lists: General Discussion: manetautoconf at ml.free.fr To Subscribe: manetautoconf-request at ml.free.fr Description of the WG: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) may 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. Ad hoc networks present several new challenges. Unlike in traditional IP networks, each ad hoc node, besides being a traffic end-point, should be capable of forwarding traffic destined for other hosts. Additionally, nodes constituting an ad-hoc network do not share access to a single multicast-capable link for signaling. Many protocol specifications used in traditional IP networks e.g. RFCs 2462, 2463 etc. do, however, assume that subnet-local signals (e.g. link-local multicast signal) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are expected to support multi-hop communication by running a MANET routing protocol, e.g. those developed by the IETF MANET WG. However, this may or may not mean that an AUTOCONF mechanism will be dependent on any specific MANET routing protocol. With this in mind, the goals of AUTOCONF WG are to: - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 stateless autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a stateful address autoconfiguration mechanism to be used by ad hoc nodes for configuring globally routable unique addresses, if an address providing entity such as DHCPv6 server is available. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Goals and Milestones: Oct 05 : Submit "terminology and problem statement" document for WG review Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms and design frameworks Feb 06: Submit "terminology and problem statement" document to IESG for publication as an informational RFC Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" for WG review Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" for WG review Apr 06: Submit initial -ID of "configured address uniqueness maintenance" for WG review Aug 06: Revise WG documents and review Dec 06 Revise documents based upon implementation experience Apr 07: Submit "stateless autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "stateful autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "configured address uniqueness maintenance" specification and supporting documentation to IESG for publications as Proposed Standard Oct 07: Close or recharter the WG _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ===================================================== >> >> >> >>On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>> Hi All >>> >>> I want to discuss this subnet definition issue that was raised in the >>> 82 meeting, could we discuss about it please. Will we need to put it >>> in a draft or include it in our active draft working in progress, >>> please advise, >>> >>> Abdussalam Baryun, >>> University of Glamorgan, UK >>> ++++++++++++++++++++++++++++++ >>> >>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>> BC> that subnet-models are not defined But in DLEP it looks at two >>> subnet-models (different models; e.g. radio subnet-models, >>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>> is not defined. Then we don¹t know how to define control protocols, >>> data-packet-formats, and managements-models without having a subnet >>> model in mind. >>> TB> In sat-comms the up-link and down-link can be very different. So >>> for different nodes on same carrier can be different data rates, SNR, >>> etc. so it is important that DLEP include the link metrics, even if it >>> is a full connected subnet. >>> BC> the subnet depends on the link of the subnet-underlying model, >>> The semantics of link up and down are determined by the underlying. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>> _______________________________________________ >>> manet mailing list >>> manet@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >>-- >>Regards, >>Charlie P. >> >>_______________________________________________ >>manet mailing list >>manet@xxxxxxxx >>https://www.ietf.org/mailman/listinfo/manet > > >