Hi Mahesh, The proposed changes work for me. Thanks! Ben. On Nov 30, 2012, at 11:03 AM, Mahesh Jethanandani <mjethanandani@xxxxxxxxx> wrote: > 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 > mjethanandani@xxxxxxxxx > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art