[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 07 April 2020 16:03 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A83A0DA1; Tue, 7 Apr 2020 09:03:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158627541271.31464.16065110875282211603@ietfa.amsl.com>
Date: Tue, 07 Apr 2020 09:03:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BEJxpBv1sl8Hn27WFkpmcbUkwVA>
Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 16:03:33 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-ov-egress-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract [IIRC the mention of "updates 6811" is queued already.] Section 1 As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH (To the extent that the speaker applies outbound policy at all? Or is that required by being a "validating BGP speaker"?) Section 3 will (or would) be announced to the peer. The effective origin AS may differ from that of the route in the RIB due to commonly available knobs such as: removal of private ASs, AS path manipulation, confederation handling, etc. Do we feel a need to add a "but not limited to"? Feels like overkill to me... nit: earlier we wrote "private AS(s)" Section 4 Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. nit: are complex policies necessarily non-deterministic (vs. "not easily predicted")?
- [Sidrops] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk via Datatracker
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Randy Bush
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Randy Bush
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Benjamin Kaduk