[Idr] Genart LC review: draft-ietf-idr-large-community-11
Robert Sparks <rjsparks@nostrum.com> Mon, 12 December 2016 18:43 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C41294A9; Mon, 12 Dec 2016 10:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level:
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcty4R984-4Q; Mon, 12 Dec 2016 10:43:37 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81312129484; Mon, 12 Dec 2016 10:43:34 -0800 (PST)
Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCIhX8r038117 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 12 Dec 2016 12:43:34 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, draft-ietf-idr-large-community.all@ietf.org, idr@ietf.org, ietf@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
Date: Mon, 12 Dec 2016 12:43:33 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C170FFA7834C9F647083ECCD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TS4Knt2iRq1EKbNBFkEyfGk0pfw>
Subject: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 18:43:40 -0000
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.
- [Idr] Genart LC review: draft-ietf-idr-large-comm… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Job Snijders
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] One question about "Terminal Action bit… Christoph Loibl
- [Idr] One question about "Terminal Action bit" in… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] One question about "Terminal Action bit… Robert Raszuk
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jari Arkko