Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

"John G. Scudder" <jgs@juniper.net> Thu, 04 May 2017 22:41 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 572A5129478 for <idr@ietfa.amsl.com>; Thu, 4 May 2017 15:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 5-vPqBKZK53j for <idr@ietfa.amsl.com>; Thu, 4 May 2017 15:41:17 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A1D128B38 for <idr@ietf.org>; Thu, 4 May 2017 15:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CWmhzWwlqSB5xngSghckFarzfghYkXz8MSKiCuHNmzw=; b=g9ATEXX7F0Y1lcVgCQFZxluH+sdTQEGDdY2JU6xIY3NReU3YxVU0ss1Q3ze5GVABpn3j03mm/IAP2L4+dWsz23WjllT+WQg9BDGfrzHLkyRc4rHwiFHszBp74xvGEuG25fiT5weEzQsKtW50IDtJXsbjl5/812OIZ75fwmdE57g=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.38.145] (66.129.241.14) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 4 May 2017 22:41:13 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net>
Date: Thu, 04 May 2017 18:41:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <81424CC3-C4B0-487E-BF56-0113CA637239@juniper.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net>
To: idr@ietf.org
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BN6PR11CA0035.namprd11.prod.outlook.com (10.173.25.21) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9f2331b7-fb39-40e9-ca18-08d4933eab3a
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 3:yL7Vn+PiR3mHmLc5aK2MHZSK+WD0abn1wVeYyK2ecuApObGz34EwSLfUlJBrvU0MKW35eQmk9P4DnaiMQdUS1O3s5gW4DcnzwCfBxjk2WOqemUY/ng8fLIPV+UBacawDk4VdzV+T0UjMIuHz/Q9fMrbmqAtP367Nu5VI4cpL7q94fwyTLNXeGyA8W26dgs2fSmosBODmYfebbNIY8GCm6bLUhg/n+KfOs45RIctEzI5Jks7eK7j3sSQprYu4ewgD6gpEMjnVv4Jezim413IyEWOmtud+M2hejwYdc0GoRVgBa2miCoZ1AxfU+jcb+Ym2DJyh4pHVGrwaPjlvskmEHz7t6jfU8SiHKOadt/LlvCc=; 25:qW4xSlSQzvux9+jhsnI/pEVMUc/pyaBU1n57Bq34X52bbHMgoA/lUl9HMNKk/rzww3yeS1mQm1KkpN1LwKv4dXgcWQR4kYayv4vtNiKgupvSA6nM0vzFPNSeq/eumEuGfmFiK6wdcGzrUIyMKIIXRPGOb4mVl/wkqVYJW0uGbq5S51SfD2bQWMMduAFLrwMbjI/4Fij9LSRBy23D4sVdXqdk7y5qChhkjg1T/OB0IPryf9OaMmxXjqr/GWcdvOM96AJZvr63TQcp7a4j6oJs+Wyv03M3IRyNZcj6+XdhEsYJwcGxH5zpv5oKCcLI8SoTy14X/PHMHyV0RSZ7tjs9GLFlbM11FQ+YIrBX7X7Ekmnk0GJHU4vsGA9EUYGHGfk5u/mert80HicE3vZyARg0oGtKrIEE2hbcGy63eJBXl4IImXH46Obpk+pPSgT4ApDL2T4nIadJ3rnTZUGC7bhHDPFGSKtexIdV6P9leLwcvgI=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:jyx3ogqCcmVxm3aKvqbfarTrbDGcet/pxJsFeDqPB0FomGDF0o2nAUalwhyhTdfldmjFQYznSHYsst+fluYm75FQ+iGdKGiS0q7oz2982XN1o1cztbIvOn+qREc+t0LHAynN2BbeQJ8BxNU+DR2IFrkr7AMle9ao+YlU6zipoFzYHwbR7RhbFm1Py2KWrWxVArbkG6T8OvWjy3BQGOxJHMgBX2dw3hOCG7OlVhmsgxTZNHAvqo5eb7Acp094kN5TqYoqg3dlhlfuGsZMMBMPGWxG3N7N3dw6yhv8dYzdfyg=; 20:qL1MhsOq+hd/7kHQyillTv41w1T8rIG1CJaGRDsrR0+wkFvnGxOadDziOlw83/h9CFtpetqfwiDw5zUPy7W2y5DLRhQRaGNpva7PBB/dZsjo8hxpQu8e00Mq4VX+pYZV9X7F3WVjUDKTx3RLnuzl1k7p9SPiW5Y5tcYnXQtLyupq8AcjWMAfcYjYxtKfzRsIkeLD/wGhgWLgVQJSNeFxTUfIB76OgDIoSmTyH8ttYNF5rGNxI5R7GIG/XRz6Jy3wJRGYhLyjkJaX6lH3/3j5K5W79BV2W5KFroFj0NEhEZR2ovAjUp+xuBXfc38q1mkcvMmsnPlj8vxZ+IjlaMW0++YzFffKuHp04r/OdbRcgKJeuuspQSB2ClzxOyLI4MY0dXBILbq8FmbUgW3hreGzB0UjcHA+TonHbiOCK5lYA/n1I2h5xjkui+emOHMRdQt0rgKp3hTZuwKKyhMXusi3J4HmaWHiztZPoxiacX7gOzov1r7AymWribB8MJALKg2qOXbBqX+lW911oMfEGUCUAaOgq3iDeOaCIwkH4ss4phol2fhmsz42HkO+dEcnBBB4g+Km984rDYKzKD7hdtd1wereTE4TfWlJL2VtbVsgTR4=
X-Microsoft-Antispam-PRVS: <CY1PR05MB2506520B55F4F729E6C721FFAAEA0@CY1PR05MB2506.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:gOjUC4lFtzYykzVdZr0wyv3ZgOdhld1/R6+LYfVqAJLYzKgGQHXTsYIKeFZQuPosZmHgl1+vaCSNXWbyg9K14OlTdjq7/h+3OT0JIGzm1uXCANF5UlpzWbwzZjvdYEP4CoOHAh6Ju9q33cDpkXDDoG5vRuFy6wSOW9gw5T8faGIonpGHCdZon4u231m4WJx4fxxtYstcLluZNTL2QXKAOCGD1pipOfhFABWRz42MEEGAxP+SRFPkKlwgiDlRVCsdRrNoofgjOZ+43tL31ZgnTL/0DhW33TJZxMX03v/0QzoT+bKv3n9ZERndKDHwlMqL8aJAqp5XXV+Bac432IzQ1nCO04lRu/jaKaVt9OCUevmKiPle9Vw5BfyQxoF3lG8xKCb4H0DN+NfV10AaUg5yPsOqQzyxcnRyklXhgki81hAqTTH2Ya3SlDzlp8YJp8Fo19Q8Rbq7Y14l5f+K7j64BRaEMlC6PhrMjvTP+FEFoZM342E6tNVwdTVsG7AoT8IePO/cqRcds5gZRE/cvZPvCvhSfBACkFIhjVcztbNQp+92/E2ofGGV4Zx+GwC1+rbnT2XJSQeQb6bcqnM0pazDP0Fo2M3n4e54zVWhvfCZ+SjYbqWZ7FQZul6i0V6rCKVaap6fUt5dCMFa3j1blw3AlQsN5/PQJb03PzWF8X/v+GWgs2EilnKJiHpyyOH+SEgxAraG+9h8pZvs4rOHHyT3kTOKycZRVb52xWI279BKv3PYIOm1e2PlDHZ0atmmH+VOgiXZxgEmi0d4IUNSp0RSEelwF+nrBjqDHHQ/0dWxj8kouo8fhPs6Qo0vZvn8R4BTQK07Ejw+c5zZFj8+vKsrcHLoqpgMft5wquKRay4mmURn4qVpSYgA3Ez9PxkIxAmPCw1v3Pdo8M+nZPN1Itmu4pYzSoKVrsDg23iwUXiJCk4=
X-Forefront-PRVS: 02973C87BC
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39450400003)(39850400002)(39860400002)(39400400002)(39410400002)(39840400002)(69234005)(53754006)(86362001)(6246003)(5660300001)(42186005)(66066001)(33656002)(6916009)(46406003)(2906002)(6666003)(2950100002)(8676002)(50466002)(8746002)(97756001)(81166006)(2351001)(38730400002)(50986999)(478600001)(76176999)(50226002)(189998001)(3846002)(6116002)(110136004)(77096006)(36756003)(305945005)(6486002)(83716003)(229853002)(47776003)(82746002)(53936002)(230783001)(7736002)(561944003)(25786009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.38.145]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 23:QUQMfiCC5XDuIXYsunbmT/PLLNdJLBUk/2l7661F9ET8/AxydzrdOZkSlG3yEhs0nOK+nbuclAeKNB8+rkh2e7cdW5CQq6pA5RIZ+ovFACbTEnsTg+W9VNWqJNw8NvWfbH2gh/1lKohohzHOzsBMGQrdw8s9uqDxKxzusQFpes2aK7FhveVzmGqAMC44ycyXcWf9p3+0rgDtmqHdkXFWdSpgxqVFkFHUQXntPd69xNncx14XuoBJBbckjKrTbk5/0LWHRobU8IXElQa2Z9BRzJzvoR7we4bDhyLzjJ37xOVuGypcvWfV5U7C17w4KM2H43BQFHZLrq8en7Yo1N1501mVWZojLVRKrcdbs2tRlrS239CoCCdQjE+BFMmEAFMOBgbIHyJNfSDNLVaK9tgWy08O+2wTvS2vDC1BE3ZHwKnl3d40krZ+uKlCkb5s3UvQPgn2cMm2c+z8VfExrlQDY4b+djKtwbamFVOKiizDygT0Ag2TtqjLwXdPknFIhag/fBnfP52RoCpk+UEe3PfJEBWEeZJjdFeqcpwmtFmtcfwU7jO4PaHB3jUgLyUSbcNMrQGpXO2T6z5QfpmqMOH6ar80czdxXLcLbVi3vTv1+5+Jjf6l5S8h9nZc2+C6REAlbJYIionLEtW6rTwFR8NOKyKnXP7Vn96jnUq8dKzPF47i9cwxOKRHCvcNVE6qsvHP/vjo9J6D+UAp0XlOHgmNIbf+ul7ReCS0HUq7VMS1MzJmh84eygitmigTrHnW4jBdDl0TgqYxkBVSRu7onHbS4cPsykNsjQTxaRs7OR3qmMs8IsP5hYnPTM9QNL0yAWeol7oCwOSY5zU0thFWjFrfMlYvuEdiVNVZjBlVFd8i8ij63HOJuMPhnn6u7jzQkqfKOCYS2fmM6/5piIepvr3BtcrgE4bNG0jZTIpp03Ndva6cSRmntcsNRETL36x1rnVqpXJNiKi2SIg2avMcEZLPzS+KNZlJqC0/DZYCYRDB96xiTKD+kchGxm316vbr91F3u9XLBNuJ5cjTgD1guLs6QKIBWSNI9Aww4MVv4yk/i7YawNP9P0S7fNnlwqEg2qQUvj2pzUSeUldeixW5YljuXgsunVv1nblnacn+n0rD6uhm23OWgl/PwAJU1oLF840soXkuIEJWKZJccg1aekp3Z7NOcd/zlYVcSyqMfAXG8s34FRib+9R9nobsqZDGoWGR62tKV4sT80ySeZRFQSbGNTfaftPbFRhWC7O09PqCWWc=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:OKlLimU1iuL7/1TGZ2sw3Ah7ASdvm7CNu/C20O9vj+aZ3aI9xlATM1exeQfAVsOcNKUzK/pQO6zoNvlYpOfzOzaC/XGGBsjXCTwUz+hmsppfU3/nbjI830NeVhHe2Hqn88rZBwAxQG2r39eohjnjiVSXrUuOzQhEv1W47AwQjuOuwfJ59E0vTY0GqciuUgpYWMnQVnDKD4QlhKGOAKOvI+85WBF1ulN6zWI8048AEw4ecl82dRJZBaVLiQsC/u+wm/IT+auAmS+s7uC1yhSZTV3zH4sIXtcXbbpUc969gYpQN4h2qkyyYjGR6L9gyFzFCD9J/D2Bchq7/F0LMHP/5gc7Z1NQk1xF2rMNCg+mHEcUwK3UB1mWQeyR2KFw9Lj/KwJf1LpoHzPpGi4tmrBjVVm5Sg9gG3WlPiQM7D5lZ009UZosJmej0zhWYfshSr3bmj/+lgU/xJPfD6iRuPjD4FmmvLvdp6knTVnjSL50kQUTmCKh2xveuQEL8NT27P0yMvWkMJO6OF2MLwgYTvyuogf3EBPbxHlzGn32gsenKQ4=; 5:uq7xjvsSWV7dSYEfjAa9dwoN+TA23jBfEpNFGw9+HtzoJ2diTv6+rU5vmUyLxr3fxpCGf9un/El7WW6nLrfiwlV1e8vYcDgpttNaKC8cJH1WG1mIVsJVGLTjnkHNaXPNg0+/xBYtpKi1dwh8ABfA4g==; 24:oQXfgmRz0FI7414ZoW88B/FVS8tXV57olMCaHDbo/S6RvGfxWqUvAyBOiD7k58RppGrCeDFuu6L9fDTIahTQg5vPZebRCWvFdDhL9eE6Tjk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:bn66bGhILLskzhY/LSZuflsBLjMCHhAtoih2AetZTVyH5NGAs4Td77JTT3RLodsF9WdxD5qMSj35Y8Kwteq43NXP4wDxjfugZpZdBGPjAaB4fGmmYnC6lGbQtSixjeZoIA2kaInkaDFctMsqSvb2BOUJmRz2SqV2s6YV7GveTqqBI6kb+Hi4T5nvwjwqB1/L5pW5/iuvlMWrpIzBrp5eKW9OPAnjUj/af/qgN9YS1G8eTc30+nq1nRl7wr+ARUOxlyaEVMG2FB+yxxgELhUJ4h2W3UL95eM0VAAELjHdGSaeHqiZI+cEEyyKjFuf3+mulMcCxWllQniSMqnCNz9rxw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 22:41:13.1500 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mqPltvvgEhpxBgAXET1y1Xow6t8>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 04 May 2017 22:41:19 -0000

