Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The
Routing Directorate seeks to review all routing or routing-related 
drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the 
Routing ADs.
For more information about the Routing Directorate, please see ​
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion 
or by
updating the draft.

Document: draft-ietf-sidrops-ov-clarify-03
Reviewer: Dhruv Dhody
Review Date: 10 Aug 2018
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:

     I have some minor concerns about this document that I think should be
     resolved before publication.

Comments:

     This is a standards track draft that clarifies the behavior of Origin
     Validation in BGP (and thus updates RFC 6811). It states that the 
origin
     validation MUST be done for all routes, including the imported 
routes; where
     as the RFC 6811 uses "SHOULD". This I-D further states that the 
policy is
     applied only if explicitly configured by the operator. The 
clarifications
     are clear and easy to follow. The I-D is technically sound and 
almost ready.

Major Issues:

     No major issues found.

Minor Issues:

     - The text in RFC6811 uses the term “lookup” and “validation 
state”, the
       clarification uses the term “mark”. This might be a bit pedantic but
       wouldn’t it be better to state the clarification in terms of RFC6811?

     - Since RFC4271 and RFC6480 are stated as mandatory reading to 
understand
       this I-D in section 2, shouldn’t they be normative references?

     - I agree with the Gen-ART review, that ask for BGP in the title, 
in fact
     “Prefix Origin Validation” in the title would be better!

Nits:

     - Expand RPKI in Abstract.

     - The Requirement language phrasing is little different from RFC 8174.

Thanks!
Dhruv