Ben, See inline. If you are ok with these changes, I will go ahead and submit an updated version of the draft.
On Nov 25, 2012, at 5:56 PM, Mahesh Jethanandani wrote: > Further trimming it to sections that require a response. > > On Nov 21, 2012, at 3:12 PM, Ben Campbell 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? > > Added this sentence. > > Although IKEv2 is discussed as a component of IPsec, KMP can use just the > mutual authentication and SA establishment portion of IKEv2. This statement has been further modified to: For point-to-point key management IKEv2 [RFC5996] provides for automated key exchange under a SA and can be used for a comprehensive Key Management Protocol (KMP) solution for routers. IKEv2 can be used for both IPsec SAs [RFC4301] and other types of SAs. For example, Fibre Channel SAs [RFC4595] are currently negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a possible option. > >> >>> >>>> >>>> *** 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) > > I have removed these unused references. > >> >>>> >>>> -- 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. >> > > Changed it to: > > In addition, the recommendations in RFC 5961 should also be followed ... Mahesh Jethanandani [email protected]
