Subject: Gen-art review of draft-ietf-netlmm-proxymip6-10.txt

From: Elwyn Davies <[email-masked]>
Date: Mon, 18 Feb 2008 23:10:35 +0000

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
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-netlmm-proxymip6-10.txt
Reviewer: Elwyn Davies
Review Date: 18 Feb 2008
IETF LC End Date: 20 Feb 2008
IESG Telechat date: 21 Feb 2008

Summary:
This document is well written and is in fairly good shape for submission 
to the IESG.
There are a number of minor issues which ought to be fixed.  I think 
that for a more general reader there are a number of points that are 
fully covered in the detail but when reading the introduction and 
protocol overview questions arise which aren't answered until later in 
the document, and I was left thinking whether the problem had been 
addressed until much later.  I have noted these items in the comments.  
I believe it would only take a few sentences to lay these issues to rest 
and make the document easier to understand for those who are not 
immersed in netlmm.

Comments:

s3, paras just after fig 2:  The para after fig 2 claims that the LMA 
sets up the bidir tunnel; then the next para claims that the MAG 
'establishes' the (same) tunnel.  Be clear which one has responsibility.

s3, p12:
>
>    The local mobility anchor, being the topological anchor point for the
>    mobile node's home network prefix, receives any packets that are 
> sent by any correspondent node to the mobile node.
>
I think it should be made clear (assuming I understand correctly what is 
going on) that this 'correspondent' node does not require any of the 
MIPv6 correspondent functionality and will not see any specialized MIPv6 
messages.  It is difficult to think of an alternative term, but this 
could be confusing.

s5.3.4, item 2:  Whether the tunnel is deleted is surely an 
implementation issue.  The LMA and MAG could agree to maintain the 
tunnel even if there are no MNs active on the MAG to save on setup 
costs.  I think this could be a MAY, leaving it up to implementers to 
optimize if desired. (This is actually discussed later in s5.6.1.. a 
forward pointer is needed here)

s6.1, bullet 2:  Does this make any assumptions about commonality of IID 
between addresses used by the interface?

s6.5: I thought it was said earlier that checking that the MN is 
entitled to mobility services was a MUST.  Does the SHOULD refer to the 
means of authenticating?

s8.2: The (M) flag is not added to the Binding Ack message by RFC 4140 
(only to the Binding Update msg).

s10: The new registry for the Handoff Indicator values is not specified 
in the IANA Considerations.

Areas where some earlier explanation would make life easier for the 
general reader:

3:  I think it would be useful to explain how the LMA knows that the MN 
that has moved from p-MAG to n-MAG is the same MN.. and hence gets the 
same prefix somewhere here (the MN_identity, auth and policy I think).

