Document:   draft-ietf-mip6-bootstrap-ps-04.txt
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Sunday 2/26/2006 2:19 PM
IESG Telechat Date:  Thursday, 02 March 2006

Summary: This document is almost ready for Informational.  There are a small 
number of very minor issues and questions plus a fair number of 
editorial nits which I think can all be handled by RFC Editor notes and 
during copy editing.

Review:
Generally this document is in good shape.

Minor Issues and Questions:
s3, 1st bullet: If boostrapping creates an IKE pre-shared secret, isn't 
that enough to be able to create the SA between HA and MN?  Do you need 
both? Or does it depend on whether RFC4285 is being used or not?

s5.2.1: Is the phrase 'traditional AAA infrastructure' sufficiently 
well-understood?  I think it may need a few hints as what is traditional 
will change over time!

s5.2.2: I would have thought this section belong with 5.1 (addressing) 
rather then 5.2 (security infrastructure).

s6, para 3: The phrase 'is not within the geographical area' doesn't 
quite cover the case. An ASP may be present in the geographical area but 
not accessible and it sounds as if it only applies to ASPs who are 
regionally limited.  Something like 'is not directly usable for 
communication at the current location of the MN' might be better.

s9.2: Should also mention (in last para) the need for replacement of 
algorithms as and when attacks become possible.

Editorial nits:
s1: s/mobile node/mobile node (MN)/  (the abbreviation is currently set 
up in s1.2 but is used in s1.1).

s1.2: s/subsequent bootstrapping/the need for subsequent bootstrapping/

s1.3, trust relationship: s/two parties/the two parties/

s2: s/in the Mobile IPv6/in Mobile IPv6/

s2: s/Yet another assumption is that some/Some/

s2: Expand acronym NAI.

s3: The last two bullets need to be slightly rephrased to make them into 
goals:
- next to last bullet: s/needs to be/must be/
- last bullet replaced with: The solution should be applicable to all 
feasible deployment
                             scenarios that can be envisaged, along with 
the relevant
                             authentication/authorization models.

s5.1.2, para 6: s/istance/instance/

s5.1.3, title: s/Management requirements/Management Requirements/

s5.2.1, para 3: s/issue/send/

s6 para 1: s/as it pertains/as they pertain/

s7, last para: The sentence 'The seed information is described further 
in Section 8.' should probably be a paragraph on its own rather than 
tacked onto the second bullet point.

s7.1, para 1: s/an MSA , called also the home MSP,/an MSA, also called 
the home MSP,/

s7.3, para 1: s/model support/model supported/

s7.3, para 2:  I don't understand the bracketed item '(MSA for instance 
a corporate network)'

s7.3, para 2: s/specializing on this service/specializing in this service/

s7.4: s/MIP6/MIPv6/ (2 places)

s8, title: s/Parameters for authentication/Parameters for Authentication/

s8, para 1: s/not.If/not. If/, s/services../services./

s8: Expand FQDN.

s8, next to last para of parameter Set 1: s/with other entity/with 
another entity/

s8, last para of parameter Set 1: s/If authentication protocol/If the 
authentication protocol/

s8, last para of parameter Set 1: s/with home agent/with the home agent/

s9.1, para 1: s/in the establishing the SA/in establishing the SA/

s9.1, para 2: s/its home agent(s) ./its home agent(s)./

s9.1, last para: s/this in order to that/this in order that/

s9.2, 2nd bullet: s/disrupts/disrupt/

s9.2, last para:  I am not sure what  'including if the keys are
                  generated from the same authentication credentials' is 
trying to say 
      (but it needs a full stop at the end in any case.)