Hi All,

Below is my summary of this mail thread, FYI.

As I understand it the next steps will be for the GROW AD (Warren) in consultation with the GROW chairs (Pete and Chris) to decide.

Thanks to all for your participation.

--John

The thread "[Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard" started on April 19 and by May 1 had accumulated well over a hundred messages from 27 or so contributors.

The thread defies a simple declaration of "there was consensus". However, and somewhat to my surprise, after reading back through the history and trying to give special attention to issues opened but subsequently rebutted, I think we do have consensus supporting advancement. 

There was quite a bit of discussion about the intended status of the document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. In the end, I think the best we can really say is that there was no consensus to choose something other than what the doc currently says. I've counted those who had document status objections under "con".

If it were up to me to call consensus (which it is not) I would say there is rough consensus to advance the document on the Standards Track, updating 4271. I might consider offering a few extra days of LC for editorial comments *only*, with discussion of the document status and general outline and features of the solution being placed explicitly out of scope. This is because there were, interspersed among the many other comments, a few editorial ones, and I just don't have the energy to figure out if they were all taken in (although I think the authors have been fairly diligent about this). It's also because the most recent versions of the document have some fairly significant changes compared to -05. 

Several issues were raised and discussed as part of the thread, including (but not limited to, I'm under no illusions that I've captured or even fairly represented every single point):

