Hi, thanks for the response. I removed sections that didn't seem to need further comment:
On Nov 19, 2012, at 1:58 AM, Mahesh Jethanandani <mjethanandani@xxxxxxxxx> wrote:
[...]
>>
>> *** Minor issues *** :
>>
>> -- section 2.2, last paragraph:
>>
>> The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I assume so, but there's been no mention of IPSec so far.
>
> No. It implies the use of IKEv2 protocol for performing mutual authentication and establishing SA. There is no suggestion of using IKE with IPSec.
>
> How about this?
>
> For point-to-point key management IKEv2[RFC5996] protocol provides ...
5996 describes IKEv2 as a component of IPSec, and a key-management mechanism for ESP and AH SAs. Now, I won't claim to be an IKE expert by any extent, but I think that if you mean to use IKE _without_ IPSec it would be good to add a sentence or two pointing that out. Or is there some other reference that could be used that describes using IKEv2 for non-IPSec SAs?
>
>
>>
>> -- section 2.3.2:
>>
>> It would be helpful for this section to describe whether privacy issues actually matter or not, rather than just stating the issues to be similar to those for other routing protocols.
>
> Changed it to:
>
> Labels, like routing information are distributed in the clear. There is currently no requirement for labels to be encrypted and that work is outside the scope of the KARP working group.
WFM
>
>>
>> -- section 3.1, 2nd paragraph:
>>
>> Does this mean that privacy is really not needed, or just that LDP does not state a requirement for privacy?
>
> Further clarified it in this section.
>
> Labels are similar to routing information which is distributed in the clear. It is important to ensure that routers exchaning labels are mutually authenticated and that there are no rogue peers or unauthenticated peers that can compromise the stability of the network. However, there is currently no requirement that the labels be encrypted.
Okay
>
>>
>> -- Section 6 (Security Considerations), 4th paragraph:
>>
>> If replay protection is required, shouldn't the draft discuss the details somewhere? I see only one mention in passing outside of this section.
>
> I have moved the replay protection requirement to the gap analysis section.
>
> However, this document is a analysis draft, and it is my understanding that details on what replay protection methods should be adopted, is best left to the routing protocols in question.
That's fine, pointing out the gap is sufficient.
>
>>
>> *** Nits/editorial comments ***:
>>
>> -- IDNits indicates some unused and obsoleted references. Please check.
>
> Found one unused reference and have removed it.
Seems like there were more than one. From IDNits:
== Missing Reference: 'IRR' is mentioned on line 92, but not defined
== Unused Reference: 'RFC2409' is defined on line 585, but no explicit
reference was found in the text
== Unused Reference: 'RFC3547' is defined on line 588, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)
-- Obsolete informational reference (is this intentional?): RFC 2409
(Obsoleted by RFC 4306)
-- Obsolete informational reference (is this intentional?): RFC 3547
(Obsoleted by RFC 6407)
[...]
>
>>
>> -- section 2.1, 5th paragraph:
>>
>> A mention of SHA1 seems needed here. Section 2.3.1.2 states the concerns about TCP-md5 more clearly.
>
> The 6th paragraph states the concern and mentions SHA-1. Did you want something more to be included?
No, sorry, on a re-read I think it's okay.
[...]
>>
>> -- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to Blind In-Window Attacks."
>>
>> sentence fragment.
>
> Changed it to say:
>
> In addition, the recommendations in Improving TCP's Robustness to Blind In-Window Attacks
>
Am I correct in assuming this merges with the following sentence? Otherwise, it's still a fragment.
[...]
Thanks!
Ben.