Responding to myself… compared -07 to -10. It seems that some of your points 
have been taken into account. I still think the SSH example is a bit weak, as 
you pointed out…

Jari

On 20 Aug 2014, at 10:19, Jari Arkko <[email protected]> wrote:

> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to