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

2008-03-11 Thread Sri Gundavelli
Hi Elwyn,


 
  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. 

 OK.. I think some clarification is required to make sure that 
 you always 
 get the same IID.  As specified I didn't grok that it had to 
 be the same 
 one from wherever the node roams to.
 
 I think a few extra words will sort that out and then we are done.
 

Sure. Will clarify this. 

Regards
Sri

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2008-03-09 Thread Elwyn Davies


Sri Gundavelli wrote:
 Hi Elwyn,

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


   
No problem.. I am stuck in a hotel in Toronto, nit getting to IETF. :-(((

Snipped the first issue as that should be fine.

   
 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. 
   
OK.. I think some clarification is required to make sure that you always 
get the same IID.  As specified I didn't grok that it had to be the same 
one from wherever the node roams to.

I think a few extra words will sort that out and then we are done.

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


 Best Regards
 Sri






   


   
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2008-03-06 Thread Sri Gundavelli
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:[EMAIL PROTECTED] 
 Sent: Friday, February 29, 2008 5:57 AM
 To: General Area Review Team
 Cc: Mary Barnes; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf