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

Guntur Wiseno Putra <gsenopu@gmail.com> Fri, 28 February 2020 06:35 UTC

Return-Path: <gsenopu@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 8842D3A1146; Thu, 27 Feb 2020 22:35:25 -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 J_zxvKWYGqfn; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 4451B3A1144; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
Received: by mail-ot1-x342.google.com with SMTP id x97so1630365ota.6; Thu, 27 Feb 2020 22:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jv+ZzBlGxHVsJsz/cKCqfLUJ5UYctP4d/yPs6O2EuaM=; b=QNG9nU4cWSFpWcUSRTqOUfZG8ckYL6Jckz4zTMbjQUITPCMD3QZbd69BEX4Apa9gMf yd4SW5GwBim4kIKMp6opHvYc3Sdna4SMlIfrGvvShX2eVe1foEf83iIY04udqKI/isju YOFEnmi9f78dj/jLYMZ4bqqZK/SsUlJdhSrNpLmcqAEI25AWdkjl9Qx+qYRXjGsVufOg nSdgeWo6aceVlBIqZzuKo54uK6uXFdGHYt6Y5Fq2GmXWLsGoGdAzTCqioh6XkFZD2PgS s+G4+WdVFmlBoZWbkPUirqYbjecZyrHKlYKsp1AEYWM4wBiEYR6ofcNTbpGTxG/Mf2R6 0PAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jv+ZzBlGxHVsJsz/cKCqfLUJ5UYctP4d/yPs6O2EuaM=; b=Nn0s4JQ8lFUx7ahxtVxY7TeTcXzBW0V8qvU368Bjkg1liERM1FK0HQn13qOFaFD8w4 yKnen+uXPei3PC2LuTQIYpXWuSdvyq5vDiYrws21XHCpjTRmR2uTmMtln1HnOnzFSkqW vVO8cinI/r5cnTl4ZfY+mFpzvBELU8MyczxDn64jHQmvCkZbmP97384KEJUaS6lTRwa6 sECpVB8+kvpWrQkrB14OsKvU9yNaphkqYxNhx/oPkomkpzEG+ricHCZksexrVqJg2hfl v/zWLWei98KRKZSMntuBNs1nS7CAf+sLoMn97KP8hv31xM1us/8hMFqp5V8TcvAnFWe+ EHOQ==
X-Gm-Message-State: APjAAAXGPsVByTeKOCXIRRiruKcHc389V5duCX/FdQ3X0swBS55CojHg 9wTm+tW9xgcfkSWymcdsBDUAKzAbVLMvq29KYnE=
X-Google-Smtp-Source: APXvYqwV07CK2fwhmMEUPdrcvGqeFcKs8s6tkBokhs5icn8LZ1v3mg88sBbr2xrZT6m54FURQQJKrbiOM5XVfkGnrI4=
X-Received: by 2002:a9d:63c6:: with SMTP id e6mr2010570otl.365.1582871722479; Thu, 27 Feb 2020 22:35:22 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 27 Feb 2020 22:35:21 -0800 (PST)
In-Reply-To: <426b2a17-5e27-fd9b-f84f-373e4f8186cd@si6networks.com>
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> <CAOW+2duimou-xSF3m8W42nh6yC=+Axje=qFs_iuW-W38XfRjzQ@mail.gmail.com> <426b2a17-5e27-fd9b-f84f-373e4f8186cd@si6networks.com>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Fri, 28 Feb 2020 13:35:21 +0700
Message-ID: <CAKi_AEvc9dcK9Kf3pDCdnjYKkYrs3rO9m8jeYBJzJJyKPqntHw@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Bernard Aboba <bernard.aboba@gmail.com>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000be54e0059f9d0ac1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/UsZ5NMyJk9CJzO7t2Ecf6kLlEc0>
Subject: [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 06:35:26 -0000

Dear Fernando &
architecture-discuss,

F. Gont said about proposals regarding with IP(v6) and among others (in the
first message of this thread):


"* On the procedural area:

  + Where/how should IETF WGs seek for architecture-related advice"?


I finded Dave Thaler said in "Evolution of the IP Model" (2009):

"(From the 1978 IEN, the 1980 RFC 760 to the 1981 RFC 7611:) The evolution
didn’t stop there, however, and the IP model has continued to change over
the years to meet new demands. Some of those changes were intentional. Some
were because we found deficiencies. Others were the result of new
capabilities. Often, the changes were a consequence of trying to do
something else.

By 1989, there was already some confusion concerning the IP model. RFC 1122
was written in an effort to clear up some of that confusion as well as to
extend the service model. There are plenty of other RFCs that offered
advice on various specific aspects of the IP model, and as a result, to
gain an understanding of the IP model, one needed to search many RFCs.

Another RFC appeared in 2004, which is probably the one that is closest in
spirit to this work. That one-RFC 3819-offered advice for link-layer
protocol designers on how to minimize the impact on layers above the link
layer. Hence, it dealt with the service model at the bottom of IP, whereas
the present work deals with the service model at the top of IP.

...".
https://www.ietfjournal.org/evolution-of-the-ip-model/


Regard,
Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Fernando Gont <fgont@si6networks.com> menulis:

> On 28/2/20 01:15, Bernard Aboba wrote:
>
>> 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?
>>
>
> Yes, that's not the case, particularly for people that participate
> independently.
>
>
>
>
> "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.
>>
>
> There's a big difference between a document being published, and the
> authors of a document crafting whatever they please into that document, and
> having the IETF rubberstamp it.
>
>
>
>
> "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".
>>
>
> I'm not referring to competing technologies. I'm talking about one spec
> (e.g. SRv6) blatantly violating another one (IPv6).
>
> When you have conflicting specs, you're kind of at odds with being a
> *standards* organization.... -- nobody knows what to expect, because one
> document says one thing, and another says another thing.
>
> There's a reason for which we have the "Update" and "Obsolete" tags in
> RFCs...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>