ietf
[Top] [All Lists]

RE: Gen-art review of draft-ietf-netlmm-proxymip6-11.txt

2008-03-06 08:48:53
Hi Elwyn,

Sorry for the late reply. Thanks for reviewing the updated
draft. We will address the two remaining issues. Please
see inline.



 

-----Original Message-----
From: Elwyn Davies [mailto:elwynd(_at_)dial(_dot_)pipex(_dot_)com] 
Sent: Friday, February 29, 2008 5:57 AM
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-11.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 wait for direction from your document shepherd
or AD before posting a new version of the draft.


Document: draft-ietf-netlmm-proxymip6-11.txt
Reviewer: Elwyn Davies
Review Date: 29 Feb 2008
IESG Telechat date: 06 March 2008

Summary:
Version 11 resolves almost all of the issues and nits that I 
raised in the last 
call review of version 10.  There is one editorial matter to 
complete the 'ease 
of reading' and an outstanding query which I think both I and 
the authors passed 
over a little lightly at the previous review.


Sorry, may be I missed it. 


An editorial update added to s3, para 4 (just after fig 1) to 
emphasize the 
pivotal role of the MN-Identity would be helpful.  Something like:
'The authenticated, stable identifier of the mobile node 
(MN-Identifier) 
uniquely identifies the mobile node to the LMA(s) as the node 
roams through the 
Proxy Mobile Domain.'


The properties and the requirements related to MN Identifier are
specified in Section 6.6. If you think, we need to cover this in
the initial introductory section. Sure, we can add the above
text.


Outstanding query: s6.1, bullet 2:  This bullet refers to 
'*the* interface 
identifier' and suggests that it might be retrieved from a 
Router Solicitation. 
  My original point was that the IID for IPv6 addresses is 
not necessarily 
common between the addresses configured on an interface.  My 
comment was a 
little glib and the authors glossed over the point in their 
reply.  I think this 
bullet may require clarification to indicate which of the 
IIDs would be implied 
here.  Particularly if SEND is in use, the IID used for the 
link local address 
(that would typically be found in the solicitation) will a.s. 
differ from the 
IID used with the address assigned out of the prefix 
allocated by Proxy MIP.  My 
original point was to ask the authors to clarify whether 
ProxyMIP actually cares 
which IID is used and, accordingly, state either that 'it 
doesn't matter' or 
specifically which IID should be transmitted.



This is the interface identifier (layer-2) and not the L3 identifier. 
This is covered in the terminology section, "Mobile Node Interface
Identifier (MN-Interface-Identifier)". 

The need for the L2 interface identifier (such as MAC address) is
to predictably identify the interface of a mobile node. The Access
Technology Type in combination with the interface identifier is
used as the index field in the BCE. 

Looks like this is not implied. We can point to the
"MN-Interface-Identifier"  term and that should probably make it
clear. 

Thanks again, for the review. Hopefully this addresses all the issues
raised by the Gen-art review.


Best Regards
Sri








_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>