1. A number of people, largely from router vendors, expressed concern that changing defaults is difficult. These ranged from saying it was impossible, to merely difficult and not worth it. In response to this, others (including but not limited to other vendor folk) provided examples for how a default could be changed without invoking a flag day. Greg Hankins, in particular, provided a detailed explanation of his company's process. The proponents of "it's hard to change defaults" didn't follow up to the various rebuttals, so on the balance I would have to say they're "in the rough". It's a bit dicey to make this call since failure to follow up can also reflect simple fatigue, but in this case the conversation doesn't just tail off, it ends with concrete arguments on the "this can be done" side.

2. Related, there is the position that "yes of course anything can be done in software but the cost/benefit ratio isn't right". This is clearly a matter of personal taste so can't be dismissed (or supported) solely on the basis of logic. 

3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply only to Internet routing and not other applications?
Pro: the motivation section of the document calls out the Internet use case
Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for different AFI/SAFI is confusing for the user and the extra complexity not required.

4. How about "default no-propagate" rather than "default no-advertise"?
Pro: Keeps CE configurations more compact, less surprising behavior.
Con: Behavior is actually more surprising (since harder to explain, less consistent). Doesn't cover all plausible use cases.

5. These defaults will hurt some deployments that want to rely on the old defaults. Examples, data centers, CEs.
Pro: as stated.
Con: it seems unlikely anyone is actually relying on default behavior in their data center, since defaults vary between vendors, can any examples be brought forward? None offered, instead a couple DC operators stated support for the draft as written. For CEs, discussion around upgrade strategies without breaking existing deployments, see #1.

