[Mip4] IETF 65 Dallas Meeting Minutes

[Pete McCann <mccap at lucent.com>]

Please find the meeting minutes attached, and send any
corrections to the MIP4 mailing list.

Many thanks to Sri Gundavelli and Vijay Devarapalli for
taking the notes during the meeting.

-Pete

MIP4 WG Meeting, March 23 2006, IETF 65
---------------------------------------

Document Status
---------------

Hesham: Comment on adopting new work
        Is there a plan to take new drafts ?
        Is it a good time:

Pete: Lets go thru the doc status
draft-ietf-mip4-rfc3344bis  	   	
   One minor nit found (Selector for the MN-HA SA)
      We need one more spin of the document,
      some errors in the selector being CoA vs. Source IP address
  
draft-ietf-mip4-vpn-problem-solution  	
   Ready for WG last call (Will be started on Monday 27th)
  
draft-ietf-mip4-dynamic-assignment 	  	
   RFC 4433
  
draft-ietf-mip4-faerr 		  	
   Approved by the IESG
  
draft-ietf-mip4-reg-tunnel 		  	
   Dead
   The draft has been re-submitted without the Appendix.
   Waiting for chairs' writeup.
  
draft-ietf-mip4-rfc3012bis 		  	
   IESG Evaluation :: AD Followup
   Several reviews done for AD,
   Decided not to fork off the Generalized 
   Mobile IP Authentication Extension as a separate draft.
   Scathing review from Elwyn Davies was very critical of the draft.
       Addressing the concrete points is not much work
       Requires the chairs and the AD to decide on the plan
       with respect to the draft.
   Waiting for AD guidance

draft-ietf-mobileip-lowlatency-handoffs-v4 	
   RFC Editor's queue
   Dependency on reg-tunnel
  
draft-ietf-mip4-rfc2006bis 		  	
    MIP-centric review done, new revision needed
    Kent: Will try to submit a version by the end of the year

draft-ietf-mip4-mobike-connectivity-00.txt
    Ready for WGLC? (Preliminary date: 17 April 2006)
? from checkpoint. there are too many solution 
documents one with three tunnels, one with two tunnels
and then this. It is too confusing for a reader.

Vijay: we tried to clarify this in the current draft.
It has an applicability statements on when this solution
should be used. Please suggest any clarificatios that
you want to see.

Henrik: Does the document refer to the two other VPN
drafts (problem statement and solution)?

Vijay: Yes.

draft-ietf-mip4-message-string-ext-00.txt
   Ready for WGLC? (Preliminary date: 8 May 2006)
   Pete: Message String extension
   We can go for last call soon

draft-ietf-mip4-radius-requirements-00.txt
   Ready for WGLC? (Preliminary date: 29 May 2006)

draft-ietf-mip4-fmipv4-00.txt
   Ready for WGLC? (Preliminary date: 19 June 2006)

Vijay: A general comment on 3012bis. Sometimes the
reviewers from Gen-ART might not be aware of the all
issues, all the reasons for design decisions, etc.,
and sometimes deliver scathing reviews. We should 
consider that when we get reviews.

Jari: Gen-ART reviews help the IESG make a decision.
But the review will be taken only as an input into
the decision process. In this particular case, I
agree with the review, there are issues, but since
this a bis document revising an existing RFC, I am
fine with this going ahead. 


Network based mobility support
------------------------------ 
     
draft-leung-mip4-proxy-mode-00.txt presented by Kent
----------------------------------------------------

Hesham: Dont see why one cannot just sell MIP4 client.
         Vendors sell VPN client and why not MIP client?

Henrik: Providing and selling a Mobile IP client 
depends on whether a particular vendor controls
the client or the mobile device. The customer for 
this is the company that makes network equipment.

Kent: We have been trying for a long time and we belive
       we require a network based solution. It is not
       easy to convince enterprises to buy MIP client.

Hesham: What is the isue. Is it poltical or ?

Henrik: This is not a host protocol. The customer for this
        is ..

Vidya: Will the funcionality be the same as it would be with
       a normal MIP client

Kent: This is for global mobility

Alex:
      What is the packet type. Do we have an idea of what type it
      is

