Security Requirements for BGP Path Validation
draft-ietf-sidr-bgpsec-reqs-12

Would like to see the 2119 usage sorted out per the others' comments but otherwise looks good to me.

What Adrian said...

On top of what Adrian wrote, there is always the question of what a SHOULD mean in a requirements document. 

Here are some examples of recent requirements documents.
1. http://www.rfc-editor.org/rfc/rfc7262.txt
	RFC 2119 keywords, but only MUST. No SHOULD or MAY

2. http://www.rfc-editor.org/rfc/rfc7226.txt
	RFC 2119 keywords with MUST/SHOULD/MAY
	With an explanation of the meaning: 

       Any statement that requires the solution to support some new
       functionality through use of [RFC2119] keywords should be interpreted
       as follows.  The implementation either MUST or SHOULD support the new
       functionality, depending on the use of either MUST or SHOULD in the
       requirements statement.  The implementation SHOULD, in most or all
       cases, allow any new functionality to be individually enabled or
       disabled through configuration.  A service provider or other
       deployment MAY enable or disable any feature in their network,
       subject to implementation limitations on sets of features that can be
       disabled.


3. http://tools.ietf.org/html/draft-ietf-cdni-requirements-17 (RFC EDITOR QUEUE)

       o  "High Priority": When a requirement is tagged as "{HIGH}", it is
          considered by the working group as an essential function for CDNI
          and necessary to a deployable solution.  This requirement has to
          be met even if it causes a delay in the delivery by the working
          group of a deployable solution.

       o  "Medium Priority": When a requirement is tagged as "{MED}", it is
          considered by the working group as an important function for CDNI.
          This requirement has to be met, unless it is established that
          attempting to meet this requirement would cause a delay in the
          delivery by the working group of a deployable solution.

       o  "Low Priority": When a requirement is tagged as "{LOW}", it is
          considered by the working group as a useful function for CDNI.
          The working group will attempt to meet this requirement as long as
          it does not prevent meeting the "High Priority" and "Medium
          Priority" requirements and does not cause a delay in the delivery
          by the working group of a deployable solution.

4. https://datatracker.ietf.org/doc/rfc6988/
	No RFC 2119 keywords.

I'm not religious at all on which way you chose, but 
1. be consistent (right now, it's not the case)
2. explain how the protocol spec. authors must interpret SHOULD/MAY/OPTIONAL (or should/may/optional) requirements.

From the early discussion between Adrian/Randy, I understand there is a willingness to fix this.
Therefore that's a COMMENT (I have nothing against the technical content). 
 

If you produce a new version ...
  == Outdated reference: draft-ietf-sidr-bgpsec-threats has been published as
     RFC 7132

  == Outdated reference: A later version (-03) exists of
     draft-ga-idr-as-migration-01

  == Outdated reference: A later version (-01) exists of
     draft-ietf-sidr-lta-use-cases-00

There is an interesting discussion going on in reference to Russ' draft on algorithm agility on the SAAG list, where folks are advocating for the pros and CONS to be included.  Would an informational reference be possible in requirement 3.21?  I don't know the timeline for this draft:
https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/

The SecDir reviewer had a few questions resulting from not being familiar with some of the terms used.  I am in an environment where data and control plane discussions come up, so the text is fine for me, but I do see his point and think it would be wrath adding a little more detail to the following sentence in the Security Considerations section.  I think you are talking about the path of each.
Maybe change from:
The data plane might not follow the control plane.
To: The data plane might not follow the path of the control plane.

SecDir review:
http://www.ietf.org/mail-archive/web/secdir/current/msg04876.html