Re: [Idr] Update on advancement of rfc5575bis draft, implementations

John Scudder <jgs@juniper.net> Tue, 28 May 2019 14:21 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68BE120163; Tue, 28 May 2019 07:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 H634sreHaVhc; Tue, 28 May 2019 07:21:24 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 68C9E12017A; Tue, 28 May 2019 07:21:24 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4SEEYZd006893; Tue, 28 May 2019 07:21:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=qyqwavHE9CYzs3fqzxZLQ83gQ+RWJyx/SGy3XZ7BpuI=; b=gxKhr6kGsFyHw0G8vHkpxLr4sfdWvVOMLFCKQ0BHGR/MX/4Ls11K5r31IEtPSAnMtnhL Q1JdT9a+LAUiwVqv7wGaFua+gftvtLdRIKGo585Jam4p6D6tFaLHFSwWaSyYq2PLiovA DDnOnY8s2Z0t7S55i06BBsf+FSCZdBfnBRlk75C/1gU/TXk3NjMkFao7QFjy8nKW3YsA NLOo2LS4Tn/qLwoQ8O7ufvGNHPOZzxQNqtYlQhq6LsbOuJ7vi4L+HBETKMZATP4mVC21 3+0BrwL1wKDFpA6eVSYmQW/SXJ3KPM5gwD7kcem+0IGItA8R6AhKDrL0QlyKnmHWo/rz tQ==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2050.outbound.protection.outlook.com [104.47.36.50]) by mx0b-00273201.pphosted.com with ESMTP id 2ss5w002yt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 May 2019 07:21:23 -0700
Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.109.215) by DM6PR05MB5258.namprd05.prod.outlook.com (20.177.223.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Tue, 28 May 2019 14:21:21 +0000
Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::2835:a395:3945:523a]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::2835:a395:3945:523a%3]) with mapi id 15.20.1943.007; Tue, 28 May 2019 14:21:21 +0000
From: John Scudder <jgs@juniper.net>
To: "idr@ietf.org" <idr@ietf.org>
CC: "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>
Thread-Topic: [Idr] Update on advancement of rfc5575bis draft, implementations
Thread-Index: AQHU/HUOGoH4YIjBa02mP4if33VSjaaAyFAA
Date: Tue, 28 May 2019 14:21:21 +0000
Message-ID: <6EF537A6-18ED-4B66-BE01-20B70D77701E@juniper.net>
References: <3ECFE192-B04B-4C1F-89F0-812D4ADC68C0@juniper.net>
In-Reply-To: <3ECFE192-B04B-4C1F-89F0-812D4ADC68C0@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a91dbfa1-fddc-437f-6fca-08d6e377c1db
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB5258;
x-ms-traffictypediagnostic: DM6PR05MB5258:
x-microsoft-antispam-prvs: <DM6PR05MB5258D2A7E94DCA3B37034379AA1E0@DM6PR05MB5258.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(136003)(366004)(396003)(346002)(199004)(189003)(53754006)(25786009)(99286004)(36756003)(81166006)(81156014)(1730700003)(186003)(8676002)(6916009)(6506007)(4326008)(102836004)(450100002)(26005)(6246003)(446003)(11346002)(476003)(8936002)(486006)(2616005)(14454004)(33656002)(2501003)(5660300002)(3846002)(6116002)(2906002)(2351001)(86362001)(316002)(66446008)(66556008)(66476007)(64756008)(73956011)(66946007)(76116006)(91956017)(68736007)(6486002)(229853002)(256004)(6436002)(82746002)(305945005)(561944003)(76176011)(66066001)(53936002)(7736002)(5640700003)(71200400001)(6512007)(478600001)(83716004)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5258; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: a49Q74subXtXN8+JEnsIpk492lbD1ZRyepMuSLguBP/EybwWCsKPYGUZuqIyf4MzZWiEARRu4YKBE0d486xABmjhlg9BeuQaGPlRFUNYvHbuMGHrNO1w/yacpJ0gU28MvnEXu8KIIDs1Ixk0Gles8Z0zujmFx2ZaAezbKdPimRYm7cL3T5ps7TWQQwzfB5VNX3EFtUIZGcWybNKQHwUZvu92LyEGePPA2bLSXfLfUxbLcRIKxMMg5qR11r7G1UafnJxlzj+6zQBGZnMmmUznAFkWi5YFgfkOC3zijxSrzophk13K+xgbNSDuTIkJRBBkIP8qEeLpRMIrSC5RudjYzg2/nyCaEuCAnRnz6nFih0vEcWmEByTkuzZzWzkz/Zmt/BKE6uby3DNCVLp5ibf98IpBlUfr7nXAL6kDf3ZejVk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0F64677E835AE4408848ABE7DBB3DB4C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: a91dbfa1-fddc-437f-6fca-08d6e377c1db
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 14:21:21.0871 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5258
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-28_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905280093
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oDyUnjfFY662xyW8x0cUXT5bNl0>
Subject: Re: [Idr] Update on advancement of rfc5575bis draft, implementations
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 14:21:28 -0000

Hi All,

In considering this further, I find myself sufficiently persuaded by Jeff’s position, in particular the shorter version he offered in a private note: "the level of rigor is perhaps excessive with regard to optional features”. Fair enough, in my opinion as a WG we should continue to be rigorous (ish) with respect to core aspects of a specification, but when it comes to optional features perhaps we can say non-implementation isn't blocking.

To be clear, I think in a perfect world a spec be fully implemented, and if it’s not, we pull out the non-implemented optional parts, put them in a different draft, advance the core spec, and leave the non-implemented parts in draft form until they become implemented. But that loads the authors and the WG with more work, so it may be better to respect the adage that “perfect is the enemy of good enough”. It’s true the WG has advanced plenty of other specs like this in the past (including RFC 4271!), for whatever that’s worth. The proposal is that as long as the non-implemented parts are genuinely optional and don’t impact the core feature or core BGP protocol, we’ll consider it potentially acceptable (though not preferable!) to proceed. 

If there’s any strong objection to advancing the document with this rationale, please follow up by the end of the week, otherwise I’ll go ahead and send the document to the IESG.

Thanks,

—John