Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 20 August 2022 20:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1886BC14F743 for <6lo@ietfa.amsl.com>; Sat, 20 Aug 2022 13:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.006
X-Spam-Level:
X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=sandelman.ca
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 QhpE5vlhto7q for <6lo@ietfa.amsl.com>; Sat, 20 Aug 2022 13:13:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 329D8C14F742 for <6lo@ietf.org>; Sat, 20 Aug 2022 13:13:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7119A18B98; Sat, 20 Aug 2022 16:33:23 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qmsswmpyar6a; Sat, 20 Aug 2022 16:33:22 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 52163182E3; Sat, 20 Aug 2022 16:33:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1661027602; bh=C5Wnizz7NHT6TjJ1mFktBKDGbkVoYMTUOPipsnyT7ps=; h=From:To:Subject:In-Reply-To:References:Date:From; b=l1Th0taaq3RmZmjuf04j+v4qA1Y7SBnwIIV9aI8dVKfnL7rLS21oPvMqEJPvZi4ZH UIXzwUvBP2jPgSt/fMEF/H7E3cRn6S9NrYcbw6F8lxRTYOWorgQE+o2nyOrTdIUJsM cZsR0DyEVREf/NhpGCs4yfW4Eo7DByc/bm8unY+phW87qKzuRSe3PO4rQv1auREWbI sLf+3pBM0znousswLYRa7jGZIlqVFyzVor+eeC/m7lzdJr14+ISGZneBFe/SYb+94d vbICmc+Y75u7IkTsa9Hpz8aIalz3u2R+Sb1852uD7+k8wOW9XqJ2dSkB0TT6i44Bx1 JWq739NS9cVhQ==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17E97147; Sat, 20 Aug 2022 16:13:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alexander Pelov <a@ackl.io>, 6lo <6lo@ietf.org>
In-Reply-To: <CACQW0EpiNuKMShika=R7Moz0n+ehgwzoiVCS=AUz5wG7ChBEeA@mail.gmail.com>
References: <91f63618-ebbc-cdc6-b38e-d7b5a3d3e850@gmail.com> <5497C7A1-231D-414E-BCEF-956BB65298C2@gmail.com> <CACQW0Eq3_oFijtuKNcPV9rHrpiwPejBEjyVcktv0xACQGw-oSg@mail.gmail.com> <6066dc1b32a5406a94b0761a8b5d1251@huawei.com> <d640c88034da4c97817593ea6a7d6f75@huawei.com> <CACQW0EpiNuKMShika=R7Moz0n+ehgwzoiVCS=AUz5wG7ChBEeA@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 20 Aug 2022 16:13:34 -0400
Message-ID: <21673.1661026414@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/PgmrMT5xKs4HptNzy0_NWtqAvjo>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2022 20:13:42 -0000

Alexander Pelov <a@ackl.io> wrote:
    > I'd be happy to discuss specific scenarios/use-cases that come from a
    > real-world need.

    > In any case, I think these are required before accepting the draft as a
    > WG item.

Well, there really aren't any formal requirements to adopt a draft as a WG
item.  It's a decision reserved for the WG chairs to make in any way that
they see fit. Typically, they observe a consensus that the WG wants to work
on it.
That means that the WG is willing to spend agenda time on the document.

But, over time the Adoption call has become overly bureaucratic due to the
belief that documents that are adopted MUST be published.  This has resulted
in the adoption call being overly litigated.

See https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-rfc7221bis/ for
some opinions and of course RFC7221.

However, like you, I am not feeling very confident that there are real use
cases, and that this document it not simply the result of researchers who
looked at RFC6550, did a page count and decided it must be hard and that
it shouldn't be so difficult, so let's invent something new, even though we
have no actual use case.
That is the research institute way, where success is measured in papers
published, rather than products shipped.

This is not the IETF way.  The IETF way is to see that there is a problem
that can not be solved with existing technology, write a paper about the
failures of the existing things, having tried them, and then do some
experiments to see what else could be done.  Write some (running) code, do experiments
and then report on it in an attempt to get rough consensus.

I've actually seriously considered the datacenter situation.  It's a core use
for ANIMA's ACP.  I can unicast some presentations, but I'm not sure that I
want the links public yet.

I like the idea of an incrementally deployable swarm of management devices
powered by the network.  I have been thinking about how to do PoE in/out in a
daisy chain/tree. I hadn't thought about using the 100baseT1 that the
automotive industry likes.

One concern that I have with NSA is that I think the network can get renumbered
whenever there are new devices.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide