[Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 20 August 2024 04:28 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 D6E7DC180B56; Mon, 19 Aug 2024 21:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.709
X-Spam-Level:
X-Spam-Status: No, score=-7.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.453, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nist.gov
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq-WtYkPO7Ku; Mon, 19 Aug 2024 21:27:56 -0700 (PDT)
Received: from CH1PR09CU001.outbound.protection.outlook.com (mail-northcentralusazon11011040.outbound.protection.outlook.com [40.107.199.40]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DA8C151552; Mon, 19 Aug 2024 21:27:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V8oxLWCT3LeJSkDSqvizgoFr0ficdm17+g5IjozE3kGdGfGRaK5Qxi/gmK3Hy7cYNbT90zPgpk8NBoBevRwsmDd6LDnW+6be9DyJNXhnffibRRGzoHDT3wFcwWOVK9vgPNsaPDHhGL/2TWtxNyZxLPWpVWCwdatw2AxU+M5oorXWW1ISsK7ik4ffvz6daSflvxvgaaEiijQ7CxiUtMgOnB93gtG4eyqa4huxjHwjWSDt+Lzbt2Byx5gQBx/MfNNSkTdKYG841E1Ibw/ugX/Y9xhxisE0gcbRfE47W4FdrNyk45vmj2haTkszuUJ8RUngF8onOB2AM4HcPkOI5r8j1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XcD21IVdNeSbFY5P8NU7Q+XIu1JUfaZQmVW06cnFdG8=; b=TuJtbsINTa43old5jvVxj4tYtszhdiaJnMnht95QCK/kV51ww48sewQ6M6ytdckkql2IkPR4M3dEGwh8gogA2W2Io0LlHKWW3C0Umqk6ZVruWVhm6s3HZ5ejCQcilggiR2FMPxBcHHlpQQOtNV8qa/nnE3n/vEil80zKd+YDCo+X986VMiCJO+H38NuDEqSLAaeC0R42wSkhTdpf/Tlj7P5+wijfeXjeuP+jOxU8u3LTW9GqsMGULgHB4/nEn5kAN0/9h1/CMKhM4jHUnEN3zUCSC76fSbUN1WWkIRx8yRuGevET+7o/lccUNKaEzinJ75rOsedC6Jy6XVN3vFF1wg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XcD21IVdNeSbFY5P8NU7Q+XIu1JUfaZQmVW06cnFdG8=; b=ZpI3euDfZYJdR/PMqFPVTx2Eh1kz1CDcLpMw3MU7I6B4zB/4ZHLbFqnbUwg7pv6iQ+4pPlrs5mXKF3lLaD6LR9IoGbak45BOHWPe2Ona9LwnTCh/EptOw9hCDUuA7r1E+qOAY3VP/x4vDtc53RqxAluNdX0a1lj8k6jdIWLIoajfwR/PSFtH3bHxFRqgVE5VnUWIZmMxecI+maRJStVjGoX9K37HkIUt76Z+rUfeUz69FB75WXe6ZijfZdAKQtCzLtTZ5Zd53C4CsZW5m/oqD8e+nYGjTvK+e6iobqJyrcr3WnWG1JNCSdeCaI00a4tG6mfM30lxBfrW2lILUhYBSQ==
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB10183.namprd09.prod.outlook.com (2603:10b6:806:280::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.21; Tue, 20 Aug 2024 04:27:53 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::504f:d20c:9137:39a7]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::504f:d20c:9137:39a7%5]) with mapi id 15.20.7875.019; Tue, 20 Aug 2024 04:27:53 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Alvaro Retana <aretana.ietf@gmail.com>
Thread-Topic: Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
Thread-Index: Adryrn/zoUldxfbbTcmoG/W/ie6jgQ==
Date: Tue, 20 Aug 2024 04:27:53 +0000
Message-ID: <SA1PR09MB8142A0CA3BD0DAEA418B4CD4848D2@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR09MB8142:EE_|SA1PR09MB10183:EE_
x-ms-office365-filtering-correlation-id: f5093a90-3855-489b-9762-08dcc0d0757e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|38070700018;
x-microsoft-antispam-message-info: 4+Wc3ZTii6HwKES2STjx66ZvSK4e72FaYFxDt/agH087qJ0K4aCFhIx79HQApBhQuP0C90Oe/6TwevQao9FOOW3RpPDwNkSd4+8X8ea1cbqT680fqjD1IVN/GXasQkxEjcIP6M5HOoG4AqqJYi4KGuE/s/QpqJgitJrknYxO2CUPcfTRY+tPomEK2hxEUbEOxkXBGcIloftt6qEirxGr2Txf4O18z9PIn/0QS/zyJFcMguHQfcbg5Kxlvr5+3KVhSvuNMvLIfgfeNyL2kPulWNvmhfu20I3xZcnBofpi8ahEYloUiL1BLW8PRVyFmtO1/3DH1450ig2ZnBXRx/Pde7k2z6m3ed8zcyD/BQL0uXitXnfU3JzpDDyHdd8g1c0tcdt956FSYcVrFE+JuIjzpxHTCyzLYjjjBFVTtZ00DKy8I3sQX97d4kxgujMnO0WT0gdFd5400DlxsAmdSzLh1rgfKt4bqrK3Zj+icYXc2tbnu0myUdeqoQLwKjPqZaIeGS7QrrHNu+ZtS0rE4y6jYWr8IJLOhgVp7RtrGPhFlNuZI//xm7vSwuY3oFe7/xuL+EYPbRzJG6P4APnv72n1Rh2KyExGPxGS/ej/s9kQ+NK+/kEmmggCGpDRPTR0ZztdISav/qJAebeR+sXD3MYQ/lNkf+J1G49hSTAYFNPBPj9Jf2CGWn+XO7uGojrBw2j9gqkvvdq1VnlhEkc1ROkI7pzQf9/WMzot+4K135cYGWFjkTNmaCF0h//ChT9T/mxrMFIDU2ht+wDtQ6aJVET/wkUcQrFxFSeVu3yuDKYDOOviyJWYlVA8ArrO/vYxIRPVP5QGOJELGhPKBthYC1oh/6c3jBl1yTXQyj1RwfVD5VQzJFF2BFZFWqMh9iVz+R3nrbePJsuTKFRVTBPrbFW6mcjoyYSNMnq/H3DZYT4KrGoTYaD0Bqj6Gqhi6Ma5rfw+1Kka8sLoKqucpyO+dCP7oeQyvDm1kapoYyqXiV4vadgr9gtZJJEFhyzhgHhKY312/ZsqUpcFEigJkEPtRuYAn8yDuNITSbXsDn6yg0ywXFbQn7LwLKPROQ5LR2uo6PZZaJHDt3Xh9ZiVKrPxshSqIcWewwhMSEM8ys8IPj6WMCuRg+A78s/9dEQOaSrHEoKnubI2l7yJtsUrFu6gAc8mQP3laIfCgIIhSpPdkSDrqNcnxpNghvcpFvuGc6fh4ghKQyPY6YEzRz5S1Igc1R4gdzPT6s8KuMNiMSaSpaB7Irm9EsBTHhYx2fr7T8hGmOG3QXz2m6yX8Wa1FyHt9tx7X4raQ+d/Vq9+rPztgGdVhILPNhJGeAge8R1tpZkyv9gEXSLlIvV55f6S8MMaXKl5Nk/CmMPa9IROYio/GCXimIA=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR09MB8142.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5tAwt2oerjvtJom3jOIVr9d7VGzSjJ7FYnsgNvTQToe92K7t7z1iwoIaDq6ShlEFWRZStW7vfv5STLfNibh0LQrNz2ITslLePZfYfewESH6vz5Hpmx53tiIJI5SFS19d+Hk4L18Lu1zqZydtdrPFEf4evgHZ7tVBtrrTuqSVN53KvnZcm0uKDaaf6lPI8JGT/crUMbBL64nzkjIdzJUTlhqNA5STsT3KK6TafSfrAfPkEbGDKZaXd7+jIu383hdFeQflm7+ytuynQyL9nVDFce1NZ6bClVIyzlWXxUjRRB7vAe+c00FUBVLon91hO6OYEfJVzebpGKYb9uWgZRzlZtA8bDR1DqzYCPav6x6SqA1muvocdNXxzrrzufxKSnXmfpXDr2umokSEE/nAHYBDMG51A4b2cuULr7S/wJW2LZ0eDQb1F7BhSnHtdlctXcPzmV/dte3+JxMNAujDWkXJZKyrvld6PcvBZ2ksf0kcT3E7nIyySeayjqebSDs5uFXmkmg80pE1Vgb2qt0+a43pa+6GulH9+f354OZE+Igxj98fnPydpJXl13n9K3gUtTPfb/9CPf9VnWBWAbv8M7ZncPT1pGx71G+upHv3Omng0DaGTcm9R0ro81wWX4K3gsaRZqXFc1axsu6dQvqTcSjJ2XE36L/ArAH9smIVZa0XUlZCjYKAl/o1vUar5uI+1QW1oSNrI7Nf9qwJmK0yS7E0fxyUWIKsbs0IjcJ/U7G4YyK5s1VqOBIa3+uTBYGdsvJglyUk9QShAwzGUWBYHjXK32UtaixhBb158H3qjapb5mRhk7AYMcweNjlrAmqJT9YiSrz4BWPmuh4iwxW/AdeAQ4MCIHVW8FJ9qwO7hBJiG3sB2U+UXAqO+mkRwXNek8UblcFdGvfOmLLneNX+iaSijECdOLxc8136Kbb0FoZtv0Ml5R2yUjOkj/1ESZk+QYB6gyVs5gs0YCQ32WoV6utcQucnJ1m44Hbq912Btw9neWT82bOUbO9OXoHf8WwZaZ4ZckeIaseFfD5uXfFclbWiZbWF2TERCG09a5A11XuHHSw+2StmjcLx9P2dl4eX0VREjDSiYxxPL8BYnj+dvtk72vSbWjvxAuKRoyV0WF7RbW4cdZ9PyALB6ZZTOivj4ghTy1pNp8TchH6pLWb+/TTEDbDnNlGNe8r+BLAQc1cwitBCYisp7EnmI94JZUULk181pYV9GY9i0kiItVj/Vu0GI1XlKrGh/qJdKROyPPhkIxfE+UqWRO+MaKkxD3b58E5UV9kvy3/tduO9e4WKq66NWATp95Razlh6FAi+mMWt7wY+SmLnbCNBn1i7JfPj50LeWYF7r/g/JvzoXUxm1TrEQHt0agCG2DZ7rgLGW0Igp5tpwrBMiFMMcX9HOYbgc89SYu21JzKgBC0Av2/h8hsEvxuKIhUaYNFdGbdsDUCLj+kuLOdP19lhoP5QBeyQ+Ku+Y60bPdZ1W3r3Cuak12kiid63IwW9QyZ0V+TECDuM6/TC1t9x7ZluJSdctT+diU050uogtOPco0LA8Rd/i92QWA9lrcfA530OGgPznO5y9XE=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f5093a90-3855-489b-9762-08dcc0d0757e
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2024 04:27:53.6592 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB10183
Message-ID-Hash: WPA7NXRT6JLPE3S6QM7L4KOBLJR56L24
X-Message-ID-Hash: WPA7NXRT6JLPE3S6QM7L4KOBLJR56L24
X-MailFrom: kotikalapudi.sriram@nist.gov
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zxMC5Z53W5s3WCO026Izp1tWowM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Alvaro,

Thank you for your review and comments (July 17th). Jeff responded to some of your comments earlier. We waited for other comments from WG members. Now the draft has been updated and version-15 has been published. All your comments have been carefully considered and changes incorporated. 

New version (v-15):  https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-15

Diff:  https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-deprecate-as-set-confed-set-14&url2=draft-ietf-idr-deprecate-as-set-confed-set-15&difftype=--html 

Looking at the Diff file may readily make it evident for you, but still I share my responses inline below marked with [KS:].

>From Alvaro Retana <aretana.ietf@gmail.com> Wed, 17 July 2024
> I support this document moving forward.  It is time to
> proscribe/deprecate/prohibit the use of AS_SETs and AS_CONFED_SETs.  Their
> use is low and the advantage of this action facilitates the deployment of
> BGP security mechanisms.
>
> However, the intent to proscribe/deprecate/prohibit does not match the
> text.  From §3:
>
> 153   BGP speakers conforming to this document (i.e., conformant BGP
> 154   speakers) SHOULD NOT locally generate BGP UPDATE messages containing
> 155   AS_SETs or AS_CONFED_SETs.  Conformant BGP speakers SHOULD NOT send
> 156   BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs.  Upon
> 157   receipt of such messages, conformant BGP speakers SHOULD use the
> 158   "treat-as-withdraw" error handling behavior as per [RFC7606].
>
> 160   The document uses normative language such as "SHOULD NOT send" rather
> 161   than "MUST NOT send" with the intention of allowing some transition
> 162   time for existing implementations and avoiding abrupt disruptions for
> 163   the operators currently using AS_SETs or AS_CONFED_SETs.  However, it
> 164   is strongly urged that operators stop sending UPDATEs with AS_SETs or
> 165   AS_CONFED_SETs as quickly as possible to avoid having UPDATEs dropped
> 166   by BGP security mechanisms such as RPKI-ROV and BGPsec.
>
> Regardless of the text in an RFC, the transition won't be immediate.  I
> don't agree with the use of "SHOULD NOT" with the explicit intent "of
> allowing some transition time".  Using this language provides a hole that
> allows conformant implementations to continue to use AS_SETs or
> AS_CONFED_SET indefinitely.
>
> Also, the Introduction mentions that "aggregation that involves AS_SETs is
> very seldom used", so the impact would be minimum.
>
> I haven't been following the discussions about this document in detail, so
> my point may have already been addressed on the list.  If that is the case,
> I will stand in the rough.

[KS:]  I think you will like the updated Section 3.  We now say, "MUST NOT advertise" instead of "SHOULD NOT send". Also, we use "MUST" while specifying treat-as-withdraw on receipt of UPDATE with AS_SET or AS_CONFED_SET. 

[KS:]  Also, we have moved the AS4_PATH related section into Sec. 3 as subsection 3.1 to try to keep all related specifications together in one place. This was also based on your suggestion (below).     

>
> I included other comments below.
>
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
> ...
> 151 3.  Recommendations
> ...
> 168   If a network operator wishes to consider BGP UPDATE messages with
> 169   AS_SETs or AS_CONFED_SETs received from an external BGP peers, they
> 170   MAY have a feature (knob) in their implementation to do so on a per-
> 171   peer basis.  The operator should understand the full implications of
> 172   choosing this option.
>
> "network operator...MAY have a feature"
>
> The action is not for the network operators, but for the implementation.
>
> Suggestion>
>
>    An implementation MAY include the ability to consider BGP UPDATE
>    messages with AS_SETs or AS_CONFED_SETs received from external BGP
>    peers on a per-peer basis.  Network operators should understand
>    the full implications of choosing this option.
>

[KS:]  I think, by looking at the Diff, you will find that this is all worded succinctly and more aptly in the spirit of "deprecate/prohibit" in Section 3 now. 

