Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07

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