Skip to main content

Last Call Review of draft-ietf-idr-large-community-11
review-ietf-idr-large-community-11-genart-lc-sparks-2016-12-12-00

Request Review of draft-ietf-idr-large-community
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-12-16
Requested 2016-12-02
Authors Jakob Heitz , Job Snijders , Keyur Patel , Ignas Bagdonas , Nick Hilliard
I-D last updated 2016-12-12
Completed reviews Rtgdir Early review of -06 by Geoff Huston (diff)
Rtgdir Early review of -06 by Danny R. McPherson (diff)
Opsdir Last Call review of -11 by Rick Casarez (diff)
Genart Last Call review of -11 by Robert Sparks (diff)
Secdir Last Call review of -11 by Vincent Roca (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-idr-large-community by General Area Review Team (Gen-ART) Assigned
Reviewed revision 11 (document currently at 12)
Result Ready w/nits
Completed 2016-12-12
review-ietf-idr-large-community-11-genart-lc-sparks-2016-12-12-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-idr-large-community-11
Reviewer: Robert Sparks
Review Date: 12 Dec 2016
IETF LC End Date: 16 Dec 2016
IESG Telechat date: 5 Jan 2017

Summary: Ready with nits

First a question (I don't know if this should lead to a change in the 
document). You say the use of reserved ASNs is NOT RECOMMENDED and later 
that the attribute MUST NOT be considered malformed if it has a reserved 
ASN in it. Is it clear what a recipient is supposed to do if one of 
these reserved ANSs shows up here? If so (for my own education) could 
you point me to where that's described?

Nits:

Section 11.3 in the references is only referenced by the implementation 
status section which you instruct the rfc-editor to delete. Do you 
intend for the reference to also be deleted? If so, save yourself a 
round-trip with the RFC-editor and add instructions now. If not, you'll 
need to find a way to work a reference in that won't be deleted.

David Farmer makes a suggestion at 
https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s 
that looks reasonable to me. Please consider it.

The security consideration section start out with a sentence that 
strongly implies the reader might learn something about the security 
considerations for this document by reading RFC1997. That document's 
security considerations section says only that "Security issues are not 
discussed in this memo." I suggest simply deleting this first sentence. 
Please also consider if there are other BGP documents with substantive 
security considerations sections that you can point to instead.