[manet] Re: Extended: Call for adoption: draft-templin-m anet-inet-05
Donald Eastlake <[email protected]> Thu, 21 May 2026 14:05:13 -0400
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <CAF4+nEH-KTaGvz3oC+fxdABkcufccta-_+F4Pn5nVWS6JRKoXw@mail.gmail.com> |
--===============1765944904535028786== Content-Type: multipart/alternative; boundary="000000000000a83826065257c1fb" --000000000000a83826065257c1fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed this draft and, as a WG participant, support its adoption. I generally support the comments that others have made, that this document does require significant work as suggested in most of those other comments. To state the main problem briefly, it needs to better enumerate candidate solutions and their pros and cons. Here are a few brief new comments of mine: Section 1: Introduction The 10**10 scaling goal is interesting and should be a factor in evaluating alternative solutions. A minor point: It says "a cellphone providing a hotspot for a multihop WiFi IBSS". As far as I know, an IBSS (Independent Basic Service Set) is an arrangement where more than one Wi-Fi station are pairwise connected in a full mesh, that is, I think "IBSS" and "multihop" are mutually inconsistent. (A Wi-Fi mesh (MBSS, formerly 802.11s which has been merged into the 802.11 standard) is sort of the multihop equivalent of an IBSS.) And I'm not sure how "hotspot" fits into this as a hotspot is usually an AP (Access Point) supporting infrastructure mode Wi-Fi. Then again, maybe IBSS was supposed to mean Infrastructure BSS but a wrong acronym was used. As far as I can tell,there is no single acronym that stands for "Infrastructure BSS". At least there is none in the 802.11 standard documents. Globally "WiFi" -> "Wi-Fi" Section 2: Terminology A number of items in this section relate to a particular solution. Suggest the entries be in alphabetic order. Section 3: MANET Use Cases This section looks pretty good and probably requires few changes. Section 4: MANET Internetworking Problem Statement and Gap Analysis Decomposing the problem into 7 problems is a good framework. But, as others have commented, there is text in Section 4 that is too solution oriented, such as the invocation of "OMNI encapsulation" and MNP etc. In 4.6, why are virtual circuits per-flow? Per-QoS seems reasonable. In any case, it seems like these would be alternatives for some particular technologies. Perhaps it is just a quirk of mine but I think there should be a sentence or two of text between the 4. header and the 4.1 header saying what is covered in Section 4. (To digress, I believe the RFC editor prefers to avoid such empty sections between a header and the next lower level header while the rules in IEEE 802 favor such empty sections.) Section 6: Security Considerations There seems to be an assumption that all MANETs with connectivity to the Internet would want connectivity to each other. That seems implausible. I would think there might be small sets of MANETs that only want to talk to each other and might even want to obscure their existence from those outside the set. Although, perhaps, much of it would be related to particular solutions, it seems like there should be something to be said about authentication of MANET nodes, securing autoconfiguration, etc. Section 7: Acknowledgements This section currently has 5 paragraphs. However, I think only the 1st and the 4th are appropriate. General: Putting addressing information in the global DNS seems to be a likely element of a complete solution although perhaps the draft should mostly speak of a directory service but also mention that the DNS is a reasonable candidate. Having to distribute/agree-on names is better than having to distribute/agree-on addresses but I think it would still have to be done. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Wed, May 6, 2026 at 12:51=E2=80=AFPM Donald Eastlake <[email protected]> = wrote: > Hi, > > There has been some discussion of this call for adoption but the > chairs would welcome more feedback. We have decided to extend the WG > Adoption call, which would have ended today, for two weeks through 20 > May 2026. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > > ---------- Forwarded message --------- > From: Donald Eastlake via Datatracker <[email protected]> > Date: Wed, Apr 15, 2026 at 10:37=E2=80=AFPM > Subject: Call for adoption: draft-templin-manet-inet-05 (Ends 2026-05-06) > To: <[email protected]>, <[email protected]>, > <[email protected]> > > > This message starts a manet WG Call for Adoption of: > draft-templin-manet-inet-05 > > This Working Group Call for Adoption ends on 2026-05-06 > > Abstract: > [RFC2501] defines a MANET as "an autonomous system of mobile nodes. > The system may operate in isolation, or may have gateways to and > interface with a fixed network" (such as the global public Internet). > This document presents a MANET Internetworking problem statement and > gap analysis. > > Please reply to this message and indicate whether or not you support > adoption > of this Internet-Draft by the manet WG. Comments to explain your preferen= ce > are greatly appreciated. Please reply to all recipients of this message a= nd > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can b= e > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-templin-manet-inet/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-templin-manet-inet-05 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=3Ddraft-templin-manet-inet-05 > --000000000000a83826065257c1fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi,</div><div><br>I have reviewed this draft and, as = a WG participant, support its adoption.<br><br>I generally support the comm= ents that others have made, that this document does require significant wor= k as suggested in most of those other comments. To state the main problem b= riefly, it needs to better enumerate candidate solutions and their pros and= cons.<br><br>Here are a few brief new comments of mine:<br><br>Section 1: = Introduction<br><br>The 10**10 scaling goal is interesting and should be a = factor in evaluating alternative solutions.<br><br>A minor point: It says &= quot;a cellphone providing a hotspot for a multihop WiFi IBSS". As far= as I know, an IBSS (Independent Basic Service Set) is an arrangement where= more than one Wi-Fi station are pairwise connected in a full mesh, that is= , I think "IBSS" and "multihop" are mutually inconsiste= nt. (A Wi-Fi mesh (MBSS, formerly 802.11s which has been merged into the 80= 2.11 standard) is sort of the multihop equivalent of an IBSS.) And I'm = not sure how "hotspot" fits into this as a hotspot is usually an = AP (Access Point) supporting infrastructure mode Wi-Fi. Then again, maybe I= BSS was supposed to mean Infrastructure BSS but a wrong acronym was used. A= s far as I can tell,there is no single acronym that stands for "Infras= tructure BSS". At least there is none in the 802.11 standard documents= . Globally "WiFi" -> "Wi-Fi"<br><br>Section 2: Termi= nology<br><br>A number of items in this section relate to a particular solu= tion.<br><br>Suggest the entries be in alphabetic order.<br><br>Section 3: = MANET Use Cases<br><br>This section looks pretty good and probably requires= few changes.<br><br>Section 4: MANET Internetworking Problem Statement and= Gap Analysis<br><br>Decomposing the problem into 7 problems is a good fram= ework. But, as others have commented, there is text in Section 4 that is to= o solution oriented, such as the invocation of "OMNI encapsulation&quo= t; and MNP etc.<br><br>In 4.6, why are virtual circuits per-flow? Per-QoS s= eems reasonable. In any case, it seems like these would be alternatives for= some particular technologies.<br><br>Perhaps it is just a quirk of mine bu= t I think there should be a sentence or two of text between the 4. header a= nd the 4.1 header saying what is covered in Section 4. (To digress, I belie= ve the RFC editor prefers to avoid such empty sections between a header and= the next lower level header while the rules in IEEE 802 favor such empty s= ections.)<br><br>Section 6: Security Considerations<br><br>There seems to b= e an assumption that all MANETs with connectivity to the Internet would wan= t connectivity to each other. That seems implausible. I would think there m= ight be small sets of MANETs that only want to talk to each other and might= even want to obscure their existence from those outside the set.<br><br>Al= though, perhaps, much of it would be related to particular solutions, it se= ems like there should be something to be said about authentication of MANET= nodes, securing autoconfiguration, etc.<br><br>Section 7: Acknowledgements= <br><br>This section currently has 5 paragraphs. However, I think only the = 1st and the 4th are appropriate.<br><br>General:<br><br>Putting addressing = information in the global DNS seems to be a likely element of a complete so= lution although perhaps the draft should mostly speak of a directory servic= e but also mention that the DNS is a reasonable candidate. Having to distri= bute/agree-on names is better than having=C2=A0to distribute/agree-on addre= sses but I think it would still have to be done.</div><div><br></div><div><= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">Thanks,<br>Donald<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>=C2=A0Donald E. Eastlake 3rd = =C2=A0 +1-508-333-2270 (cell)<br>=C2=A02386 Panoramic Circle, Apopka, FL 32= 703 USA<br>=C2=A0<a href=3D"mailto:[email protected]" target=3D"_blank">d3e3= [email protected]</a></div></div><br></div><br><div class=3D"gmail_quote gmail_q= uote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 6, 2026 a= t 12:51=E2=80=AFPM Donald Eastlake <<a href=3D"mailto:[email protected]">= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-left:1ex">Hi,<br> <br> There has been some discussion of this call for adoption but the<br> chairs would welcome more feedback. We have decided to extend the WG<br> Adoption call, which would have ended today, for two weeks through 20<br> May 2026.<br> <br> Thanks,<br> Donald<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D<br> =C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)<br> =C2=A02386 Panoramic Circle, Apopka, FL 32703 USA<br> =C2=A0<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a><br> <br> ---------- Forwarded message ---------<br> From: Donald Eastlake via Datatracker <<a href=3D"mailto:[email protected]= g" target=3D"_blank">[email protected]</a>><br> Date: Wed, Apr 15, 2026 at 10:37=E2=80=AFPM<br> Subject: Call for adoption: draft-templin-manet-inet-05 (Ends 2026-05-06)<b= r> To: <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a>>, <<a href=3D"mailto:[email protected]" target=3D"_blank">man= [email protected]</a>>,<br> <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>><br> <br> <br> This message starts a manet WG Call for Adoption of:<br> draft-templin-manet-inet-05<br> <br> This Working Group Call for Adoption ends on 2026-05-06<br> <br> Abstract:<br> =C2=A0 =C2=A0[RFC2501] defines a MANET as "an autonomous system of mob= ile nodes.<br> =C2=A0 =C2=A0The system may operate in isolation, or may have gateways to a= nd<br> =C2=A0 =C2=A0interface with a fixed network" (such as the global publi= c Internet).<br> =C2=A0 =C2=A0This document presents a MANET Internetworking problem stateme= nt and<br> =C2=A0 =C2=A0gap analysis.<br> <br> Please reply to this message and indicate whether or not you support adopti= on<br> of this Internet-Draft by the manet WG. Comments to explain your preference= <br> are greatly appreciated. Please reply to all recipients of this message and= <br> include this message in your response.<br> <br> Authors, and WG participants in general, are reminded of the Intellectual<b= r> Property Rights (IPR) disclosure obligations described in BCP 79 [2].<br> Appropriate IPR disclosures required for full conformance with the provisio= ns<br> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.<br> Sanctions available for application to violators of IETF IPR Policy can be<= br> found at [3].<br> <br> Thank you.<br> [1] <a href=3D"https://datatracker.ietf.org/doc/bcp78/" rel=3D"noreferrer" = target=3D"_blank">https://datatracker.ietf.org/doc/bcp78/</a><br> [2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" rel=3D"noreferrer" = target=3D"_blank">https://datatracker.ietf.org/doc/bcp79/</a><br> [3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" rel=3D"noreferrer= " target=3D"_blank">https://datatracker.ietf.org/doc/rfc6701/</a><br> <br> The IETF datatracker status page for this Internet-Draft is:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-templin-manet-inet/" rel= =3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draft-te= mplin-manet-inet/</a><br> <br> There is also an HTMLized version available at:<br> <a href=3D"https://datatracker.ietf.org/doc/html/draft-templin-manet-inet-0= 5" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/ht= ml/draft-templin-manet-inet-05</a><br> <br> A diff from the previous version is available at:<br> <a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-templin-manet-= inet-05" rel=3D"noreferrer" target=3D"_blank">https://author-tools.ietf.org= /iddiff?url2=3Ddraft-templin-manet-inet-05</a><br> </blockquote></div> --000000000000a83826065257c1fb-- --===============1765944904535028786== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============1765944904535028786==--