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 <[email protected]> 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.
