Re: Ancient history (was Accurate history was [Re: "professional" in an IETF context])

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 03 November 2021 12:40 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE43A13B9 for <ietf@ietfa.amsl.com>; Wed, 3 Nov 2021 05:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.227
X-Spam-Level:
X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 VLS_XLTb94z5 for <ietf@ietfa.amsl.com>; Wed, 3 Nov 2021 05:40:38 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C81EA3A13B6 for <IETF@ietf.org>; Wed, 3 Nov 2021 05:40:35 -0700 (PDT)
Received: (qmail 37931 invoked from network); 3 Nov 2021 12:38:14 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2021 12:38:14 -0000
Message-ID: <1017bb30-97f4-6651-9f6f-a2305cb8ff86@necom830.hpcl.titech.ac.jp>
Date: Wed, 03 Nov 2021 21:40:32 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Subject: Re: Ancient history (was Accurate history was [Re: "professional" in an IETF context])
Content-Language: en-US
To: ietf <IETF@ietf.org>
References: <37b299c8-e821-07e5-6240-68fb9d1ca137@gmail.com> <ADBD9121-758D-46D9-BD3D-D32098B89895@gmail.com> <4108B7BF-8CE0-484A-86E2-AEE8D41D828C@sobco.com> <70581daf-5c17-cdf6-80db-19eaa7cbb1a3@necom830.hpcl.titech.ac.jp> <84ac0acc-fd3d-173f-8afa-e603604b03e4@lear.ch>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <84ac0acc-fd3d-173f-8afa-e603604b03e4@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jt59alJ2kZZtUXOlrUr97KoyGmQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2021 12:40:43 -0000

Eliot Lear wrote:

>> It should also be noted that SIPP is already a union
>> of SIP and PIP, though Paul Francis, who proposed PIP,
>> was, in the face of SIPP, saying "PIP is dead".
>>
>> So, SIPP was developed highly politically, though its
>> address is still 64bit long.
>
> While *perhaps* SIPP shared some principles with Pip I don't think that 
> either the addressing or routing architecture was one of them. 

   https://www.potaroo.net/ietf/idref/draft-ietf-sipp-spec/
   o  Changed name from "SIP" to "SIPP" as part of merger with Pip.

IIRC, some routing header was added to SIP to politically claim
it is merged with PIP.

> My 
> recollection was that the 128 bit address came to be because of concerns 
> that we'd end up having to do All Of This *again* if there were a 
> shortage.

As it is obvious even at that time that 64bit is a lot more than
enough, that was a poor excuse for political merger, I'm afraid.

> You can say that IPv6 was the result of committee thinking, and 
> I would probably agree, but I'm not sure what the alternative would be.

As I wrote:

 >> So, SIPP was developed highly politically, though its
 >> address is still 64bit long.

SIP or SIPP was an alternative.

As an afterthought, it were even better if very complicated
functionality of SIP that it has optional headers, which
was denied by long and extensive operational experience
of IPv4, which makes SIP and IPv6 not simple at all, were
removed. Fragmentation could and should have been handled
more elegantly than PMTUD.

						Masataka Ohta