Re: [Int-area] [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: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78C3A0EF0; Thu, 27 Feb 2020 20:16:06 -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 BsIb79f9TKbb; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) (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 174E13A0EEF; Thu, 27 Feb 2020 20:16:03 -0800 (PST)
Received: by mail-vk1-xa42.google.com with SMTP id o2so557338vka.10; 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=tM1leVE+SN4k38FW6DvbztGqUNkuVmpX7oNpjnEWugf+rL71imgdHWhleZejbEutKa oYJ0kQ83UBoMHmV6E1yTUGlwdVFUVGGkCoD3POOGFY7KO4A1lM7+m1YxgrOjgxxKSYSg mpf/CXSjSkU8j0lAJpqeuTc13oHuRE1piz6IUZnfKOD3wVbgEReKW5RXT4jgCvrDMa87 fN5iXm69OXF/Az6M3TQcLVfjMzQpWI4HXq3llIVnSbqaKnNcz8+Rz6Pn3r9aM2DcEeSp lJuBErOG92njT1p78MZmPLm7nsCWaY7vuZCaTcJ3gJWE0k3/aQLPNjJO4wzwWIxTQLan h+vQ==
X-Gm-Message-State: ANhLgQ1VI9Lfj1nClBGGAR5peXec6D1ro1tlUhedvScSgdo1xTxtmsUd dSA7RlBi6fHwF7yxnhMaKBp2g2Dz8AF6mPZUFtr5W076
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/int-area/_QIj-00YhD6ASIsv3LidD758V_Q>
Subject: Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 04:16:06 -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
>
>
>
>
>