[Mip4] Minutes from IETF-72 in Dublin
Henrik Levkowetz <henrik@levkowetz.com> Fri, 29 August 2008 17:13 UTC
Return-Path: <mip4-bounces@ietf.org>
X-Original-To: mip4-archive@optimus.ietf.org
Delivered-To: ietfarch-mip4-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0253A3A69C5; Fri, 29 Aug 2008 10:13:43 -0700 (PDT)
X-Original-To: mip4@core3.amsl.com
Delivered-To: mip4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934233A69C5 for <mip4@core3.amsl.com>; Fri, 29 Aug 2008 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXhlJpvXSw3M for <mip4@core3.amsl.com>; Fri, 29 Aug 2008 10:13:40 -0700 (PDT)
Received: from merlot.tools.ietf.org (unknown [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id EB85F3A68C0 for <mip4@ietf.org>; Fri, 29 Aug 2008 10:13:39 -0700 (PDT)
Received: from localhost ([127.0.0.1]:56837 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <henrik@levkowetz.com>) id 1KZ7XR-0006VM-H8; Fri, 29 Aug 2008 19:13:33 +0200
Message-ID: <48B82E3D.7010201@levkowetz.com>
Date: Fri, 29 Aug 2008 19:13:33 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Mobile IPv4 Mailing List <mip4@ietf.org>, Mip4 Chairs <mip4-chairs@tools.ietf.org>
X-Enigmail-Version: 0.95.7
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: mip4@ietf.org, mip4-chairs@tools.ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false
Subject: [Mip4] Minutes from IETF-72 in Dublin
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org
Here are proposed minutes from IETF-72 in Dublin. Many thanks to the note-taker, Vijay Devarapalli, for the notes! Comments to the list and chairs, please. Best, Henrik ======================================================================== MIP4 WG Minutes =============== MONDAY, July 28, 2008 1300-1500 Afternoon Session I 2. Document Status WG Documents: draft-ietf-mip4-rfc3344bis - Waiting for Shepherd Writeup draft-ietf-mip4-generic-notification-message - New version needed draft-ietf-mip4-nemov4-fa - Please review and comment draft-ietf-mip4-nemov4-dynamic - Re-submit, review and comment draft-ietf-mip4-gen-ext - Review and discuss based on draft-deng-mip4-host-configuration-00.txt draft-ietf-mip4-rfc2006bis - Waiting for final revision draft-ietf-mip4-dsmipv4 - IESG Processing, waiting for processing at the same time as DSMIPv6 RFCs Published: draft-ietf-mip4-nemo-v4-base - RFC 5177 draft-ietf-mip4-mobike-connectivity - RFC 5266 draft-ietf-mip4-vpn-problem-solution - RFC 5265 3. DHCP-based Host Configuration draft-deng-mip4-host-configuration-00.txt Henrik - Why use the MAC address instead of the NAI Hui - Captured and analyzed DHCP messages. They all use the MAC address, so recommended using the MAC address Henrik - The use of MAC address is common, but does not prevent other forms of identies from being used Pete - 3G cellular links do not have the MAC address Henrik - It should be possible to use NAI as the client identifier Kent - Using the NAI for client identifier is common too Kent - On the use of broadcast IP address. HA is supposed to replicate the broadcast packets and sent to every mobile node. Is that applicable here? Hui - Yes Kent - This is a bad idea. HA should not be broadcasting these DHCP messages. So prefers using unicast addressing for the DHCP messages. Kent - Previous drafts spoke about informatiom from both the home and visited networks. This is addressed in the current draft. Ahmad - What is the intended status? The messages are already there. We are only describing how to use these messages with MIP4 Henrik - Informational might make sense. Jari - Are there examples of visited network information that you would want to delivered to the MN Kent - To get back to Jari on that Henrik - Why not use DHCP directly in the visited network to obtain information from the local visited network? Pete - There might be an issue with sending a DHCP message locally broadcast at the same time as sending one to the home network Henrik - Do the local DHCP request before setting up a tunnel with the home agent Pete - There is an issue with FA mode. There is no local address for the MN to use. Ahmad - There was a draft from WiMAX about sending a broadcast/multicast packets locally. Maybe that draft could be considered Pete - We need to look at the general issue of local breakout for broadcast packets. 4. Generic Notification draft-ietf-mip4-generic-notification-message-06 Ahmad & Sri - Some confusion. Henrik - There is agreement already to make the changes to the draft. There is no point in re-hashing the discussion. Lets move on Vidya - Is integrity protection optional? Sri - No 5. Better Than Nothing MIP4 Fast Handovers draft-doswald-robert-mip4-btn-fmipv4-00.txt This document proposes a complement to fast handover mechanisms according to RFC 4881 and RFC 4988. Those require the presence of Foreign Agents; while the mechanism proposed here uses a direct connection to the Home Agent. Sri - What is the motivation for this? Any use-case? Alistair - Looking for a solution to improve handovers without a FA Kent - Can you give an example of such a network? Alistair - Has a use-case for mobiles using an existing infrastructure. (Some sort of street cleaning robots. ) Kent - What kind of access technologies? Alistair - We are using WiFi and some 3G cellular technologies Henrik - This looks like delay tolerance is the most important thing here rather than fast handovers -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/
- [Mip4] Minutes from IETF-72 in Dublin Henrik Levkowetz