Ajoy: There can be a FA in the illustration as well right.
      It will help if we clarify htis.

Kent: yes

Charlie: Any comments on the IPR's on this draft.

Kent: We have a patent on this.

Vijay:
      The correct way is to send a note to the IETF IPR disclosure
      page.



draft-chowdhury-netmip4-00.txt presented by Kuntal
--------------------------------------------------

Pete: whats the different between the two drafts? 
did the authors read each others drafts

Kuntal: there are some subtle differences.

Pete: Then there was some discussion on global and local
mobility. One difference is about preconfigured SA's or the dynamic SA's

Kuntal: don't understand the difference between local and global

Kent: Global vs local mobility has different
      implications for security.
      Issue for global vs local is not discussed in either drafts.
      We are just focussing on the signalling.
      In wlan space, it is possible to configure SA's for range
      of MNs's. Right now we are just focussing on the signal flow.

Hesham: The use case can have implications on security.
High level question - Are we going to solve business
problems? There are not technical protocol issues.

Jari: We do technical work at IETF.

Pete: We are not chartered for this. We will consider
NETLMM

Jari: I am worried about doing the same work in 
multiple places. NETLMM is considering PMIP as one
solution. We can solve technical problems here. Not
others.

Kent: The charter of the MIP4 WG says we will deal
with deployment issues. So thats the justification
for this work.

Gopal: This is not a business problem. There are many
reasons why there is no MObile IP client software on
the mobile node. This addresses this.

Hesham: I don't agree that it is a deployment problem.
Then the real problem seems to be that you
cant install software on the client. In that case,
do you need Mobile IP at all?


draft-navali-ip6-over-netmip4-00.txt
------------------------------------

Pete: This has come before. Putting v6 addresses in v4 signalling

Alex: this scenario makes no sense. The network
supports DHCPv6, but not IPv6 and supports Proxy
MIPv4? 

Kuntal: There could be cases

Alex: If the access network has a DHCPv6 server
and hands out IPv6 addresses, then the access network
should be able to route the IPv6 address.

Alex: NETLMM does IPv6 only according to the charter.

Henrik: There are many opinions here. We need to discuss in the
        mailing list.

Raj: Why do you assume the mobile node has IPv6, 
     but no IPv4? Thats a wrong assumption

Hesham: You have to lookup the differences between
        IPv6-capable, IPv6-enabled, IPv4-capable, etc...

Vijay: Agrees with Raj. We shouldnt start work items
       based on the assumption that the MN will support
       IPv6 but not IPv4. 


NAI based home address
----------------------
draft-paulkandasamy-mobileip-nai-based-home-addres-01.txt

Charlie: Disagrees that RFC 2794 is ambiguous. NAI
is only an alternate identifier. not a request for
address assignment

Vijay: I dont see the ambiguity either.  We need to
       work on motivation.

Kent: We had questions when we implemented this. 
So thats why this work.

Charlie: These are new extensions you are requested.
If you need anything clarified in 3344bis, we can do
it. 

Kent: The lifetime of the SA is not specified. We
currently tie it to binding lifetime.

Charlie: thats not a good idea

Pete: when we go to 3957 we distribute the lifetime
      along with the nonces.

Kent: We are not trying to add new functionality.

There was a discussion on what indexes the SA when 
there is no home address

Charlie: NAI is not mandatory. We can do authentication based on the SA
         present.
         You cannot have SA if home address assighnment is enabled. With
         the help of AAA, you can eastablish that.

Henrik: When we implemented, there were some questions,
but we figured out what to do. But would probably have
been better if we had these clarifications.

Charlie: the mobile node is supposed to have a longer
a home address. the HA is not a DHCP server. Mobile IP
is not a protocol where you keep constantly re-assigning
the home address.

Pete: Lets take it to the list.
      We dont have time for the preso on Generic Notification.


Generic notification messages
-----------------------------

draft-deng-mip4-generic-notification-message-01.txt

No time for this.


Henrik: how many people are interested in IPv6 over MIPv4?
? people raised hands.

Vijay: We should have a discussion first before taking
a vote.

Henrik: I want to get a sense of the room.

-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/