>
> 174   Network operators SHOULD NOT locally generate any new announcements
> 175   containing AS_SETs or AS_CONFED_SETs.
>
> This text is a duplicate of the text in the first paragraph of this section.

[KS:]  Yes, agree.  We have tried to eliminate all duplications the document (in v-15).

>
> 177   BGP security technologies (such as those that take advantage of X.509
> 178   extensions for IP addresses and AS identifiers ([RFC3779], [RFC6480],
> 179   [RFC6811], [RFC8205]) might not support routes with AS_SETs or
> 180   AS_CONFED_SETs in them.  Routes with AS_SETs have no possibility of
> 181   ever being considered RPKI-ROV valid [RFC6811] [RFC6907].
>
> BGPSec also doesn't support the AS_SET (not "might not").
>

[KS:]  Yes.  Now Section 4 (Treatment of Routes with AS_SET in RPKI-based BGP Security) addresses BGPsec and more (ROV, ASPA, etc.) with precise wording.

>
> 183 4.  Updates to Existing RFCs
>
> Except for these first 3 paragraphs, none of the subsections (4.*) contain
> any Updates to Existing RFCs.
>
> 185   This document deprecates the origination of BGP routes with AS_SET
> 186   (type 1) (see [RFC4271], Section 4.3).
>
> 188   This document also deprecates the origination of BGP routes with
> 189   AS_CONFED_SET (type 4) AS_PATH segments (see [RFC5065], Section 3).
>
> 191   BGP speakers conforming to this document - i.e., conformant BGP
> 192   speakers - SHOULD NOT originate BGP UPDATE messages containing
> 193   AS_SETs or AS_CONFED_SETs.  Upon receipt of BGP routes containing
> 194   AS_SETs, conformant BGP speakers SHOULD use the "treat-as-withdraw"
> 195   error handling behavior as per [RFC7606].
>
> This is the same text that is in §3.  Keep the specification in one place:
> it is easy for maintenance of the document, it avoids potential conflict,
> getting out of sync, etc.
>

[KS:]  What RFCs are updated is concisely stated now in updated Section 3 in one brief paragraph as follows:

   Per above specifications, this document updates RFC 4271 and RFC 5065
   by deprecating AS_SET (see [RFC4271], Section 4.3) and AS_CONFED_SET
   (see [RFC5065], Section 3), respectively. 

[KS:]  All duplication that existed earlier has been eliminated.  The "Brief aggregation" material is now a separate section (Sec. 5) by itself.

> ...
> 232 4.2.  Issues with "Brief" AS_PATH Aggregation and RPKI-ROV
> ...
> 245   *  In the presence of such varying origin ASes, it would be necessary
> 246      for the resource holder to register Route Origin Authorizations
> 247      (ROAs) [RFC6482] for each potential origin AS that may result from
> 248      the expected aggregated AS_PATHs.
>
> RFC6482 is Obsolete; use RFC9582 instead.

[KS:]  Yes, replaced.

>
> 250 4.3.  Recommendations to Mitigate Unpredictable AS_PATH Origins for
> 251      RPKI-ROV Purposes
>
> 253   In order to ensure a consistent BGP origin AS is announced for
> 254   aggregate BGP routes for implementations of "brief" BGP aggregation,
> 255   the implementation should be configured to truncate the AS_PATH after
> 256   the right-most instance of the desired origin AS for the aggregate.
> 257   The desired origin AS could be the aggregating AS itself.
>
> Should there be Normative language in this paragraph?
>
> The obvious place seems to be s/implementation should be configured to
> truncate/implementation SHOULD be configured to truncate   But, should that
> be a "MUST" instead?  If the aggregation is to be "consistent", then the
> operation should be REQUIRED and not just RECOMMENDED.
>

[KS:]   We use "MUST" now;  see Sec. 5.2 in the updated version.

> ...
> 268 4.4.  Interactions with Four-octet AS Numbers
>
> 270   [RFC4893] created support for four-octet AS numbers in BGP.  A BGP
> 271   speaker not supporting four-octet AS numbers, termed an "OLD speaker"
> 272   in that document, might have routes that carry the AS4_PATH Path
> 273   Attribute.  This attribute is used to carry four-octet AS paths
> 274   across OLD speakers and may contain AS_PATH segments of type AS_SET.
>
> RFC4893 is Obsolete; use RFC6793 instead.

[KS:]   Yes, done.

>
> 276   BGP speakers conforming to this specification MUST NOT use the
> 277   information contained in the AS4_PATH for treat-as-withdraw purposes.
> 278   Instead, only the AS_PATH should be used.
>
> I'm assuming that this reference to "treat-as-withdraw purposes" refers to
> the specification in §3.
>
> If so, it might be helpful to add to the specification in §3 the fact that
> the receive part only applies to the AS_PATH.  Suggestion> s/Upon receipt
> of such messages.../Upon receipt of such messages in the AS_PATH...
>

[KS:]   Your suggestion is incorporated in the revised Sec. 3 & Sec. 3.1.  Previous Sec. 4.4 is condensed and moved into Sec. 3.1.

> ...
> 370 9.2.  Informative References
> ...
> 413   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
> 414              Patel, "Revised Error Handling for BGP UPDATE Messages",
> 415              RFC 7606, DOI 10.17487/RFC7606, August 2015,
> 416              <https://www.rfc-editor.org/info/rfc7606>.
>
> This reference should be Normative: it is used to specify an action in §3.

[KS:]  Yes, done.

>
> 418   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
> 419              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
> 420              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
>
> This reference should be Normative.

[KS:]  Yes, done.

>
> [EoR-14]

Thanks! 
Sriram