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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Sun, 01 March 2020 01:31 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
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 640B23A1738 for <ietf@ietfa.amsl.com>; Sat, 29 Feb 2020 17:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 0IBzAVjtFuys for <ietf@ietfa.amsl.com>; Sat, 29 Feb 2020 17:31:14 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281203A1746 for <ietf@ietf.org>; Sat, 29 Feb 2020 17:31:13 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2105.outbound.protection.outlook.com [104.47.18.105]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-7-c9TGl985P02DrdlmeiiYjQ-1; Sun, 01 Mar 2020 01:30:04 +0000
X-MC-Unique: c9TGl985P02DrdlmeiiYjQ-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5191.eurprd03.prod.outlook.com (20.179.46.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Sun, 1 Mar 2020 01:30:02 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.018; Sun, 1 Mar 2020 01:30:02 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Guntur Wiseno Putra <gsenopu@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: Internet Area <int-area@ietf.org>, IETF <ietf@ietf.org>, Tom Herbert <tom@herbertland.com>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>, Internet Architecture Board <iab@iab.org>
Subject: Re: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Thread-Topic: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Thread-Index: AQHV7hX2fo5LhdujpkaAQVIa4VmXnKgzJ/cA
Date: Sun, 01 Mar 2020 01:30:01 +0000
Message-ID: <A1505922-7866-4D03-AEF8-E90E0090A9B7@liquidtelecom.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <d41a94f5ede994b9e14605871f9f7140@strayalpha.com> <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com> <a24a3621-99f6-755d-c679-2061b9a67adf@si6networks.com> <CAOj+MMGJ11CBCov=-jfZUtROJPwhQB3A=+0gMBhzZgxoF_9N1A@mail.gmail.com> <A83D4788-AD7B-490C-B74E-2548A1345C47@strayalpha.com> <CAOj+MMHfKMGa7w9pkqg=2RC4XeuYk7+iHt949B3kUtc+vCeB1Q@mail.gmail.com> <CAKi_AEtxLZXV-tDFC0wTueZjGyBUvf7p4wDw8_OWVw6FmQz13g@mail.gmail.com>
In-Reply-To: <CAKi_AEtxLZXV-tDFC0wTueZjGyBUvf7p4wDw8_OWVw6FmQz13g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [2c0f:fe40:3:3:808d:eb0:4250:7e10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 695e9b6d-801d-473e-2b40-08d7bd801040
x-ms-traffictypediagnostic: DBBPR03MB5191:
x-microsoft-antispam-prvs: <DBBPR03MB51914634E75B5064E14FEE1CEEE60@DBBPR03MB5191.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0329B15C8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(346002)(376002)(136003)(39850400004)(366004)(199004)(189003)(66556008)(66476007)(5660300002)(36756003)(64756008)(66446008)(6512007)(71200400001)(186003)(66946007)(2906002)(478600001)(4326008)(8936002)(2616005)(316002)(54906003)(6486002)(110136005)(81166006)(81156014)(33656002)(76116006)(86362001)(91956017)(8676002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5191; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6vKQOBsoHyeyi1KTIO4/Cg2r/wIwDOxV5LNATG6Z0zsR8lSdMxaj9/Ukw2qMMf4g8aFYPdT0xzCXl/QqTu/oVwVZgci07x6Y74LhltEwKAyv/F5w7cARr9QiULlYqexohXdK+a2O4TtDSQtji1wqTHciXVMtkxPbinzyQdwSWW8bMbu47RIcAIq/+XQMnIPhCfg0NnVhJ6UC204UgkWFDlz3fMSzKH8Ty2QpSVVAkSMVADkzADmDtQuytTpn7ctLwnJDa49Qa1lYur4K/kl0MhXWtklwJoSLKumEiiS5eUwFZ6Eedc5EQ3j8f4SlLMOLa4WcJYcJCkFnsD14PurZci7gOk9NKiixZIXP3nXDSu3Xm/cIw1d02QQL5syraVNnuqQwsDcpihiwrGDXvICbAcD1hg3SVQQSqbkHVakSy09LDyZChsEAbQ3zAWZ5F4Ta
x-ms-exchange-antispam-messagedata: aGXRvHyjEI0Cu5RwlW8cmuU521WuEqxK8FCeTH4IrOMyd8hifH745625P2/DxECeGkP1DjMcKvuX2Stu4JaoWIJ5F/3QPe7kghARjIILc3/wDn6ldFTL3nBAXxrvNp3iFLtyV8YG12nUTCyYcDGznxDp+2nuyKLqbtENYBUjwgyG5goFCrIyngHRwGB8w1yF3OOzluhFt788TVri7A5cdA==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 695e9b6d-801d-473e-2b40-08d7bd801040
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2020 01:30:01.9640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WSnzgYECaFn3A20KzJ9BDdfwDA0Hh966fzye4SSmJKOCpOPJdBZgHdiA94Kuh56d00aLzi0N8yz8EGGj9VfHmwsEXizzqk0aZZ+bElvcOu0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5191
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_A150592278664D03AEF8E90E0090A9B7liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HpdS47ALDnLz-zj2BITvPP09hNE>
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: Sun, 01 Mar 2020 01:31:18 -0000

Guntur,

I have to say – I sat and thought about what you wrote here – and there was one line tha really struck in in the context of this whole debate

<snip>
> Any change requires a reason to overcome the associated hurdle. Consequently, I have found it very instructive to try to think about the network and protocols in terms of assets, incentives, costs, and benefits".

On this – we are in total agreement – which is why when I look at what has occurred in SPRING – I find myself getting very depressed.

In order to consider protocols and change in the context of the four criteria you listed – we would need certain information –


  1.  Why do the authors of the disputed draft insist on holding with PSP – what is the substantive use case – I for one – do not believe this has been close to addressed in light of the fact that there were no less than 4 ways to progress the contentious draft (compromises were offered, everything from, progress the draft with this moved to another document that could be debated, to update the rfc8200) – in every case – the authors refused to budge
  2.  In order to evaluate benefit you need people who are prepared to state the benefit they see in something – instead we have a document advancing based not on consensus but on (and I quote) “We had to move this forward” and citing a bunch of people who +1’ed a list in what was in my view a clearly orchestrated +1 campaign as justification for support.  I’ll be releasing a rather interesting summary from the lists showing just how many times the majority of those people have *ever* posted to the lists before – it makes for an interesting read.
  3.  With regards to the costs – without knowing what the real reason for insisting on holding to this – and there must be done considering the dogged way the authors and the vendor behind this document have insisted on it – without giving proper reasons – this cannot be evaluated.

So – on the basis of the criteria you listed alone – the fact that we are seeing something being railed through a working group – despite substantive – numerous – and unaddressed objections in total violation of the very concept of consensus – disturbs me greatly.  I have always believed that if things like appeals can be avoided – that is always first prize – sadly in this case – we are now forced into an appeal process and we will see how it plays out – but – in light of all this – I can understand why people on so many lists are questioning what is going on.

Thanks

Andrew