Re: Next steps for rfc6874bis

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Mon, 16 August 2021 14:02 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 AFDE53A143B for <ipv6@ietfa.amsl.com>; Mon, 16 Aug 2021 07:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR4avWqMNmjd for <ipv6@ietfa.amsl.com>; Mon, 16 Aug 2021 07:02:56 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:981:201c:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8C63A1439 for <ipv6@ietf.org>; Mon, 16 Aug 2021 07:02:54 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1mFdCV-0000HvC; Mon, 16 Aug 2021 16:02:51 +0200
Message-Id: <m1mFdCV-0000HvC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Subject: Re: Next steps for rfc6874bis
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <667b9ebb-3c99-8c5b-fa57-796e5bb84b4c@gmail.com> <3269d750-2e97-9bb2-550a-94b652d689a4@foobar.org> <1ea4c0e5-fd7c-c39a-28a6-681f6c40af8c@gmail.com> <27470.1628692112@localhost> <m1mFccG-0000I3C@stereo.hq.phicoh.net> <20210816134703.meb4pfloazkco22n@anna.jacobs.jacobs-university.de>
In-reply-to: Your message of "Mon, 16 Aug 2021 15:47:03 +0200 ." <20210816134703.meb4pfloazkco22n@anna.jacobs.jacobs-university.de>
Date: Mon, 16 Aug 2021 16:02:51 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/THOxshejTI0kFy05mYQqOzbOYPA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 16 Aug 2021 14:02:58 -0000

>10 years? 20 years? This address format is out in the wild for years
>now. Lets look at an example: changing the IP address formats defined
>in RFC 6991 (published 2013, updating RFC 6021 published 2010) would
>likely be a non-backwards compatible change and thus all YANG modules
>importing from RFC 6991 may need updates and then these updates need
>to be implemented and finally shipped and deployed.

I assume we start with an RFC that says that IPv6 address parsers SHOULD
accept '-' in addition to '%'.

I don't see how that would invalidate YANG modules.

Next step, in some years, to to change the canonical IPv6 address
representation to use '-'.

Obviously, that would trigger the need to update YANG modules, but old ones
will continue to work.

At some point we can make '%' to be something the MAY be supported. But I
assume that will only happen after we have mostly switched to the new
character.

Is this annoying maintainance work, yes. But being stuck forever with the
wrong character is also not something the wider internet community is going
to appreciate.