[Idr] secdir review of draft-ietf-idr-ls-distribution

⌘ Matt Miller <mamille2@cisco.com> Wed, 08 April 2015 22:19 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5E7181A9067; Wed, 8 Apr 2015 15:19:54 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA651A9066 for <xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com>; Wed, 8 Apr 2015 15:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.2
X-Spam-Level:
X-Spam-Status: No, score=-9.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 2bDXX22Edouj for <xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com>; Wed, 8 Apr 2015 15:19:51 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1013D1A9057 for <draft-ietf-idr-ls-distribution.all@ietf.org>; Wed, 8 Apr 2015 15:19:51 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com ([173.37.86.75]:7068) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <mamille2@cisco.com>) id 1YfyK5-0004Rb-2u for draft-ietf-idr-ls-distribution.all@tools.ietf.org; Wed, 08 Apr 2015 15:19:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1428531589; x=1429741189; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ju7P58caE8AddNNhGQZ1b6EdvcZIpnPzOspTGWvp9O4=; b=EY0p6ysKhrWtF8ZbIYepXTk5P34N6+z59d+2WZtpVsQgqZZGEjpQ63hj Nj+25aleah+EVgb1a/WeFHwahNfPFRTOlp0mSVOglHt5ERdqnSTIPhNcA adWDaJe8n8FUBANY2xRsiPiPcnJ2CX1/hXIaWm+vbXtavOZb+lGd3Jtnf 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A7BQCsqCVV/4cNJK1cgwhSXAWDEMIqhzNMAQEBAQEBfoRJDwF7AgUhAhECNhYBDAYCAQGIJrZWllkBAQEBAQUBAQEBAQEYBIEhkXWBRQWLJ4lFhg+BHYM3gkKJe4NKIoICHYFvUIFEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,546,1422921600"; d="scan'208";a="410365429"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2015 22:19:42 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t38MJgMM003821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 22:19:42 GMT
Received: from [64.101.72.33] (64.101.72.33) by xhc-aln-x02.cisco.com (173.36.12.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Apr 2015 17:19:41 -0500
Message-ID: <5525A97D.70607@cisco.com>
Date: Wed, 8 Apr 2015 16:19:41 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <mamille2@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>, <draft-ietf-idr-ls-distribution.all@tools.ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.33]
X-SA-Exim-Connect-IP: 173.37.86.75
X-SA-Exim-Rcpt-To: draft-ietf-idr-ls-distribution.all@tools.ietf.org
X-SA-Exim-Mail-From: mamille2@cisco.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-idr-ls-distribution.all@ietf.org
Resent-Message-Id: <20150408221951.1013D1A9057@ietfa.amsl.com>
Resent-Date: Wed, 8 Apr 2015 15:19:51 -0700 (PDT)
Resent-From: mamille2@cisco.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-idr-ls-distribution.all@tools/q6lzYgy3uV5iZiorf32MgOwT87U>
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/AA6LLL0g2tRfkb5Nvx9pwxdJQL8>
X-Mailman-Approved-At: Thu, 09 Apr 2015 08:06:20 -0700
Subject: [Idr] secdir review of draft-ietf-idr-ls-distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 08 Apr 2015 22:19:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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@cisco.com >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVJal9AAoJEDWi+S0W7cO1Dc8H/j9UqCwTn+VecPTnd2b5UQ2W
mhFM5SGMc+KRpBjriTmxs/snwoLFtuD+u5aGuEEp+mvebR8C2Tg2wDga4TE1R5cu
fs+kmmvzgGkoKtQGcg3MfnAp5F+MEKGRh9iLUt6bBzSEZqMjDvchx+Ha9z+Raxs4
W2Paw6UUr6+RIsKgeioRKYjk+hMQHabtSrb9rdJEjSLgcMcOgXPeLwMz/wlq/pVZ
j5qPVSYTnOcfDEhRle6K99HZ/MZucGwxAv0fe8ukc0X5Ate9P0HrA3pW2oNyAVSX
4MdTvkxcIHucbeiWKpWMy8LpK+9e9CeVKBmvEitixnvOjqLq3qmS0SBu5O7P+qI=
=8yaG
-----END PGP SIGNATURE-----