Subject: [Gen-art] Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Nov 2006 16:48:59 -0600

I am the assigned Gen-ART reviewer for
draft-ietf-mip6-ikev2-ipsec-07.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-mip6-ikev2-ipsec-07.txt
Title: Mobile IPv6 Operation with IKEv2 and the revised IPSec
   Architecture
Review Date:  Nov. 14, 2006
IESG Telechat date:  Nov. 16, 2006

Summary: This draft is ready for publication as a Proposed Standard RFC.

The draft describes Mobile IPv6 operations with respect to the revised
IPSec architecture [RFC4301] and IKEv2 [RFC4306].  These revisions
contain enough changes in them to warrant an update to RFC3776, the RFC
that this document updates.

Some nits and additional feedback follows:

1) In S4, the authors state that "Many of the requirements are repeated
  from RFC3776 to make this document self-contained and complete."
  There are a fair number of requirements in subsequent sub-sections.
  It may help if the authors tag each requirement that was already
  present in RFC3776, so the reader can see which new requirement was
  generated by this draft.

2) Nit: S6.1, under heading "mobile node SPD-S:"
    s/=BU/= BU/

3) In S9, first full paragraph of Page 22: "In case the home agent ...
  an INTERNAL_ADDRESS_FAILURE message."  If a mobile node gets an
  INTERNAL_ADDRESS_FAILURE message, does it make sense to specify
  what should it do, if anything?

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 25 Nov 2006 12:37:43 -0800

hi,

thanks for the review. responses inline.

>  present in RFC3776, so the reader can see which new requirement was

we would like to keep this document self-contained,
basically one needn't refer to RFC 3776 at all to
implement this spec. the very initial versions of
the document were written with only the new
requirements listed, but folks didn't like it.

> 2) Nit: S6.1, under heading "mobile node SPD-S:"

fixed.

>  what should it do, if anything?

good catch. the mobile node has the following
options.

1. it can attempt to auto-configure a home address
as described in section 5.3.2 of
draft-ietf-mip6-bootstrapping-split-03.txt. the
sequence is a bit complicated though. it has to
terminate the current IKE exchange and initiate a
new one. in the new IKE_AUTH exchange, the MN
should try to auto-configure a home address.
2. switch to another home agent (most home agent
discovery mechanisms return more than one home
agent).
3. throw an exception and report and error to the
user.

2) seems to be simplest option.

comments?

Vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 27 Nov 2006 09:28:20 -0600

> requirements listed, but folks didn't like it.

OK.  More inline.

> 2) seems to be simplest option.

I am viewing this from a generalist angle; so please filter
what I write through your subject matter expert lens.
It appears to me that (2) sounds reasonable, and if all the
subsequent home agents should return an INTERNAL_ADDRESS_FAILURE
(for whatever reason), then (3) should kick in.

Thanks,

- vijay