Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

[Lorenzo Colitti <[e-mail]>]

I gave this feedback already at adoption call time, and I think it needs to
be addressed before we can talk about publication.

tl;dr: this document is too rambling and vague, and tries to do too many
things, to be published in anything like its current form, or even to be
productively reviewed by the WG.

First: it's much too long and has way too much content in it to be a
"framework", which is what it calls itself at the moment. Last I looked at
the draft (before adoption) it was basically a rambling document that
covered the history of technologies such as ND, DAD, and various wireless
link layers, and discussed some of the design tradeoffs. That may be OK for
a history document (assuming we want to publish one), but it's not OK for a
framework or for any kind of standard. A standard must have a clear problem
statement and must discuss a clear solution. One important reason why it
cannot be too long is that in a standard, correctness is paramount, and if
the document is too long it's very difficult for WG participants to review
it and make it correct. If we want this to be a standard, or lead to the
development of standards later on, then it must be short enough to
reasonably review.

This document also really needs to decide whether it's defining a framework
and changing the standards, or not. To provide just one example: are
statements such as "the IPv6 routers that serve a Subnet must form a
connected dominating set such that every host in the Subnet is connected to
at least one router and the routers are connected to one another directly"
normative? If they are, then what does that mean in practice to protocols,
implementations, and bits in the wire? We cannot publish an informational
draft that vaguely defines a "framework" unless we have actual standards
and protocol definitions that explain how things work. The reason we cannot
do that is that when we try to encode the framework into actual standards,
we may very well find out that the framework *cannot* actually be
implemented as is.

Another issue is that the draft presents as facts statements that are
vague/handwavy or are merely opinions instead of facts, or sometimes just
incorrect. For example, "All IP Links are abstracted as Point-to-Point"
might sound good in theory but in practice most existing wifi networks rely
on broadcast/multicast and many applications will fall over without it. But
again, there are loads of these statements, and while the document remains
so long, it's hard to even review all of it.

Also, please replace "ND classic" with "Neighbor Discovery" everywhere.
There is no such thing as "ND classic". There is only ND.

On Wed, May 24, 2023 at 3:52 PM Pascal Thubert (pthubert) <pthubert=
[e-mail]> wrote:

> Dear WG:
>
>
>
> We adopted that draft to publish it as informational; it is at the same
> time a state of the art, a problem statement, and an applicability
> statement.
>
>
>
> The issues are clear and present, see also
> draft-ietf-v6ops-nd-considerations. We face customer situations where
> clients are not properly served because ND snooping fails to locate them
> all with a painful regularity. This impacts all sorts of situations, from
> wireless to fabrics / EVPN.
>
>
>
> Note that This is indeed very related to the SLAAC operation and IPv4 is
> mostly immune. Meaning that the IPv6 experience is of more broadcasts and
> less reliability.
>
>
>
> In order to progress in solving the issues raised, it makes sense to
> publish soon and move on. The draft has been progressing as an individual
> submission for a long time and it is mostly complete, IMHO. So my intent is
> to ask for WGLC sooner than later. To get there, reviews would be highly
> appreciated.
>
>
>
> Many thanks in advance : )
>
>
>
> Pascal
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>