Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Bernard Aboba <bernard.aboba@gmail.com> Fri, 28 February 2020 01:05 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28FD3A0AC5; Thu, 27 Feb 2020 17:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2JfMUqjiSeta; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17FA3A0A6D; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id y3so397065uae.3; Thu, 27 Feb 2020 17:05:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q9jxTKMpacA61yqy7dA1yTRZVl+Ts1439naph9dUjc0=; b=S1OhCE6aWOCtApmHCDzupOWdSht843dGIWsXbtQOwv1EKywtyWNzvNEIVNOYuH2Tgq S32B2N/QCdz/IUscd/BmMAl8mULCHhg3a9YiiMgj/ckpksQCBlR5bKx4RojDrkqndl+g 06aAAFIC9TVauy8AmzTdziudUcD5OFhgxBnJ6xuJple7caQKIKK7ewB3/uawQvmf92v0 n4dH9I8CW/IH8bfnZGKdnxIkHP/ezn/2u55DFHGKewauNhamqyNiwU+whAHloXfZ/9Vi teRmqC6GGE4vZG15gjm058TCeQmfBuNLvqAxcVeu0IZYtaKHTbRWH/vAKjlrfsGUIlMA ov4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q9jxTKMpacA61yqy7dA1yTRZVl+Ts1439naph9dUjc0=; b=eRHo2TY523yvdGIJkRORrpe8eX3Q0zCEz2k9+71G0omSM8hGnYOafW/FyR2iG9zHL+ X4ribfenSBmMj92z8RzDD4IKg0uWBPZGd6wr1H3nBuCScW8OPbUCtE8//AXX8tfFy0gv B0xlIpyjFC0mhaUe62zYqDLKPdqouGwLPEFKbksWep6LpxDg2h0UkQhMi1B/EZlslXXI ON8TRBFfdUyuV3rgEGWB0/qNykN1U5jebL5WwN8XyeR7WUNrZLk09Ef4przP4wuEo5fn qqMuHqWsyCW5RRKaTyiVr3sPdHMMk/zbcWVe/oXy92sp04nsmpTpJ5a9wXj4v3K6ar78 IOXw==
X-Gm-Message-State: ANhLgQ33lSB0284X6fULt+7oOQxQI+9G7YBBIVLbfXzKTBHLxzXBO5Z4 tm50sjE26BYC/Fa3F0+WylJWMoYMXeGHEabVEKM=
X-Google-Smtp-Source: ADFU+vtCQkxc8ItVBjb5hADiwfO5wJ4BLOCERMzNtpuDH5wYsuMmjOhyR/LwoLQXaufxz6IotdFj4VH72+FmNZ+KcK4=
X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr855891uar.62.1582851920602; Thu, 27 Feb 2020 17:05:20 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CAOW+2dsNQLsyw3ohgYhXNBGA_Ziruh+z5ieQB3a7bhPrce6-OQ@mail.gmail.com> <caee3e5c-f6f6-2cc8-420f-1c8e4f0afb99@si6networks.com>
In-Reply-To: <caee3e5c-f6f6-2cc8-420f-1c8e4f0afb99@si6networks.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 27 Feb 2020 17:05:09 -0800
Message-ID: <CAOW+2dt2kePGMTcqXd=Res57EzJegE2V+zwFphw1D6xd8kz8ew@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>, architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="00000000000075ad55059f986e13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/sITtUuoJjp8RuCOdndZQSgpJ048>
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 01:05:25 -0000

Fernando said:

"May I ask what is the point of bothering publishing specs if they are
going to be violated at will *within the same organization that
published the specs*."

[BA] The point of publishing specifications is to make them available for
evaluation and potential implementation.  It's a contribution to the
"marketplace of ideas".  As noted in RFC 5218, the imprimatur (e.g. the
standards status or stream) has little influence on acceptance.  Some
widely deployed specifications are Standards Track, others are
Informational. In practice, factors such as the availability of reference
implementations have more influence on deployment.

This levels the playing field - a single person (or small group) can design
a new protocol and put out an open source implementation, with a very good
chance that the work will be evaluated and succeed/fail on its own merits,
regardless of what "the experts" might think of it.

So if you take issue with a particular approach, offer up your own
alternative, or articulate the reasons why it is a bad idea.

Better to light a candle than to curse the darkness.


On Thu, Feb 27, 2020 at 2:58 PM Fernando Gont <fgont@si6networks.com> wrote:

> On 27/2/20 19:43, Bernard Aboba wrote:
> > Fernando --
> >
> > "the proponents have argued that "we have implemented it,
> > and the industry wants it" -- as if we just have to rubberstamp what
> > they have done."
> >
> > [BA] The IETF has no enforcement authority, so that vendors have the
> > ability to ship products implementing IETF standards in whole or in part
> > - or not at all.
>
> Agreed. The problem here is that it's an *IETF* working group
> rubber-stamping what a vendor did. *That* is the problem.
>
> May I ask what is the point of bothering publishing specs if they are
> going to be violated at will *within the same organization that
> published the specs*.
>
>
> As noted by Jinmei here
> <https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/>
>
> , I believe not only are we just rubber-stamping stuff, but also I
> believe that our processes are being circumvented.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>