 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
This is a cryptographically signed message in MIME format.Vijay Devarapalli wrote:
we would like to keep this document self-contained,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.
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.
OK. More inline.
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)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?
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 siFrom mip6-bounces at ietf.org Thu Nov 30 13:46:03 2006
we would like to keep this document self-contained,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.
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.
OK. More inline.
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?
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?
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
--
Vijay K. Gurbani vkg at {lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Mip6 mailing list Mip6 at ietf.org https://www1.ietf.org/mailman/listinfo/mip6