Re: [IPv6] WG adoption for https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ ?

Lorenzo Colitti <lorenzo@google.com> Wed, 11 January 2023 09:34 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9408C151540 for <ipv6@ietfa.amsl.com>; Wed, 11 Jan 2023 01:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.597
X-Spam-Level:
X-Spam-Status: No, score=-22.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBMECsdLGv3X for <ipv6@ietfa.amsl.com>; Wed, 11 Jan 2023 01:33:58 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80153C15153D for <ipv6@ietf.org>; Wed, 11 Jan 2023 01:33:58 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id t10so4510204vsr.3 for <ipv6@ietf.org>; Wed, 11 Jan 2023 01:33:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LyujSYxtu5WOq59f1R4oxwARzhQi7p9CcxGCPpC3xbI=; b=cqkj3v+uAv/YFdwymj0cWmT1Q/Cadz/doJ7SIsTmaIM9L9XiZmhiy638rz2POtHOJR fYqixafpVYV52Sqvll/FzrQs/MjHywKiLiBF39OQOxZKZiNL2vdhzCHO5xBf9l2TK/Ml zr+7NZ2m7L6VsEfjdcvqZJOq4O2MX8TibRKf+j0p64PD4MsHEzR7QYoPm1zUYxFpq9+H sTs+13C5WbdHZ0CvajbDtGw2WwF6TC6Y9IE4oKHYcdwf2TXnZMcvljv/eX0Qw6XF6l3G BMnkd+loDxeL+e0ZDMRc3gssZjxrn1dFtiNS78KlvaH5uk1X6z/MJzXWyqp3Fqy6mUq6 IRTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LyujSYxtu5WOq59f1R4oxwARzhQi7p9CcxGCPpC3xbI=; b=PYg7DSeUaeSj6lXaZlOgrc73FAGJPlNYkYuYtXuWjO7mVwhkGJgkkvybl9SWksQG6Z rSkCWcW2mOTXT/5a7/hHSH76RrXnjOSfF+o/z1JFKB3b/vYfIa5nUTv3yfJTKhnWSdYa yj8OJ7r/HbQtE2+476HwD7BEbua4xv+ILO1SuD+VsZWx9rmEzV2XDud6BeQD0Us54CBu 9c3zdYUKWgDFV2OVUvkFTRK4yvGK7mf6ASurYjW6RFYnRoskkDcuU0VPyUn4i1TJUEfZ QLjIC3ENSTBWh+0Q/KRCkxTEKr0wxQ8QdhBcvUVKy3rO/M4FS0eCaXOQXNkP4+vflPW2 EODQ==
X-Gm-Message-State: AFqh2koNJjvoMWlb1Y3Qk7RCjDEuvmMI9TUP5UAzDyHo4FJr7VVtOogU DFmmxQL7EXnUfQ6nrnnyWUZfDu7M9FY6DDH4u1JdY2XMMhdgDoh7
X-Google-Smtp-Source: AMrXdXvybZZZrRiFtc6ceIprL+cLFXos5oZQ5KiRGJjoqT57V/NgUF52X3UyJySpjCb3G6c5u7c7JGxjmUuAdbSmjbw=
X-Received: by 2002:a67:e11d:0:b0:3c6:e398:1da2 with SMTP id d29-20020a67e11d000000b003c6e3981da2mr8423792vsl.52.1673429637144; Wed, 11 Jan 2023 01:33:57 -0800 (PST)
MIME-Version: 1.0
References: <CO1PR11MB4881DC1AD7D75BEDAB4980DAD8FA9@CO1PR11MB4881.namprd11.prod.outlook.com> <CO1PR11MB488107BA21A6B9FA55C2F61BD8FC9@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488107BA21A6B9FA55C2F61BD8FC9@CO1PR11MB4881.namprd11.prod.outlook.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 11 Jan 2023 18:33:45 +0900
Message-ID: <CAKD1Yr1ioP2c0v+n-dFo4F+Mf3QJQdmYmJga3aJsGiLeW=Uj2g@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "IPv6 WG (ipv6@ietf.org)" <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000014930d05f1f9b3b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_eBfZBiXsFNrMuAWPCWQRJdZ-ns>
Subject: Re: [IPv6] WG adoption for https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ ?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2023 09:34:00 -0000

While this document makes for interesting reading, it does not seem to be
appropriate for 6man. If you look at the 6man charter
<https://datatracker.ietf.org/doc/charter-ietf-6man/>, the group is
responsible for maintaining and advancing the IPv6 specifications. This
document doesn't seem to be doing that - it's describing how things can be
deployed.

But more than that - after reading the document it's not clear to me what
the purpose of the document is, and whether it should end up being
published by IETF consensus at all. Is the goal of the document to advocate
changes in the specs? But if so, it should contain a clear statement of a
problem to be solved (and should probably be in v6ops). Is it to describe
how things can be deployed? But if so, it should probably focus on a
narrower set of scenarios, and go into more detail on each of them, with
the goal of making some recommendations of what to use where (which again
would be appropriate in v6ops). But that doesn't seem to be the case
either. After reading through the document it feels that what it comes
closest to is a tutorial for how some types of ND can be used. But these
are probably not the only way these can be used; the document tries to
cover so much ground that it does not seem to be possible for it to be
comprehensive.

Your email states that the goal of the document is to explain why certain
choices were made. That's definitely interesting reading, though I'd guess
it will inevitably end up being a matter of opinion; WGs make choices for
lots of reasons, many of them not directly technically motivated (e.g.,
compromise between proponents of different technologies, compromise between
implementations, etc.) and it seems difficult of impossible to
authoritatively describe those reasons after the fact.

It definitely seems interesting as an individual submission - you were
there when all these RFCs were written, and your perspective on them is
certainly interesting - but perhaps not as a WG doc?

On Wed, Jan 11, 2023 at 5:54 PM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Gentle reminder:
>
> Please let us know if the addition of the new bit in the RPL option causes
> any issue on the 6MAN side (we expect not).
>
> All the best to you all;
>
> Pascal
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: jeudi 5 janvier 2023 14:39
> > To: IPv6 WG (ipv6@ietf.org) <ipv6@ietf.org>
> > Subject: WG adoption for
> https://datatracker.ietf.org/doc/draft-thubert-6man-
> > ipv6-over-wireless/ ?
> >
> > Dear chairs and all:
> >
> > At the last IETF meeting in London I presented
> draft-thubert-6man-ipv6-over-
> > wireless which describes how IPv6 can be deployed over wireless
> networks, and
> > suggests that the L3 models of Links and Subnets can be decoupled from L2
> > connectivity, e.g., when the lower layer does not provide transitive
> > connectivity, which is the case of most wireless networks.
> >
> > In MANET and 6lo networks, it is usual that the L3 link abstraction is
> based
> > on P2P even when L2 may reach more than one node. The subnet can still
> be a
> > /64, though the membership becomes an administrative decision as opposed
> to
> > mapping a broadcast domain as is typically done with wires. And routing
> > inside the subnet replaces the need for traditional IPv6 ND which 1) is
> not
> > designed for NBMA and 2) is inefficient in terms of power, spectrum, and
> > reliability (e.g., for DAD).
> >
> > The doc was written to explain to a larger audience why those choices
> were
> > made; it is now complete and I got positive feedback, including from
> Brian at
> > v6ops before the break, that it should be published; would the chairs now
> > consider calling for adoption now - or else why not ?
> >
> > All the best;
> >
> > Pascal
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>