[manet] Re: Problems and Gaps
Lou Berger <[email protected]> Thu, 30 Jul 2026 16:17:57 +0200
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
--===============2550983959270398392== Content-Type: multipart/alternative; boundary="------------j0cUNERD0ZIolsP0lh6ypf1m" Content-Language: en-US --------------j0cUNERD0ZIolsP0lh6ypf1m Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Fred, "the editors of those documents got to apply their own interpretations" Editors opinions have no more standing / weight on the contents of a WG document than anyone else in the WG. I suggest you reread https://datatracker.ietf.org/doc/html/rfc9281#name-document-editor-or-author. I may be in the rough, but is the editor's/Author's (and ultimately the WG chairs') role to demonstrate that is the case, and that the document accurately reflects WG consensus. This is why I was surprised you didn't explicitly review each WG adoption comment and it's resolution either on the list or in the WG session -- and why I suggested that we may need an interim if the WG doesn't want to wait to have the discussion at the next IETF (either are fine with my, subject to the actual schedule of the interim). Lou On 7/29/2026 5:50 PM, Templin (US), Fred L wrote: > > Lou, I suspect if you asked 20 random IETFers what is meant by > “problem” and what is meant by “gap” you would get 20 different > answers. Still, those terms turn up in published RFCs all the time – > for example, RFC9365 talks about “problems” and RFC7429 talks about > “gaps” and the editors of those documents got to apply their own > interpretations of what is meant by the terms. > > Thank you - Fred > > *From:*Lou Berger <[email protected]> > *Sent:* Wednesday, July 29, 2026 8:14 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* [email protected]; manet <[email protected]> > *Subject:* [EXTERNAL] Re: [manet] Re: Extended: Call for adoption: > draft-templin-manet-inet-05 > > > > > EXT email: be mindful of links/attachments. > > Fred > > see below. Dropping closed topics. > > On 7/27/2026 2:09 PM, Templin (US), Fred L wrote: > > Hi Lou, see responses marked with “>>” below: > > Thank you - Fred > > *From:*Lou Berger <[email protected]> <mailto:[email protected]> > *Sent:* Monday, July 27, 2026 9:36 AM > *To:* Templin (US), Fred L <[email protected]> > <mailto:[email protected]> > *Cc:* [email protected]; manet <[email protected]> > <mailto:[email protected]> > *Subject:* Re: [manet] Re: Extended: Call for adoption: > draft-templin-manet-inet-05 > > > Fred, > > See in-line below. > > On 7/24/2026 10:52 AM, Templin (US), Fred L wrote: > > Hello Lou, follow-ups below: > > Thank you - Fred > > *From:*Lou Berger <[email protected]> <mailto:[email protected]> > *Sent:* Thursday, July 23, 2026 2:33 PM > *To:* Templin (US), Fred L <[email protected]> > <mailto:[email protected]> > *Cc:* [email protected]; manet > <[email protected]> <mailto:[email protected]> > *Subject:* Re: [manet] Re: Extended: Call for adoption: > draft-templin-manet-inet-05 > > Fred, > > See inline below -- also for ref I'll use > draft-ietf-manet-inet-gap-analysis-03 > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03> assuming > it is the same as the PDF you sent to the list... > > On 7/22/2026 12:34 PM, Templin (US), Fred L wrote: > > Hi Lou, > > > > ... > > If this text exists in the document or a reference used by the > document, then no. If it does not, then sounds like it should be. > > FLT >> OK, I will add the above text in the intro. > > Thanks. > > >> done > > ... > > > > The discussion appears in the introduction and throughout the problem statements. > > Much of the discussion was added in response to your previous set of comments. > > For me the design choice of a global overly is so significant > it should be covered explicitly. to be clear, the following text > > A widely-accepted axiom at the time of this writing suggests > that there are more cellphones than people on the > planet [STATISTA > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#STATISTA>]. > According to Wikipedia, the world population reached 8 billion > in 2022 and is expected to reach 10 billion by 2056 [WIKI > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#WIKI>]. > Each mobile node that connects to the global public Internet > can in some sense be regarded as a singleton "MANET" with the > potential to connect still larger MANETs. > > MANET Internetworking therefore regards the global Internet as > a "network of (mobile ad-hoc) networks" with unrestricted > dynamic relationships between distinct MANET local routing > regions joined by a Non-Broadcast Multiple Access (NBMA) > virtual overlay link manifested through encapsulation. Figure > 1 > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#manet-inet> illustrates > an example of 2 distinct MANET local routing regions connected > via the NBMA overlay using the Internet as transit: > > .-(::::::::) > > .-(::: Global ::)-. > > X==+======(===================)======+==X > > | `-(: Internet :)-' | > > | `-(::::::)-' | > > | | > > .-(::::::::) .-(::::::::) > > .-(::::::::::::)-. .-(::::::::::::)-. > > (::::: MANET 1 :::::) (::::: MANET 2 :::::) > > `-(::::::::::::)-' `-(::::::::::::)-' > > `-(::::::)-' `-(::::::)-' > > Figure 1 > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#figure-1>: > MANET Internetworking > <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-manet-internetworking> > > > While the figure depicts just 2 MANET local routing regions, > many others worldwide will also want to connect to the virtual > link. Since a sustained increase in both the world population > and number of mobile wireless devices is certain, MANET > Internetworking must therefore accommodate populations on the > order of O(10**10) or more. This includes address duplication > avoidance through operational assurance since statistical > properties alone may be insufficient to avoid duplication in > such large populations. > > appears to be used to justify the global overlay, but to me it > does the opposite, i.e. why would we want an overlay that > accommodates O(10**10) or more vs just using the standard > Internet. > > >> A couple of things here. First, BGP scaling in the standard > Internet is only able to accommodate O(10**6) > > >> prefixes that rarely change. Second, frequent advertisement > and withdrawal of mobile network prefixes > > >> can cause BGP churn resulting in instability in the global > routing system. In other words, BGP is not > > >> well suited to supporting mobile Internetworking by itself. > With an overlay, the BGP routing service > > >> only needs to cover the addresses of the Mobility Anchor > Points (MAPs) which are stable nodes > > >> not subject to mobility. Within the overlay, the MAPs keep > track of Mobile Network Prefix (MNP) > > >> to MAP associations which may change dynamically. This is > accommodated through a combination > > >> of a hierarchical overlay BGP arrangement of the MAPs in > combination with dynamic updates to the > > >> (reverse) DNS resource records that associate MNPs with MAPs. > One final thing is that there need > > >> not be only one gigantic global overlay – there could be many > smaller overlays operated by > > >> Mobility Service Providers (MSPs). > > It may be we have different understanding of the objectives of > "MANET internetwoking". For the purposes are, in priority order, > (A) manet nodes being able to initiate and maintain communication > with nodes on the rest of the Network > (B) Nodes on the Internet being able to initiate and maintain > communication with nodes in a MANET > (C) for nodes in a MANET being able to initiate and maintain > communication with nodes in another MANET > > Do you agree with this list? Do you agree with the priority order? > > >> I do not agree with a priority order for these, because the > requirement is very much use-case > > >> specific. For a MANET of nodes that want to browse the Internet, > (A) might be a higher priority. > > >> For a MANET consisting of sensor nodes, (B) might be the higher > priority. For people and their > > >> cellphones wanting to call each other, (C) might be the higher > priority. I therefore do not want > > >> to assign priorities to the problems. I want for any solution > proposals to completely address > > >> all of the problems while also explaining how they address the gaps. > > In either (any) case I think the draft needs to clearly state what > problem is being solved by MANET Interworking. Then the GAPs can > cover the points and limitations above which then can explain why > a particular solution architecture is proposed by the document. > > *//* > > >> New text in the draft clarifies what is meant by a “problem” and > what is meant by a “gap” > > >> and I do not think it is going to be productive to have endless > arguments about whether > > >> something is a “problem” vs a “gap”. Please do not try to read > too much into these terms. > > I'm sorry, I completely disagree. An RFC should stand on its own > without having to see the email history to understand it. I'm saying I > don't understand the current text as it stands, and that delineating > what is the problem, from the existing solutions, from the gaps is > needed in this document. I may be in the rough on this, but we'll > need to see if others agree or disagree to know this. > > > > Another motivation for an overlay that is not yet addressed in the > > document is seamless support for MANET nodes with multiple > > interfaces. A natural reaction is to dismiss this as a corner case > > I agree that this is an important use case to consider in the problem > > statement. I note that the document introduces this concept in Gap 1 > > and not as it's own problem statement. > > > > Yes, it is listed as a gap that needs to be addressed by solution proposals. > > a gap for which of the problem statements? I suspect you are > missing one and it should be added. (IMO you can't have a gap > without a defined problem, do you see it differently?) > > *//* > > >> As above, please see the new text I will add to the draft. I > do not think an endless > > >> argument about what is a problem vs what is a gap will be > productive. > > >> The gaps apply to any and all of the problem statements and > not necessarily in 1x1 correspondence. > > >> The gaps are technology requirements that are specific to > MANET Internetworking but not currently > > >> addressed by existing Internetworking technologies. Solution > proposals need to explain how they > > >> close the gaps. > > Don't the gaps also need to be clear on what problem they are > solving? Said another way, a gap that isn't addressing a stated > problem really don't belong in this document. > > >> Lots of solutions both new and existing can claim to already > address some or all > > >> of the problems but the gap analysis should identify which > solutions do so most > > >> correctly, completely and/or efficiently. > > I think you missed my point -- the document should only have topics in > the gaps that are first introduced in the problem statements. I > suspect we disagree on this. > > > > > > until > > one considers that vast number of cellphones worldwide have > > multiple interfaces (cellular, Wi-Fi, bluetooth, and in some cases > > even SATCOM) where at least the cellular and Wi-Fi can be seen > > as candidate MANET interfaces when disconnected from or > > intermittently connected to infrastructure. > > > > This line of argument does *not* resonate with me as we already have a > > very scalable solution that is widely deployed, and that earlier > > attempts at MANETs on cell phones (I'll need to dig a bit on where this > > was discussed at the IETF, many years ago) didn't really pan out due to > > battery consumption. > > > > Modern cellphones have both WiFi and 5G interfaces. WiFi can already run > > in "ad-hoc" mode (for some flavor of "ad-hoc") and 3GPP is standardizing > > SideLink mode for 5G. The cellphone can therefore become be a MANET > > router to do multihop forwarding device-to-device when outside the > > context of cellular and/or WiFi infrastructure. Battery consumption is > > not an issue when the cellphone is connected to a power source such > > as when used inside of a vehicle. Even in dismounted scenarios, however, > > having a (limited-duration) multi-hop communications capability may be > > deemed worthwhile and could provide a safety-of-life capability such as > > for emergency response / disaster relief events. For these reasons, I believe > > the modern cellphone (of which there are billions worldwide) will become > > an important MANET router platform. > > Where is this discussed in the document? If it isn't then I > think it should be covered in a problem statement. > > >> I can add this, but I believe this document should be kept as > brief as possible. I am not in > > >> favor of gratuitous expansion that could cause the document > to grow without bounds. > > From one perspective it by be obvious and gratuitous, from another > it may be irrelevant. If not stated, IMO you can't assume any > consensus in the WG. > > This is making think of the quote "Everything should be made as > simple as possible, but not simpler." > > >> I have added the above text, but in the introduction and not the > problem statement. > > >> I am willing to consider adding more gaps if someone identifies > them, but I do not > > >> want to add more problems. > > Well this is now a working group document, so each of our voices > represent one WG contributor. Document editors have a lot of leeway > in document consensus, but it is incumbent on the editor to document > WG consensus - not the opinion of the authors. > > > > I heard you make a related comment just now at the mic that is not > > evident (at least to me) in the document -- I think it would be good to > > expand on your thoughts on this and make sure that the concepts are > > covered in the document. > > > > Does the above help? > > (covered by previous response.) > > > > > > An overlay interface > > configured over the MANET interfaces can then be used to > > orchestrate communications using a singular IP address that > > identifies the node as opposed to a distinct IP address for each > > MANET interface. > > > > Heretoo, this is something that is commonly done in non-manet networks > > without requiring a new global overlay. > > > > This is referring to a capability sometimes termed "multilink". It allows for > > carrying some packet flows over link "A" and others over links "B", "C", etc. > > but all using the same IP address in the overlay. Multilink is useful for > > fault tolerance, load balancing, matching flows to appropriate link > > performance profiles, cost optimization, etc. > > This is not unique to manets and is not generally solved using > an overlay., > > >> Multilink is solved by configuring a virtual interface over > multiple underlying interfaces > > >> which then applies encapsulation. Data communications can > then use an IP address > > >> assigned to the virtual interface even though the underlying > interfaces use different IP > > >> addresses. > > This is a common overlay (aka SD-WAN) solution that is very in > vogue today. It isn't the only or even obvious choice to me. (I'm > used to seeing 802.1 LACP/LAG, IETF bundling or unnumbered links) > > >> I should have started my response with: “Within the context of > MANET Internetworking, > > >> multilink is solved by configuring a virtual interface over > multiple underlying interfaces > > >> which then applies encapsulation.”. There may be other point > solution approaches to > > >> multilink, but the one I am referring to is “within the context > of MANET Internetworking”, > > >> i.e., when the solution also addresses all of the MANET > Internetworking problems while > > >> best closing the technological gaps. > > Where are the details substantiating this perspective? I think the > document needs references to support this position.(and I'd really > like to understand them, since I don't understand the assertion being > made.) > > Lou > > Another topic that > > I think needs to be better explored is the implicit role of DNS ( is > > it required or optional, is there complete definition, does it belong in > > this document). > > Agreed and we can expand on the discussion surrounding the DNS. > > > > I don't see this discussion in the current document, perhaps the > > document needs another section on assumptions/presumed architecture and > > rationale for such. > > > > The document already does discuss expectations of the DNS service in several > > places. I think going into a deeper discussion of the DNS architecture would be > > subject for a different document. > > Do you see providing "the global DNS which returns a (stable) > globally-routable IP address for the [mobile] correspondent." > to be a solved problem? If so can you add a reference to the > solution to the document? If not, I think it should be called > out as its own problem. > > >> As above, I don’t favor gratuitous expansion of this > document but will see what I can > > >> do about adding a few more words. > > great (and same response as above.) > > Thanks, > > Lou > > > > > > I think these issue can be worked before or after document adoption. In > > either case, I support having the WG discuss the topics represented in > > the draft. > > Thank you for bringing this discussion forward! > > > > Thank you! > > > > Lou > > > > Thanks - Fred > > Thanks! > > Lou > --------------j0cUNERD0ZIolsP0lh6ypf1m Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Fred,<br> <p>"the editors of those documents got to apply their own interpretations" </p> <p>Editors opinions have no more standing / weight on the contents of a WG document than anyone else in the WG. I suggest you reread <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc9281#name-document-editor-or-author">https://datatracker.ietf.org/doc/html/rfc9281#name-document-editor-or-author</a>.</p> <p>I may be in the rough, but is the editor's/Author's (and ultimately the WG chairs') role to demonstrate that is the case, and that the document accurately reflects WG consensus. This is why I was surprised you didn't explicitly review each WG adoption comment and it's resolution either on the list or in the WG session -- and why I suggested that we may need an interim if the WG doesn't want to wait to have the discussion at the next IETF (either are fine with my, subject to the actual schedule of the interim). </p> <p> Lou</p> <div class="moz-cite-prefix">On 7/29/2026 5:50 PM, Templin (US), Fred L wrote:<br> </div> <blockquote type="cite" cite="mid:BN0P110MB14206F0BF1CF1AC3192FF761A3CAA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@scope { @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;}@font-face {font-family:Aptos;}@font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:12.0pt; font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; font-size:10.0pt; font-family:"Courier New";}span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; mso-ligatures:none;}span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}@page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1 {page:WordSection1;} }</style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size:11.0pt">Lou, I suspect if you asked 20 random IETFers what is meant by “problem” and what is meant by “gap” you would get 20 different answers. Still, those terms turn up in published RFCs all the time – for example, RFC9365 talks about “problems” and RFC7429 talks about “gaps” and the editors of those documents got to apply their own interpretations of what is meant by the terms.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">Thank you - Fred<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Lou Berger <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> <br> <b>Sent:</b> Wednesday, July 29, 2026 8:14 AM<br> <b>To:</b> Templin (US), Fred L <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; manet <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Subject:</b> [EXTERNAL] Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05<o:p></o:p></span></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <table class="MsoNormalTable" border="0" cellspacing="3" cellpadding="0" width="100%" style="width:100.0%"> <tbody> <tr> <td style="background:white;padding:.75pt .75pt .75pt .75pt"> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%;margin-left:.75pt;margin-right:.75pt"> <tbody> <tr> <td style="background:#910A19;padding:5.25pt 1.5pt 5.25pt 1.5pt"><br> </td> <td width="100%" style="width:100.0%;background:#FDF2F4;padding:5.25pt 3.75pt 5.25pt 11.25pt"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly"> <span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#212121">EXT email: be mindful of links/attachments.</span><o:p></o:p></p> </td> </tr> </tbody> </table> <pre><span style="color:black"> <o:p></o:p></span></pre> </td> </tr> </tbody> </table> <p>Fred <o:p></o:p></p> <p>see below. Dropping closed topics.<o:p></o:p></p> <p class="MsoNormal"><span style="font-family:"Times New Roman",serif">On 7/27/2026 2:09 PM, Templin (US), Fred L wrote:<o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Hi Lou, see responses marked with “>>” below:</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Thank you - Fred</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Lou Berger <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a> <br> <b>Sent:</b> Monday, July 27, 2026 9:36 AM<br> <b>To:</b> Templin (US), Fred L <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Cc:</b> <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>; manet <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Subject:</b> Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05</span><o:p></o:p></p> </div> <table class="MsoNormalTable" border="0" cellspacing="3" cellpadding="0" width="100%" style="width:100.0%"> <tbody> <tr> <td style="background:white;padding:.75pt .75pt .75pt .75pt"><br> </td> </tr> </tbody> </table> <p>Fred,<o:p></o:p></p> <p>See in-line below.<o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Times New Roman",serif">On 7/24/2026 10:52 AM, Templin (US), Fred L wrote:</span><o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Hello Lou, follow-ups below:</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Thank you - Fred</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Lou Berger <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a> <br> <b>Sent:</b> Thursday, July 23, 2026 2:33 PM<br> <b>To:</b> Templin (US), Fred L <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Cc:</b> <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>; manet <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Subject:</b> Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05</span><o:p></o:p></p> </div> <p>Fred, <o:p></o:p></p> <p>See inline below -- also for ref I'll use <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03" moz-do-not-send="true">draft-ietf-manet-inet-gap-analysis-03</a> assuming it is the same as the PDF you sent to the list...<o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Times New Roman",serif">On 7/22/2026 12:34 PM, Templin (US), Fred L wrote:</span><o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Hi Lou,<o:p></o:p></pre> <pre> <o:p></o:p></pre> </blockquote> </blockquote> </blockquote> <p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">... <o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p>If this text exists in the document or a reference used by the document, then no. If it does not, then sounds like it should be.<o:p></o:p></p> <p><span style="font-size:11.0pt">FLT >> OK, I will add the above text in the intro.</span><o:p></o:p></p> </blockquote> <p>Thanks.<o:p></o:p></p> <p><span style="font-size:11.0pt">>> done</span><o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">... </span><o:p></o:p></p> <pre> <o:p></o:p></pre> <pre>The discussion appears in the introduction and throughout the problem statements.<o:p></o:p></pre> <pre>Much of the discussion was added in response to your previous set of comments.<o:p></o:p></pre> </blockquote> <p>For me the design choice of a global overly is so significant it should be covered explicitly. to be clear, the following text<o:p></o:p></p> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-5"> <span style="font-family:Consolas;color:#212529">A widely-accepted axiom at the time of this writing suggests that there are more cellphones than people on the planet [<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#STATISTA" moz-do-not-send="true"><span style="color:#0D6EFD">STATISTA</span></a>]. According to Wikipedia, the world population reached 8 billion in 2022 and is expected to reach 10 billion by 2056 [<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#WIKI" moz-do-not-send="true"><span style="color:#0D6EFD">WIKI</span></a>]. Each mobile node that connects to the global public Internet can in some sense be regarded as a singleton "MANET" with the potential to connect still larger MANETs.</span><o:p></o:p></p> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-6"> <span style="font-family:Consolas;color:#212529">MANET Internetworking therefore regards the global Internet as a "network of (mobile ad-hoc) networks" with unrestricted dynamic relationships between distinct MANET local routing regions joined by a Non-Broadcast Multiple Access (NBMA) virtual overlay link manifested through encapsulation. <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#manet-inet" moz-do-not-send="true"><span style="color:#0D6EFD">Figure 1</span></a> illustrates an example of 2 distinct MANET local routing regions connected via the NBMA overlay using the Internet as transit:</span><o:p></o:p></p> <div id="manet-inet"> <div style="margin-top:15.6pt;margin-bottom:15.6pt;box-sizing: border-box;flex-wrap: nowrap;align-items: end;display:flex" id="section-1-7.1"> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::: Global ::)-.</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> X==+======(===================)======+==X</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(: Internet :)-' |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(::::::)-' |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::) .-(::::::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::::::)-. .-(::::::::::::)-.</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> (::::: MANET 1 :::::) (::::: MANET 2 :::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::::::::)-' `-(::::::::::::)-'</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::)-' `-(::::::)-'</span><o:p></o:p></pre> </div> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;background:white"> <span style="font-family:Consolas;color:#212529"><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#figure-1" moz-do-not-send="true"><span style="text-decoration:none">Figure 1</span></a>: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-manet-internetworking" moz-do-not-send="true"><span style="text-decoration:none">MANET Internetworking</span></a> </span><o:p></o:p></p> </div> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-8"> <span style="font-family:Consolas;color:#212529">While the figure depicts just 2 MANET local routing regions, many others worldwide will also want to connect to the virtual link. Since a sustained increase in both the world population and number of mobile wireless devices is certain, MANET Internetworking must therefore accommodate populations on the order of O(10**10) or more. This includes address duplication avoidance through operational assurance since statistical properties alone may be insufficient to avoid duplication in such large populations.</span><o:p></o:p></p> <p>appears to be used to justify the global overlay, but to me it does the opposite, i.e. why would we want an overlay that accommodates O(10**10) or more vs just using the standard Internet.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> A couple of things here. First, BGP scaling in the standard Internet is only able to accommodate O(10**6)</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> prefixes that rarely change. Second, frequent advertisement and withdrawal of mobile network prefixes</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> can cause BGP churn resulting in instability in the global routing system. In other words, BGP is not</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> well suited to supporting mobile Internetworking by itself. With an overlay, the BGP routing service</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> only needs to cover the addresses of the Mobility Anchor Points (MAPs) which are stable nodes</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> not subject to mobility. Within the overlay, the MAPs keep track of Mobile Network Prefix (MNP)</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> to MAP associations which may change dynamically. This is accommodated through a combination</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> of a hierarchical overlay BGP arrangement of the MAPs in combination with dynamic updates to the</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> (reverse) DNS resource records that associate MNPs with MAPs. One final thing is that there need</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> not be only one gigantic global overlay – there could be many smaller overlays operated by</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Mobility Service Providers (MSPs).</span><o:p></o:p></p> </blockquote> <p>It may be we have different understanding of the objectives of "MANET internetwoking". For the purposes are, in priority order, <br> (A) manet nodes being able to initiate and maintain communication with nodes on the rest of the Network<br> (B) Nodes on the Internet being able to initiate and maintain communication with nodes in a MANET<br> (C) for nodes in a MANET being able to initiate and maintain communication with nodes in another MANET<o:p></o:p></p> <p>Do you agree with this list? Do you agree with the priority order?<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I do not agree with a priority order for these, because the requirement is very much use-case</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> specific. For a MANET of nodes that want to browse the Internet, (A) might be a higher priority.</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> For a MANET consisting of sensor nodes, (B) might be the higher priority. For people and their</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> cellphones wanting to call each other, (C) might be the higher priority. I therefore do not want</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> to assign priorities to the problems. I want for any solution proposals to completely address</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> all of the problems while also explaining how they address the gaps.</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <p style="margin:0in">In either (any) case I think the draft needs to clearly state what problem is being solved by MANET Interworking. Then the GAPs can cover the points and limitations above which then can explain why a particular solution architecture is proposed by the document.<o:p></o:p></p> <p style="margin:0in"><b><i><span style="font-size:11.0pt"> </span></i></b><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> New text in the draft clarifies what is meant by a “problem” and what is meant by a “gap”</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> and I do not think it is going to be productive to have endless arguments about whether</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> something is a “problem” vs a “gap”. Please do not try to read too much into these terms.</span><o:p></o:p></p> </blockquote> <p>I'm sorry, I completely disagree. An RFC should stand on its own without having to see the email history to understand it. I'm saying I don't understand the current text as it stands, and that delineating what is the problem, from the existing solutions, from the gaps is needed in this document. I may be in the rough on this, but we'll need to see if others agree or disagree to know this. <o:p></o:p></p> <p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre> <o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Another motivation for an overlay that is not yet addressed in the<o:p></o:p></pre> <pre>document is seamless support for MANET nodes with multiple<o:p></o:p></pre> <pre>interfaces. A natural reaction is to dismiss this as a corner case<o:p></o:p></pre> </blockquote> <pre>I agree that this is an important use case to consider in the problem<o:p></o:p></pre> <pre>statement. I note that the document introduces this concept in Gap 1<o:p></o:p></pre> <pre>and not as it's own problem statement.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Yes, it is listed as a gap that needs to be addressed by solution proposals.<o:p></o:p></pre> </blockquote> <p style="margin:0in">a gap for which of the problem statements? I suspect you are missing one and it should be added. (IMO you can't have a gap without a defined problem, do you see it differently?)<o:p></o:p></p> <p style="mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:0in;margin-left:0in"> <b><i><span style="font-size:11.0pt"> </span></i></b><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> As above, please see the new text I will add to the draft. I do not think an endless</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> argument about what is a problem vs what is a gap will be productive.</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> The gaps apply to any and all of the problem statements and not necessarily in 1x1 correspondence.</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> The gaps are technology requirements that are specific to MANET Internetworking but not currently</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addressed by existing Internetworking technologies. Solution proposals need to explain how they</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> close the gaps.</span><o:p></o:p></p> </blockquote> <p> <o:p></o:p></p> <p>Don't the gaps also need to be clear on what problem they are solving? Said another way, a gap that isn't addressing a stated problem really don't belong in this document.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Lots of solutions both new and existing can claim to already address some or all</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> of the problems but the gap analysis should identify which solutions do so most</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> correctly, completely and/or efficiently.</span><o:p></o:p></p> </blockquote> <p>I think you missed my point -- the document should only have topics in the gaps that are first introduced in the problem statements. I suspect we disagree on this.<o:p></o:p></p> <p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre> <o:p></o:p></pre> <pre> <o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>until<o:p></o:p></pre> <pre>one considers that vast number of cellphones worldwide have<o:p></o:p></pre> <pre>multiple interfaces (cellular, Wi-Fi, bluetooth, and in some cases<o:p></o:p></pre> <pre>even SATCOM) where at least the cellular and Wi-Fi can be seen<o:p></o:p></pre> <pre>as candidate MANET interfaces when disconnected from or<o:p></o:p></pre> <pre>intermittently connected to infrastructure.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>This line of argument does *not* resonate with me as we already have a<o:p></o:p></pre> <pre>very scalable solution that is widely deployed, and that earlier<o:p></o:p></pre> <pre>attempts at MANETs on cell phones (I'll need to dig a bit on where this<o:p></o:p></pre> <pre>was discussed at the IETF, many years ago) didn't really pan out due to<o:p></o:p></pre> <pre>battery consumption.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Modern cellphones have both WiFi and 5G interfaces. WiFi can already run<o:p></o:p></pre> <pre>in "ad-hoc" mode (for some flavor of "ad-hoc") and 3GPP is standardizing<o:p></o:p></pre> <pre>SideLink mode for 5G. The cellphone can therefore become be a MANET<o:p></o:p></pre> <pre>router to do multihop forwarding device-to-device when outside the<o:p></o:p></pre> <pre>context of cellular and/or WiFi infrastructure. Battery consumption is<o:p></o:p></pre> <pre>not an issue when the cellphone is connected to a power source such<o:p></o:p></pre> <pre>as when used inside of a vehicle. Even in dismounted scenarios, however,<o:p></o:p></pre> <pre>having a (limited-duration) multi-hop communications capability may be<o:p></o:p></pre> <pre>deemed worthwhile and could provide a safety-of-life capability such as<o:p></o:p></pre> <pre>for emergency response / disaster relief events. For these reasons, I believe<o:p></o:p></pre> <pre>the modern cellphone (of which there are billions worldwide) will become<o:p></o:p></pre> <pre>an important MANET router platform.<o:p></o:p></pre> </blockquote> <p>Where is this discussed in the document? If it isn't then I think it should be covered in a problem statement.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I can add this, but I believe this document should be kept as brief as possible. I am not in</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> favor of gratuitous expansion that could cause the document to grow without bounds.</span><o:p></o:p></p> </blockquote> <p>From one perspective it by be obvious and gratuitous, from another it may be irrelevant. If not stated, IMO you can't assume any consensus in the WG.<o:p></o:p></p> <p>This is making think of the quote "Everything should be made as simple as possible, but not simpler."<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I have added the above text, but in the introduction and not the problem statement.</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I am willing to consider adding more gaps if someone identifies them, but I do not</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> want to add more problems.</span><o:p></o:p></p> </blockquote> <p>Well this is now a working group document, so each of our voices represent one WG contributor. Document editors have a lot of leeway in document consensus, but it is incumbent on the editor to document WG consensus - not the opinion of the authors. <o:p></o:p></p> <p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre> <o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>I heard you make a related comment just now at the mic that is not<o:p></o:p></pre> <pre>evident (at least to me) in the document -- I think it would be good to<o:p></o:p></pre> <pre>expand on your thoughts on this and make sure that the concepts are<o:p></o:p></pre> <pre>covered in the document.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Does the above help?<o:p></o:p></pre> </blockquote> <p>(covered by previous response.)<o:p></o:p></p> <p> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre> <o:p></o:p></pre> <pre> <o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>An overlay interface<o:p></o:p></pre> <pre>configured over the MANET interfaces can then be used to<o:p></o:p></pre> <pre>orchestrate communications using a singular IP address that<o:p></o:p></pre> <pre>identifies the node as opposed to a distinct IP address for each<o:p></o:p></pre> <pre>MANET interface.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Heretoo, this is something that is commonly done in non-manet networks<o:p></o:p></pre> <pre>without requiring a new global overlay.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>This is referring to a capability sometimes termed "multilink". It allows for<o:p></o:p></pre> <pre>carrying some packet flows over link "A" and others over links "B", "C", etc.<o:p></o:p></pre> <pre>but all using the same IP address in the overlay. Multilink is useful for<o:p></o:p></pre> <pre>fault tolerance, load balancing, matching flows to appropriate link<o:p></o:p></pre> <pre>performance profiles, cost optimization, etc.<o:p></o:p></pre> </blockquote> <p>This is not unique to manets and is not generally solved using an overlay.,<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Multilink is solved by configuring a virtual interface over multiple underlying interfaces</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> which then applies encapsulation. Data communications can then use an IP address</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> assigned to the virtual interface even though the underlying interfaces use different IP</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addresses.</span><o:p></o:p></p> </blockquote> <p>This is a common overlay (aka SD-WAN) solution that is very in vogue today. It isn't the only or even obvious choice to me. (I'm used to seeing 802.1 LACP/LAG, IETF bundling or unnumbered links)<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I should have started my response with: “Within the context of MANET Internetworking,</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> multilink is solved by configuring a virtual interface over multiple underlying interfaces</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> which then applies encapsulation.”. There may be other point solution approaches to</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> multilink, but the one I am referring to is “within the context of MANET Internetworking”,</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> i.e., when the solution also addresses all of the MANET Internetworking problems while</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> best closing the technological gaps.</span><o:p></o:p></p> </blockquote> <p>Where are the details substantiating this perspective? I think the document needs references to support this position.(and I'd really like to understand them, since I don't understand the assertion being made.)<o:p></o:p></p> <p>Lou<o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Another topic that<o:p></o:p></pre> <pre>I think needs to be better explored is the implicit role of DNS ( is<o:p></o:p></pre> <pre>it required or optional, is there complete definition, does it belong in<o:p></o:p></pre> <pre>this document).<o:p></o:p></pre> </blockquote> <pre>Agreed and we can expand on the discussion surrounding the DNS.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>I don't see this discussion in the current document, perhaps the<o:p></o:p></pre> <pre>document needs another section on assumptions/presumed architecture and<o:p></o:p></pre> <pre>rationale for such.<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>The document already does discuss expectations of the DNS service in several<o:p></o:p></pre> <pre>places. I think going into a deeper discussion of the DNS architecture would be<o:p></o:p></pre> <pre>subject for a different document. <o:p></o:p></pre> </blockquote> <p>Do you see providing "the global DNS which returns a (stable) globally-routable IP address for the [mobile] correspondent." to be a solved problem? If so can you add a reference to the solution to the document? If not, I think it should be called out as its own problem.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> As above, I don’t favor gratuitous expansion of this document but will see what I can</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> do about adding a few more words.</span><o:p></o:p></p> </blockquote> <p>great (and same response as above.)<o:p></o:p></p> <p> <o:p></o:p></p> <p>Thanks,<o:p></o:p></p> <p>Lou<o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre> <o:p></o:p></pre> <pre> <o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>I think these issue can be worked before or after document adoption. In<o:p></o:p></pre> <pre>either case, I support having the WG discuss the topics represented in<o:p></o:p></pre> <pre>the draft.<o:p></o:p></pre> </blockquote> <pre>Thank you for bringing this discussion forward!<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Thank you!<o:p></o:p></pre> <pre> <o:p></o:p></pre> <pre>Lou<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Thanks - Fred<o:p></o:p></pre> </blockquote> <p>Thanks!<o:p></o:p></p> <p>Lou<o:p></o:p></p> </blockquote> </blockquote> </div> </blockquote> </body> </html> --------------j0cUNERD0ZIolsP0lh6ypf1m-- --===============2550983959270398392== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============2550983959270398392==--