Jari, we have addressed those comments, and have added Peter Yee in the "acknowledgement" section.
Michael > -----Original Message----- > From: Jari Arkko [mailto:[email protected]] > Sent: 20 August 2014 09:20 > To: Peter Yee > Cc: [email protected]; 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