6. This should not update 4271, not be Standards Track, it should be a BCP, should be Informational, etc.
Pro: It's not protocol, but just defaults, doesn't affect state machine, wire encoding.
Con: Plenty of Standards Track documents specify defaults when considered important to operation of protocol, and even more ephemeral things such as textual encodings.
Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to make existing implementations nonconformant.
Con: Formally, it doesn't work that way. Also, the point is to ask implementations to change.

7. There are various other proposals to mitigate route leaks and provide BGP security features.
Pro: implied, "we've already got one"
Con: some of these are still in flight, not even WG docs. None address exactly the same issues. Some don't even overlap.

8. Why not just do perfect filtering at the service provider border? It's an education problem!
Pro: perfect filtering prevents harm from route leaks.
Con: decades of experience indicate strategies that require perfection are not successful.

Taking a rough head count, here's here I understand people's positions to have ended up:

Commented, no discernible position on advancing the doc -- 2

chris morrow
alvaro retana

Pro -- 16

john scudder
randy bush
brian dickson
joe provo
warren kumari
jared mauch
job snijders
gert doering
mik abrahamson
jeff haas -- support, though would prefer BCP
greg hankins
nick hilliard
jay borkenhagen
ian dickinson
martijn schmidt
keyur patel

Con -- On procedural grounds (should be a BCP, or should be Informational) -- 3

eric rosen -- would be OK as Informational, opposes other statuses
tony przygienda -- it should be a BCP
enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the rough")

Con -- In the rough -- 2

acee lindem -- contrary to auto-discovery (rebutted, in the rough), should have a 'backwards compatibility' section
jeff tantsura -- changing defaults "can not be changed". -- in the rough

Con -- Other objections, in most cases not explicitly stated as opposing advancement but that's my reading of their mood -- 4

robert raszuk -- not explicitly, but has raised numerous "but what about...", all or most replied to
alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare anyway', both later rebutted and not replied (so, "in the rough")
tom petch -- not explicitly, but generally skeptical tone to comments. specifically requested an analysis of what harms the proposal might cause. (not done or replied to AFAIK)
bruno decraene -- would rather improve route-leak draft, numerous other points and suggestions, mostly replied to, too much to summarize