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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 06 Apr 2020 10:43:03 -0700

Robert Wilton 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:
----------------------------------------------------------------------

I'm not a BGP expert, but this document seems sensible to me.

Some comments:

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 ..."

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.

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?

One nit:

1) In the first sentence of the introduction "of [RFC6811] of RPKI-based origin
validation" -> "of [RFC6811] RPKI-based origin validation"?

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Apr 2020 11:09:21 -0700

> "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.

> 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.
 
> 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.

thanks!

randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 7 Apr 2020 08:07:37 +0000

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Randy Bush
> Sent: 06 April 2020 19:09
> To: Robert Wilton via Datatracker <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-sidrops-ov-
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-
> 02: (with COMMENT)
> 
> > 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 ..."
> 
[RW] 

Okay.  Possibly pulling the 4th paragraph about updating into the first paragraph would make the document more clear as to how it is treats/updates RFC6811, but I'm also okay if you want to leave the introduction as is.

> 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?
> 
[RW] 

LGTM.

> > 1) In the first sentence of the introduction "of [RFC6811] of
> > RPKI-based origin validation" -> "of [RFC6811] RPKI-based origin
> validation"?
> 

Thanks,
Rob