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 04:16 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 122003A0EF1; Thu, 27 Feb 2020 20:16:05 -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=ham 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 iVkMICCCegWH; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 1919A3A0EF0; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: by mail-vk1-xa41.google.com with SMTP id x62so559990vkg.11; Thu, 27 Feb 2020 20:16:03 -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=vItfVZBSFCm3TuCeDg179NsSoQtCkmQOiUqS6KXaVA8=; b=q1qT+5ZvYXMwSY6UWOQQWpGeCdBlbuIvvDNok/qjVmUxNX+LqALL2AMG3Qv2kSYr9m TfBK/9zszA2/B+Q4FmCp4HpoR8SqS0NgZ1wlmb2kZBRKItCPB9srtid3sXr7wEvbXWEp C+SSTpBUUZgCeelL2mWDcMMgBrXLUU8Z0dJHdt9s18crlYChx7ISfC0rGIMhjuzBZCpx bOMVK/48RiRvWUr1Xv8VCWKVfk7Y4hlUFsuvT2Ug4xraSORLVa87W0QAyRwCPjeiJVdZ n0Pvr+8S66EZooip3A+lLWte9VAzhro4CePF2CmxMVyrj6KgneioEYhkgIwQcR6Rasqz Cy0Q==
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=vItfVZBSFCm3TuCeDg179NsSoQtCkmQOiUqS6KXaVA8=; b=kGsxDffpWFO52fqrpZT3/BZcOPpRBF4nNacmZ3pDPcIxC+COM55YfIfy3PrjT6g0g1 CcqVpQd56C5szXCWgHekol/nHYhmiFZAQZQ8p1NOm0mYMelr8uBeKWYjdE/0MOwW7L3Y 5llNaGX2dVzyUJYQQ/BS5GadZVzuK31Ar/Rwjf5AxV076MYvJQOEwQycCvFg2c85JBDO lpKzc31mIOGWCMuZovSDjVtKKwERfq3p3zBz1d7YOYf44FcKPh6ibsY3VEpP+ymqklWH L8bL/kmkWDlugaLH+kQVsS1X54nuhJYIa7RvSGSIweadlYjIcAzUq9PHKfQHNAYNs0MJ RFcg==
X-Gm-Message-State: ANhLgQ1KSby87/s70dpqatKRy70TSKnE0tfL/dzvxy3k9bHMoWq59OzT mLBIOIgBdBtpjZYs18616sM8ku0Ng2hgpe/Uyf4=
X-Google-Smtp-Source: ADFU+vssuFTCSl2paxU5fKDMoskcL3P5fOjoF+bKXksgS+LNM0MK1fUiRRW+X/P6HRxSd3y6XM9HsUZHxzc8qBA3Rns=
X-Received: by 2002:a1f:2c58:: with SMTP id s85mr1490168vks.93.1582863361998; Thu, 27 Feb 2020 20:16:01 -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> <CAOW+2dt2kePGMTcqXd=Res57EzJegE2V+zwFphw1D6xd8kz8ew@mail.gmail.com> <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>
In-Reply-To: <9905c05f-7569-3523-5f19-560901f6767c@si6networks.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 27 Feb 2020 20:15:51 -0800
Message-ID: <CAOW+2duimou-xSF3m8W42nh6yC=+Axje=qFs_iuW-W38XfRjzQ@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="0000000000006b8632059f9b1823"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/6EEGltB3haDg35Ze3_SHaGqK110>
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 04:16:05 -0000

Fernando said:

"If that were the case, anything and everything would be published as an
RFC."

[BA] So you're saying that this is not the case already?

"Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications."

[BA] Please feel free to design a process that can accomplish this, given
the level of participation we have within the IETF.
The IESG members have a near-impossible job, so they have to rely on
Directorates, who in turn do the best they can. But the IETF process
exercises much of its restraint at the beginning of the process (*before* a
WG is chartered).  Once Chartered, it is rare for a WG document with
sufficient energy behind it to fail to get through the process.  The review
process does not guarantee that drafts conform to BCPs or IAB statements,
let alone consistency with other RFCs.

"If you have one spec that says one thing, and then you have another, from
the same Std Org, that says the opposite, without "obsoleting" the former,
then you end up with something that won't have a single bit of coherence,
virtually impossible to digest by anybody else other by than a limited
group of people that just happens to know how everyone
violates each others specs."

[BA] This has been the case from the earliest days.  For example, as
documented in RFC 4840, back in the early 1980s, there were 3+ approaches
to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the marketplace
sorted things out then, as they did later when some of the same issues
arose with WiMax/802.16 (RIP).  If there are dueling approaches, it is
often best to document them; rather than relying on standards bodies to
"choose a winner".

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

> On 27/2/20 22:05, Bernard Aboba wrote:
> > 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".
>
> It would seem to me there's much more than that.
>
> If that were the case, anything and everything would be published as an
> RFC.
>
> Among other things, the specs we publish are supposed to be subject to a
> decent level of review, and are also supposed to be coherent groups of
> specifications.
>
> If you have one spec that says one thing, and then you have another,
> from the same Std Org, that says the opposite, without "obsoleting" the
> former, then you end up with something that won't have a single bit of
> coherence, virtually impossible to digest by anybody else other by than
> a limited group of people that just happens to know how everyone
> violates each others specs.
>
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>