Subject: [Mip6] [issue90] Comments from Francis

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 19:25:05 +0000

New submission from Vijay Devarapalli <[email-masked]>:

Francis Dupont wrote:

I have reread the last proposed version, here are some points to fix:
 - (last but first in XML) [email-masked] ->
   [email-masked]
 - 4 page 4: key negociation protocol -> key management protocol
   (standard name for these beasts).
 - 4.2 page 6 3rd paragraph: address address -> address
 - 4.2 page 7 1st paragraph: with HoTi/HoT selectors there is no need
   to torn down the SPD entries because they'll never match. So I propose
   to change the MUST in SHOULD and to add something in the granulary part.
 - 4.3 page 8 1st paragraph: optional -> OPTIONAL ?
 - 4.4 page 9: if the IKE SA has -> if the SAs, including the IKE SA, have
   (in IKEv2 SAs have a common fate: when the IKE SA is closed all the SAs
   it has established are closed too)
 - 4.4 page 9 last paragraph: same comment
 - 5 page 10 first item: this is the place I propose to add some text about
   the fact the fine grain selectors can't match at home so the policy can
   be safely kept.
 - 5 page 10 3rd item: considerations -> considerations,
 - 5 page 10 4th item: I don't like the "a high priority": the idea is good
   but as it can be different QoS or security IMHO we should improve the
   wording?
 - 5 page 10 last item: end point -From [email-masked] Tue Dec 12 14:28:36 2006
To: [email-masked]
From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 19:25:05 +0000
Subject: [Mip6] [issue90] Comments from Francis
Reply-To: Mip6 issue tracker <[email-masked]>

New submission from Vijay Devarapalli <[email-masked]>:

Francis Dupont wrote:

I have reread the last proposed version, here are some points to fix:
 - (last but first in XML) [email-masked] ->
   [email-masked]
 - 4 page 4: key negociation protocol -> key management protocol
   (standard name for these beasts).
 - 4.2 page 6 3rd paragraph: address address -> address
 - 4.2 page 7 1st paragraph: with HoTi/HoT selectors there is no need
   to torn down the SPD entries because they'll never match. So I propose
   to change the MUST in SHOULD and to add something in the granulary part.
 - 4.3 page 8 1st paragraph: optional -> OPTIONAL ?
 - 4.4 page 9: if the IKE SA has -> if the SAs, including the IKE SA, have
   (in IKEv2 SAs have a common fate: when the IKE SA is closed all the SAs
   it has established are closed too)
 - 4.4 page 9 last paragraph: same comment
 - 5 page 10 first item: this is the place I propose to add some text about
   the fact the fine grain selectors can't match at home so the policy can
   be safely kept.
 - 5 page 10 3rd item: considerations -> considerations,
 - 5 page 10 4th item: I don't like the "a high priority": the idea is good
   but as it can be different QoS or security IMHO we should improve the
   wording?
 - 5 page 10 last item: end point -> endpoint (twice)
 - 5 page 11 last sentence: I propose to add an explaination: address. ->
   address when the origin is authenticated.
 - 7.3 page 19: by the security association created -> by the IKE security...
   (in general the 7.3 is a bit loose about what kind of SAs we talk about)
 - 7.3 page 20 first paragraph: to create the security associations ->
   to create the IPsec security...
   (second case of the problem)
 - 7.3 page 20: the IDi payload must correspond -> MUST ?
 - 7.3 page 20: in the iPAddress -> in an iPAddress
   (the SubjectAltName extension is a sequence of general names)
 - 8 page 21: there are more than 4 exchanges in general, I proposed to
   add 3 dots between second and third exchanges.
 - 8 page 21 last paragraph: to derive a shared key from EAP is RECOMMENDED
   because it is the way to verify the EAP and IKE peers are the same!
   If we keep the current wording someone shall loudly complain, IMHO
   the best is the change "Same EAP" into "Recommended EAP" with a word
   or two to explain the context of the recommendation, for instance "used
   within IKE" ?
 - 13.2 page 25 [12] (again!): Sugimoto-san has two co-authors...

----------
category: Technical
draft: draft-ietf-mip6-ikev2-ipsec
messages: 317
nosy: vijay
priority: Must fix
status: Pending
title: Comments from Francis

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue90>
_________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6