Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)

Randy Bush <> Mon, 06 April 2020 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AE6A3A0D59; Mon, 6 Apr 2020 11:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DcExFASOkEnp; Mon, 6 Apr 2020 11:09:28 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 010FD3A0D7E; Mon, 6 Apr 2020 11:09:27 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1jLWBZ-0005wC-6q; Mon, 06 Apr 2020 18:09:25 +0000
Date: Mon, 06 Apr 2020 11:09:21 -0700
Message-ID: <>
From: Randy Bush <>
To: Robert Wilton via Datatracker <>
Cc: The IESG <>,,,,,,
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2020 18:09:30 -0000

> 1) In the first sentence of the introduction: Is it really correct that the
> "This document does not change semantics of [RFC6811] RPKI-based origin
> validation"?  Given that the 4th paragraph in the introduction then states that
> "This document clarifies ..."

the document adds, not modifies.

> 2) I wasn't entirely sure that section 2 (Suggested Reading) is
> required at all, given that this is effectively what section 8.1 and
> 8.2 is listing anyway, but equally I'm okay if the section is left in.

yes, the Suggested Reading kinda duplicates many References.  yet we
still get requests to enumerate all the bgp features which modify AS
and other disgusting bgp knobs.  it was hoped that a bit of rtfm would
help.  there is an underlying problem that there are many knobs which
are not in rfcs; and it is not clear that they are even enumerable.

> 3) The security section is terse, and I agree that this doesn't introduce any
> new security issues.  But I was wondering if the purpose of this clarification
> is to improve security with more reliable filtering, and if so, would it be
> helpful to have a sentence in the security section that states that?

   This document does not create security considerations beyond those of
   [RFC6811] and [RFC8481].  By facilitating more correct validation, it
   attempts to improve BGP reliability.

i hesitated to say increses 'security', as origin validation is more
accident reduction than a real security mechanism.  this distinction is
too oft misunderstood.
> 1) In the first sentence of the introduction "of [RFC6811] of RPKI-based origin
> validation" -> "of [RFC6811] RPKI-based origin validation"?

actually, i looked at the title of 6811, and <blush>  the text is now

    [RFC6811], BGP prefix origin validation.