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:elwynd(_at_)dial(_dot_)pipex(_dot_)com]
Sent: Monday, February 18, 2008 3:11 PM
To: General Area Review Team
Cc: Mary Barnes; sgundave(_at_)cisco(_dot_)com; kleung(_at_)cisco(_dot_)com;
vijay(_dot_)devarapalli(_at_)azairenet(_dot_)com;
kchowdhury(_at_)starentnetworks(_dot_)com;
basavaraj(_dot_)patil(_at_)nsn(_dot_)com;
netlmm-ads(_at_)tools(_dot_)ietf(_dot_)org;
netlmm-chairs(_at_)tools(_dot_)oetf(_dot_)org; IETF
Discussion
Subject: Gen-art review of draft-ietf-netlmm-proxymip6-10.txt
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.
There are two parts to it. Each end point setting up its own
part of the tunnel. Clarified the language.
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.
Replaced the word "correspondent" with "node", still implying the
LMA as the topological anchor point.
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)
Yes. Clarified this to suggest, its only for dynamically created
tunnels.
s6.1, bullet 2: Does this make any assumptions about
commonality of IID
between addresses used by the interface?
Its just talking about the L2 idenfier.
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?
yes.
s8.2: The (M) flag is not added to the Binding Ack message by
RFC 4140
(only to the Binding Update msg).
Fixed. Thanks
s10: The new registry for the Handoff Indicator values is not
specified
in the IANA Considerations.
Thanks. Good catch. Fixed
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).
Rephrased it to imply the LMA identifies the BCE associated with
the request.
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.
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.
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.)
slight rewording
Editorial:
(idnits is happy with the document)
s2.2, MN-Identifier: Expand NAI and MAC acronyms.
Sure.
s4.1: Associate PAD with Peer Authorization Database.
Yes
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'.
Thanks. Fixed
s5.1, bullet 3: Define ALL_ZERO.
Added the definition in the terminology section
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?
Added the definition in the terminology section
s5.3: Would be useful to put in a pointer to the message format
descriptions here.
Fixed
s5.4.1.1: use of == and != ... use of words is better than C
programming
language .
:) Sure
Thanks for the detailed review. Appreciate it.
Regards
Sri
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf