Last Call Review of draft-ietf-idr-ls-distribution-10

Request Review of draft-ietf-idr-ls-distribution
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-04-08
Requested 2015-03-19
Authors Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray
Draft last updated 2015-04-09
Completed reviews Genart Last Call review of -10 by Alexey Melnikov (diff)
Secdir Last Call review of -10 by Matthew Miller (diff)
Opsdir Last Call review of -10 by Carlos Pignataro (diff)
Rtgdir Early review of -05 by Acee Lindem (diff)
Assignment Reviewer Matthew Miller 
State Completed
Review review-ietf-idr-ls-distribution-10-secdir-lc-miller-2015-04-09
Reviewed rev. 10 (document currently at 13)
Review result Has Nits
Review completed: 2015-04-09


Hash: SHA512

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments that had
arrived in a more timely manner.

I think the document is ready, but I have a couple of nits.  Please
note that I am not well versed in the subject of network routing,
so these nits might be irrelevant due to my naivete.

*  Section 6.2.6. is written in terms of what an operator ought to
   do, but I'm not entirely sure what that means to an implementer.
   Does that mean the implementer MUST provide some sort of mechanism
   to allow the operator do follow the SHOULD?  I admittedly only
   glanced through RFC 5706 and RFC 4271, so if this is actually
   covered more generally then please ignore this item.

*  In Section 8., second paragraph, are there known cases where it
   might be ok to accept Consumer peer updates, therefore violating
   the SHOULD NOT?  If there are not, I would think MUST NOT is more
   appropriate.  If there are cases where the SHOULD NOT can be
   ignored, does it makes sense to briefly describe one or two of
   them?  While there are several places in this document where SHOULD
   (or SHOULD NOT) is used without any such exceptions described, it
   seems pertinent to me to describe a case or two for such a SHOULD
   (NOT) in the Security Considerations.

Thank you for your consideration,

- -- 
- - m&m

Matt Miller < mamille2 at >
Cisco Systems, Inc.
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -