Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07
Jari Arkko <jari.arkko@piuha.net> Thu, 25 September 2014 13:32 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0431A007E; Thu, 25 Sep 2014 06:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 5-uL0tojKpqw; Thu, 25 Sep 2014 06:32:38 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 054B41A6FE3; Thu, 25 Sep 2014 06:32:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 903D72CEDC; Thu, 25 Sep 2014 16:32:24 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0UPjEntGANk; Thu, 25 Sep 2014 16:32:20 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 5BAAF2CED9; Thu, 25 Sep 2014 16:32:20 +0300 (EEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_67374B6F-52B8-4C45-8706-556A22868932"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C515DA@xmb-rcd-x14.cisco.com>
Date: Thu, 25 Sep 2014 16:32:19 +0300
Message-Id: <7B9F3822-6A66-44C6-BCB8-C8DE32CBF726@piuha.net>
References: <012001cf52f7$f0361670$d0a24350$@akayla.com> <0AC232F9-A8E7-4632-BC67-682813152C70@piuha.net> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C515DA@xmb-rcd-x14.cisco.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/WOIuzSNGFCLrm3haxG8LBU3_3xA
Cc: "draft-ietf-opsec-lla-only.all@tools.ietf.org" <draft-ietf-opsec-lla-only.all@tools.ietf.org>, Gen Art <gen-art@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Sep 2014 13:32:41 -0000
Thanks! On 25 Sep 2014, at 16:18, Michael Behringer (mbehring) <mbehring@cisco.com> wrote: > Jari, we have addressed those comments, and have added Peter Yee in the "acknowledgement" section. > > Michael > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: 20 August 2014 09:20 >> To: Peter Yee >> Cc: draft-ietf-opsec-lla-only.all@tools.ietf.org; Gen Art; The IESG >> Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07 >> >> Hi, >> >> I'm wondering which of the below issues have been corrected in the most >> recent version of the draft. Have the authors seen the review? Some of the >> comments at least have been taken into account, so the answer is probably >> yes. >> >> But I do not see e-mails from the authors on this topic in my Inbox, so I want >> to check. >> >> Jari >> >> On 08 Apr 2014, at 09:58, Peter Yee <peter@akayla.com> wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-opsec-lla-only-07 >>> Reviewer: Peter Yee >>> Review Date: April-7-2014 >>> IETF LC End Date: April-7-2014 >>> IESG Telechat date: TBD >>> >>> Summary: This draft is basically ready for publication as an >>> Informational RFC, but has issues that should be fixed before >>> publication. [Ready with issues.] >>> >>> This document discusses the (controversial) use of IPv6 link-local >>> addresses on router infrastructure links. I don't find all of the >>> arguments for use of link-local addresses to be terribly compelling, >>> but I'm not utterly averse to the document's publication as a summary >>> of some of the pros and cons for those who desire to configure their >>> routers in the manner prescribed. There may be other reasons that >>> should be taken into consideration, but I lack a network operator's >> experience to discuss them. >>> >>> Minor: >>> >>> Page 4, 4th paragraph: I don't buy this argument. DNS can be >>> simplified for non-link-local addresses by simply not registering those >> addresses in DNS. >>> Use of link-local addresses isn't a requirement to simplify DNS. >>> >>> Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks >>> aren't really reduced unless the reduction is simply not being able to >>> attack a single router over multiple interfaces in parallel. A better >>> scheme for reducing SSH brute force password attacks might be to limit >>> the rate of responses to SSH login attempts in the face of repeated >> failures. >>> Considering dropping this marginal example. >>> >>> Page 4, 6th paragraph, 1st sentence: I'm not sure what is meant by >>> "the same result". Is this in reference to all 5 paragraphs that >>> precede the 6th? If so, you might wish to elaborate with "the same results >> as the above" . >>> However, if the same results can be obtained without going to >>> link-local addressing as this paragraph indicates, why is the use of >>> link-local addressing being suggested? The paragraph might do well to >>> explain why one scheme is preferable over the other. >>> >>> Page 6, 1st partial paragraph: the argument is made that "more work" >>> is required to discover all of an IXPs loopback interface addresses >>> before a generic attack can be mounted. This wouldn't seem to be a >>> lot of upfront work and once it has been done, the advantage is >>> negated. I don't find the argument particularly persuasive. >>> >>> Nits: >>> >>> Page 2, Section 2 title: change "Address" to "Addressing". >>> >>> Page 3, second paragraph: change "non link-local" to "non-link-local". >>> >>> Page 4, 1st paragraph, 3rd sentence: change "accellerated" to " >>> accelerated". >>> >>> Page 4, 5th paragraph, 2nd sentence: delete the comma after >>> "[RFC4987])" and change the "or" to "and". >>> >>> Page 6, 1st full paragraph, 1st sentence: change "allow" to "allows" >>> and insert "an" before "MPLS LSP". >>> >>> >>> -Peter Yee >>> >>> >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >
- [Gen-art] Gen-ART LC review of draft-ietf-opsec-l… Peter Yee
- Re: [Gen-art] Gen-ART LC review of draft-ietf-ops… Jari Arkko
- Re: [Gen-art] Gen-ART LC review of draft-ietf-ops… Jari Arkko
- Re: [Gen-art] Gen-ART LC review of draft-ietf-ops… Jari Arkko
- Re: [Gen-art] Gen-ART LC review of draft-ietf-ops… Michael Behringer (mbehring)