[manet] Re: Extended: Call for adoption: draft-templin-m anet-inet-05
Donald Eastlake <[email protected]> Fri, 29 May 2026 13:09:08 -0400
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <CAF4+nEEiw4pn5=iVt3HMBEZc1-zstC9hKad7ujjkapn_hBzzbQ@mail.gmail.com> |
--===============2404362849751797989== Content-Type: multipart/alternative; boundary="000000000000cac6a70652f7e713" --000000000000cac6a70652f7e713 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fred, See below at <de> On Tue, May 26, 2026 at 2:32=E2=80=AFPM Templin (US), Fred L < [email protected]> wrote: > Donald, please excuse the delayed response and see below for replies to > your comments: > > > > Thank you - Fred > > > > *From:* Donald Eastlake <[email protected]> > *Sent:* Thursday, May 21, 2026 11:05 AM > *To:* manet <[email protected]> > *Cc:* Mobile Ad-hoc Networks Working Group <[email protected]>; > [email protected] > *Subject:* [EXTERNAL] [manet] Re: Extended: Call for adoption: > draft-templin-manet-inet-05 > > 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 documen= t > does require significant work as suggested in most of those other comment= s. > To state the main problem briefly, it needs to better enumerate candidate > solutions and their pros and cons. > > > > >> This comment is consistent with what Don Fedyk said earlier and I agre= e > that an enumeration > > >> of candidate solutions would fit in well with the =E2=80=9CGap Analysi= s=E2=80=9D aspect > of the document title. > > 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. > > > > >> Indeed, the population of candidate end user mobile devices is enormou= s. > > > 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.) > > > > >> I agree your terminology is more current than the understanding I had > when I wrote > > >> this and =E2=80=9CMBSS=E2=80=9D would be the more appropriate term. A = good discussion > of the > > >> various types of IEEE 802.11 service sets is here: > > >> https://en.wikipedia.org/wiki/Service_set_(802.11_network) > <de> Actually, in the 802.11 standard, an MBSS is a particular kind of Wi-Fi mesh also specified in that standard which, while it has been implemented and deployed a bit, is not widely used. I don't think you want to restrict it to that... I think just saying "... a multihop Wi-Fi mesh" might be best. > And I'm not sure how "hotspot" fits into this as a hotspot is usually an > AP (Access Point) supporting infrastructure mode Wi-Fi. > > > > >> Suggested change is to change =E2=80=9Chotspot=E2=80=9D to =E2=80=9CIn= ternet connection sharing > peer=E2=80=9D. > <de> OK. > > > Then again, maybe IBSS was supposed to mean Infrastructure BSS but a wron= g > 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. > > > > >> According to Wikipedia, the infrastructure mode is known simply as > =E2=80=9CBSS=E2=80=9D (no =E2=80=9CI=E2=80=9D or =E2=80=9CM=E2=80=9D).*\* > <de> I haven't looked at Wikipedia and am generally going by the 802.11 standard. There, when it wants to talk about infrastructure mode (an AP and associated non-AP stations), it almost always explicitly says "infrastructure BSS". > Globally "WiFi" -> "Wi-Fi" > > > > >> Yes, we can certainly do this. > <de> I think the preference in the field for "Wi-Fi" is because wi-fi.com is the important Wi-Fi Alliance, while wifi.com has been a specific company= . > Section 2: Terminology > > A number of items in this section relate to a particular solution. > > Suggest the entries be in alphabetic order. > > > > >> Yes, we can do this. > > > Section 3: MANET Use Cases > > This section looks pretty good and probably requires few changes. > > > > >> OK. > > > 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. > > > > >> Yes, we can remove solution-specific terms such as OMNI and MNP. But, > > >> encapsulation and stable end user network prefixes are key elements of > > >>MANET Internetworking independent of specific solutions. > > > 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. > > > > >> The use of the word =E2=80=9Cflow=E2=80=9D is intended to be consisten= t with the IPv6 > definition for > > >> flows as determined by the IPv6 Flow Label plus source and destination > addresses. > > >> There are many published RFCs that discuss the IPv6 flow concept, and > we can > > >> cite some of these if it would be helpful? > <de> Probably that would help. We shall see. > 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 heade= r > while the rules in IEEE 802 favor such empty sections.) > > > > >> Yes, we can fix this. Thanks for the comment. > > > 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. > > > > >> Full global IP addressability is a controversial subject and depending > on who you > > >> ask everyone wants it or no one does. In today=E2=80=99s Internet, NAT= s perform > a crude form > > >> of address hiding by only sharing the public IP address of the NAT > device itself and > > >> not publishing public IP addresses for what could potentially be a > large number > > >> of end user devices behind the NAT. But, there are many who think NATs > should > > >> go away in IPv6 and this document does emphasize the concept of full > global IP > > >> addressability. In comparison, cellular telephony takes the standpoint > that > > >> anyone should be able to dial the phone number of any other cellphone > on the > > >> planet and cause that phone to ring. End user devices have therefore > gotten > > >> smart about detecting and flagging potential spam calls as a way to > support > > >> call screening or =E2=80=9Cfirewalling=E2=80=9D. So, for full global I= P addressability, > end user > > >> devices are advised to implement their own firewalls even if they are > > >> behind network-based firewalls. > <de> I agree that there isn't unanimity about how this should work. Still, I do not think that handling would always be determined by source and destination address and IPv6 flow label. It seems like more of a burden (which might, of course, lead to greater rewards) to create and maintain flow labels than to, for example, set the differentiated services field appropriately. > Although, perhaps, much of it would be related to particular solutions, i= t > seems like there should be something to be said about authentication of > MANET nodes, securing autoconfiguration, etc. > > > > >> Yes, we can update accordingly. > > Section 7: Acknowledgements > > This section currently has 5 paragraphs. However, I think only the 1st an= d > the 4th are appropriate. > > > > >> Will fix. > > > 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 reasonabl= e > 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. > > > > >> Agree =E2=80=93 we can say more about the role of global directory ser= vices in > > >> general and the DNS as a reasonable candidate. > > > <DE> 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 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 > > --000000000000cac6a70652f7e713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Fred,</div><div><br></div><div>Se= e below at <de></div><div><div dir=3D"ltr" class=3D"gmail_signature">= <div dir=3D"ltr"><br></div></div></div></div><div class=3D"gmail_quote gmai= l_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 26, 20= 26 at 2:32=E2=80=AFPM Templin (US), Fred L <<a href=3D"mailto:Fred.L.Tem= [email protected]">[email protected]</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"><div class=3D"msg-170555790905435= 6642"> <div lang=3D"EN-US" style=3D"overflow-wrap: break-word;"> <div class=3D"m_-1705557909054356642WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">Donald, please excuse= the delayed response and see below for replies to your comments:<u></u><u>= </u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">Thank you - Fred<u></= u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><= /span></p> <div style=3D"border-width:medium medium medium 1.5pt;border-style:none non= e none solid;border-color:currentcolor currentcolor currentcolor blue;paddi= ng:0in 0in 0in 4pt"> <div> <div style=3D"border-width:1pt medium medium;border-style:solid none none;b= order-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in"= > <p class=3D"MsoNormal"><b><span style=3D"font-size:11pt;font-family:Calibri= ,sans-serif">From:</span></b><span style=3D"font-size:11pt;font-family:Cali= bri,sans-serif"> Donald Eastlake <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>> <br> <b>Sent:</b> Thursday, May 21, 2026 11:05 AM<br> <b>To:</b> manet <<a href=3D"mailto:[email protected]" target=3D"_blank">ma= [email protected]</a>><br> <b>Cc:</b> Mobile Ad-hoc Networks Working Group <<a href=3D"mailto:manet= [email protected]" target=3D"_blank">[email protected]</a>>; <a href= =3D"mailto:[email protected]" target=3D"_blank">draft-templ= [email protected]</a><br> <b>Subject:</b> [EXTERNAL] [manet] Re: Extended: Call for adoption: draft-t= emplin-manet-inet-05<u></u><u></u></span></p> </div> </div> <p class=3D"MsoNormal"><u></u>=C2=A0<span style=3D"font-size:10pt">Hi,</spa= n></p></div></div></div></div></blockquote><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"><div class=3D"msg-1705557909054356642"><div lang=3D"EN-US= " style=3D"overflow-wrap: break-word;"><div class=3D"m_-1705557909054356642= WordSection1"><div style=3D"border-width:medium medium medium 1.5pt;border-= style:none none none solid;border-color:currentcolor currentcolor currentco= lor blue;padding:0in 0in 0in 4pt"> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> I have reviewed this draft and, as a WG participant, support its adoption.<= br> <br> 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.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> This comment= is consistent with what Don Fedyk said earlier and I agree that an enumera= tion<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> of candidate= solutions would fit in well with the =E2=80=9CGap Analysis=E2=80=9D aspect= of the document title.</span><span style=3D"font-size:10pt"><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.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Indeed, the = population of candidate end user mobile devices is enormous.<u></u><u></u><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> 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, forme= rly 802.11s which has been merged into the 802.11 standard) is sort of the = multihop equivalent of an IBSS.)<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> I agree your= terminology is more current than the understanding I had when I wrote<u></= u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> this and =E2= =80=9CMBSS=E2=80=9D would be the more appropriate term. A good discussion o= f the<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> various type= s of IEEE 802.11 service sets is here:<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> <a href=3D"h= ttps://en.wikipedia.org/wiki/Service_set_(802.11_network)" target=3D"_blank= "> https://en.wikipedia.org/wiki/Service_set_(802.11_network)</a></span></p></= div></div></div></div></div></div></blockquote><div><de> Actually, in= the 802.11 standard, an MBSS is a particular kind of Wi-Fi mesh also speci= fied in that standard which, while it has been implemented and deployed a b= it, is not widely used. I don't think you want to restrict it to that..= . I think just saying "... a multihop Wi-Fi mesh" might be best.= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D= "msg-1705557909054356642"><div lang=3D"EN-US" style=3D"overflow-wrap: break= -word;"><div class=3D"m_-1705557909054356642WordSection1"><div style=3D"bor= der-width:medium medium medium 1.5pt;border-style:none none none solid;bord= er-color:currentcolor currentcolor currentcolor blue;padding:0in 0in 0in 4p= t"><div><div> <p class=3D"MsoNormal"><span style=3D"font-size:10pt">And I'm not sure = how "hotspot" fits into this as a hotspot is usually an AP (Acces= s Point) supporting infrastructure mode Wi-Fi.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Suggested ch= ange is to change =E2=80=9Chotspot=E2=80=9D to =E2=80=9CInternet connection= sharing peer=E2=80=9D.</span></p></div></div></div></div></div></div></blo= ckquote><div><de> OK.=C2=A0</div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex"><div class=3D"msg-1705557909054356642"><div lang=3D"EN-US" st= yle=3D"overflow-wrap: break-word;"><div class=3D"m_-1705557909054356642Word= Section1"><div style=3D"border-width:medium medium medium 1.5pt;border-styl= e:none none none solid;border-color:currentcolor currentcolor currentcolor = blue;padding:0in 0in 0in 4pt"><div><div><p class=3D"MsoNormal"><span style= =3D"font-size:11pt"><u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt">Then again, maybe IBS= S 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 "Infrastr= ucture BSS". At least there is none in the 802.11 standard documents.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> According to= Wikipedia, the infrastructure mode is known simply as =E2=80=9CBSS=E2=80= =9D (no =E2=80=9CI=E2=80=9D or =E2=80=9CM=E2=80=9D).<u>\</u></span></p></di= v></div></div></div></div></div></blockquote><div><de> I haven't = looked at Wikipedia and am generally going by the 802.11 standard. There, w= hen it wants to talk=C2=A0about infrastructure mode (an AP and associated n= on-AP stations), it almost always explicitly says "infrastructure BSS&= quot;.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D= "msg-1705557909054356642"><div lang=3D"EN-US" style=3D"overflow-wrap: break= -word;"><div class=3D"m_-1705557909054356642WordSection1"><div style=3D"bor= der-width:medium medium medium 1.5pt;border-style:none none none solid;bord= er-color:currentcolor currentcolor currentcolor blue;padding:0in 0in 0in 4p= t"><div><div> <p class=3D"MsoNormal"><span style=3D"font-size:10pt">Globally "WiFi&q= uot; -> "Wi-Fi"<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Yes, we can = certainly do this.</span></p></div></div></div></div></div></div></blockquo= te><div><de> I think the preference in the field for "Wi-Fi"= ; is because <a href=3D"http://wi-fi.com">wi-fi.com</a> is the important Wi= -Fi Alliance, while <a href=3D"http://wifi.com">wifi.com</a> has been a spe= cific company.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = class=3D"msg-1705557909054356642"><div lang=3D"EN-US" style=3D"overflow-wra= p: break-word;"><div class=3D"m_-1705557909054356642WordSection1"><div styl= e=3D"border-width:medium medium medium 1.5pt;border-style:none none none so= lid;border-color:currentcolor currentcolor currentcolor blue;padding:0in 0i= n 0in 4pt"><div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt"> Section 2: Terminology<br> <br> A number of items in this section relate to a particular solution.<br> <br> Suggest the entries be in alphabetic order.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Yes, we can = do this.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> Section 3: MANET Use Cases<br> <br> This section looks pretty good and probably requires few changes.<u></u><u>= </u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> OK.<u></u><u= ></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> Section 4: MANET Internetworking Problem Statement and Gap Analysis<br> <br> 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.<u></u= ><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Yes, we can = remove solution-specific terms such as OMNI and MNP. But,<u></u><u></u></sp= an></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> encapsulatio= n and stable end user network prefixes are key elements of<u></u><u></u></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>>MANET Interne= tworking independent of specific solutions.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> 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 techno= logies.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> The use of t= he word =E2=80=9Cflow=E2=80=9D is intended to be consistent with the IPv6 d= efinition for<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> flows as det= ermined by the IPv6 Flow Label plus source and destination addresses.<u></u= ><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> There are ma= ny published RFCs that discuss the IPv6 flow concept, and we can<u></u><u><= /u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> cite some of= these if it would be helpful?</span></p></div></div></div></div></div></di= v></blockquote><div><de> Probably that would help. We shall see.=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"ms= g-1705557909054356642"><div lang=3D"EN-US" style=3D"overflow-wrap: break-wo= rd;"><div class=3D"m_-1705557909054356642WordSection1"><div style=3D"border= -width:medium medium medium 1.5pt;border-style:none none none solid;border-= color:currentcolor currentcolor currentcolor blue;padding:0in 0in 0in 4pt">= <div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt"> Perhaps it is just a quirk of mine but I think there should be a sentence o= r two of text between the 4. header and the 4.1 header saying what is cover= ed in Section 4. (To digress, I believe the RFC editor prefers to avoid suc= h empty sections between a header and the next lower level header while the rules in IEEE 802 favor such emp= ty sections.)<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Yes, we can = fix this. Thanks for the comment.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> Section 6: Security Considerations<br> <br> There seems to be an assumption that all MANETs with connectivity to the In= ternet would want connectivity to each other. That seems implausible. I wou= ld 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.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Full global = IP addressability is a controversial subject and depending on who you<u></u= ><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> ask everyone= wants it or no one does. In today=E2=80=99s Internet, NATs perform a crude= form<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> of address h= iding by only sharing the public IP address of the NAT device itself and<u>= </u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> not publishi= ng public IP addresses for what could potentially be=C2=A0 a large number<u= ></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> of end user = devices behind the NAT. But, there are many who think NATs should<u></u><u>= </u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> go away in I= Pv6 and this document does emphasize the concept of full global IP<u></u><u= ></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> addressabili= ty. In comparison, cellular telephony takes the standpoint that<u></u><u></= u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> anyone shoul= d be able to dial the phone number of any other cellphone on the<u></u><u><= /u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> planet and c= ause that phone to ring. End user devices have therefore gotten<u></u><u></= u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> smart about = detecting and flagging potential spam calls as a way to support<u></u><u></= u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> call screeni= ng or =E2=80=9Cfirewalling=E2=80=9D. So, for full global IP addressability,= end user<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> devices are = advised to implement their own firewalls even if they are<u></u><u></u></sp= an></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> behind netwo= rk-based firewalls.</span></p></div></div></div></div></div></div></blockqu= ote><div><de> I agree that there isn't unanimity about how this s= hould work. Still, I do not think that handling would always be determined = by source and destination address and IPv6 flow label. It seems like more o= f a burden (which might, of course, lead to greater rewards) to create and = maintain flow labels than to, for example, set the differentiated services = field appropriately.</div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= ><div class=3D"msg-1705557909054356642"><div lang=3D"EN-US" style=3D"overfl= ow-wrap: break-word;"><div class=3D"m_-1705557909054356642WordSection1"><di= v style=3D"border-width:medium medium medium 1.5pt;border-style:none none n= one solid;border-color:currentcolor currentcolor currentcolor blue;padding:= 0in 0in 0in 4pt"><div><div><p class=3D"MsoNormal"><span style=3D"font-size:= 10pt"> Although, perhaps, much of it would be related to particular solutions, it = seems like there should be something to be said about authentication of MAN= ET nodes, securing autoconfiguration, etc.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Yes, we can = update accordingly.</span><span style=3D"font-size:10pt"><br> <br> Section 7: Acknowledgements<br> <br> This section currently has 5 paragraphs. However, I think only the 1st and = the 4th are appropriate.<u></u><u></u></span></p> <p class=3D"MsoNormal"><b><i><span style=3D"font-size:11pt"><u></u>=C2=A0<u= ></u></span></i></b></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Will fix.<u>= </u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><br> General:<br> <br> Putting addressing information in the global DNS seems to be a likely eleme= nt of a complete solution although perhaps the draft should mostly speak of= a directory service but also mention that the DNS is a reasonable candidat= e. Having to distribute/agree-on names is better than having=C2=A0to distribute/agree-on addresses but I th= ink it would still have to be done.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> Agree =E2=80= =93 we can say more about the role of global directory services in<u></u><u= ></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11pt">>> general and = the DNS as a reasonable candidate.<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10pt"><u></u>=C2=A0</span><= /p></div></div></div></div></div></div></blockquote><DE> Thanks,<br>D= onald<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<br>=C2=A02386 P= anoramic Circle, Apopka, FL 32703 USA<br>=C2=A0<a href=3D"mailto:d3e3e3@gma= il.com" target=3D"_blank">[email protected]</a><br class=3D"gmail-Apple-inte= rchange-newline"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><div class=3D"msg-1705557909054356642"><div lang=3D"EN-US" style= =3D"overflow-wrap: break-word;"><div class=3D"m_-1705557909054356642WordSec= tion1"><div style=3D"border-width:medium medium medium 1.5pt;border-style:n= one none none solid;border-color:currentcolor currentcolor currentcolor blu= e;padding:0in 0in 0in 4pt"><div><div><p class=3D"MsoNormal"><span style=3D"= font-size:13.3333px">...</span></p></div></div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10pt">On Wed, May 6, 2026 a= t 12:51</span><span style=3D"font-size:10pt;font-family:Arial,sans-serif">= =E2=80=AF</span><span style=3D"font-size:10pt">PM Donald Eastlake <<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<u></u><u></u></span></p> </div> <blockquote style=3D"border-width:medium medium medium 1pt;border-style:non= e none none solid;border-color:currentcolor currentcolor currentcolor rgb(2= 04,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"> <p class=3D"MsoNormal"><span style=3D"font-size:10pt">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</span><span style=3D"font-size:10pt;font-f= amily:Arial,sans-serif">=E2=80=AF</span><span style=3D"font-size:10pt">PM<b= r> 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/" target=3D"_blank">h= ttps://datatracker.ietf.org/doc/bcp78/</a><br> [2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" target=3D"_blank">h= ttps://datatracker.ietf.org/doc/bcp79/</a><br> [3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" 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/" targ= et=3D"_blank">https://datatracker.ietf.org/doc/draft-templin-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" target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-templin-ma= net-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" target=3D"_blank">https://author-tools.ietf.org/iddiff?url2=3Ddraf= t-templin-manet-inet-05</a><u></u><u></u></span></p> </blockquote> </div> </div> </div> </div> </div></blockquote></div></div> --000000000000cac6a70652f7e713-- --===============2404362849751797989== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============2404362849751797989==--