[manet] Re: Call for adoption: draft-templin-manet-inet-05 (Ends 2026-05-06)

Christopher, I couldn't quite tell from your message whether you thought OLSRv2 and NHDP
were being excluded, but that is very much not the case. Instead, MANET Internetworking
depends on MANET local routing region "islands" running the same MANET routing protocols
they always have - whether that be OLSRv2/NHDP, Babel or something else - and disjoint
islands are then bridged across a global Internetwork "ocean" but without needing to
boil the ocean.

I also don't share the concern that this would be too much work for the working group
to take on. RFC9365 is an existence proof that documents like this can and should be done.

Thank you - Fred

> -----Original Message-----
> From: Christopher Dearlove <[email protected]>
> Sent: Thursday, April 30, 2026 1:56 PM
> To: Donald Eastlake <[email protected]>
> Cc: [email protected] List <[email protected]>; [email protected]; [email protected]
> Subject: [manet] Re: Call for adoption: draft-templin-manet-inet-05 (Ends 2026-05-06)
> 
> I have read the draft - though not in complete detail - and sit in an intermediate position.
> 
> I agree that the issues arising of MANET addressing and, in particular, non-stub working, are important.
> 
> I think that this draft does not start from a clean sheet of paper, but addresses the problem as one to be addressed through an approach of a
> particular form. This I think is where Juliusz is coming from in indicating the document is a mixture of problem statement and solution.
> [Apologies to Juliusz if I have misinterpreted him.]
> 
> It would be acceptable - in my opinion - to say here is the problem, constrained to only considering a certain class of solutions, because to
> consider all possible solutions would - as has previously been demonstrated - get stuck in a rut of too many options. But I think that restriction
> would need to be clearer. And agreed.
> 
> In passing I note that I don’t think what is described as an axiom in the introduction is properly so described. More importantly, in section 4.2
> two methods are described, followed by an “in summary” that I don’t believe is a summary, because it introduce the idea of using NAT at a
> gateway which is not part of the two methods, as both are distributing addresses out to the MANET, but with a NAT that could be avoided.
> Ignoring that “NAT is evil”, a simple NAT approach is probably easier, except for (a) the need to trust the NAT gateway, and (b) the need for
> multiple gateways - as is the case if not a stub network - to communicate. I think that latter aspect is underplayed.
> 
> [With regard to (a) I note that I, and several other past and present WG participants, come from a defence equipment background - though I
> am now retired - where this is not a problem. But there always has been a general reluctance to include military examples in IDs/RFCs, for
> good reasons. But that does mean that things like (a) are not killing details in all cases, but may matter in others.]
> 
> Note that when it come to solutions - which of course is not here - that this starts from different assumptions to NHDP/OLSRv2 (or
> alternatives), which assume addresses are already in place, will be an issue. On the one hand the distribution of addresses does some of the
> work NHDP does, but not all of it, so cannot substitute for it. But on the other hand would provide some information NHDP could use. (Which
> is permitted by NHDP.) This line of thought also indicates that a solution protocol to address handling would need to be ongoing, contain well-
> defined messages, and handle issues such as non-bidirectional links and lossy messages. And cope with cases such a merger of MANETs. A full
> development of a problem statement would, I think, need to summary those - and I’m sure other - points as things a solution would need.
> 
> I’m thus saying that I think there’s a lot of work needed, both in framing and in details. Unlike Juliusz I do not see this as an absolute bar to
> acceptance as a WG document - if adopted and if there is participation, this could be done within a WG, which would require this to be a WG
> draft.
> 
> But the key point there is a lot of work. And Don has indicated that support should indicate willingness to contribute. While I don’t exclude
> that, for me this is - barring a surprise offer of consultancy that I do not expect - essentially a hobby and I cannot guarantee that participation.
> I also have some, but more is needed, of the required background. (I have indicated above that it is in how this would relate to NHDP/OLSRv2
> might be my trinket point.) Thus I cannot give the full support in Don’s terms. However, I can agree the topic remains important - although
> input from more people with real use cases that I no longer have would be good - and there isn’t any other candidate alternative. But a lot of
> work would be needed and I haven’t been the evidence of it being forthcoming. So put me down as only partial but not full support.
> 
> Christopher
> 
> > On 16 Apr 2026, at 03:37, Donald Eastlake via Datatracker <[email protected]> wrote:
> >
> > 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 preference
> > are greatly appreciated. Please reply to all recipients of this message and
> > 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 be
> > 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=draft-templin-manet-inet-05
> >
> > _______________________________________________
> > manet mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> 
> _______________________________________________
> manet mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]