Security Requirements for BGP Path Validation
RFC 7353

Note: This ballot was opened for revision 11 and is now closed.

(Alia Atlas) Yes

(Richard Barnes) Yes

Comment (2014-07-09 for -11)
No email
send info
I'm not sure what you mean by saying that origin validation doesn't provide "cryptographic assurance".   Do you mean to say something like "authentication of the originator of the route"?  If I'm understanding correctly, the issue you're trying to point out here is that a ROA lets a prefix holder say "AS $foo may originate prefix $bar", but it doesn't prove that "This announcement for prefix $bar was originated by AS $foo"

Nit: "The authors wishe"

(Adrian Farrel) Yes

Comment (2014-07-04 for -11)
No email
send info
The mixed use of 2119 language could do with being tidied up to remove
any implication that there is meaning in the inconsistency. Actually,
when I read 3.1-3.3 I was rather pleased at the use of lower case words
(as a speaker of English :-) and then got grumpy in 3.4. 

I won't make a big thing of whether you choose to go upper case or lower
case, but your mixed usage is a little bit awkward. Probably, given the
wide scale usage in the rest of the document, you probably just want to
fix up 3.1-3.3 and quickly check the rest of the document.

3.11 has "it need NOT handle" which needs "not".

(Stephen Farrell) Yes

Comment (2014-07-10 for -11)
No email
send info
I'm not sure if this would be a good or bad idea but I'll ask
anyway since I'm happy to embarrass myself if it might help:-)
Feel free to chat about or entirely ignore this.

From time to time I get asked if there's any work to be done
with BGP (or interdomain routing) that might help to make
pervasive monitoring harder. I always answer "dunno, what do
you think?" since I do not know. Would it be worth adding a
requirement here that designs should consider whether and if
so the extent to which confidentiality being a part of BGPsec
might be beneficial? I guess there's no formal need to add
this since we do have a BCP on the topic (BCP188) but it might
be something that designers would not otherwise consider, so a
mention could be useful.

(Jari Arkko) No Objection

(Benoît Claise) No Objection

Comment (2014-07-07 for -11)
No email
send info
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

Alissa Cooper No Objection

Comment (2014-07-08 for -11)
No email
send info
Would like to see the 2119 usage sorted out per the others' comments but otherwise looks good to me.

(Spencer Dawkins) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-07-06 for -11)
No email
send info
What Adrian said...

(Kathleen Moriarty) No Objection

Comment (2014-07-09 for -11)
No email
send info
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

(Martin Stiemerling) No Objection