[manet] Draft feedback and comments (was Re: Re: Call fo r adoption: draft-templin-manet-inet-05 (Ends 2026-05-06) )

--===============0283136842675390860==
Content-Type: multipart/alternative; boundary="0000000000008b0109065133832f"

--0000000000008b0109065133832f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Christopher and WG,

comments below,

On Thu, Apr 30, 2026 at 10:57=E2=80=AFPM Christopher Dearlove <
[email protected]> wrote:

> 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 agree too, so we may agree to make it into a WG draft to show the problem
statement only without solutions or recommendations until we finish stating
the important_problem.


>
> 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 indicati=
ng
> the document is a mixture of problem statement and solution. [Apologies t=
o
> Juliusz if I have misinterpreted him.]
>

Where in the draft shows that it has a solution approach?


>
> 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 demonstrat=
ed
> - get stuck in a rut of too many options. But I think that restriction
> would need to be clearer. And agreed.
>

IMHO, we need to state the general manet internetworking problem, not
classes or type of routing or topologies.


>
> In passing I note that I don=E2=80=99t think what is described as an axio=
m in the
> introduction is properly so described. More importantly, in section 4.2 t=
wo
> methods are described, followed by an =E2=80=9Cin summary=E2=80=9D that I=
 don=E2=80=99t 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 th=
e
> MANET, but with a NAT that could be avoided. Ignoring that =E2=80=9CNAT i=
s evil=E2=80=9D, 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.


Yes, I agree, so author to remove/amend.

>
>
> [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 genera=
l
> reluctance to include military examples in IDs/RFCs, for good reasons. Bu=
t
> that does mean that things like (a) are not killing details in all cases,
> but may matter in others.]
>

this draft can exclude military examples if that what you want, but for me
it is better for this WG to exclude military scenarios from civil
scenarios,


>
> 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 n=
ot
> all of it, so cannot substitute for it. But on the other hand would provi=
de
> 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 thin=
k,
> need to summary those - and I=E2=80=99m sure other - points as things a s=
olution
> would need.
>
>
IMHO this draft should not go into solutions, but maybe one
future-work-recommendation end_section, which can help focus on the problem
statement issues, which we can remove at last.

best regards
AB

--0000000000008b0109065133832f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi=C2=A0Christopher and WG,</div><div><br></div><div>=
comments below,</div><br><div class=3D"gmail_quote gmail_quote_container"><=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 30, 2026 at 10:57=E2=80=AF=
PM Christopher Dearlove &lt;<a href=3D"mailto:[email protected]=
m">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">I have read the draft - though not in comp=
lete detail - and sit in an intermediate position.<br>
<br>
I agree that the issues arising of MANET addressing and, in particular, non=
-stub working, are important.<br></blockquote><div><br></div><div>I agree t=
oo, so we may agree to make it into a WG draft to show the problem statemen=
t only without solutions or recommendations until we finish stating the imp=
ortant_problem.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
<br>
I think that this draft does not start from a clean sheet of paper, but add=
resses the problem as one to be addressed through an approach of a particul=
ar form. This I think is where Juliusz is coming from in indicating the doc=
ument is a mixture of problem statement and solution. [Apologies to Juliusz=
 if I have misinterpreted him.]<br></blockquote><div><br></div><div>Where i=
n the draft shows that it has a solution approach?</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It would be acceptable - in my opinion - to say here is the problem, constr=
ained to only considering a certain class of solutions, because to consider=
 all possible solutions would - as has previously been demonstrated - get s=
tuck in a rut of too many options. But I think that restriction would need =
to be clearer. And agreed.<br></blockquote><div><br></div><div>IMHO, we nee=
d to state the general manet internetworking problem, not classes or type o=
f routing or topologies.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
<br>
In passing I note that I don=E2=80=99t 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 =E2=80=9Cin summary=E2=80=9D =
that I don=E2=80=99t 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 d=
istributing addresses out to the MANET, but with a NAT that could be avoide=
d. Ignoring that =E2=80=9CNAT is evil=E2=80=9D, a simple NAT approach is pr=
obably easier, except for (a) the need to trust the NAT gateway, and (b) th=
e need for multiple gateways - as is the case if not a stub network - to co=
mmunicate. I think that latter aspect is underplayed.</blockquote><div><br>=
</div><div>Yes, I agree, so author to remove/amend.=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"> <br>
<br>
[With regard to (a) I note that I, and several other past and present WG pa=
rticipants, come from a defence equipment background - though I am now reti=
red - where this is not a problem. But there always has been a general relu=
ctance 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 m=
ay matter in others.]<br></blockquote><div><br></div><div>this draft can ex=
clude military examples if that what you want, but for me it is better for =
this WG to exclude military scenarios from civil scenarios,=C2=A0</div><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">
<br>
Note that when it come to solutions - which of course is not here - that th=
is starts from different assumptions to NHDP/OLSRv2 (or alternatives), whic=
h 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 som=
e information NHDP could use. (Which is permitted by NHDP.) This line of th=
ought also indicates that a solution protocol to address handling would nee=
d to be ongoing, contain well-defined messages, and handle issues such as n=
on-bidirectional links and lossy messages. And cope with cases such a merge=
r of MANETs. A full development of a problem statement would, I think, need=
 to summary those - and I=E2=80=99m sure other - points as things a solutio=
n would need.<br>
<br></blockquote><div><br></div><div>IMHO this draft should not go into sol=
utions, but maybe one future-work-recommendation end_section, which can hel=
p focus on the problem statement issues, which we can remove at last.</div>=
<div>=C2=A0</div><div>best regards</div><div>AB</div></div></div>

--0000000000008b0109065133832f--


--===============0283136842675390860==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp
bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK

--===============0283136842675390860==--