[Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01
Linda Dunbar via Datatracker <noreply@ietf.org> Tue, 17 March 2020 21:53 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 BAA503A0856; Tue, 17 Mar 2020 14:53:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: sidrops@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.121.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158448201565.32201.9748655174984394118@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Tue, 17 Mar 2020 14:53:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/eHuYfMwCoe5nv7W3Srzt7DsvOyg>
Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01
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, 17 Mar 2020 21:53:37 -0000
Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document claims that it highlights an important use case of origin validation in eBGP egress policies, explaining specifics of correct implementation in this context. But I don't see where the "Use Case" is described. It seems to me that the document should have more sections to describe the Use Case and the procedure of Egress Export of the RPKI validated Origins. Section 3 Egress Processing only has one sentence stating that "When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer." What other choices there are ? Are there any routers that support RFC 6480 RPKI not performing this step? how? My two cents. Linda Dunbar
- [Sidrops] Opsdir last call review of draft-ietf-s… Linda Dunbar via Datatracker
- Re: [Sidrops] Opsdir last call review of draft-ie… Chris Morrow
- Re: [Sidrops] Opsdir last call review of draft-ie… Nick Hilliard
- Re: [Sidrops] Opsdir last call review of draft-ie… Randy Bush
- Re: [Sidrops] Opsdir last call review of draft-ie… Job Snijders
- Re: [Sidrops] Opsdir last call review of draft-ie… Randy Bush
- Re: [Sidrops] Opsdir last call review of draft-ie… Linda Dunbar
- Re: [Sidrops] Opsdir last call review of draft-ie… Ben Maddison
- Re: [Sidrops] Opsdir last call review of draft-ie… Randy Bush
- Re: [Sidrops] Opsdir last call review of draft-ie… Warren Kumari
- Re: [Sidrops] Opsdir last call review of draft-ie… Ben Maddison
- Re: [Sidrops] Opsdir last call review of draft-ie… Randy Bush