Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Wed, 27 May 2020 21:32 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533933A0C57; Wed, 27 May 2020 14:32:11 -0700 (PDT)
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=boeing.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 iOHaAbez86CO; Wed, 27 May 2020 14:32:09 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4493A0C52; Wed, 27 May 2020 14:32:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 04RLW21c017677; Wed, 27 May 2020 17:32:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1590615125; bh=ZMl6VNe5OTBf/lk9wSBTHF6iyLB6OUb4rQaxa2IopP4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=iCznYD4FfFcspwBWOVf1EfQWenMSLIImSzHvbizdjnJ0AnUBTmoZqPLfaYnfB39Xm UkdKj7k6UB8VQwUjTnT5i+rdSaC4S5ymUy1aOxmP7DJjOJ1UrNuOfCHhNBuws5CJVV 9OCDSOCO91oAMp6DCrqPauJ0CGkExX0s3zdrEUmLEP0mTskifK1luCoWMUt44n3B+W s7RnxrzZytKVPyKgZhuAiCOhpzkt1uQlZiQO7B+ggQBp98wlLFrwr3p70D18DPsNHe O/3Zr+8MsbFKRVxhWdNNJZpL/QeAwC42BYQ3apWQP2gjYYiXYS/tIPAmwnISgf5H9s KYHHWByHu4+Qg==
Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 04RLVmNl015641 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 27 May 2020 17:31:48 -0400
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Wed, 27 May 2020 14:31:47 -0700
Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.1979.003; Wed, 27 May 2020 14:31:47 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Sander Steffann <sander@steffann.nl>
CC: "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Thread-Topic: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Thread-Index: AQHWNGnylwwxay+VQEy91DJNjeI+mKi8cYfQ
Date: Wed, 27 May 2020 21:31:47 +0000
Message-ID: <c3dc3919bb8a467592041209dc56e800@boeing.com>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <4F868A41-7263-4B43-90B2-4E54BB1BE279@steffann.nl>
In-Reply-To: <4F868A41-7263-4B43-90B2-4E54BB1BE279@steffann.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 1239FEAC5C072A910DC98A02BF1834736348B4EA85585584D2EA22AA5BA82F8C2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/j-Sn031UvG6T9q0U3O-KYomQ130>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 21:32:11 -0000

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Sander Steffann

> This makes me think back to the days of telcos. You know, the world where telcos defined the protocols and the users just had to accept their choices... The world where TCP/IP flourished because it allowed permissionless innovation (which is the very thing that the IETF says it's all about to their supporters on https://www.ietf.org/about/support/).

That's also been my reaction to the objections to CRH. Who cares if other ways of doing roughly the same thing exist? Plus, RFC 8663 is worded to read that it's for MPLS segment routing, which will instantly turn off a lot of potential users.

In the Internet way of doing things, an innovation that finds a couple of adopters becomes fact. No need to overcome any other hurdles. Over time, some RFCs are labeled "historic," if they have no current relevance. Pretty simple.

Bert