s5.1, last para:  (it turns out that s5.2 and s6.3 give most of the 
answers but I was left worrying) States that the mobile node's address 
prefix would normally be the key for the binding cache entry.  This 
implies that it will be a unique key and hence every MN requires a 
different address prefix.  I think this is sort of implied earlier, but 
I think it could be stressed at the outset.  This raises a couple of 
more significant issues in my mind:
- A MAG using stateless address config will be advertising one prefix 
per attached MN:  if there are lots of them the RA's will be very 
large.  Is this an issue? (not if everything is a pt2pt link, but
- How does the MN know which prefix to use if it isn't a pt2pt link?
[s5.2 does not address these issues although it clarifies that the 
prefix per MN mode is used]  s6.3 states that it is assumed that links 
will be pt2pt and hence only one prefix on link.  This should be made 
clear earlier, probably in the protocol overview.

I think some additional notes on the Shared_prefix model case and what 
happens if the links are *not* pt2pt would be helpful:  There is a 
significant risk of the RAs getting very large if multiple prefixes need 
to be advertised - and it requires slightly different policy to make 
sure a MN can pick the right prefix if there is more than one prefix 
advertised.

s6.4: I think that explaining where the DHCPv6 server would be and how 
it would know what prefix to take the address out of would be useful.  
(A few words plus a pointer to s6.11 would do.)

Editorial:

(idnits is happy with the document)

s2.2, MN-Identifier: Expand NAI and MAC acronyms.

s4.1: Associate PAD with Peer Authorization Database.

Fig 5: Provide key to various acronyms.

s5.1, bullet 1: 'enabled'/'turned off':   This reads as if the flag is 
sometimes present and sometimes not present.  Suggest using 
'set'/'reset' or 'true'/'false'.

s5.1, bullet 3: Define ALL_ZERO.

s5.2: The terms Per-MN-Prefix and Shared-Prefix model are not defined in 
this doc.  Are they imported from some other netlmm doc?

s5.3: Would be useful to put in a pointer to the message format 
descriptions here.

s5.4.1.1: use of == and != ... use of words is better than C programming 
language .

_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Feb 2008 16:33:06 -0800 (PST)

Thanks Elwyn for the review. We will address each of these comments
and will propose the text, some time this week.

Regards
Sri

On Mon, 18 Feb 2008, Elwyn Davies wrote:

> This document is well written and is in fairly good shape for submission to 
> the IESG.
> There are a number of minor issues which ought to be fixed.  I think that for 
> a more general reader there are a number of points that are fully covered in 
> the detail but when reading the introduction and protocol overview questions 
> arise which aren't answered until later in the document, and I was left 
> thinking whether the problem had been addressed until much later.  I have 
> noted these items in the comments.  I believe it would only take a few 
> sentences to lay these issues to rest and make the document easier to 
> understand for those who are not immersed in netlmm.
>
> Comments:
>
> s3, paras just after fig 2:  The para after fig 2 claims that the LMA sets up 
> the bidir tunnel; then the next para claims that the MAG 'establishes' the 
> (same) tunnel.  Be clear which one has responsibility.
>
> s3, p12:
>>
> going on) that this 'correspondent' node does not require any of the MIPv6 
> correspondent functionality and will not see any specialized MIPv6 messages. 
> It is difficult to think of an alternative term, but this could be confusing.
>
> s5.3.4, item 2:  Whether the tunnel is deleted is surely an implementation 
> issue.  The LMA and MAG could agree to maintain the tunnel even if there are 
> no MNs active on the MAG to save on setup costs.  I think this could be a 
> MAY, leaving it up to implementers to optimize if desired. (This is actually 
> discussed later in s5.6.1.. a forward pointer is needed here)
>
> s6.5: I thought it was said earlier that checking that the MN is entitled to 
> mobility services was a MUST.  Does the SHOULD refer to the means of 
> authenticating?
>
> s8.2: The (M) flag is not added to the Binding Ack message by RFC 4140 (only 
> to the Binding Update msg).
>
> s10: The new registry for the Handoff Indicator values is not specified in 
> the IANA Considerations.
>
> Areas where some earlier explanation would make life easier for the general 
> reader:
>
> 3:  I think it would be useful to explain how the LMA knows that the MN that 
> has moved from p-MAG to n-MAG is the same MN.. and hence gets the same prefix 
> somewhere here (the MN_identity, auth and policy I think).
>
> s5.1, last para:  (it turns out that s5.2 and s6.3 give most of the answers 
> but I was left worrying) States that the mobile node's address prefix would 
> normally be the key for the binding cache entry.  This implies that it will 
> be a unique key and hence every MN requires a different address prefix.  I 
> think this is sort of implied earlier, but I think it could be stressed at 
> the outset.  This raises a couple of more significant issues in my mind:
> - A MAG using stateless address config will be advertising one prefix per 
> attached MN:  if there are lots of them the RA's will be very large.  Is this 
> an issue? (not if everything is a pt2pt link, but
> [s5.2 does not address these issues although it clarifies that the prefix per 
> MN mode is used]  s6.3 states that it is assumed that links will be pt2pt and 
> hence only one prefix on link.  This should be made clear earlier, probably 
> in the protocol overview.
>
> significant risk of the RAs getting very large if multiple prefixes need to 
> be advertised - and it requires slightly different policy to make sure a MN 
> can pick the right prefix if there is more than one prefix advertised.
>
> s6.4: I think that explaining where the DHCPv6 server would be and how it 
> would know what prefix to take the address out of would be useful.  (A few 
> words plus a pointer to s6.11 would do.)
>
> Editorial:
>
> sometimes present and sometimes not present.  Suggest using 'set'/'reset' or 
> 'true'/'false'.
>
> s5.2: The terms Per-MN-Prefix and Shared-Prefix model are not defined in this 
> doc.  Are they imported from some other netlmm doc?
>
> s5.3: Would be useful to put in a pointer to the message format descriptions 
> here.
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 24 Feb 2008 22:51:25 -0800

Hi Elwyn,

Thanks for the detailed review. Appreciate it.
The latest draft that we published (-11) should address
your comments. Please see inline.

Regards
Sri

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 3:11 PM
> To: General Area Review Team
> Cc: Mary Barnes; [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; IETF 
> Discussion
> Subject: Gen-art review of draft-ietf-netlmm-proxymip6-10.txt
> 
> 

There are two parts to it. Each end point setting up its own
part of the tunnel. Clarified the language.

> messages.  It is difficult to think of an alternative term, but this 

Replaced the word "correspondent" with "node", still implying the
LMA as the topological anchor point.

> forward pointer is needed here)

Yes. Clarified this to suggest, its only for dynamically created
tunnels.

> between addresses used by the interface?

Its just talking about the L2 idenfier. 

> entitled to mobility services was a MUST.  Does the SHOULD 

yes.

> (only to the Binding Update msg).

Fixed. Thanks

> in the IANA Considerations.

Thanks. Good catch. Fixed

> same prefix somewhere here (the MN_identity, auth and policy I think).

Rephrased it to imply the LMA identifies the BCE associated with
the request.

> sure a MN can pick the right prefix if there is more than one prefix 

The draft clearly supports p2p link model and does not support
shared prefix model. I'd think, we should not discuss about the
issues related to shared link in this draft. So, for the above
comments, no change.

> (A few words plus a pointer to s6.11 would do.)

slight rewording

> s2.2, MN-Identifier: Expand NAI and MAC acronyms.

Sure.

> s4.1: Associate PAD with Peer Authorization Database.

Yes

> 'set'/'reset' or 'true'/'false'.

Thanks. Fixed

> s5.1, bullet 3: Define ALL_ZERO.

Added the definition in the terminology section

> this doc.  Are they imported from some other netlmm doc?

Added the definition in the terminology section

> s5.3: Would be useful to put in a pointer to the message format 

Fixed

> s5.4.1.1: use of == and != ... use of words is better than C 

:) Sure

Thanks for the detailed review. Appreciate it.

Regards
Sri

IETF mailing list
[email-masked]