From mailman-admin@ietf.org Sun Jun 1 09:12:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06915 for ; Sun, 1 Jun 2003 09:12:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51DC6B17758 for ; Sun, 1 Jun 2003 09:12:06 -0400 Date: Sun, 01 Jun 2003 09:12:06 -0400 Message-ID: <20030601131206.11734.41500.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-admin@ietf.org Mon Jun 2 03:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26477 for ; Mon, 2 Jun 2003 03:17:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527GOB17098; Mon, 2 Jun 2003 03:16:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527F7B17037 for ; Mon, 2 Jun 2003 03:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26431 for ; Mon, 2 Jun 2003 03:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MjVQ-0000Yi-00 for nemo@ietf.org; Mon, 02 Jun 2003 03:13:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19MjVQ-0000Ye-00 for nemo@ietf.org; Mon, 02 Jun 2003 03:13:20 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2003 09:13:42 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h527CXVd027283; Mon, 2 Jun 2003 09:12:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Jun 2003 09:14:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Mon, 2 Jun 2003 08:14:30 +0100 Message-ID: Thread-Topic: IPv4 / PAT / NAT / Reverse NAT traversal for MIPv6 Thread-Index: AcMo1pz2yHaGkyMETWmUXWzfhGZZ0Q== From: "Pascal Thubert (pthubert)" To: "mipv6-handoff (mailer list)" , X-OriginalArrivalTime: 02 Jun 2003 07:14:30.0768 (UTC) FILETIME=[9C58BF00:01C328D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h527F7B17038 Subject: [nemo] IPv4 / PAT / NAT / Reverse NAT traversal for MIPv6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: Please note that version one of this draft is now available. It extends 6to4 to transport MIPv6 based traffic across IPv4 in various cases. It was initially discussed in Nemo, but at this point I’m not sure which group is that best / most interested for pursuing since the subject was also discussed in MIPv6. Help and comments welcome ☺ http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01.txt Pascal From mailnull@www1.ietf.org Mon Jun 2 03:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26507 for ; Mon, 2 Jun 2003 03:18:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h527HmJ17212 for nemo-archive@odin.ietf.org; Mon, 2 Jun 2003 03:17:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527HlB17209 for ; Mon, 2 Jun 2003 03:17:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26493 for ; Mon, 2 Jun 2003 03:17:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MjY0-0000Zp-00 for nemo-web-archive@ietf.org; Mon, 02 Jun 2003 03:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MjY0-0000Zm-00 for nemo-web-archive@ietf.org; Mon, 02 Jun 2003 03:16:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527GOB17098; Mon, 2 Jun 2003 03:16:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527F7B17037 for ; Mon, 2 Jun 2003 03:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26431 for ; Mon, 2 Jun 2003 03:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MjVQ-0000Yi-00 for nemo@ietf.org; Mon, 02 Jun 2003 03:13:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19MjVQ-0000Ye-00 for nemo@ietf.org; Mon, 02 Jun 2003 03:13:20 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2003 09:13:42 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h527CXVd027283; Mon, 2 Jun 2003 09:12:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Jun 2003 09:14:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Mon, 2 Jun 2003 08:14:30 +0100 Message-ID: Thread-Topic: IPv4 / PAT / NAT / Reverse NAT traversal for MIPv6 Thread-Index: AcMo1pz2yHaGkyMETWmUXWzfhGZZ0Q== From: "Pascal Thubert (pthubert)" To: "mipv6-handoff (mailer list)" , X-OriginalArrivalTime: 02 Jun 2003 07:14:30.0768 (UTC) FILETIME=[9C58BF00:01C328D6] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h527F7B17038 Subject: [nemo] IPv4 / PAT / NAT / Reverse NAT traversal for MIPv6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h527GOB17098 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h527HlB17209 Content-Transfer-Encoding: 8bit Hi: Please note that version one of this draft is now available. It extends 6to4 to transport MIPv6 based traffic across IPv4 in various cases. It was initially discussed in Nemo, but at this point I’m not sure which group is that best / most interested for pursuing since the subject was also discussed in MIPv6. Help and comments welcome ☺ http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01.txt Pascal From nemo-admin@ietf.org Mon Jun 2 05:01:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28732 for ; Mon, 2 Jun 2003 05:01:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5290uB25646; Mon, 2 Jun 2003 05:00:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h528xaB25530 for ; Mon, 2 Jun 2003 04:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28638 for ; Mon, 2 Jun 2003 04:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ml8V-0001Al-00 for nemo@ietf.org; Mon, 02 Jun 2003 04:57:47 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19Ml8V-0001Ah-00 for nemo@ietf.org; Mon, 02 Jun 2003 04:57:47 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 7F5C95D094; Mon, 2 Jun 2003 17:59:01 +0900 (JST) Date: Mon, 2 Jun 2003 17:56:01 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tk@kniveton.com Message-Id: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Vienna Agenda Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, The Vienna meeting is fast approaching and we need to set up an agenda. Before we request a time slot, could you please let us know what items should be added on the agenda in addition to the ones below. Please motivate your request and let us know about drafts, if any, that the discussion would be based on. # Definitely on the agenda o Terminology and Requirements draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt - comments - what to do next o Report from the Design Team draft-ietf-nemo-????? - status / consensus - draft ? # Might be good to speak about: - multihoming Based on the active discussion on the mailing list, I guess a discussion on multihoming would be useful. - Threat analysis L Let me remind you "threat analysis" is one of our milestones, is there is any input regarding this ? That would be MORE than highly appreciated. The chairs. From mailnull@www1.ietf.org Mon Jun 2 05:02:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28768 for ; Mon, 2 Jun 2003 05:02:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5292At25755 for nemo-archive@odin.ietf.org; Mon, 2 Jun 2003 05:02:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5292AB25752 for ; Mon, 2 Jun 2003 05:02:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28750 for ; Mon, 2 Jun 2003 05:02:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MlAz-0001C9-00 for nemo-web-archive@ietf.org; Mon, 02 Jun 2003 05:00:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MlAz-0001C6-00 for nemo-web-archive@ietf.org; Mon, 02 Jun 2003 05:00:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5290uB25646; Mon, 2 Jun 2003 05:00:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h528xaB25530 for ; Mon, 2 Jun 2003 04:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28638 for ; Mon, 2 Jun 2003 04:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ml8V-0001Al-00 for nemo@ietf.org; Mon, 02 Jun 2003 04:57:47 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19Ml8V-0001Ah-00 for nemo@ietf.org; Mon, 02 Jun 2003 04:57:47 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 7F5C95D094; Mon, 2 Jun 2003 17:59:01 +0900 (JST) Date: Mon, 2 Jun 2003 17:56:01 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tk@kniveton.com Message-Id: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Vienna Agenda Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, The Vienna meeting is fast approaching and we need to set up an agenda. Before we request a time slot, could you please let us know what items should be added on the agenda in addition to the ones below. Please motivate your request and let us know about drafts, if any, that the discussion would be based on. # Definitely on the agenda o Terminology and Requirements draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt - comments - what to do next o Report from the Design Team draft-ietf-nemo-????? - status / consensus - draft ? # Might be good to speak about: - multihoming Based on the active discussion on the mailing list, I guess a discussion on multihoming would be useful. - Threat analysis L Let me remind you "threat analysis" is one of our milestones, is there is any input regarding this ? That would be MORE than highly appreciated. The chairs. From nemo-admin@ietf.org Thu Jun 5 17:26:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17859 for ; Thu, 5 Jun 2003 17:26:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55LOSB11961; Thu, 5 Jun 2003 17:24:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554BVB16733 for ; Thu, 5 Jun 2003 00:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24839 for ; Thu, 5 Jun 2003 00:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nm4I-0002nG-00 for nemo@ietf.org; Thu, 05 Jun 2003 00:09:38 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19Nm4G-0002nC-00 for nemo@ietf.org; Thu, 05 Jun 2003 00:09:37 -0400 Received: from web12303.mail.yahoo.com (web12303.mail.yahoo.com [216.136.173.101]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with SMTP id h554BJnd011460 for ; Thu, 5 Jun 2003 06:11:23 +0200 Message-ID: <20030605041111.75825.qmail@web12303.mail.yahoo.com> Received: from [203.196.130.114] by web12303.mail.yahoo.com via HTTP; Wed, 04 Jun 2003 21:11:11 PDT Date: Wed, 4 Jun 2003 21:11:11 -0700 (PDT) From: ashok kumar To: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-175525696-1054786271=:75374" Subject: [nemo] please help me Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --0-175525696-1054786271=:75374 Content-Type: text/plain; charset=us-ascii sir, i ashok is pursuing M-Tech is working on a project on mobile ip .i have some questoins regarding foreign agent visitors list. (i) How does a foreing agent maintains the database of the mobile nodes (ie what data sturcture it uses) (ii) how to determine the optimum number of mobile node FA can support without degradations of services (ie what are the considerartionms to be kept in mind to determine the optimum number. madam i will be grate full to u ashok --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-175525696-1054786271=:75374 Content-Type: text/html; charset=us-ascii
sir,
i ashok is pursuing M-Tech is working on a project on mobile ip .i have some questoins regarding foreign agent visitors list.
 
(i) How does a foreing agent maintains the database of the mobile nodes (ie what data sturcture it uses)
(ii) how to determine the optimum number of  mobile node FA can support without degradations of services (ie what are the considerartionms to be kept in mind to determine the optimum number.
madam i will be grate full to u
 
ashok

Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-175525696-1054786271=:75374-- From mailnull@www1.ietf.org Thu Jun 5 17:26:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17902 for ; Thu, 5 Jun 2003 17:26:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55LQQg12149 for nemo-archive@odin.ietf.org; Thu, 5 Jun 2003 17:26:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55LQQB12146 for ; Thu, 5 Jun 2003 17:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17895 for ; Thu, 5 Jun 2003 17:26:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O2Dm-0003kI-00 for nemo-web-archive@ietf.org; Thu, 05 Jun 2003 17:24:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O2Dm-0003kD-00 for nemo-web-archive@ietf.org; Thu, 05 Jun 2003 17:24:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55LOSB11961; Thu, 5 Jun 2003 17:24:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554BVB16733 for ; Thu, 5 Jun 2003 00:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24839 for ; Thu, 5 Jun 2003 00:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nm4I-0002nG-00 for nemo@ietf.org; Thu, 05 Jun 2003 00:09:38 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19Nm4G-0002nC-00 for nemo@ietf.org; Thu, 05 Jun 2003 00:09:37 -0400 Received: from web12303.mail.yahoo.com (web12303.mail.yahoo.com [216.136.173.101]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with SMTP id h554BJnd011460 for ; Thu, 5 Jun 2003 06:11:23 +0200 Message-ID: <20030605041111.75825.qmail@web12303.mail.yahoo.com> Received: from [203.196.130.114] by web12303.mail.yahoo.com via HTTP; Wed, 04 Jun 2003 21:11:11 PDT Date: Wed, 4 Jun 2003 21:11:11 -0700 (PDT) From: ashok kumar To: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-175525696-1054786271=:75374" Subject: [nemo] please help me Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --0-175525696-1054786271=:75374 Content-Type: text/plain; charset=us-ascii sir, i ashok is pursuing M-Tech is working on a project on mobile ip .i have some questoins regarding foreign agent visitors list. (i) How does a foreing agent maintains the database of the mobile nodes (ie what data sturcture it uses) (ii) how to determine the optimum number of mobile node FA can support without degradations of services (ie what are the considerartionms to be kept in mind to determine the optimum number. madam i will be grate full to u ashok --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-175525696-1054786271=:75374 Content-Type: text/html; charset=us-ascii
sir,
i ashok is pursuing M-Tech is working on a project on mobile ip .i have some questoins regarding foreign agent visitors list.
 
(i) How does a foreing agent maintains the database of the mobile nodes (ie what data sturcture it uses)
(ii) how to determine the optimum number of  mobile node FA can support without degradations of services (ie what are the considerartionms to be kept in mind to determine the optimum number.
madam i will be grate full to u
 
ashok

Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-175525696-1054786271=:75374-- From nemo-admin@ietf.org Fri Jun 6 06:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16810 for ; Fri, 6 Jun 2003 06:38:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AbbB11517; Fri, 6 Jun 2003 06:37:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AaMB10640 for ; Fri, 6 Jun 2003 06:36:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16766 for ; Fri, 6 Jun 2003 06:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEYC-0000NE-00 for nemo@ietf.org; Fri, 06 Jun 2003 06:34:24 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19OEY9-0000NA-00 for nemo@ietf.org; Fri, 06 Jun 2003 06:34:23 -0400 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h56Aa5nd018190 for ; Fri, 6 Jun 2003 12:36:08 +0200 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h56AZtwI018405; Fri, 6 Jun 2003 03:35:59 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h56AZoVN019011; Fri, 6 Jun 2003 05:35:52 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5F40E2EC8B; Fri, 6 Jun 2003 12:35:50 +0200 (CEST) Message-ID: <3EE06E85.20807@nal.motlabs.com> Date: Fri, 06 Jun 2003 12:35:49 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ashok kumar Cc: nemo@nal.motlabs.com Subject: Re: [nemo] please help me References: <20030605041111.75825.qmail@web12303.mail.yahoo.com> In-Reply-To: <20030605041111.75825.qmail@web12303.mail.yahoo.com> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Ashok, ashok kumar wrote: > i ashok is pursuing M-Tech is working on a project on mobile ip .i > have some questoins regarding foreign agent visitors list. Foreign Agents are a concept mostly related to Mobile IPv4 for Mobile Hosts; so maybe this question can be easily asnwered by someone in the Mobile IP WG. I think in this WG people look mostly at moving networks (entire sets of hosts that move homogeneously), rather than Mobile Hosts. > (i) How does a foreing agent maintains the database of the mobile > nodes (ie what data sturcture it uses) Personally I do not know. But I suppose you can imagine a list, or a table. > (ii) how to determine the optimum number of mobile node FA can > support without degradations of services (ie what are the > considerartionms to be kept in mind to determine the optimum number. I suppose that can be determined by experimentation. Install an FA and an HA. Then use a Mobile Host under the FA to file transfer a file from a CN. Then use two MH's under the same FA, doing the same file transfer. Then try three, four and so on, until a degradation in service is noticed. Publicly available software is available publicly to do these experimentations. Alex GBU From mailnull@www1.ietf.org Fri Jun 6 06:39:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16852 for ; Fri, 6 Jun 2003 06:39:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Acp411621 for nemo-archive@odin.ietf.org; Fri, 6 Jun 2003 06:38:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AcpB11618 for ; Fri, 6 Jun 2003 06:38:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16826 for ; Fri, 6 Jun 2003 06:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEaa-0000OE-00 for nemo-web-archive@ietf.org; Fri, 06 Jun 2003 06:36:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OEaa-0000OB-00 for nemo-web-archive@ietf.org; Fri, 06 Jun 2003 06:36:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AbbB11517; Fri, 6 Jun 2003 06:37:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AaMB10640 for ; Fri, 6 Jun 2003 06:36:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16766 for ; Fri, 6 Jun 2003 06:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEYC-0000NE-00 for nemo@ietf.org; Fri, 06 Jun 2003 06:34:24 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19OEY9-0000NA-00 for nemo@ietf.org; Fri, 06 Jun 2003 06:34:23 -0400 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h56Aa5nd018190 for ; Fri, 6 Jun 2003 12:36:08 +0200 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h56AZtwI018405; Fri, 6 Jun 2003 03:35:59 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h56AZoVN019011; Fri, 6 Jun 2003 05:35:52 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5F40E2EC8B; Fri, 6 Jun 2003 12:35:50 +0200 (CEST) Message-ID: <3EE06E85.20807@nal.motlabs.com> Date: Fri, 06 Jun 2003 12:35:49 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ashok kumar Cc: nemo@nal.motlabs.com Subject: Re: [nemo] please help me References: <20030605041111.75825.qmail@web12303.mail.yahoo.com> In-Reply-To: <20030605041111.75825.qmail@web12303.mail.yahoo.com> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Ashok, ashok kumar wrote: > i ashok is pursuing M-Tech is working on a project on mobile ip .i > have some questoins regarding foreign agent visitors list. Foreign Agents are a concept mostly related to Mobile IPv4 for Mobile Hosts; so maybe this question can be easily asnwered by someone in the Mobile IP WG. I think in this WG people look mostly at moving networks (entire sets of hosts that move homogeneously), rather than Mobile Hosts. > (i) How does a foreing agent maintains the database of the mobile > nodes (ie what data sturcture it uses) Personally I do not know. But I suppose you can imagine a list, or a table. > (ii) how to determine the optimum number of mobile node FA can > support without degradations of services (ie what are the > considerartionms to be kept in mind to determine the optimum number. I suppose that can be determined by experimentation. Install an FA and an HA. Then use a Mobile Host under the FA to file transfer a file from a CN. Then use two MH's under the same FA, doing the same file transfer. Then try three, four and so on, until a degradation in service is noticed. Publicly available software is available publicly to do these experimentations. Alex GBU From nemo-admin@ietf.org Mon Jun 9 07:44:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28403 for ; Mon, 9 Jun 2003 07:44:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BhfB26195; Mon, 9 Jun 2003 07:43:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Bg0B26142 for ; Mon, 9 Jun 2003 07:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28275 for ; Mon, 9 Jun 2003 07:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PL0I-0001uG-00 for nemo@ietf.org; Mon, 09 Jun 2003 07:39:58 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19PL07-0001th-00 for nemo@ietf.org; Mon, 09 Jun 2003 07:39:55 -0400 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h59Bevnd012521; Mon, 9 Jun 2003 13:41:20 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E55876B9C5; Mon, 9 Jun 2003 07:40:30 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h59BeQuW021591; Mon, 9 Jun 2003 07:40:26 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h59Be9YM009948; Mon, 9 Jun 2003 07:40:26 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030609073242.0171e008@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 09 Jun 2003 07:40:00 -0400 To: Alexandru Petrescu From: William D Ivancic Subject: Re: [nemo] please help me Cc: ashok kumar , nemo@nal.motlabs.com In-Reply-To: <3EE06E85.20807@nal.motlabs.com> References: <20030605041111.75825.qmail@web12303.mail.yahoo.com> <20030605041111.75825.qmail@web12303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >>(ii) how to determine the optimum number of mobile node FA can support >>without degradations of services (ie what are the considerartionms to be >>kept in mind to determine the optimum number. This is a difficult question as it depends on may factors. Those factor include: Number of hosts Type and amount of traffic being generated by each host Size (computing power) of the FA Computing power of the HA Type of radio(s) used between the FA and Mobile Nodes. Amount of movement into and out of the FA FA, Mobile Node and HA advertisement, registration and binding timers. For radio systems such as 802.11, I suspect the first area you would see performance drop off would be at the radio (bandwidth limit). Will Ivancic From mailnull@www1.ietf.org Mon Jun 9 07:45:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28567 for ; Mon, 9 Jun 2003 07:45:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59BikZ26237 for nemo-archive@odin.ietf.org; Mon, 9 Jun 2003 07:44:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BikB26233 for ; Mon, 9 Jun 2003 07:44:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28456 for ; Mon, 9 Jun 2003 07:44:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PL2y-0001wT-00 for nemo-web-archive@ietf.org; Mon, 09 Jun 2003 07:42:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PL2x-0001wP-00 for nemo-web-archive@ietf.org; Mon, 09 Jun 2003 07:42:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BhfB26195; Mon, 9 Jun 2003 07:43:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Bg0B26142 for ; Mon, 9 Jun 2003 07:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28275 for ; Mon, 9 Jun 2003 07:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PL0I-0001uG-00 for nemo@ietf.org; Mon, 09 Jun 2003 07:39:58 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19PL07-0001th-00 for nemo@ietf.org; Mon, 09 Jun 2003 07:39:55 -0400 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h59Bevnd012521; Mon, 9 Jun 2003 13:41:20 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E55876B9C5; Mon, 9 Jun 2003 07:40:30 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h59BeQuW021591; Mon, 9 Jun 2003 07:40:26 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h59Be9YM009948; Mon, 9 Jun 2003 07:40:26 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030609073242.0171e008@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 09 Jun 2003 07:40:00 -0400 To: Alexandru Petrescu From: William D Ivancic Subject: Re: [nemo] please help me Cc: ashok kumar , nemo@nal.motlabs.com In-Reply-To: <3EE06E85.20807@nal.motlabs.com> References: <20030605041111.75825.qmail@web12303.mail.yahoo.com> <20030605041111.75825.qmail@web12303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >>(ii) how to determine the optimum number of mobile node FA can support >>without degradations of services (ie what are the considerartionms to be >>kept in mind to determine the optimum number. This is a difficult question as it depends on may factors. Those factor include: Number of hosts Type and amount of traffic being generated by each host Size (computing power) of the FA Computing power of the HA Type of radio(s) used between the FA and Mobile Nodes. Amount of movement into and out of the FA FA, Mobile Node and HA advertisement, registration and binding timers. For radio systems such as 802.11, I suspect the first area you would see performance drop off would be at the radio (bandwidth limit). Will Ivancic From nemo-admin@ietf.org Wed Jun 11 04:18:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29221 for ; Wed, 11 Jun 2003 04:18:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8HOB17678; Wed, 11 Jun 2003 04:17:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8GWB17637 for ; Wed, 11 Jun 2003 04:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29184 for ; Wed, 11 Jun 2003 04:16:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0kU-0005pl-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:14:26 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19Q0kT-0005pi-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:14:25 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id B82EB5A84D; Wed, 11 Jun 2003 16:20:35 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> Date: Wed, 11 Jun 2003 16:20:35 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?cXVlc3Rpb25zIGFib3V0IG11bHRpaG9taW5nLg==?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,all If there are 2 root-MRs in the same NEMO, and they have same prefix/length but different CoA, if they share the same HA, then how would be the routing tablez(one prefix has two out interfaces ) and Bindng Cache(one prefix needs two CoAs) of the HA? if they have their respective HA , both HAs will have the chance to deal with the pakage destined to the NEMO, how to choose the two HAs and does it possible that both of the two HAs routing the packag to MR respectively? Thanks a lot! Wanrong Yu Wanrong Yu From mailnull@www1.ietf.org Wed Jun 11 04:19:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29244 for ; Wed, 11 Jun 2003 04:19:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8Iuw17733 for nemo-archive@odin.ietf.org; Wed, 11 Jun 2003 04:18:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8ItB17730 for ; Wed, 11 Jun 2003 04:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29241 for ; Wed, 11 Jun 2003 04:18:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0mn-0005qS-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 04:16:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q0mm-0005qO-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 04:16:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8HOB17678; Wed, 11 Jun 2003 04:17:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8GWB17637 for ; Wed, 11 Jun 2003 04:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29184 for ; Wed, 11 Jun 2003 04:16:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0kU-0005pl-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:14:26 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19Q0kT-0005pi-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:14:25 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id B82EB5A84D; Wed, 11 Jun 2003 16:20:35 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> Date: Wed, 11 Jun 2003 16:20:35 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?cXVlc3Rpb25zIGFib3V0IG11bHRpaG9taW5nLg==?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,all If there are 2 root-MRs in the same NEMO, and they have same prefix/length but different CoA, if they share the same HA, then how would be the routing tablez(one prefix has two out interfaces ) and Bindng Cache(one prefix needs two CoAs) of the HA? if they have their respective HA , both HAs will have the chance to deal with the pakage destined to the NEMO, how to choose the two HAs and does it possible that both of the two HAs routing the packag to MR respectively? Thanks a lot! Wanrong Yu Wanrong Yu From nemo-admin@ietf.org Wed Jun 11 04:51:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29770 for ; Wed, 11 Jun 2003 04:51:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8pAB19796; Wed, 11 Jun 2003 04:51:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8oFB19766 for ; Wed, 11 Jun 2003 04:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29744 for ; Wed, 11 Jun 2003 04:50:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1H6-0005wo-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:48:08 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19Q1H4-0005wW-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:48:07 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5B8gSi20872; Wed, 11 Jun 2003 16:42:28 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 1361710E95DA; Wed, 11 Jun 2003 16:50:44 +0800 (SGT) Subject: Re: [nemo] questions about multihoming. From: Chan-Wah Ng To: Wanrong Yu Cc: IETF NEMO WG In-Reply-To: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> References: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1055321443.2410.47.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 11 Jun 2003 16:50:43 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Wanrong, See my responses in-line. /rgds /cwng On Wed, 2003-06-11 at 16:20, Wanrong Yu wrote: > Hi,all > > If there are 2 root-MRs in the same NEMO, and they have > same prefix/length but different CoA, > if they share the same HA, > then how would be the routing tablez(one prefix has two > out interfaces ) and Bindng Cache(one prefix needs two > CoAs) of the HA? For the routing table, it will behave as though a normal router's routing table having two route entries to the same destination prefix. AFAIK, it is perfectly valid (eg. load balancing between two routes) and nothing NEMO specific. Now, for the binding cache. Having a prefix field in the binding cache is NEMO specific, and it depends on which is the primary field (or sometimes known as the index field) in a binding cache. I would think it is the home-address, and not the prefix. Then there will be no problem as far as I can see right now. > > if they have their respective HA , > both HAs will have the chance to deal with the pakage > destined to the NEMO, how to choose the two HAs and > does it possible that both of the two HAs routing the > packag to MR respectively? If the packet is sent by a node outside the administrative domain of both HA, the packet will reach one (and only one) HA depending on the routing decision of the core/border routers. If the packet is sent by a node behind one of the HA, the packet will be intercepted by that HA, and tunneled to the mobile network. No, AFAIK, you cannot have one packet reaching two separate HAs simultaneously. However, I do agree that there is the slight possibility of packets from the same session (eg TCP session) going through both HAs, eg first packet through HA1, 2nd packet through HA2, etc. Is this a problem? Will it affect TCP's estimation of RTT and parameters of the congestion algorithm, etc? /rgds /cwng From mailnull@www1.ietf.org Wed Jun 11 04:52:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29796 for ; Wed, 11 Jun 2003 04:52:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8q2919870 for nemo-archive@odin.ietf.org; Wed, 11 Jun 2003 04:52:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8q2B19867 for ; Wed, 11 Jun 2003 04:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29790 for ; Wed, 11 Jun 2003 04:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1Io-0005xV-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 04:49:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q1Io-0005xS-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 04:49:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8pAB19796; Wed, 11 Jun 2003 04:51:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8oFB19766 for ; Wed, 11 Jun 2003 04:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29744 for ; Wed, 11 Jun 2003 04:50:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1H6-0005wo-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:48:08 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19Q1H4-0005wW-00 for nemo@ietf.org; Wed, 11 Jun 2003 04:48:07 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5B8gSi20872; Wed, 11 Jun 2003 16:42:28 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 1361710E95DA; Wed, 11 Jun 2003 16:50:44 +0800 (SGT) Subject: Re: [nemo] questions about multihoming. From: Chan-Wah Ng To: Wanrong Yu Cc: IETF NEMO WG In-Reply-To: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> References: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1055321443.2410.47.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 11 Jun 2003 16:50:43 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Wanrong, See my responses in-line. /rgds /cwng On Wed, 2003-06-11 at 16:20, Wanrong Yu wrote: > Hi,all > > If there are 2 root-MRs in the same NEMO, and they have > same prefix/length but different CoA, > if they share the same HA, > then how would be the routing tablez(one prefix has two > out interfaces ) and Bindng Cache(one prefix needs two > CoAs) of the HA? For the routing table, it will behave as though a normal router's routing table having two route entries to the same destination prefix. AFAIK, it is perfectly valid (eg. load balancing between two routes) and nothing NEMO specific. Now, for the binding cache. Having a prefix field in the binding cache is NEMO specific, and it depends on which is the primary field (or sometimes known as the index field) in a binding cache. I would think it is the home-address, and not the prefix. Then there will be no problem as far as I can see right now. > > if they have their respective HA , > both HAs will have the chance to deal with the pakage > destined to the NEMO, how to choose the two HAs and > does it possible that both of the two HAs routing the > packag to MR respectively? If the packet is sent by a node outside the administrative domain of both HA, the packet will reach one (and only one) HA depending on the routing decision of the core/border routers. If the packet is sent by a node behind one of the HA, the packet will be intercepted by that HA, and tunneled to the mobile network. No, AFAIK, you cannot have one packet reaching two separate HAs simultaneously. However, I do agree that there is the slight possibility of packets from the same session (eg TCP session) going through both HAs, eg first packet through HA1, 2nd packet through HA2, etc. Is this a problem? Will it affect TCP's estimation of RTT and parameters of the congestion algorithm, etc? /rgds /cwng From nemo-admin@ietf.org Wed Jun 11 05:45:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00734 for ; Wed, 11 Jun 2003 05:45:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9j9B23688; Wed, 11 Jun 2003 05:45:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9aOB22525 for ; Wed, 11 Jun 2003 05:36:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00598 for ; Wed, 11 Jun 2003 05:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1zk-00068V-00 for nemo@ietf.org; Wed, 11 Jun 2003 05:34:16 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19Q1zj-00068S-00 for nemo@ietf.org; Wed, 11 Jun 2003 05:34:15 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5B9Ztaj017006; Wed, 11 Jun 2003 02:35:56 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5B9Zpcl002510; Wed, 11 Jun 2003 04:35:53 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 35B3E2EC86; Wed, 11 Jun 2003 11:35:49 +0200 (CEST) Message-ID: <3EE6F7F5.4060002@nal.motlabs.com> Date: Wed, 11 Jun 2003 11:35:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] questions about multihoming. References: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> In-Reply-To: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Wanrong. Wanrong Yu wrote: > If there are 2 root-MRs in the same NEMO, and they have same > prefix/length but different CoA, if they share the same HA, then how > would be the routing tablez(one prefix has two out interfaces ) and > Bindng Cache(one prefix needs two CoAs) of the HA? Let me first understand your question, by drawing a picture of the mobile network at home: CN ----------/ ------- | | ------------------------------------| HA/BR |---| Internet | | | ------- | | |HoA1 |HoA2 ---------- ----- ----- ----- | MR1 | |LFN1 | | MR2 | ----- ----- ----- | | | -------------------- prefix1/len1 If my picture corresponds to your model of the "multi-homed" mobile network at home then that's fine. At home, the HA/BR (Border Router) will have the following two entries in its routing table: prefix1/len1 HoA1 eth1 prefix1/len1 HoA2 eth1 Now, I consider the mobile network moves and the root-MR's attach to two AR's respectively, as in the figure below: ---- --| AR |--------------------- / ---- | / | ----------/ | ------- | | | ---| HA/BR |---| Internet | | ------- | | | ----------\ | \ | \ ---- | --| AR |--- | ---- | | |CoA1 |CoA2 ----- ----- ----- | MR1 | |LFN1 | | MR2 | ----- ----- ----- | | | -------------------- prefix1/len1 At home, the HA/BR will have the same two entries in the routing table: prefix1/len1 HoA1 eth1 prefix1/len1 HoA2 eth1 Depending on the protocol, the following two entries might also exist in the HA routing table, pointing to virtual tunnel interfaces tn0 and tn1. prefix1/len1 :: tn0 prefix1/len1 :: tn1 The Binding Cache entries in the HA are the following: HoA1 CoA1 HoA2 CoA2 > if they have their respective HA The sketches are similar, and the entries in the tables are similar. > both HAs will have the chance to deal with the pakage destined to the > NEMO, how to choose the two HAs and does it possible that both of > the two HAs routing the packag to MR respectively? A-ha, that's a good question. In order to find an answer, please allow me to get back to the first figure I sketched at the beginning of this email. Assume that, when the "multi-homed" mobile network is at home, that CN needs to talk to LFN. It will send a packet to LFN, and BR will need to forward it to either MR1 or MR2. Which one? I say to the first entry in the routing table, that is to HoA1 of MR1. Assume now that LFN wants to reply to CN. LFN will need a default route. LFN receives two RA's with the same prefix1/len1: one from MR1, the other from MR2. Only one of those RA's can advertise as a default route. Which one? I say only MR1 will advertise itself as a default router; MR2 will not. So, LFN will send packets to CN through MR1. In this way, a multi-homed mobile network that is at home allows LFN and CN to communicate ok [*]. When the multi-homed mobile network is away from home, the same preference for MR1 will be used to get through the respective CoA's and tunnel interfaces. Alex GBU [*]Remark it uses a certain preference for MR1, which is a preference. Other preference schemes might exist, like for example: use the entry whose router is up, and don't use the router that is down; or use the entry whose router's wireless is cheaper and don't use the entry whose router's wireless is expensive. I think that this choice of preference should be left open. From mailnull@www1.ietf.org Wed Jun 11 05:46:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00788 for ; Wed, 11 Jun 2003 05:46:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B9k5e23778 for nemo-archive@odin.ietf.org; Wed, 11 Jun 2003 05:46:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9k5B23774 for ; Wed, 11 Jun 2003 05:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00784 for ; Wed, 11 Jun 2003 05:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q297-0006B6-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 05:43:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q296-0006B3-00 for nemo-web-archive@ietf.org; Wed, 11 Jun 2003 05:43:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9j9B23688; Wed, 11 Jun 2003 05:45:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9aOB22525 for ; Wed, 11 Jun 2003 05:36:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00598 for ; Wed, 11 Jun 2003 05:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1zk-00068V-00 for nemo@ietf.org; Wed, 11 Jun 2003 05:34:16 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19Q1zj-00068S-00 for nemo@ietf.org; Wed, 11 Jun 2003 05:34:15 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5B9Ztaj017006; Wed, 11 Jun 2003 02:35:56 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5B9Zpcl002510; Wed, 11 Jun 2003 04:35:53 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 35B3E2EC86; Wed, 11 Jun 2003 11:35:49 +0200 (CEST) Message-ID: <3EE6F7F5.4060002@nal.motlabs.com> Date: Wed, 11 Jun 2003 11:35:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] questions about multihoming. References: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> In-Reply-To: <20030611082035.B82EB5A84D@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Wanrong. Wanrong Yu wrote: > If there are 2 root-MRs in the same NEMO, and they have same > prefix/length but different CoA, if they share the same HA, then how > would be the routing tablez(one prefix has two out interfaces ) and > Bindng Cache(one prefix needs two CoAs) of the HA? Let me first understand your question, by drawing a picture of the mobile network at home: CN ----------/ ------- | | ------------------------------------| HA/BR |---| Internet | | | ------- | | |HoA1 |HoA2 ---------- ----- ----- ----- | MR1 | |LFN1 | | MR2 | ----- ----- ----- | | | -------------------- prefix1/len1 If my picture corresponds to your model of the "multi-homed" mobile network at home then that's fine. At home, the HA/BR (Border Router) will have the following two entries in its routing table: prefix1/len1 HoA1 eth1 prefix1/len1 HoA2 eth1 Now, I consider the mobile network moves and the root-MR's attach to two AR's respectively, as in the figure below: ---- --| AR |--------------------- / ---- | / | ----------/ | ------- | | | ---| HA/BR |---| Internet | | ------- | | | ----------\ | \ | \ ---- | --| AR |--- | ---- | | |CoA1 |CoA2 ----- ----- ----- | MR1 | |LFN1 | | MR2 | ----- ----- ----- | | | -------------------- prefix1/len1 At home, the HA/BR will have the same two entries in the routing table: prefix1/len1 HoA1 eth1 prefix1/len1 HoA2 eth1 Depending on the protocol, the following two entries might also exist in the HA routing table, pointing to virtual tunnel interfaces tn0 and tn1. prefix1/len1 :: tn0 prefix1/len1 :: tn1 The Binding Cache entries in the HA are the following: HoA1 CoA1 HoA2 CoA2 > if they have their respective HA The sketches are similar, and the entries in the tables are similar. > both HAs will have the chance to deal with the pakage destined to the > NEMO, how to choose the two HAs and does it possible that both of > the two HAs routing the packag to MR respectively? A-ha, that's a good question. In order to find an answer, please allow me to get back to the first figure I sketched at the beginning of this email. Assume that, when the "multi-homed" mobile network is at home, that CN needs to talk to LFN. It will send a packet to LFN, and BR will need to forward it to either MR1 or MR2. Which one? I say to the first entry in the routing table, that is to HoA1 of MR1. Assume now that LFN wants to reply to CN. LFN will need a default route. LFN receives two RA's with the same prefix1/len1: one from MR1, the other from MR2. Only one of those RA's can advertise as a default route. Which one? I say only MR1 will advertise itself as a default router; MR2 will not. So, LFN will send packets to CN through MR1. In this way, a multi-homed mobile network that is at home allows LFN and CN to communicate ok [*]. When the multi-homed mobile network is away from home, the same preference for MR1 will be used to get through the respective CoA's and tunnel interfaces. Alex GBU [*]Remark it uses a certain preference for MR1, which is a preference. Other preference schemes might exist, like for example: use the entry whose router is up, and don't use the router that is down; or use the entry whose router's wireless is cheaper and don't use the entry whose router's wireless is expensive. I think that this choice of preference should be left open. From nemo-admin@ietf.org Fri Jun 13 12:59:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12644 for ; Fri, 13 Jun 2003 12:59:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBq1a01963; Fri, 13 Jun 2003 07:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBp4m01894 for ; Fri, 13 Jun 2003 07:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29020 for ; Fri, 13 Jun 2003 07:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qn38-0003ov-00 for nemo@ietf.org; Fri, 13 Jun 2003 07:48:54 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19Qn37-0003os-00 for nemo@ietf.org; Fri, 13 Jun 2003 07:48:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5DBotTN019473 for ; Fri, 13 Jun 2003 13:50:57 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28992; Fri, 13 Jun 2003 07:50:53 -0400 (EDT) Message-Id: <200306131150.HAA28992@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@nal.motlabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Jun 2003 07:50:52 -0400 Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Author(s) : J. Jeong et al. Filename : draft-jeong-nemo-ro-ndproxy-00.txt Pages : 8 Date : 2003-6-12 This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router provides the prefix of its care-of- address for its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-nemo-ro-ndproxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-12132235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-nemo-ro-ndproxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132235.I-D@ietf.org> --OtherAccess-- --NextPart-- From mailnull@www1.ietf.org Fri Jun 13 13:00:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12742 for ; Fri, 13 Jun 2003 13:00:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DH0An04726 for nemo-archive@odin.ietf.org; Fri, 13 Jun 2003 13:00:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH09m04721 for ; Fri, 13 Jun 2003 13:00:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12696 for ; Fri, 13 Jun 2003 13:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrsF-0006oa-00 for nemo-web-archive@ietf.org; Fri, 13 Jun 2003 12:57:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QrsE-0006oT-00 for nemo-web-archive@ietf.org; Fri, 13 Jun 2003 12:57:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBq1a01963; Fri, 13 Jun 2003 07:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBp4m01894 for ; Fri, 13 Jun 2003 07:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29020 for ; Fri, 13 Jun 2003 07:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qn38-0003ov-00 for nemo@ietf.org; Fri, 13 Jun 2003 07:48:54 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19Qn37-0003os-00 for nemo@ietf.org; Fri, 13 Jun 2003 07:48:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5DBotTN019473 for ; Fri, 13 Jun 2003 13:50:57 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28992; Fri, 13 Jun 2003 07:50:53 -0400 (EDT) Message-Id: <200306131150.HAA28992@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@nal.motlabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Jun 2003 07:50:52 -0400 Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Author(s) : J. Jeong et al. Filename : draft-jeong-nemo-ro-ndproxy-00.txt Pages : 8 Date : 2003-6-12 This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router provides the prefix of its care-of- address for its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-nemo-ro-ndproxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-12132235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-nemo-ro-ndproxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132235.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Sun Jun 15 02:50:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24768 for ; Sun, 15 Jun 2003 02:50:09 -0400 (EDT) Received: from optimus.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F3RGa14782; Sat, 14 Jun 2003 23:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F3Qbm14761 for ; Sat, 14 Jun 2003 23:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10399 for ; Sat, 14 Jun 2003 23:26:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RO7y-0001ML-00 for nemo@ietf.org; Sat, 14 Jun 2003 23:24:22 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RO7x-0001MA-00 for nemo@ietf.org; Sat, 14 Jun 2003 23:24:21 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5F3QPTN007822 for ; Sun, 15 Jun 2003 05:26:27 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5F3cx728435 for ; Sun, 15 Jun 2003 12:39:00 +0900 (KST) Message-ID: <005d01c332ed$b6058980$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: Date: Sun, 15 Jun 2003 12:25:02 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C33339.24FBCCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] Request for your comments on a new RO draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C33339.24FBCCA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 SGVsbG8sIG5lbW8gZ3V5cyEgDQoNCkkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHRoZSBS b3V0ZSBPcHRpbWl6YXRpb24gKFJPKSBmb3IgbW9iaWxlIG5vZGVzIGluIG1vYmlsZSBuZXR3b3Jr LiANCg0KIFRpdGxlIDogTkQtUHJveHkgYmFzZWQgUm91dGUgT3B0aW1pemF0aW9uIGZvciBNb2Jp bGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsgDQogVVJMIGZvciB0aGUgRHJhZnQgOiBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHkt MDAudHh0IA0KDQpJdCBpcyBiYXNlZCBvbiBORC1Qcm94eSBmb3Igc3VwcG9ydGluZyBtdWx0aS1s aW5rIHN1Ym5ldC4NCldoZW5ldmVyIGEgbW9iaWxlIHJvdXRlciBtb3ZlcyBpbnRvIGFub3RoZXIg YWNjZXNzIG5ldHdvcmssIA0KaXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdp dGggdGhlIG5ldHdvcmsgcHJlZml4IG9mIHRoZSBhY2Nlc3MgbmV0d29yay4NClRoaXMgc2NoZW1l IG1ha2VzIHRoZSBhY2Nlc3MgbmV0d29yayBhbmQgbW9iaWxlIG5ldHdvcmsgYmVjb21lIGEgbXVs dGktbGluayBzdWJuZXQsIA0KYWxsb3dpbmcgdGhlIGxvY2FsIG9yIHZpc2l0aW5nIG1vYmlsZSBu b2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrDQp0byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRl IGZvciByb3V0ZSBvcHRpbWl6YXRpb24uDQoNClRob3VnaCBSTyBpcyBub3QgdGhlIGN1cnJlbnQg aXNzdWUgaW4gbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBpbXBvcnRh bnQgaW4gbmVtby4gDQpUaHJvdWdoIG9uLWxpbmUgZGlzY3Vzc2lvbiBhYm91dCBSTywgaXQgbWF5 IGJlIGdvb2QgZm9yIHVzIHRvIHByZXBhcmUgUk8gaXNzdWUgDQp0aGF0IGNhbiBiZSBkaXNjdXNz ZWQgaW4gZWFybmVzdCBuZXh0IHllYXIuIA0KU28sIEknZCBsaWtlIHRvIHJlcXVlc3QgeW91ciBj b21tZW50cyBvbiBteSBkcmFmdC4gDQpUaGFua3MuIA0KDQpSZWdhcmRzLCANCkphZWhvb24gDQo= ------=_NextPart_000_005A_01C33339.24FBCCA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3 NTQ4OyBzaXplPTI+SGVsbG8sIG5lbW8gZ3V5cyEgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj5JIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBh Ym91dCB0aGUgUm91dGUgT3B0aW1pemF0aW9uIA0KKFJPKSBmb3IgbW9iaWxlIG5vZGVzIGluIG1v YmlsZSBuZXR3b3JrLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3 NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7 JiM0NzU0ODsgc2l6ZT0yPiZuYnNwO1RpdGxlIDogTkQtUHJveHkgYmFzZWQgUm91dGUgT3B0aW1p emF0aW9uIGZvciANCk1vYmlsZSBOb2RlcyBpbiBNb2JpbGUgTmV0d29yayA8QlI+Jm5ic3A7VVJM IGZvciB0aGUgRHJhZnQgOiA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQ8 L0E+IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7 IHNpemU9Mj5JdCBpcyBiYXNlZCBvbiBORC1Qcm94eSBmb3Igc3VwcG9ydGluZyBtdWx0aS1saW5r IA0Kc3VibmV0LjxCUj5XaGVuZXZlciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVy IGFjY2VzcyBuZXR3b3JrLCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0 OyYjNDc1NDg7IHNpemU9Mj5pdCBwcm92aWRlcyBpdHMgbW9iaWxlIG5ldHdvcmsgbm9kZXMgd2l0 aCB0aGUgbmV0d29yayANCnByZWZpeCBvZiB0aGUgYWNjZXNzIG5ldHdvcmsuPEJSPlRoaXMgc2No ZW1lIG1ha2VzIHRoZSBhY2Nlc3MgbmV0d29yayBhbmQgbW9iaWxlIA0KbmV0d29yayBiZWNvbWUg YSBtdWx0aS1saW5rIHN1Ym5ldCwgPEJSPmFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNpdGluZyBt b2JpbGUgDQpub2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrPEJSPnRvIHBlcmZvcm0gYmlu ZGluZyB1cGRhdGUgZm9yIHJvdXRlIA0Kb3B0aW1pemF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+VGhvdWdoIFJPIGlzIG5vdCB0 aGUgY3VycmVudCBpc3N1ZSBpbiBuZW1vIHdnLCBJIA0KdGhpbmssIHRoZSByZXNlYXJjaCBmb3Ig Uk8gaXMgaW1wb3J0YW50IGluIG5lbW8uIDxCUj5UaHJvdWdoIG9uLWxpbmUgZGlzY3Vzc2lvbiAN CmFib3V0IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFyZSBSTyBpc3N1ZSA8QlI+ dGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIA0KZWFybmVzdCBuZXh0IHllYXIuIDxCUj5TbywgSSdk IGxpa2UgdG8gcmVxdWVzdCB5b3VyIGNvbW1lbnRzIG9uIG15IGRyYWZ0LiANCjxCUj5UaGFua3Mu IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXpl PTI+UmVnYXJkcywgPEJSPkphZWhvb24gPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_005A_01C33339.24FBCCA0-- From mailnull@www1.ietf.org Sun Jun 15 02:50:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24807 for ; Sun, 15 Jun 2003 02:50:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5F6oG405861 for nemo-archive@odin.ietf.org; Sun, 15 Jun 2003 02:50:16 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F6oGm05858 for ; Sun, 15 Jun 2003 02:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24786 for ; Sun, 15 Jun 2003 02:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RRJ3-0002FN-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 02:48:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RRJ2-0002FJ-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 02:48:00 -0400 Received: from optimus.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F3RGa14782; Sat, 14 Jun 2003 23:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F3Qbm14761 for ; Sat, 14 Jun 2003 23:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10399 for ; Sat, 14 Jun 2003 23:26:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RO7y-0001ML-00 for nemo@ietf.org; Sat, 14 Jun 2003 23:24:22 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RO7x-0001MA-00 for nemo@ietf.org; Sat, 14 Jun 2003 23:24:21 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5F3QPTN007822 for ; Sun, 15 Jun 2003 05:26:27 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5F3cx728435 for ; Sun, 15 Jun 2003 12:39:00 +0900 (KST) Message-ID: <005d01c332ed$b6058980$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: Date: Sun, 15 Jun 2003 12:25:02 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C33339.24FBCCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] Request for your comments on a new RO draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C33339.24FBCCA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 SGVsbG8sIG5lbW8gZ3V5cyEgDQoNCkkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHRoZSBS b3V0ZSBPcHRpbWl6YXRpb24gKFJPKSBmb3IgbW9iaWxlIG5vZGVzIGluIG1vYmlsZSBuZXR3b3Jr LiANCg0KIFRpdGxlIDogTkQtUHJveHkgYmFzZWQgUm91dGUgT3B0aW1pemF0aW9uIGZvciBNb2Jp bGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsgDQogVVJMIGZvciB0aGUgRHJhZnQgOiBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHkt MDAudHh0IA0KDQpJdCBpcyBiYXNlZCBvbiBORC1Qcm94eSBmb3Igc3VwcG9ydGluZyBtdWx0aS1s aW5rIHN1Ym5ldC4NCldoZW5ldmVyIGEgbW9iaWxlIHJvdXRlciBtb3ZlcyBpbnRvIGFub3RoZXIg YWNjZXNzIG5ldHdvcmssIA0KaXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdp dGggdGhlIG5ldHdvcmsgcHJlZml4IG9mIHRoZSBhY2Nlc3MgbmV0d29yay4NClRoaXMgc2NoZW1l IG1ha2VzIHRoZSBhY2Nlc3MgbmV0d29yayBhbmQgbW9iaWxlIG5ldHdvcmsgYmVjb21lIGEgbXVs dGktbGluayBzdWJuZXQsIA0KYWxsb3dpbmcgdGhlIGxvY2FsIG9yIHZpc2l0aW5nIG1vYmlsZSBu b2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrDQp0byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRl IGZvciByb3V0ZSBvcHRpbWl6YXRpb24uDQoNClRob3VnaCBSTyBpcyBub3QgdGhlIGN1cnJlbnQg aXNzdWUgaW4gbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBpbXBvcnRh bnQgaW4gbmVtby4gDQpUaHJvdWdoIG9uLWxpbmUgZGlzY3Vzc2lvbiBhYm91dCBSTywgaXQgbWF5 IGJlIGdvb2QgZm9yIHVzIHRvIHByZXBhcmUgUk8gaXNzdWUgDQp0aGF0IGNhbiBiZSBkaXNjdXNz ZWQgaW4gZWFybmVzdCBuZXh0IHllYXIuIA0KU28sIEknZCBsaWtlIHRvIHJlcXVlc3QgeW91ciBj b21tZW50cyBvbiBteSBkcmFmdC4gDQpUaGFua3MuIA0KDQpSZWdhcmRzLCANCkphZWhvb24gDQo= ------=_NextPart_000_005A_01C33339.24FBCCA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3 NTQ4OyBzaXplPTI+SGVsbG8sIG5lbW8gZ3V5cyEgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj5JIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBh Ym91dCB0aGUgUm91dGUgT3B0aW1pemF0aW9uIA0KKFJPKSBmb3IgbW9iaWxlIG5vZGVzIGluIG1v YmlsZSBuZXR3b3JrLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3 NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7 JiM0NzU0ODsgc2l6ZT0yPiZuYnNwO1RpdGxlIDogTkQtUHJveHkgYmFzZWQgUm91dGUgT3B0aW1p emF0aW9uIGZvciANCk1vYmlsZSBOb2RlcyBpbiBNb2JpbGUgTmV0d29yayA8QlI+Jm5ic3A7VVJM IGZvciB0aGUgRHJhZnQgOiA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQ8 L0E+IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7 IHNpemU9Mj5JdCBpcyBiYXNlZCBvbiBORC1Qcm94eSBmb3Igc3VwcG9ydGluZyBtdWx0aS1saW5r IA0Kc3VibmV0LjxCUj5XaGVuZXZlciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVy IGFjY2VzcyBuZXR3b3JrLCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0 OyYjNDc1NDg7IHNpemU9Mj5pdCBwcm92aWRlcyBpdHMgbW9iaWxlIG5ldHdvcmsgbm9kZXMgd2l0 aCB0aGUgbmV0d29yayANCnByZWZpeCBvZiB0aGUgYWNjZXNzIG5ldHdvcmsuPEJSPlRoaXMgc2No ZW1lIG1ha2VzIHRoZSBhY2Nlc3MgbmV0d29yayBhbmQgbW9iaWxlIA0KbmV0d29yayBiZWNvbWUg YSBtdWx0aS1saW5rIHN1Ym5ldCwgPEJSPmFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNpdGluZyBt b2JpbGUgDQpub2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrPEJSPnRvIHBlcmZvcm0gYmlu ZGluZyB1cGRhdGUgZm9yIHJvdXRlIA0Kb3B0aW1pemF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+VGhvdWdoIFJPIGlzIG5vdCB0 aGUgY3VycmVudCBpc3N1ZSBpbiBuZW1vIHdnLCBJIA0KdGhpbmssIHRoZSByZXNlYXJjaCBmb3Ig Uk8gaXMgaW1wb3J0YW50IGluIG5lbW8uIDxCUj5UaHJvdWdoIG9uLWxpbmUgZGlzY3Vzc2lvbiAN CmFib3V0IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFyZSBSTyBpc3N1ZSA8QlI+ dGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIA0KZWFybmVzdCBuZXh0IHllYXIuIDxCUj5TbywgSSdk IGxpa2UgdG8gcmVxdWVzdCB5b3VyIGNvbW1lbnRzIG9uIG15IGRyYWZ0LiANCjxCUj5UaGFua3Mu IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXpl PTI+UmVnYXJkcywgPEJSPkphZWhvb24gPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_005A_01C33339.24FBCCA0-- From nemo-admin@ietf.org Sun Jun 15 09:06:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01029 for ; Sun, 15 Jun 2003 09:06:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBCxa25056; Sun, 15 Jun 2003 07:12:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBC1m25037 for ; Sun, 15 Jun 2003 07:12:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28458 for ; Sun, 15 Jun 2003 07:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RVOM-00034g-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:09:46 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19RVOL-00034d-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:09:45 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 0348A5A5F2; Sun, 15 Jun 2003 19:15:58 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu Cc: petrescu@nal.motlabs.co, cwng@psl.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20030615111558.0348A5A5F2@ds20.nudt.edu.cn> Date: Sun, 15 Jun 2003 19:15:58 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B??= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,Chan-Wah,Alex Thanks for your enthusiastic answers, though the thanks may be later:-) Wed, 11 Jun 2003 16:54:47 Chan-Wah wrote: > No, AFAIK, you cannot have one packet reaching two separate HAs > simultaneously. However, I do agree that there is the slight > possibility of packets from the same session (eg TCP session) going > through both HAs, eg first packet through HA1, 2nd packet through HA2, > etc. Is this a problem? Will it affect TCP's estimation of RTT and > parameters of the congestion algorithm, etc? No,I don't think there are problems, at least I don't find any at present. Wanrong Yu From mailnull@www1.ietf.org Sun Jun 15 09:07:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01063 for ; Sun, 15 Jun 2003 09:07:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FD73T30629 for nemo-archive@odin.ietf.org; Sun, 15 Jun 2003 09:07:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FD73m30626 for ; Sun, 15 Jun 2003 09:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01045 for ; Sun, 15 Jun 2003 09:07:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RXBh-0003Zt-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 09:04:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RXBg-0003Zq-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 09:04:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBCxa25056; Sun, 15 Jun 2003 07:12:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBC1m25037 for ; Sun, 15 Jun 2003 07:12:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28458 for ; Sun, 15 Jun 2003 07:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RVOM-00034g-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:09:46 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19RVOL-00034d-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:09:45 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 0348A5A5F2; Sun, 15 Jun 2003 19:15:58 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu Cc: petrescu@nal.motlabs.co, cwng@psl.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20030615111558.0348A5A5F2@ds20.nudt.edu.cn> Date: Sun, 15 Jun 2003 19:15:58 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B??= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,Chan-Wah,Alex Thanks for your enthusiastic answers, though the thanks may be later:-) Wed, 11 Jun 2003 16:54:47 Chan-Wah wrote: > No, AFAIK, you cannot have one packet reaching two separate HAs > simultaneously. However, I do agree that there is the slight > possibility of packets from the same session (eg TCP session) going > through both HAs, eg first packet through HA1, 2nd packet through HA2, > etc. Is this a problem? Will it affect TCP's estimation of RTT and > parameters of the congestion algorithm, etc? No,I don't think there are problems, at least I don't find any at present. Wanrong Yu From nemo-admin@ietf.org Sun Jun 15 09:17:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01196 for ; Sun, 15 Jun 2003 09:17:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBn1a26756; Sun, 15 Jun 2003 07:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBmim26744 for ; Sun, 15 Jun 2003 07:48:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28803 for ; Sun, 15 Jun 2003 07:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RVxu-00038E-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:46:30 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19RVxt-00038B-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:46:29 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id AC3AC5B058; Sun, 15 Jun 2003 19:52:54 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu Cc: petrescu@nal.motlabs.com, cwng@psl.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20030615115254.AC3AC5B058@ds20.nudt.edu.cn> Date: Sun, 15 Jun 2003 19:52:54 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBxdWVzdGlvbnMgYWJvdXQgbXVsdGlob21pbmc=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,Chan-Wah,Alex Thanks for your enthusiastic answers, though the thanks may be later:-) Wed, 11 Jun 2003 16:54:47 Chan-Wah wrote: > No, AFAIK, you cannot have one packet reaching two separate HAs > simultaneously. However, I do agree that there is the slight > possibility of packets from the same session (eg TCP session) going > through both HAs, eg first packet through HA1, 2nd packet through HA2, > etc. Is this a problem? Will it affect TCP's estimation of RTT and > parameters of the congestion algorithm, etc? No,I don't think there are problems, at least I don't find any at present. Wanrong Yu From mailnull@www1.ietf.org Sun Jun 15 09:18:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01215 for ; Sun, 15 Jun 2003 09:18:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FDI4n31718 for nemo-archive@odin.ietf.org; Sun, 15 Jun 2003 09:18:04 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FDI4m31715 for ; Sun, 15 Jun 2003 09:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01212 for ; Sun, 15 Jun 2003 09:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RXMM-0003cc-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 09:15:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RXML-0003cZ-00 for nemo-web-archive@ietf.org; Sun, 15 Jun 2003 09:15:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBn1a26756; Sun, 15 Jun 2003 07:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBmim26744 for ; Sun, 15 Jun 2003 07:48:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28803 for ; Sun, 15 Jun 2003 07:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RVxu-00038E-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:46:30 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19RVxt-00038B-00 for nemo@ietf.org; Sun, 15 Jun 2003 07:46:29 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id AC3AC5B058; Sun, 15 Jun 2003 19:52:54 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org Reply-To: Wanrong Yu Cc: petrescu@nal.motlabs.com, cwng@psl.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20030615115254.AC3AC5B058@ds20.nudt.edu.cn> Date: Sun, 15 Jun 2003 19:52:54 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBxdWVzdGlvbnMgYWJvdXQgbXVsdGlob21pbmc=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,Chan-Wah,Alex Thanks for your enthusiastic answers, though the thanks may be later:-) Wed, 11 Jun 2003 16:54:47 Chan-Wah wrote: > No, AFAIK, you cannot have one packet reaching two separate HAs > simultaneously. However, I do agree that there is the slight > possibility of packets from the same session (eg TCP session) going > through both HAs, eg first packet through HA1, 2nd packet through HA2, > etc. Is this a problem? Will it affect TCP's estimation of RTT and > parameters of the congestion algorithm, etc? No,I don't think there are problems, at least I don't find any at present. Wanrong Yu From nemo-admin@ietf.org Mon Jun 16 03:31:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04459 for ; Mon, 16 Jun 2003 03:31:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1E0a08876; Sun, 15 Jun 2003 21:14:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1Dfm08862 for ; Sun, 15 Jun 2003 21:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15972 for ; Sun, 15 Jun 2003 21:13:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RiWs-0006KE-00 for nemo@ietf.org; Sun, 15 Jun 2003 21:11:26 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RiWo-0006KA-00 for nemo@ietf.org; Sun, 15 Jun 2003 21:11:24 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5G1DVTN012317 for ; Mon, 16 Jun 2003 03:13:32 +0200 Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5G1BWgx008924; Mon, 16 Jun 2003 10:11:34 +0900 From: "Na, Jong Keun" To: "'Jaehoon Jeong'" , Subject: RE: [nemo] Request for your comments on a new RO draft Date: Mon, 16 Jun 2003 10:15:23 +0900 Message-ID: <01e201c333a4$c58f1e90$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E3_01C333F0.3576C690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <005d01c332ed$b6058980$c470fe81@etri.re.kr> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_01E3_01C333F0.3576C690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jaehoon, I have a concern in your draft. Is it right direction to give the burden of mobility management to each MNNs, not MRs? To the best of my knowledge, In NEMO, it's a basic principal for MR to manage the mobility of mobile network transparently to nodes behind it. If nodes behind MR get new CoA of the access link via Proxy-ND each time MR changes the point of attachment, all of nodes have to directly process each their handover(L3 address changed). How do you think of my point? If something missed, please correct me. Thanks. /Jong -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Jaehoon Jeong Sent: Sunday, June 15, 2003 12:25 PM To: nemo@nal.motlabs.com Subject: [nemo] Request for your comments on a new RO draft Hello, nemo guys! I submitted a new draft about the Route Optimization (RO) for mobile nodes in mobile network. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network URL for the Draft : http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt It is based on ND-Proxy for supporting multi-link subnet. Whenever a mobile router moves into another access network, it provides its mobile network nodes with the network prefix of the access network. This scheme makes the access network and mobile network become a multi-link subnet, allowing the local or visiting mobile nodes within the mobile network to perform binding update for route optimization. Though RO is not the current issue in nemo wg, I think, the research for RO is important in nemo. Through on-line discussion about RO, it may be good for us to prepare RO issue that can be discussed in earnest next year. So, I'd like to request your comments on my draft. Thanks. Regards, Jaehoon ------=_NextPart_000_01E3_01C333F0.3576C690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jaehoon,

 

I have a concern in your = draft.

Is it right direction to = give the burden of mobility management to each MNNs, not MRs?

To the best of my = knowledge, In NEMO, it’s a basic principal for MR to manage the mobility of mobile = network transparently to nodes behind it. If nodes behind MR get new CoA of the access link via Proxy-ND each time MR = changes the point of attachment, all of nodes have to directly process each = their handover(L3 address changed). How do you think of = my point?

If something missed, please correct me. Thanks.

 

/Jong

 

-----Original Message-----
From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On = Behalf Of Jaehoon Jeong
Sent: Sunday, June 15, = 2003 12:25 PM
To: = nemo@nal.motlabs.com
Subject: [nemo] Request = for your comments on a new RO draft

 

Hello, nemo guys!

 

I submitted a new draft about the Route Optimization = (RO) for mobile nodes in mobile network.

 

 Title : ND-Proxy based Route Optimization for = Mobile Nodes in Mobile Network
 URL for the Draft : http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00= .txt

 

It is based on ND-Proxy for supporting multi-link = subnet.
Whenever a mobile router moves into another access network, =

it provides its mobile network nodes with the network = prefix of the access network.
This scheme makes the access network and mobile network become a = multi-link subnet,
allowing the local or visiting mobile nodes within the mobile = network
to perform binding update for route optimization.

 

Though RO is not the current issue in nemo wg, I = think, the research for RO is important in nemo.
Through on-line discussion about RO, it may be good for us to prepare RO = issue
that can be discussed in earnest next year.
So, I'd like to request your comments on my draft.
Thanks.

 

Regards,
Jaehoon

------=_NextPart_000_01E3_01C333F0.3576C690-- From mailnull@www1.ietf.org Mon Jun 16 03:32:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04499 for ; Mon, 16 Jun 2003 03:32:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G7VsQ10645 for nemo-archive@odin.ietf.org; Mon, 16 Jun 2003 03:31:54 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7Vsm10642 for ; Mon, 16 Jun 2003 03:31:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04495 for ; Mon, 16 Jun 2003 03:31:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RoQs-0000TM-00 for nemo-web-archive@ietf.org; Mon, 16 Jun 2003 03:29:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RoQs-0000TI-00 for nemo-web-archive@ietf.org; Mon, 16 Jun 2003 03:29:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1E0a08876; Sun, 15 Jun 2003 21:14:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1Dfm08862 for ; Sun, 15 Jun 2003 21:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15972 for ; Sun, 15 Jun 2003 21:13:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RiWs-0006KE-00 for nemo@ietf.org; Sun, 15 Jun 2003 21:11:26 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RiWo-0006KA-00 for nemo@ietf.org; Sun, 15 Jun 2003 21:11:24 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5G1DVTN012317 for ; Mon, 16 Jun 2003 03:13:32 +0200 Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5G1BWgx008924; Mon, 16 Jun 2003 10:11:34 +0900 From: "Na, Jong Keun" To: "'Jaehoon Jeong'" , Subject: RE: [nemo] Request for your comments on a new RO draft Date: Mon, 16 Jun 2003 10:15:23 +0900 Message-ID: <01e201c333a4$c58f1e90$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E3_01C333F0.3576C690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <005d01c332ed$b6058980$c470fe81@etri.re.kr> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_01E3_01C333F0.3576C690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jaehoon, I have a concern in your draft. Is it right direction to give the burden of mobility management to each MNNs, not MRs? To the best of my knowledge, In NEMO, it's a basic principal for MR to manage the mobility of mobile network transparently to nodes behind it. If nodes behind MR get new CoA of the access link via Proxy-ND each time MR changes the point of attachment, all of nodes have to directly process each their handover(L3 address changed). How do you think of my point? If something missed, please correct me. Thanks. /Jong -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Jaehoon Jeong Sent: Sunday, June 15, 2003 12:25 PM To: nemo@nal.motlabs.com Subject: [nemo] Request for your comments on a new RO draft Hello, nemo guys! I submitted a new draft about the Route Optimization (RO) for mobile nodes in mobile network. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network URL for the Draft : http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt It is based on ND-Proxy for supporting multi-link subnet. Whenever a mobile router moves into another access network, it provides its mobile network nodes with the network prefix of the access network. This scheme makes the access network and mobile network become a multi-link subnet, allowing the local or visiting mobile nodes within the mobile network to perform binding update for route optimization. Though RO is not the current issue in nemo wg, I think, the research for RO is important in nemo. Through on-line discussion about RO, it may be good for us to prepare RO issue that can be discussed in earnest next year. So, I'd like to request your comments on my draft. Thanks. Regards, Jaehoon ------=_NextPart_000_01E3_01C333F0.3576C690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jaehoon,

 

I have a concern in your = draft.

Is it right direction to = give the burden of mobility management to each MNNs, not MRs?

To the best of my = knowledge, In NEMO, it’s a basic principal for MR to manage the mobility of mobile = network transparently to nodes behind it. If nodes behind MR get new CoA of the access link via Proxy-ND each time MR = changes the point of attachment, all of nodes have to directly process each = their handover(L3 address changed). How do you think of = my point?

If something missed, please correct me. Thanks.

 

/Jong

 

-----Original Message-----
From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On = Behalf Of Jaehoon Jeong
Sent: Sunday, June 15, = 2003 12:25 PM
To: = nemo@nal.motlabs.com
Subject: [nemo] Request = for your comments on a new RO draft

 

Hello, nemo guys!

 

I submitted a new draft about the Route Optimization = (RO) for mobile nodes in mobile network.

 

 Title : ND-Proxy based Route Optimization for = Mobile Nodes in Mobile Network
 URL for the Draft : http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00= .txt

 

It is based on ND-Proxy for supporting multi-link = subnet.
Whenever a mobile router moves into another access network, =

it provides its mobile network nodes with the network = prefix of the access network.
This scheme makes the access network and mobile network become a = multi-link subnet,
allowing the local or visiting mobile nodes within the mobile = network
to perform binding update for route optimization.

 

Though RO is not the current issue in nemo wg, I = think, the research for RO is important in nemo.
Through on-line discussion about RO, it may be good for us to prepare RO = issue
that can be discussed in earnest next year.
So, I'd like to request your comments on my draft.
Thanks.

 

Regards,
Jaehoon

------=_NextPart_000_01E3_01C333F0.3576C690-- From nemo-admin@ietf.org Mon Jun 16 08:59:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12452 for ; Mon, 16 Jun 2003 08:59:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G6s2a08248; Mon, 16 Jun 2003 02:54:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G6r7m08212 for ; Mon, 16 Jun 2003 02:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03806 for ; Mon, 16 Jun 2003 02:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RnpK-0000I6-00 for nemo@ietf.org; Mon, 16 Jun 2003 02:50:50 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RnpI-0000Hk-00 for nemo@ietf.org; Mon, 16 Jun 2003 02:50:48 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5G6qjTN013741 for ; Mon, 16 Jun 2003 08:52:49 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5G75H707514; Mon, 16 Jun 2003 16:05:17 +0900 (KST) Message-ID: <010401c333d3$b6656440$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Na, Jong Keun" Cc: "NEMO WG" , =?utf-8?B?67CV7KCV7IiY?= , =?utf-8?B?6rmA7ZiV7KSA?= , =?utf-8?B?7J206rK97KeE?= , =?utf-8?B?6rmA67OR7Je9?= , =?utf-8?B?7LCo7ZiE7Jqx?= , =?utf-8?B?7KCV7J6s7ZuI?= References: <01e201c333a4$c58f1e90$dbf02e93@jongkn02> Subject: Re: [nemo] Request for your comments on a new RO draft Date: Mon, 16 Jun 2003 15:51:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01C3341F.1FECF7C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00FF_01C3341F.1FECF7C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEpvbmcgS2V1bi4NCg0KaW5saW5lczotKQ0KDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQo+IEZyb206IE5hLCBKb25nIEtldW4gDQo+IFRvOiAnSmFlaG9vbiBKZW9uZycgOyBu ZW1vQG5hbC5tb3RsYWJzLmNvbSANCj4gU2VudDogTW9uZGF5LCBKdW5lIDE2LCAyMDAzIDEwOjE1 IEFNDQo+IFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciBjb21tZW50cyBvbiBh IG5ldyBSTyBkcmFmdA0KPg0KPg0KPiBIaSBKYWVob29uLA0KPiANCj4gSSBoYXZlIGEgY29uY2Vy biBpbiB5b3VyIGRyYWZ0Lg0KPiBJcyBpdCByaWdodCBkaXJlY3Rpb24gdG8gZ2l2ZSB0aGUgYnVy ZGVuIG9mIG1vYmlsaXR5IG1hbmFnZW1lbnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPw0KDQogICAg Rm9yIFJvdXRlIE9wdGltaXphdGlvbiAoUk8pLCBJIHRoaW5rLCBlYWNoIE1OTiAoVk1OIG9yIExN Tikgc2hvdWxkIHBlcmZvcm0gDQogICAgdGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgcmVsYXRlZCB0 byBSTy4NCiAgICBCZWNhdXNlIFJPIHVzZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGRpcmVjdGx5LCBl YWNoIG1vYmlsZSBub2RlIGlzIGVmZmljaWVudCB0byBwZXJmb3JtIGl0cyBSTw0KICAgIGluIHRo ZSBzYW1lIG1hbm5lciBhcyBNSVB2Ni4gDQoNCj4gDQo+IFRvIHRoZSBiZXN0IG9mIG15IGtub3ds ZWRnZSwgSW4gTkVNTywgaXTigJlzIGEgYmFzaWMgcHJpbmNpcGFsIGZvciBNUiB0byBtYW5hZ2Ug dGhlIG1vYmlsaXR5IG9mIA0KPiBtb2JpbGUgbmV0d29yayB0cmFuc3BhcmVudGx5IHRvIG5vZGVz IGJlaGluZCBpdC4NCj4gDQogICAgT25seSB3aGVuIFJPIGlzIGV4Y2x1ZGVkIGluIE5FTk8gb3Bl cmF0aW9uLCBpdCBpcyByaWdodC4NCiAgICBGb3IgbG9jYWwgZml4ZWQgbm9kZSAoTEZOKSwgdGhl IG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQuDQogICAgVGhlIHNjb3BlIG9m IFJPIG9mIG15IGRyYWZ0IGlzIGZvciBtb2JpbGUgbm9kZXMsIGVpdGhlciBsb2NhbCBtb2JpbGUg bm9kZSAoTE1OKSBvciANCiAgICB2aXNpdGluZyBtb2JpbGUgbm9kZSAoVk1OKS4gIA0KDQo+IA0K PiBJZiBub2RlcyBiZWhpbmQgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2VzcyBsaW5rIHZpYSBQ cm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyANCj4gdGhlIHBvaW50IG9mIGF0dGFjaG1lbnQs IGFsbCBvZiBub2RlcyBoYXZlIHRvIGRpcmVjdGx5IHByb2Nlc3MgZWFjaCB0aGVpciBoYW5kb3Zl cihMMyBhZGRyZXNzIGNoYW5nZWQpLg0KDQogICAgIEFsbCBtb2JpbGUgbm9kZXMgbmVlZCBub3Qg cGFydGljaXBhdGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBkcmFmdC4gDQogICAgIEhvdyBh Ym91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5lZWQgUk8gcGVyZm9ybWluZyB0aGUgUk8/IA0K ICAgICBSTyBjYW4gYmUgcGVyZm9ybWVkIG9ubHkgYnkgbW9iaWxlIG5vZGVzIHRoYXQgY2FuIHVu ZGVyc3RhbmQgdGhlIGV4dGVuZGVkIHByZWZpeCBpbmZvcm1hdGlvbiBvcHRpb24NCiAgICAgb2Yg UkEgbWVzc2FnZSwgaW5jbHVkaW5nIHRoZSBwcmVmaXggb2YgYSBuZXcgYWNjZXNzIG5ldHdvcmsu DQogICAgIEl0IGlzIHJlYXNvbmFibGUsIEkgdGhpbmsuDQogICAgIEluIGNvbmNsdXNpb24sIGZv ciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyByZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVy biByb3V0YWJpbGl0eSBhbmQgDQogICAgIGJpbmRpbmcgdXBkYXRlIHByb2NlZHVyZSBieSBpdHNl bGYuDQoNCj4gDQo+IEhvdyBkbyB5b3UgdGhpbmsgb2YgbXkgcG9pbnQ/DQo+IElmIHNvbWV0aGlu ZyBtaXNzZWQsIHBsZWFzZSBjb3JyZWN0IG1lLiBUaGFua3MuDQo+ICANCj4gL0pvbmcNCg0KICAg IFRoYW5rcyBmb3IgeW91ciBpbnRlcmVzdC4NCiAgICANCiAgICAvSmFlaG9vbg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5lbW8tYWRtaW5AaWV0Zi5vcmcgW21haWx0 bzpuZW1vLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFlaG9vbiBKZW9uZw0KPiBTZW50 OiBTdW5kYXksIEp1bmUgMTUsIDIwMDMgMTI6MjUgUE0NCj4gVG86IG5lbW9AbmFsLm1vdGxhYnMu Y29tDQo+IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEgbmV3 IFJPIGRyYWZ0DQo+ICANCj4gSGVsbG8sIG5lbW8gZ3V5cyEgDQo+ICANCj4gSSBzdWJtaXR0ZWQg YSBuZXcgZHJhZnQgYWJvdXQgdGhlIFJvdXRlIE9wdGltaXphdGlvbiAoUk8pIGZvciBtb2JpbGUg bm9kZXMgaW4gbW9iaWxlIG5ldHdvcmsuIA0KPiAgDQo+ICBUaXRsZSA6IE5ELVByb3h5IGJhc2Vk IFJvdXRlIE9wdGltaXphdGlvbiBmb3IgTW9iaWxlIE5vZGVzIGluIE1vYmlsZSBOZXR3b3JrIA0K PiAgVVJMIGZvciB0aGUgRHJhZnQgOiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDAudHh0IA0KPiAgDQo+IEl0IGlzIGJhc2Vk IG9uIE5ELVByb3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxpbmsgc3VibmV0Lg0KPiBXaGVuZXZl ciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFjY2VzcyBuZXR3b3JrLCANCj4g aXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdpdGggdGhlIG5ldHdvcmsgcHJl Zml4IG9mIHRoZSBhY2Nlc3MgbmV0d29yay4NCj4gVGhpcyBzY2hlbWUgbWFrZXMgdGhlIGFjY2Vz cyBuZXR3b3JrIGFuZCBtb2JpbGUgbmV0d29yayBiZWNvbWUgYSBtdWx0aS1saW5rIHN1Ym5ldCwg DQo+IGFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNpdGluZyBtb2JpbGUgbm9kZXMgd2l0aGluIHRo ZSBtb2JpbGUgbmV0d29yaw0KPiB0byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRlIGZvciByb3V0ZSBv cHRpbWl6YXRpb24uDQo+ICANCj4gVGhvdWdoIFJPIGlzIG5vdCB0aGUgY3VycmVudCBpc3N1ZSBp biBuZW1vIHdnLCBJIHRoaW5rLCB0aGUgcmVzZWFyY2ggZm9yIFJPIGlzIGltcG9ydGFudCBpbiBu ZW1vLiANCj4gVGhyb3VnaCBvbi1saW5lIGRpc2N1c3Npb24gYWJvdXQgUk8sIGl0IG1heSBiZSBn b29kIGZvciB1cyB0byBwcmVwYXJlIFJPIGlzc3VlIA0KPiB0aGF0IGNhbiBiZSBkaXNjdXNzZWQg aW4gZWFybmVzdCBuZXh0IHllYXIuIA0KPiBTbywgSSdkIGxpa2UgdG8gcmVxdWVzdCB5b3VyIGNv bW1lbnRzIG9uIG15IGRyYWZ0LiANCj4gVGhhbmtzLiANCj4gIA0KPiBSZWdhcmRzLCANCj4gSmFl aG9vbiA= ------=_NextPart_000_00FF_01C3341F.1FECF7C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVU QSBjb250ZW50PVdvcmQuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPE1FVEEgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTAiIG5hbWU9T3JpZ2luYXRvcj48TElOSyANCmhyZWY9ImNpZDpmaWxlbGlzdC54 bWxAMDFDMzMzRjAuMzJCRUFCNzAiIHJlbD1GaWxlLUxpc3Q+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25DU1MvPg0K IDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0YXRlPkNs ZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFtbWFy U3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4N CiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6VXNlRkVMYXlv dXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdElu dGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94 bWw+PCFbZW5kaWZdLS0+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEJhdGFu ZzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBHdWxpbTsNCn0NCkBmb250LWZhY2Ug ew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTog R3VsaW07DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQmF0YW5nOw0KfQ0KQHBhZ2Ug U2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA5OS4yNXB0IDMuMGNtIDMu MGNtIDMuMGNtOyBtc28taGVhZGVyLW1hcmdpbjogNDIuNTVwdDsgbXNvLWZvb3Rlci1tYXJnaW46 IDQ5LjZwdDsgbXNvLXBhcGVyLXNvdXJjZTogMDsgfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1z byAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8gDQogdGFibGUuTXNvTm9y bWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlxENDVDXEM5MDAgXEQ0NUMiOw0KCW1zby10c3R5 bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5 bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDow Y20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBhcmEtbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1LTyB2TGluaz1ibHVlIGxpbms9Ymx1ZSBiZ0Nv bG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj4NCjxESVY+SGksIEpvbmcgS2V1bi48QlI+PC9ESVY+ DQo8RElWPmlubGluZXM6LSk8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3qtbTrprwgc2l6ZT0yPjwv Rk9OVD48Rk9OVCBmYWNlPeq1tOumvCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U96rW066a8IA0K c2l6ZT0yPjwvRk9OVD48QlI+Jmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDxCUj4m Z3Q7IEZyb206IE5hLCBKb25nIEtldW4gDQo8QlI+Jmd0OyBUbzogJ0phZWhvb24gSmVvbmcnIDsg bmVtb0BuYWwubW90bGFicy5jb20gPEJSPiZndDsgU2VudDogTW9uZGF5LCBKdW5lIA0KMTYsIDIw MDMgMTA6MTUgQU08QlI+Jmd0OyBTdWJqZWN0OiBSRTogW25lbW9dIFJlcXVlc3QgZm9yIHlvdXIg Y29tbWVudHMgb24gYSBuZXcgDQpSTyBkcmFmdDxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBIaSBK YWVob29uLDxCUj4mZ3Q7Jm5ic3A7PEJSPiZndDsgSSBoYXZlIGEgDQpjb25jZXJuIGluIHlvdXIg ZHJhZnQuPEJSPiZndDsgSXMgaXQgcmlnaHQgZGlyZWN0aW9uIHRvIGdpdmUgdGhlIGJ1cmRlbiBv ZiANCm1vYmlsaXR5IG1hbmFnZW1lbnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPzxCUj48QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZvciBSb3V0ZSANCk9wdGltaXphdGlvbiAoUk8pLCBJIHRoaW5rLCBl YWNoIE1OTiAoVk1OIG9yIExNTikgc2hvdWxkIHBlcmZvcm0gPC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3RoZSBtb2JpbGl0eSBtYW5hZ2VtZW50IHJlbGF0ZWQgdG8gDQpSTy48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVjYXVzZSBSTyB1c2VzIHRoZSBhY2Nlc3MgbmV0 d29yayBkaXJlY3RseSwgZWFjaCANCm1vYmlsZSBub2RlIGlzIGVmZmljaWVudCB0byBwZXJmb3Jt IGl0cyBSTzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhlIHNhbWUmbmJzcDtt YW5uZXIgYXMgTUlQdjYuIDxCUj48L0RJVj4NCjxESVY+Jmd0OyA8QlI+Jmd0OyBUbyB0aGUgYmVz dCBvZiBteSBrbm93bGVkZ2UsIEluIE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCANCmZv ciBNUiB0byBtYW5hZ2UgdGhlIG1vYmlsaXR5IG9mIDxCUj4mZ3Q7IG1vYmlsZSBuZXR3b3JrIHRy YW5zcGFyZW50bHkgdG8gbm9kZXMgDQpiZWhpbmQgaXQuPEJSPiZndDsmbmJzcDs8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9ubHkgd2hlbiBSTyBpcyBleGNsdWRlZCBpbiBORU5PIA0Kb3BlcmF0aW9u LCBpdCBpcyByaWdodC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIGxvY2FsIGZpeGVk IG5vZGUgKExGTiksIA0KdGhlIG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQu PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgc2NvcGUgb2YgUk8gb2YgbXkgZHJh ZnQgaXMgZm9yIG1vYmlsZSBub2RlcywgZWl0aGVyIA0KbG9jYWwgbW9iaWxlIG5vZGUgKExNTikm bmJzcDtvciZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgdmlzaXRpbmcgbW9i aWxlJm5ic3A7bm9kZSAoVk1OKS4mbmJzcDsmbmJzcDs8QlI+PC9ESVY+DQo8RElWPiZndDsgPEJS PiZndDsgSWYgbm9kZXMgYmVoaW5kIE1SIGdldCBuZXcgQ29BIG9mIHRoZSBhY2Nlc3MgbGluayB2 aWEgDQpQcm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyA8L0RJVj4NCjxESVY+Jmd0OyB0aGUg cG9pbnQgb2YgYXR0YWNobWVudCwgYWxsIG9mIG5vZGVzIGhhdmUgdG8gZGlyZWN0bHkgcHJvY2Vz cyBlYWNoIA0KdGhlaXIgaGFuZG92ZXIoTDMgYWRkcmVzcyBjaGFuZ2VkKS48QlI+PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDtBbGwgbW9iaWxlIA0Kbm9kZXMgbmVlZCBub3QgcGFydGljaXBh dGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBkcmFmdC4gDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEhvdyBhYm91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5lZWQgUk8gcGVyZm9y bWluZyANCnRoZSBSTz8gPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSTyBjYW4gYmUgcGVy Zm9ybWVkIG9ubHkgYnkgbW9iaWxlIG5vZGVzIA0KdGhhdCBjYW4gdW5kZXJzdGFuZCB0aGUgZXh0 ZW5kZWQgcHJlZml4IGluZm9ybWF0aW9uIG9wdGlvbjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7b2YgUkEgbWVzc2FnZSwgaW5jbHVkaW5nIHRoZSBwcmVmaXggb2YgYSBuZXcg DQphY2Nlc3MgbmV0d29yay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlYXNv bmFibGUsIEkgDQp0aGluay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGNvbmNsdXNp b24sIGZvciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyANCnJlYXNvbmFibGUgdG8gcGVyZm9ybSBp dHMgcmV0dXJuIHJvdXRhYmlsaXR5IGFuZCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K YmluZGluZyB1cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi48QlI+PC9ESVY+DQo8RElWPiZndDsg PEJSPiZndDsgSG93IGRvIHlvdSB0aGluayBvZiBteSBwb2ludD88QlI+Jmd0OyBJZiBzb21ldGhp bmcgbWlzc2VkLCANCnBsZWFzZSBjb3JyZWN0IG1lLiBUaGFua3MuPEJSPiZndDsmbmJzcDsmbmJz cDs8QlI+Jmd0OyAvSm9uZzxCUj48QlI+Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7VGhhbmtzIGZvciB5 b3VyIGludGVyZXN0LjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyAvSmFlaG9vbjxCUj48QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxCUj4mZ3Q7IA0KRnJvbTogbmVtby1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOm5lbW8tYWRtaW5A aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWVob29uIA0KSmVvbmc8QlI+Jmd0OyBTZW50OiBTdW5k YXksIEp1bmUgMTUsIDIwMDMgMTI6MjUgUE08QlI+Jmd0OyBUbzogDQpuZW1vQG5hbC5tb3RsYWJz LmNvbTxCUj4mZ3Q7IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9u IGEgbmV3IA0KUk8gZHJhZnQ8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IEhlbGxvLCBuZW1v IGd1eXMhIA0KPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBJIHN1Ym1pdHRlZCBhIG5ldyBk cmFmdCBhYm91dCB0aGUgUm91dGUgDQpPcHRpbWl6YXRpb24gKFJPKSBmb3IgbW9iaWxlIG5vZGVz IGluIG1vYmlsZSBuZXR3b3JrLiANCjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsmbmJzcDsm bmJzcDtUaXRsZSA6IE5ELVByb3h5IGJhc2VkIFJvdXRlIA0KT3B0aW1pemF0aW9uIGZvciBNb2Jp bGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsgPEJSPiZndDsmbmJzcDsmbmJzcDtVUkwgZm9yIHRo ZSANCkRyYWZ0IDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVv bmctbmVtby1yby1uZHByb3h5LTAwLnR4dCANCjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsg SXQgaXMgYmFzZWQgb24gTkQtUHJveHkgZm9yIHN1cHBvcnRpbmcgbXVsdGktbGluayANCnN1Ym5l dC48QlI+Jmd0OyBXaGVuZXZlciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFj Y2VzcyBuZXR3b3JrLCANCjxCUj4mZ3Q7IGl0IHByb3ZpZGVzIGl0cyBtb2JpbGUgbmV0d29yayBu b2RlcyB3aXRoIHRoZSBuZXR3b3JrIHByZWZpeCBvZiB0aGUgDQphY2Nlc3MgbmV0d29yay48QlI+ Jmd0OyBUaGlzIHNjaGVtZSBtYWtlcyB0aGUgYWNjZXNzIG5ldHdvcmsgYW5kIG1vYmlsZSBuZXR3 b3JrIA0KYmVjb21lIGEgbXVsdGktbGluayBzdWJuZXQsIDxCUj4mZ3Q7IGFsbG93aW5nIHRoZSBs b2NhbCBvciB2aXNpdGluZyBtb2JpbGUgbm9kZXMgDQp3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3Jr PEJSPiZndDsgdG8gcGVyZm9ybSBiaW5kaW5nIHVwZGF0ZSBmb3Igcm91dGUgDQpvcHRpbWl6YXRp b24uPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBUaG91Z2ggUk8gaXMgbm90IHRoZSBjdXJy ZW50IGlzc3VlIGluIA0KbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBp bXBvcnRhbnQgaW4gbmVtby4gPEJSPiZndDsgVGhyb3VnaCANCm9uLWxpbmUgZGlzY3Vzc2lvbiBh Ym91dCBSTywgaXQgbWF5IGJlIGdvb2QgZm9yIHVzIHRvIHByZXBhcmUgUk8gaXNzdWUgPEJSPiZn dDsgDQp0aGF0IGNhbiBiZSBkaXNjdXNzZWQgaW4gZWFybmVzdCBuZXh0IHllYXIuIDxCUj4mZ3Q7 IFNvLCBJJ2QgbGlrZSB0byByZXF1ZXN0IA0KeW91ciBjb21tZW50cyBvbiBteSBkcmFmdC4gPEJS PiZndDsgVGhhbmtzLiA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IA0KUmVnYXJkcywgPEJS PiZndDsgSmFlaG9vbiA8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00FF_01C3341F.1FECF7C0-- From mailnull@www1.ietf.org Mon Jun 16 09:38:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13663 for ; Mon, 16 Jun 2003 09:38:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GDbZl03679 for nemo-archive@odin.ietf.org; Mon, 16 Jun 2003 09:37:35 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDbYm03676 for ; Mon, 16 Jun 2003 09:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13635 for ; Mon, 16 Jun 2003 09:37:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ru8j-0002j1-00 for nemo-web-archive@ietf.org; Mon, 16 Jun 2003 09:35:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ru8j-0002iy-00 for nemo-web-archive@ietf.org; Mon, 16 Jun 2003 09:35:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G6s2a08248; Mon, 16 Jun 2003 02:54:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G6r7m08212 for ; Mon, 16 Jun 2003 02:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03806 for ; Mon, 16 Jun 2003 02:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RnpK-0000I6-00 for nemo@ietf.org; Mon, 16 Jun 2003 02:50:50 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19RnpI-0000Hk-00 for nemo@ietf.org; Mon, 16 Jun 2003 02:50:48 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5G6qjTN013741 for ; Mon, 16 Jun 2003 08:52:49 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5G75H707514; Mon, 16 Jun 2003 16:05:17 +0900 (KST) Message-ID: <010401c333d3$b6656440$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Na, Jong Keun" Cc: "NEMO WG" , =?utf-8?B?67CV7KCV7IiY?= , =?utf-8?B?6rmA7ZiV7KSA?= , =?utf-8?B?7J206rK97KeE?= , =?utf-8?B?6rmA67OR7Je9?= , =?utf-8?B?7LCo7ZiE7Jqx?= , =?utf-8?B?7KCV7J6s7ZuI?= References: <01e201c333a4$c58f1e90$dbf02e93@jongkn02> Subject: Re: [nemo] Request for your comments on a new RO draft Date: Mon, 16 Jun 2003 15:51:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01C3341F.1FECF7C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00FF_01C3341F.1FECF7C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEpvbmcgS2V1bi4NCg0KaW5saW5lczotKQ0KDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQo+IEZyb206IE5hLCBKb25nIEtldW4gDQo+IFRvOiAnSmFlaG9vbiBKZW9uZycgOyBu ZW1vQG5hbC5tb3RsYWJzLmNvbSANCj4gU2VudDogTW9uZGF5LCBKdW5lIDE2LCAyMDAzIDEwOjE1 IEFNDQo+IFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciBjb21tZW50cyBvbiBh IG5ldyBSTyBkcmFmdA0KPg0KPg0KPiBIaSBKYWVob29uLA0KPiANCj4gSSBoYXZlIGEgY29uY2Vy biBpbiB5b3VyIGRyYWZ0Lg0KPiBJcyBpdCByaWdodCBkaXJlY3Rpb24gdG8gZ2l2ZSB0aGUgYnVy ZGVuIG9mIG1vYmlsaXR5IG1hbmFnZW1lbnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPw0KDQogICAg Rm9yIFJvdXRlIE9wdGltaXphdGlvbiAoUk8pLCBJIHRoaW5rLCBlYWNoIE1OTiAoVk1OIG9yIExN Tikgc2hvdWxkIHBlcmZvcm0gDQogICAgdGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgcmVsYXRlZCB0 byBSTy4NCiAgICBCZWNhdXNlIFJPIHVzZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGRpcmVjdGx5LCBl YWNoIG1vYmlsZSBub2RlIGlzIGVmZmljaWVudCB0byBwZXJmb3JtIGl0cyBSTw0KICAgIGluIHRo ZSBzYW1lIG1hbm5lciBhcyBNSVB2Ni4gDQoNCj4gDQo+IFRvIHRoZSBiZXN0IG9mIG15IGtub3ds ZWRnZSwgSW4gTkVNTywgaXTigJlzIGEgYmFzaWMgcHJpbmNpcGFsIGZvciBNUiB0byBtYW5hZ2Ug dGhlIG1vYmlsaXR5IG9mIA0KPiBtb2JpbGUgbmV0d29yayB0cmFuc3BhcmVudGx5IHRvIG5vZGVz IGJlaGluZCBpdC4NCj4gDQogICAgT25seSB3aGVuIFJPIGlzIGV4Y2x1ZGVkIGluIE5FTk8gb3Bl cmF0aW9uLCBpdCBpcyByaWdodC4NCiAgICBGb3IgbG9jYWwgZml4ZWQgbm9kZSAoTEZOKSwgdGhl IG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQuDQogICAgVGhlIHNjb3BlIG9m IFJPIG9mIG15IGRyYWZ0IGlzIGZvciBtb2JpbGUgbm9kZXMsIGVpdGhlciBsb2NhbCBtb2JpbGUg bm9kZSAoTE1OKSBvciANCiAgICB2aXNpdGluZyBtb2JpbGUgbm9kZSAoVk1OKS4gIA0KDQo+IA0K PiBJZiBub2RlcyBiZWhpbmQgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2VzcyBsaW5rIHZpYSBQ cm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyANCj4gdGhlIHBvaW50IG9mIGF0dGFjaG1lbnQs IGFsbCBvZiBub2RlcyBoYXZlIHRvIGRpcmVjdGx5IHByb2Nlc3MgZWFjaCB0aGVpciBoYW5kb3Zl cihMMyBhZGRyZXNzIGNoYW5nZWQpLg0KDQogICAgIEFsbCBtb2JpbGUgbm9kZXMgbmVlZCBub3Qg cGFydGljaXBhdGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBkcmFmdC4gDQogICAgIEhvdyBh Ym91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5lZWQgUk8gcGVyZm9ybWluZyB0aGUgUk8/IA0K ICAgICBSTyBjYW4gYmUgcGVyZm9ybWVkIG9ubHkgYnkgbW9iaWxlIG5vZGVzIHRoYXQgY2FuIHVu ZGVyc3RhbmQgdGhlIGV4dGVuZGVkIHByZWZpeCBpbmZvcm1hdGlvbiBvcHRpb24NCiAgICAgb2Yg UkEgbWVzc2FnZSwgaW5jbHVkaW5nIHRoZSBwcmVmaXggb2YgYSBuZXcgYWNjZXNzIG5ldHdvcmsu DQogICAgIEl0IGlzIHJlYXNvbmFibGUsIEkgdGhpbmsuDQogICAgIEluIGNvbmNsdXNpb24sIGZv ciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyByZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVy biByb3V0YWJpbGl0eSBhbmQgDQogICAgIGJpbmRpbmcgdXBkYXRlIHByb2NlZHVyZSBieSBpdHNl bGYuDQoNCj4gDQo+IEhvdyBkbyB5b3UgdGhpbmsgb2YgbXkgcG9pbnQ/DQo+IElmIHNvbWV0aGlu ZyBtaXNzZWQsIHBsZWFzZSBjb3JyZWN0IG1lLiBUaGFua3MuDQo+ICANCj4gL0pvbmcNCg0KICAg IFRoYW5rcyBmb3IgeW91ciBpbnRlcmVzdC4NCiAgICANCiAgICAvSmFlaG9vbg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5lbW8tYWRtaW5AaWV0Zi5vcmcgW21haWx0 bzpuZW1vLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFlaG9vbiBKZW9uZw0KPiBTZW50 OiBTdW5kYXksIEp1bmUgMTUsIDIwMDMgMTI6MjUgUE0NCj4gVG86IG5lbW9AbmFsLm1vdGxhYnMu Y29tDQo+IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEgbmV3 IFJPIGRyYWZ0DQo+ICANCj4gSGVsbG8sIG5lbW8gZ3V5cyEgDQo+ICANCj4gSSBzdWJtaXR0ZWQg YSBuZXcgZHJhZnQgYWJvdXQgdGhlIFJvdXRlIE9wdGltaXphdGlvbiAoUk8pIGZvciBtb2JpbGUg bm9kZXMgaW4gbW9iaWxlIG5ldHdvcmsuIA0KPiAgDQo+ICBUaXRsZSA6IE5ELVByb3h5IGJhc2Vk IFJvdXRlIE9wdGltaXphdGlvbiBmb3IgTW9iaWxlIE5vZGVzIGluIE1vYmlsZSBOZXR3b3JrIA0K PiAgVVJMIGZvciB0aGUgRHJhZnQgOiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDAudHh0IA0KPiAgDQo+IEl0IGlzIGJhc2Vk IG9uIE5ELVByb3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxpbmsgc3VibmV0Lg0KPiBXaGVuZXZl ciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFjY2VzcyBuZXR3b3JrLCANCj4g aXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdpdGggdGhlIG5ldHdvcmsgcHJl Zml4IG9mIHRoZSBhY2Nlc3MgbmV0d29yay4NCj4gVGhpcyBzY2hlbWUgbWFrZXMgdGhlIGFjY2Vz cyBuZXR3b3JrIGFuZCBtb2JpbGUgbmV0d29yayBiZWNvbWUgYSBtdWx0aS1saW5rIHN1Ym5ldCwg DQo+IGFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNpdGluZyBtb2JpbGUgbm9kZXMgd2l0aGluIHRo ZSBtb2JpbGUgbmV0d29yaw0KPiB0byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRlIGZvciByb3V0ZSBv cHRpbWl6YXRpb24uDQo+ICANCj4gVGhvdWdoIFJPIGlzIG5vdCB0aGUgY3VycmVudCBpc3N1ZSBp biBuZW1vIHdnLCBJIHRoaW5rLCB0aGUgcmVzZWFyY2ggZm9yIFJPIGlzIGltcG9ydGFudCBpbiBu ZW1vLiANCj4gVGhyb3VnaCBvbi1saW5lIGRpc2N1c3Npb24gYWJvdXQgUk8sIGl0IG1heSBiZSBn b29kIGZvciB1cyB0byBwcmVwYXJlIFJPIGlzc3VlIA0KPiB0aGF0IGNhbiBiZSBkaXNjdXNzZWQg aW4gZWFybmVzdCBuZXh0IHllYXIuIA0KPiBTbywgSSdkIGxpa2UgdG8gcmVxdWVzdCB5b3VyIGNv bW1lbnRzIG9uIG15IGRyYWZ0LiANCj4gVGhhbmtzLiANCj4gIA0KPiBSZWdhcmRzLCANCj4gSmFl aG9vbiA= ------=_NextPart_000_00FF_01C3341F.1FECF7C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVU QSBjb250ZW50PVdvcmQuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPE1FVEEgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTAiIG5hbWU9T3JpZ2luYXRvcj48TElOSyANCmhyZWY9ImNpZDpmaWxlbGlzdC54 bWxAMDFDMzMzRjAuMzJCRUFCNzAiIHJlbD1GaWxlLUxpc3Q+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25DU1MvPg0K IDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0YXRlPkNs ZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFtbWFy U3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4N CiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6VXNlRkVMYXlv dXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdElu dGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94 bWw+PCFbZW5kaWZdLS0+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEJhdGFu ZzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBHdWxpbTsNCn0NCkBmb250LWZhY2Ug ew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTog R3VsaW07DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQmF0YW5nOw0KfQ0KQHBhZ2Ug U2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA5OS4yNXB0IDMuMGNtIDMu MGNtIDMuMGNtOyBtc28taGVhZGVyLW1hcmdpbjogNDIuNTVwdDsgbXNvLWZvb3Rlci1tYXJnaW46 IDQ5LjZwdDsgbXNvLXBhcGVyLXNvdXJjZTogMDsgfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1z byAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8gDQogdGFibGUuTXNvTm9y bWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlxENDVDXEM5MDAgXEQ0NUMiOw0KCW1zby10c3R5 bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5 bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDow Y20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBhcmEtbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1LTyB2TGluaz1ibHVlIGxpbms9Ymx1ZSBiZ0Nv bG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj4NCjxESVY+SGksIEpvbmcgS2V1bi48QlI+PC9ESVY+ DQo8RElWPmlubGluZXM6LSk8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3qtbTrprwgc2l6ZT0yPjwv Rk9OVD48Rk9OVCBmYWNlPeq1tOumvCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U96rW066a8IA0K c2l6ZT0yPjwvRk9OVD48QlI+Jmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDxCUj4m Z3Q7IEZyb206IE5hLCBKb25nIEtldW4gDQo8QlI+Jmd0OyBUbzogJ0phZWhvb24gSmVvbmcnIDsg bmVtb0BuYWwubW90bGFicy5jb20gPEJSPiZndDsgU2VudDogTW9uZGF5LCBKdW5lIA0KMTYsIDIw MDMgMTA6MTUgQU08QlI+Jmd0OyBTdWJqZWN0OiBSRTogW25lbW9dIFJlcXVlc3QgZm9yIHlvdXIg Y29tbWVudHMgb24gYSBuZXcgDQpSTyBkcmFmdDxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBIaSBK YWVob29uLDxCUj4mZ3Q7Jm5ic3A7PEJSPiZndDsgSSBoYXZlIGEgDQpjb25jZXJuIGluIHlvdXIg ZHJhZnQuPEJSPiZndDsgSXMgaXQgcmlnaHQgZGlyZWN0aW9uIHRvIGdpdmUgdGhlIGJ1cmRlbiBv ZiANCm1vYmlsaXR5IG1hbmFnZW1lbnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPzxCUj48QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZvciBSb3V0ZSANCk9wdGltaXphdGlvbiAoUk8pLCBJIHRoaW5rLCBl YWNoIE1OTiAoVk1OIG9yIExNTikgc2hvdWxkIHBlcmZvcm0gPC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3RoZSBtb2JpbGl0eSBtYW5hZ2VtZW50IHJlbGF0ZWQgdG8gDQpSTy48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVjYXVzZSBSTyB1c2VzIHRoZSBhY2Nlc3MgbmV0 d29yayBkaXJlY3RseSwgZWFjaCANCm1vYmlsZSBub2RlIGlzIGVmZmljaWVudCB0byBwZXJmb3Jt IGl0cyBSTzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhlIHNhbWUmbmJzcDtt YW5uZXIgYXMgTUlQdjYuIDxCUj48L0RJVj4NCjxESVY+Jmd0OyA8QlI+Jmd0OyBUbyB0aGUgYmVz dCBvZiBteSBrbm93bGVkZ2UsIEluIE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCANCmZv ciBNUiB0byBtYW5hZ2UgdGhlIG1vYmlsaXR5IG9mIDxCUj4mZ3Q7IG1vYmlsZSBuZXR3b3JrIHRy YW5zcGFyZW50bHkgdG8gbm9kZXMgDQpiZWhpbmQgaXQuPEJSPiZndDsmbmJzcDs8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9ubHkgd2hlbiBSTyBpcyBleGNsdWRlZCBpbiBORU5PIA0Kb3BlcmF0aW9u LCBpdCBpcyByaWdodC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIGxvY2FsIGZpeGVk IG5vZGUgKExGTiksIA0KdGhlIG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQu PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgc2NvcGUgb2YgUk8gb2YgbXkgZHJh ZnQgaXMgZm9yIG1vYmlsZSBub2RlcywgZWl0aGVyIA0KbG9jYWwgbW9iaWxlIG5vZGUgKExNTikm bmJzcDtvciZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgdmlzaXRpbmcgbW9i aWxlJm5ic3A7bm9kZSAoVk1OKS4mbmJzcDsmbmJzcDs8QlI+PC9ESVY+DQo8RElWPiZndDsgPEJS PiZndDsgSWYgbm9kZXMgYmVoaW5kIE1SIGdldCBuZXcgQ29BIG9mIHRoZSBhY2Nlc3MgbGluayB2 aWEgDQpQcm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyA8L0RJVj4NCjxESVY+Jmd0OyB0aGUg cG9pbnQgb2YgYXR0YWNobWVudCwgYWxsIG9mIG5vZGVzIGhhdmUgdG8gZGlyZWN0bHkgcHJvY2Vz cyBlYWNoIA0KdGhlaXIgaGFuZG92ZXIoTDMgYWRkcmVzcyBjaGFuZ2VkKS48QlI+PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDtBbGwgbW9iaWxlIA0Kbm9kZXMgbmVlZCBub3QgcGFydGljaXBh dGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBkcmFmdC4gDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEhvdyBhYm91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5lZWQgUk8gcGVyZm9y bWluZyANCnRoZSBSTz8gPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSTyBjYW4gYmUgcGVy Zm9ybWVkIG9ubHkgYnkgbW9iaWxlIG5vZGVzIA0KdGhhdCBjYW4gdW5kZXJzdGFuZCB0aGUgZXh0 ZW5kZWQgcHJlZml4IGluZm9ybWF0aW9uIG9wdGlvbjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7b2YgUkEgbWVzc2FnZSwgaW5jbHVkaW5nIHRoZSBwcmVmaXggb2YgYSBuZXcg DQphY2Nlc3MgbmV0d29yay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlYXNv bmFibGUsIEkgDQp0aGluay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGNvbmNsdXNp b24sIGZvciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyANCnJlYXNvbmFibGUgdG8gcGVyZm9ybSBp dHMgcmV0dXJuIHJvdXRhYmlsaXR5IGFuZCA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K YmluZGluZyB1cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi48QlI+PC9ESVY+DQo8RElWPiZndDsg PEJSPiZndDsgSG93IGRvIHlvdSB0aGluayBvZiBteSBwb2ludD88QlI+Jmd0OyBJZiBzb21ldGhp bmcgbWlzc2VkLCANCnBsZWFzZSBjb3JyZWN0IG1lLiBUaGFua3MuPEJSPiZndDsmbmJzcDsmbmJz cDs8QlI+Jmd0OyAvSm9uZzxCUj48QlI+Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7VGhhbmtzIGZvciB5 b3VyIGludGVyZXN0LjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwOyAvSmFlaG9vbjxCUj48QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxCUj4mZ3Q7IA0KRnJvbTogbmVtby1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOm5lbW8tYWRtaW5A aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWVob29uIA0KSmVvbmc8QlI+Jmd0OyBTZW50OiBTdW5k YXksIEp1bmUgMTUsIDIwMDMgMTI6MjUgUE08QlI+Jmd0OyBUbzogDQpuZW1vQG5hbC5tb3RsYWJz LmNvbTxCUj4mZ3Q7IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9u IGEgbmV3IA0KUk8gZHJhZnQ8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IEhlbGxvLCBuZW1v IGd1eXMhIA0KPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBJIHN1Ym1pdHRlZCBhIG5ldyBk cmFmdCBhYm91dCB0aGUgUm91dGUgDQpPcHRpbWl6YXRpb24gKFJPKSBmb3IgbW9iaWxlIG5vZGVz IGluIG1vYmlsZSBuZXR3b3JrLiANCjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsmbmJzcDsm bmJzcDtUaXRsZSA6IE5ELVByb3h5IGJhc2VkIFJvdXRlIA0KT3B0aW1pemF0aW9uIGZvciBNb2Jp bGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsgPEJSPiZndDsmbmJzcDsmbmJzcDtVUkwgZm9yIHRo ZSANCkRyYWZ0IDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVv bmctbmVtby1yby1uZHByb3h5LTAwLnR4dCANCjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsg SXQgaXMgYmFzZWQgb24gTkQtUHJveHkgZm9yIHN1cHBvcnRpbmcgbXVsdGktbGluayANCnN1Ym5l dC48QlI+Jmd0OyBXaGVuZXZlciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFj Y2VzcyBuZXR3b3JrLCANCjxCUj4mZ3Q7IGl0IHByb3ZpZGVzIGl0cyBtb2JpbGUgbmV0d29yayBu b2RlcyB3aXRoIHRoZSBuZXR3b3JrIHByZWZpeCBvZiB0aGUgDQphY2Nlc3MgbmV0d29yay48QlI+ Jmd0OyBUaGlzIHNjaGVtZSBtYWtlcyB0aGUgYWNjZXNzIG5ldHdvcmsgYW5kIG1vYmlsZSBuZXR3 b3JrIA0KYmVjb21lIGEgbXVsdGktbGluayBzdWJuZXQsIDxCUj4mZ3Q7IGFsbG93aW5nIHRoZSBs b2NhbCBvciB2aXNpdGluZyBtb2JpbGUgbm9kZXMgDQp3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3Jr PEJSPiZndDsgdG8gcGVyZm9ybSBiaW5kaW5nIHVwZGF0ZSBmb3Igcm91dGUgDQpvcHRpbWl6YXRp b24uPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBUaG91Z2ggUk8gaXMgbm90IHRoZSBjdXJy ZW50IGlzc3VlIGluIA0KbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBp bXBvcnRhbnQgaW4gbmVtby4gPEJSPiZndDsgVGhyb3VnaCANCm9uLWxpbmUgZGlzY3Vzc2lvbiBh Ym91dCBSTywgaXQgbWF5IGJlIGdvb2QgZm9yIHVzIHRvIHByZXBhcmUgUk8gaXNzdWUgPEJSPiZn dDsgDQp0aGF0IGNhbiBiZSBkaXNjdXNzZWQgaW4gZWFybmVzdCBuZXh0IHllYXIuIDxCUj4mZ3Q7 IFNvLCBJJ2QgbGlrZSB0byByZXF1ZXN0IA0KeW91ciBjb21tZW50cyBvbiBteSBkcmFmdC4gPEJS PiZndDsgVGhhbmtzLiA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IA0KUmVnYXJkcywgPEJS PiZndDsgSmFlaG9vbiA8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00FF_01C3341F.1FECF7C0-- From nemo-admin@ietf.org Tue Jun 17 09:26:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14392 for ; Tue, 17 Jun 2003 09:26:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HAZ2a14994; Tue, 17 Jun 2003 06:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HAYBm14950 for ; Tue, 17 Jun 2003 06:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06081 for ; Tue, 17 Jun 2003 06:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SDkm-0004hX-00 for nemo@ietf.org; Tue, 17 Jun 2003 06:31:52 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19SDkl-0004hU-00 for nemo@ietf.org; Tue, 17 Jun 2003 06:31:51 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5HAY67M020571 for ; Tue, 17 Jun 2003 03:34:07 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5HAY3cC016247 for ; Tue, 17 Jun 2003 05:34:05 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id ED70E2EC8B for ; Tue, 17 Jun 2003 12:34:01 +0200 (CEST) Message-ID: <3EEEEE99.2030404@nal.motlabs.com> Date: Tue, 17 Jun 2003 12:34:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Admin note: NEMO Additional Web Page down for one day Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Sorry for the inconvenience, but there is an urgent need to temporarily turn down the http daemon of the NEMO Additional Web Page at www.nal.motlabs.com. Will be back up tomorrow afternoon, thanks for your understanding. This has no implications on the NEMO mailing list (which continues to work fine at ietf.org). Alex GBU From mailnull@www1.ietf.org Tue Jun 17 09:27:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14427 for ; Tue, 17 Jun 2003 09:27:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HDR8p27962 for nemo-archive@odin.ietf.org; Tue, 17 Jun 2003 09:27:08 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDR7m27959 for ; Tue, 17 Jun 2003 09:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14417 for ; Tue, 17 Jun 2003 09:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGS9-0006ou-00 for nemo-web-archive@ietf.org; Tue, 17 Jun 2003 09:24:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SGS8-0006oq-00 for nemo-web-archive@ietf.org; Tue, 17 Jun 2003 09:24:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HAZ2a14994; Tue, 17 Jun 2003 06:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HAYBm14950 for ; Tue, 17 Jun 2003 06:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06081 for ; Tue, 17 Jun 2003 06:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SDkm-0004hX-00 for nemo@ietf.org; Tue, 17 Jun 2003 06:31:52 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19SDkl-0004hU-00 for nemo@ietf.org; Tue, 17 Jun 2003 06:31:51 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5HAY67M020571 for ; Tue, 17 Jun 2003 03:34:07 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5HAY3cC016247 for ; Tue, 17 Jun 2003 05:34:05 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id ED70E2EC8B for ; Tue, 17 Jun 2003 12:34:01 +0200 (CEST) Message-ID: <3EEEEE99.2030404@nal.motlabs.com> Date: Tue, 17 Jun 2003 12:34:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Admin note: NEMO Additional Web Page down for one day Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Sorry for the inconvenience, but there is an urgent need to temporarily turn down the http daemon of the NEMO Additional Web Page at www.nal.motlabs.com. Will be back up tomorrow afternoon, thanks for your understanding. This has no implications on the NEMO mailing list (which continues to work fine at ietf.org). Alex GBU From nemo-admin@ietf.org Wed Jun 18 04:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23782 for ; Wed, 18 Jun 2003 04:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYLN-000603-Km; Wed, 18 Jun 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYKU-0005zT-Qo for nemo@optimus.ietf.org; Wed, 18 Jun 2003 04:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23746 for ; Wed, 18 Jun 2003 04:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYIF-0001IU-00 for nemo@ietf.org; Wed, 18 Jun 2003 04:27:47 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19SYID-0001IR-00 for nemo@ietf.org; Wed, 18 Jun 2003 04:27:46 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 64F7A5B15B; Wed, 18 Jun 2003 16:34:17 +0800 (HKT) From: Wanrong Yu To: paul@etri.re.kr Reply-To: Wanrong Yu Cc: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030618083417.64F7A5B15B@ds20.nudt.edu.cn> Date: Wed, 18 Jun 2003 16:34:17 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?cmU6W25lbW9dIFJlcXVlc3QgZm9yIHlvdXIgY29tbWVudHMgb24gYSBuZXcgUk8gZHJhZnQ=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jaehoon, I have read your draft. If the mobile node in the NEMO form a new CoA with the network prefix of access network,the packet send by the mobile nodes will use the new CoA as the source address,my question is how could the packet by pass the ingress filtering of MR? So the mechanism of MR's ingress filtering needs some adaption. Also, if the NEMO is multihomed and has different ARs with different network prefixs(AR_Ps), does there anything new to be considered? If something wrong, please correct me. Thanks. Wanrong Yu From exim@www1.ietf.org Wed Jun 18 04:31:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23797 for ; Wed, 18 Jun 2003 04:31:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8V6f23116 for nemo-archive@odin.ietf.org; Wed, 18 Jun 2003 04:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYLS-00060l-03 for nemo-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 04:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23771 for ; Wed, 18 Jun 2003 04:31:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYJC-0001It-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 04:28:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SYJB-0001Iq-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 04:28:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYLN-000603-Km; Wed, 18 Jun 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYKU-0005zT-Qo for nemo@optimus.ietf.org; Wed, 18 Jun 2003 04:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23746 for ; Wed, 18 Jun 2003 04:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYIF-0001IU-00 for nemo@ietf.org; Wed, 18 Jun 2003 04:27:47 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19SYID-0001IR-00 for nemo@ietf.org; Wed, 18 Jun 2003 04:27:46 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 64F7A5B15B; Wed, 18 Jun 2003 16:34:17 +0800 (HKT) From: Wanrong Yu To: paul@etri.re.kr Reply-To: Wanrong Yu Cc: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030618083417.64F7A5B15B@ds20.nudt.edu.cn> Date: Wed, 18 Jun 2003 16:34:17 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?cmU6W25lbW9dIFJlcXVlc3QgZm9yIHlvdXIgY29tbWVudHMgb24gYSBuZXcgUk8gZHJhZnQ=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jaehoon, I have read your draft. If the mobile node in the NEMO form a new CoA with the network prefix of access network,the packet send by the mobile nodes will use the new CoA as the source address,my question is how could the packet by pass the ingress filtering of MR? So the mechanism of MR's ingress filtering needs some adaption. Also, if the NEMO is multihomed and has different ARs with different network prefixs(AR_Ps), does there anything new to be considered? If something wrong, please correct me. Thanks. Wanrong Yu From nemo-admin@ietf.org Wed Jun 18 10:49:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10655 for ; Wed, 18 Jun 2003 10:49:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeU-00036k-H6; Wed, 18 Jun 2003 10:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdMy-0001nF-Pu for nemo@optimus.ietf.org; Wed, 18 Jun 2003 09:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07046 for ; Wed, 18 Jun 2003 09:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdKh-0004qp-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:50:39 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19SdKc-0004qm-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:50:39 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5IDqndJ001465 for ; Wed, 18 Jun 2003 15:52:50 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5IE5Z705281; Wed, 18 Jun 2003 23:05:35 +0900 (KST) Message-ID: <001601c335a0$badf1f10$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Wanrong Yu" Cc: "NEMO WG" , "autonet" References: <20030618083417.64F7A5B15B@ds20.nudt.edu.cn> Subject: Re: re:[nemo] Request for your comments on a new RO draft Date: Wed, 18 Jun 2003 22:51:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA10655 ----- Original Message ----- From: "Wanrong Yu" To: Cc: Sent: Wednesday, June 18, 2003 5:34 PM Subject: re:[nemo] Request for your comments on a new RO draft > > Hi Jaehoon, > > I have read your draft. > > If the mobile node in the NEMO form a new CoA with the > network prefix of access network,the packet send by the > mobile nodes will use the new CoA as the source > address,my question is how could the packet by pass the > ingress filtering of MR? So the mechanism of MR's > ingress filtering needs some adaption. > Because my scheme uses multi-link subnet, there happens no ingress filtering. Refer to "Multi-link Subnet Support in IPv6" draft for detailed mechanism. http://www.amaranthnetworks.com/ietf/drafts/draft-ietf-ipv6-multilink-subnets-00.txt > Also, if the NEMO is multihomed and has different ARs > with different network prefixs(AR_Ps), does there > anything new to be considered? I am considering multi-homing now. Maybe, I think, something will be added, such as the selection of Acess Network prefixes. > If something wrong, please correct me. > Thanks. > > Wanrong Yu > Thanks for your suggestion. /Jaehoon From exim@www1.ietf.org Wed Jun 18 11:24:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12437 for ; Wed, 18 Jun 2003 11:24:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IFO7i27111 for nemo-archive@odin.ietf.org; Wed, 18 Jun 2003 11:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeFZ-00058j-Ml for nemo-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:49:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10607 for ; Wed, 18 Jun 2003 10:49:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SeDI-0005Jr-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 10:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SeDH-0005Jn-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 10:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeU-00036k-H6; Wed, 18 Jun 2003 10:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdMy-0001nF-Pu for nemo@optimus.ietf.org; Wed, 18 Jun 2003 09:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07046 for ; Wed, 18 Jun 2003 09:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdKh-0004qp-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:50:39 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19SdKc-0004qm-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:50:39 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5IDqndJ001465 for ; Wed, 18 Jun 2003 15:52:50 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5IE5Z705281; Wed, 18 Jun 2003 23:05:35 +0900 (KST) Message-ID: <001601c335a0$badf1f10$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Wanrong Yu" Cc: "NEMO WG" , "autonet" References: <20030618083417.64F7A5B15B@ds20.nudt.edu.cn> Subject: Re: re:[nemo] Request for your comments on a new RO draft Date: Wed, 18 Jun 2003 22:51:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA12437 ----- Original Message ----- From: "Wanrong Yu" To: Cc: Sent: Wednesday, June 18, 2003 5:34 PM Subject: re:[nemo] Request for your comments on a new RO draft > > Hi Jaehoon, > > I have read your draft. > > If the mobile node in the NEMO form a new CoA with the > network prefix of access network,the packet send by the > mobile nodes will use the new CoA as the source > address,my question is how could the packet by pass the > ingress filtering of MR? So the mechanism of MR's > ingress filtering needs some adaption. > Because my scheme uses multi-link subnet, there happens no ingress filtering. Refer to "Multi-link Subnet Support in IPv6" draft for detailed mechanism. http://www.amaranthnetworks.com/ietf/drafts/draft-ietf-ipv6-multilink-subnets-00.txt > Also, if the NEMO is multihomed and has different ARs > with different network prefixs(AR_Ps), does there > anything new to be considered? I am considering multi-homing now. Maybe, I think, something will be added, such as the selection of Acess Network prefixes. > If something wrong, please correct me. > Thanks. > > Wanrong Yu > Thanks for your suggestion. /Jaehoon From nemo-admin@ietf.org Wed Jun 18 13:22:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17240 for ; Wed, 18 Jun 2003 13:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sg1V-0002PG-HK; Wed, 18 Jun 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdHX-0001Y7-AJ for nemo@optimus.ietf.org; Wed, 18 Jun 2003 09:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06832 for ; Wed, 18 Jun 2003 09:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdFG-0004mg-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:45:02 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19SdF9-0004mZ-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:44:58 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5IDl7dJ001443 for ; Wed, 18 Jun 2003 15:47:08 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5IDxt705249; Wed, 18 Jun 2003 22:59:55 +0900 (KST) Message-ID: <000e01c3359f$f0d1a850$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Na, Jong Keun" Cc: "NEMO WG" , "autonet" References: <02b301c334ba$3d3264a0$dbf02e93@jongkn02> Subject: Re: [nemo] Request for your comments on a new RO draft Date: Wed, 18 Jun 2003 22:45:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C335EB.601BFEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C335EB.601BFEE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lcyA6LSkNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogTmEs IEpvbmcgS2V1biANCiAgVG86ICdKYWVob29uIEplb25nJyANCiAgQ2M6ICdORU1PIFdHJyA7ICfr sJXsoJXsiJgnIDsgJ+q5gO2YleykgCcgOyAn7J206rK97KeEJyA7ICfquYDrs5Hsl70nIDsgJ+yw qO2YhOyasScgDQogIFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTcsIDIwMDMgNzoyMSBQTQ0KICBTdWJq ZWN0OiBSRTogW25lbW9dIFJlcXVlc3QgZm9yIHlvdXIgY29tbWVudHMgb24gYSBuZXcgUk8gZHJh ZnQNCg0KDQogIEhpIEphZWhvb24sIA0KDQogICANCg0KICBUaGFua3MgZm9yIHlvdXIgcXVpY2sg cmVwbHkuDQoNCiAgIA0KDQogIEF0IHRoZXNlIGRheXMsIEnigJltIGNvbnNpZGVyaW5nIGhvdyB0 byBzb2x2ZSB0aGUgbmVzdGVkIHR1bm5lbHMgcHJvYmxlbS4NCg0KICAtPiBJdCBpcyBpbXBvcnRh bnQgdG8gc29sdmUgdGhlIHByb2JsZW0sIEkgYWdyZWUuDQoNCg0KDQogIElNSE8sIHRoaXMgbmVz dGVkIHR1bm5lbHMgb3B0aW1pemF0aW9uIGlzIHZlcnkgaW1wb3J0YW50IGluIHRoZSBhcmVhIG9m IE5FTU8gUk8gcHJvYmxlbS4NCg0KICBJbiB0aGlzIGFzcGVjdCwgSSB0aGluayBpdCBpcyBuZWVk ZWQgdG8gY29uc2lkZXIgdGhpcyBraW5kIG9mIG9wdGltaXphdGlvbiBpbiB5b3VyIGRyYWZ0Lg0K DQogIC0+IEluIHRoaXMgcmVzcGVjdCwgSSBkaXNhZ3JlZS4NCg0KICAgICAgIEJlY2F1c2UgbXkg c2NoZW1lIGlzIGJhc2VkIG9uIG11bHRpLWxpbmsgc3VibmV0LCB0aGVyZSBoYXBwZW5zIG5vIG5l c3RlZCB0dW5uZWwgcHJvYmxlbQ0KDQogICAgICAgZm9yIG1vYmlsZSBub2RlcyB3aXRoaW4gTkVN Ty4NCg0KDQoNCiAgSG93IGFib3V0IE1ScyBkbyBORC1wcm94eSBiYXNlZCBSTyBhYm91dCB0aGVp ciBlZ3Jlc3MgaW50ZXJmYWNlPw0KDQogIC0+IEluIG15IGRyYWZ0LCBsaWtlIHlvdXIgc3VnZ2Vz dGlvbiwgTVJzIHBsYXlzIHRoZSByb2xlIG9mIE5ELXByb3h5IGZvciB0aGVpciBvd24gZWdyZXNz IGludGVyZmFjZSBhbmQNCg0KICAgICAgIHBsYXlzIHRoZSBub3JtYWwgcm91dGVyIGZvciB0aGVp ciBvd24gaW5ncmVzcyBpbnRlcmZhY2UuDQoNCiAgICAgICBSZWZlciB0byAiTXVsdGktbGluayBT dWJuZXQgU3VwcG9ydCBpbiBJUHY2IiBkcmFmdCBmb3IgZGV0YWlsZWQgbWVjaGFuaXNtLg0KDQog ICAgICAgaHR0cDovL3d3dy5hbWFyYW50aG5ldHdvcmtzLmNvbS9pZXRmL2RyYWZ0cy9kcmFmdC1p ZXRmLWlwdjYtbXVsdGlsaW5rLXN1Ym5ldHMtMDAudHh0DQoNCg0KDQogIElmIE1SIGNhbiBkbyB0 aGF0LCB0aGUgbm9kZXMgYmVoaW5kIE1SIHdpbGwgZ2V0IHRoZSBlZmZlY3Qgb2YgbmVzdGVkIHR1 bm5lbHMgb3B0aW1pemF0aW9uLg0KDQogIFRoZXJlIHdpbGwgYmUgbm8gbW9yZSBuZXN0ZWQgdHVu bmVsIGlmIE1ScyB1c2Ugb25lIGFkZHJlc3MgYWxsb2NhdGVkIGluIGFjY2VzcyBsaW5rIHByZWZp eCBhcyB0aGVpciBDb0Egb2YgdGhlIGVncmVzcyBpbnRlcmZhY2UgYW5kIE1ScyBvbiB0aGUgcGF0 aCBvcGVyYXRlIGluIE5ELVByb3h5IG1vZGUuIA0KDQogIC0+IFJpZ2h0LiBCZWNhdXNlIHRoZXJl IGFyZSBubyBuZXN0ZWQgdHVubmVscyBiZXR3ZWVuIHJvb3QtTVIgYW5kIHN1Yi1NUiBvd2luZyB0 byBtdWx0aS1saW5rIHN1Ym5ldCwNCg0KICAgICAgIHRoZSBuZXN0ZWQgdHVubmVscyBvcHRpbWl6 YXRpb24gaXMgbm90IHJlbGF0ZWQgdG8gbXkgc2hlbWUuIFRoZXJlZm9yZSwgbXkgc2NoZW1lIG5l ZWQgbm90IGNvbnNpZGVyDQoNCiAgICAgICB0aGUgbmVzdGVkIHR1bm5lbHMgb3B0aW1pemF0aW9u Lg0KDQoNCg0KICBJIHRoaW5rIGl04oCZcyBwb3NzaWJsZSB0aGlzIGFwcHJvYWNoIGNhbiBiZSBh IGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdGhlIG5lc3RlZCB0dW5uZWxzIG9wdGltaXphdGlvbiBh bHJlYWR5IHRvdWNoZWQgYnkgUlJILWJhc2VkIGFuZCBBUk8tYmFzZWQgcHJvcG9zZWQgc29sdXRp b25zLCBldmVuIHRob3VnaCB0aGVyZSBhcmUgc29tZSBhcmd1bWVudHMgb24gdGhlIGdlbmVyYWwg ZmVhc2liaWxpdHkgb2YgTkQtcHJveHkgYmFzZWQgc29sdXRpb24uDQoNCiAgLT4gSSBhZ3JlZS4g SSBhbSB0aGlua2luZyB0aGUgc2NhbGFiaWxpdHkgb2YgbXkgc2NoZW1lIG5vdy4NCg0KICAgICAg IEkgdGhpbmsgbXkgc2NoZW1lIGlzIHVzZWZ1bCBmb3IgYSBmZXcgbGV2ZWwgTkVNTywgbm90IGRl ZXAgbGV2ZWwgTkVNTy4NCg0KICAgICAgIEZvciBleGFtcGxlLCBpdCB3aWxsIGJlIHVzZWQgZm9y IE5FTU8gd2l0aGluIEludGVybmV0IGNhciBhbmQgYnVzLg0KDQogICAgICAgICAgDQoNCiAgRG8g eW91IHRoaW5rIG9mIHRoaXMgb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlPyBQbGVhc2UgbGV0IG1l IGtub3cgeW91ciBvcGluaW9uLiBUaGFua3MuDQoNCg0KDQogIC9Kb25nDQoNCiAgIA0KDQogIC0+ IFRoYW5rcyBmb3IgeW91ciBnb29kIGNvbW1lbnRzLg0KDQogICAgICANCg0KICAgICAgIC9KYWVo b29uDQoNCg0KDQoNCg0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICBGcm9tOiBuZW1v LWFkbWluQGlldGYub3JnIFttYWlsdG86bmVtby1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEphZWhvb24gSmVvbmcNCiAgU2VudDogTW9uZGF5LCBKdW5lIDE2LCAyMDAzIDM6NTEgUE0NCiAg VG86IE5hLCBKb25nIEtldW4NCiAgQ2M6IE5FTU8gV0c7IOuwleygleyImDsg6rmA7ZiV7KSAOyDs nbTqsr3sp4Q7IOq5gOuzkeyXvTsg7LCo7ZiE7JqxOyDsoJXsnqztm4gNCiAgU3ViamVjdDogUmU6 IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEgbmV3IFJPIGRyYWZ0DQoNCiAg IA0KDQogIEhpLCBKb25nIEtldW4uDQoNCiAgaW5saW5lczotKQ0KDQoNCiAgPiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KICA+IEZyb206IE5hLCBKb25nIEtldW4gDQogID4gVG86ICdK YWVob29uIEplb25nJyA7IG5lbW9AbmFsLm1vdGxhYnMuY29tIA0KICA+IFNlbnQ6IE1vbmRheSwg SnVuZSAxNiwgMjAwMyAxMDoxNSBBTQ0KICA+IFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBm b3IgeW91ciBjb21tZW50cyBvbiBhIG5ldyBSTyBkcmFmdA0KICA+DQogID4NCiAgPiBIaSBKYWVo b29uLA0KICA+IA0KICA+IEkgaGF2ZSBhIGNvbmNlcm4gaW4geW91ciBkcmFmdC4NCiAgPiBJcyBp dCByaWdodCBkaXJlY3Rpb24gdG8gZ2l2ZSB0aGUgYnVyZGVuIG9mIG1vYmlsaXR5IG1hbmFnZW1l bnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPw0KDQogICAgICBGb3IgUm91dGUgT3B0aW1pemF0aW9u IChSTyksIEkgdGhpbmssIGVhY2ggTU5OIChWTU4gb3IgTE1OKSBzaG91bGQgcGVyZm9ybSANCg0K ICAgICAgdGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgcmVsYXRlZCB0byBSTy4NCiAgICAgIEJlY2F1 c2UgUk8gdXNlcyB0aGUgYWNjZXNzIG5ldHdvcmsgZGlyZWN0bHksIGVhY2ggbW9iaWxlIG5vZGUg aXMgZWZmaWNpZW50IHRvIHBlcmZvcm0gaXRzIFJPDQoNCiAgICAgIGluIHRoZSBzYW1lIG1hbm5l ciBhcyBNSVB2Ni4gDQoNCiAgPiANCiAgPiBUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIElu IE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCBmb3IgTVIgdG8gbWFuYWdlIHRoZSBtb2Jp bGl0eSBvZiANCiAgPiBtb2JpbGUgbmV0d29yayB0cmFuc3BhcmVudGx5IHRvIG5vZGVzIGJlaGlu ZCBpdC4NCiAgPiANCiAgICAgIE9ubHkgd2hlbiBSTyBpcyBleGNsdWRlZCBpbiBORU5PIG9wZXJh dGlvbiwgaXQgaXMgcmlnaHQuDQogICAgICBGb3IgbG9jYWwgZml4ZWQgbm9kZSAoTEZOKSwgdGhl IG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQuDQoNCiAgICAgIFRoZSBzY29w ZSBvZiBSTyBvZiBteSBkcmFmdCBpcyBmb3IgbW9iaWxlIG5vZGVzLCBlaXRoZXIgbG9jYWwgbW9i aWxlIG5vZGUgKExNTikgb3IgDQoNCiAgICAgIHZpc2l0aW5nIG1vYmlsZSBub2RlIChWTU4pLiAg DQoNCiAgPiANCiAgPiBJZiBub2RlcyBiZWhpbmQgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2Vz cyBsaW5rIHZpYSBQcm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyANCg0KICA+IHRoZSBwb2lu dCBvZiBhdHRhY2htZW50LCBhbGwgb2Ygbm9kZXMgaGF2ZSB0byBkaXJlY3RseSBwcm9jZXNzIGVh Y2ggdGhlaXIgaGFuZG92ZXIoTDMgYWRkcmVzcyBjaGFuZ2VkKS4NCg0KICAgICAgIEFsbCBtb2Jp bGUgbm9kZXMgbmVlZCBub3QgcGFydGljaXBhdGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBk cmFmdC4gDQogICAgICAgSG93IGFib3V0IG9ubHkgbW9iaWxlIG5vZGVzIHRoYXQgbmVlZCBSTyBw ZXJmb3JtaW5nIHRoZSBSTz8gDQogICAgICAgUk8gY2FuIGJlIHBlcmZvcm1lZCBvbmx5IGJ5IG1v YmlsZSBub2RlcyB0aGF0IGNhbiB1bmRlcnN0YW5kIHRoZSBleHRlbmRlZCBwcmVmaXggaW5mb3Jt YXRpb24gb3B0aW9uDQoNCiAgICAgICBvZiBSQSBtZXNzYWdlLCBpbmNsdWRpbmcgdGhlIHByZWZp eCBvZiBhIG5ldyBhY2Nlc3MgbmV0d29yay4NCiAgICAgICBJdCBpcyByZWFzb25hYmxlLCBJIHRo aW5rLg0KICAgICAgIEluIGNvbmNsdXNpb24sIGZvciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyBy ZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVybiByb3V0YWJpbGl0eSBhbmQgDQogICAgICAg YmluZGluZyB1cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi4NCg0KICA+IA0KICA+IEhvdyBkbyB5 b3UgdGhpbmsgb2YgbXkgcG9pbnQ/DQogID4gSWYgc29tZXRoaW5nIG1pc3NlZCwgcGxlYXNlIGNv cnJlY3QgbWUuIFRoYW5rcy4NCiAgPiAgDQogID4gL0pvbmcNCg0KICAgICAgVGhhbmtzIGZvciB5 b3VyIGludGVyZXN0Lg0KICAgICAgDQoNCiAgICAgIC9KYWVob29uDQoNCiAgPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICA+IEZyb206IG5lbW8tYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpu ZW1vLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFlaG9vbiBKZW9uZw0KICA+IFNlbnQ6 IFN1bmRheSwgSnVuZSAxNSwgMjAwMyAxMjoyNSBQTQ0KICA+IFRvOiBuZW1vQG5hbC5tb3RsYWJz LmNvbQ0KICA+IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEg bmV3IFJPIGRyYWZ0DQogID4gIA0KICA+IEhlbGxvLCBuZW1vIGd1eXMhIA0KICA+ICANCiAgPiBJ IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCB0aGUgUm91dGUgT3B0aW1pemF0aW9uIChSTykg Zm9yIG1vYmlsZSBub2RlcyBpbiBtb2JpbGUgbmV0d29yay4gDQogID4gIA0KICA+ICBUaXRsZSA6 IE5ELVByb3h5IGJhc2VkIFJvdXRlIE9wdGltaXphdGlvbiBmb3IgTW9iaWxlIE5vZGVzIGluIE1v YmlsZSBOZXR3b3JrIA0KICA+ICBVUkwgZm9yIHRoZSBEcmFmdCA6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQgDQog ID4gIA0KICA+IEl0IGlzIGJhc2VkIG9uIE5ELVByb3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxp bmsgc3VibmV0Lg0KICA+IFdoZW5ldmVyIGEgbW9iaWxlIHJvdXRlciBtb3ZlcyBpbnRvIGFub3Ro ZXIgYWNjZXNzIG5ldHdvcmssIA0KICA+IGl0IHByb3ZpZGVzIGl0cyBtb2JpbGUgbmV0d29yayBu b2RlcyB3aXRoIHRoZSBuZXR3b3JrIHByZWZpeCBvZiB0aGUgYWNjZXNzIG5ldHdvcmsuDQogID4g VGhpcyBzY2hlbWUgbWFrZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGFuZCBtb2JpbGUgbmV0d29yayBi ZWNvbWUgYSBtdWx0aS1saW5rIHN1Ym5ldCwgDQogID4gYWxsb3dpbmcgdGhlIGxvY2FsIG9yIHZp c2l0aW5nIG1vYmlsZSBub2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrDQogID4gdG8gcGVy Zm9ybSBiaW5kaW5nIHVwZGF0ZSBmb3Igcm91dGUgb3B0aW1pemF0aW9uLg0KICA+ICANCiAgPiBU aG91Z2ggUk8gaXMgbm90IHRoZSBjdXJyZW50IGlzc3VlIGluIG5lbW8gd2csIEkgdGhpbmssIHRo ZSByZXNlYXJjaCBmb3IgUk8gaXMgaW1wb3J0YW50IGluIG5lbW8uIA0KICA+IFRocm91Z2ggb24t bGluZSBkaXNjdXNzaW9uIGFib3V0IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFy ZSBSTyBpc3N1ZSANCiAgPiB0aGF0IGNhbiBiZSBkaXNjdXNzZWQgaW4gZWFybmVzdCBuZXh0IHll YXIuIA0KICA+IFNvLCBJJ2QgbGlrZSB0byByZXF1ZXN0IHlvdXIgY29tbWVudHMgb24gbXkgZHJh ZnQuIA0KICA+IFRoYW5rcy4gDQogID4gIA0KICA+IFJlZ2FyZHMsIA0KICA+IEphZWhvb24gDQo= ------=_NextPart_000_000B_01C335EB.601BFEE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxN RVRBIGNvbnRlbnQ9V29yZC5Eb2N1bWVudCBuYW1lPVByb2dJZD4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxMCIgbmFtZT1PcmlnaW5hdG9yPjxMSU5LIA0KaHJlZj0iY2lkOmZpbGVsaXN0 LnhtbEAwMUMzMzUwNS5BNzFGNzBCMCIgcmVsPUZpbGUtTGlzdD48bzpTbWFydFRhZ1R5cGUgDQpu YW1lPSJ0aW1lIiANCm5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzIj48L286U21hcnRUYWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9ImRh dGUiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86T2Zm aWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25DU1MvPg0KIDwvbzpPZmZpY2VE b2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0YXRlPkNsZWFuPC93OlNwZWxs aW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFtbWFyU3RhdGU+DQogIDx3 OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4NCiAgPHc6RW52ZWxv cGVWaXMvPg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6 Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9y ZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT5zdDFcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjaWVvb3VpKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPg0KPCEtLQ0KIC8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuuwlO2DlTsN CglwYW5vc2UtMToyIDMgNiAwIDAgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpCYXRhbmc7DQoJ bXNvLWZvbnQtY2hhcnNldDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJ bXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkz IDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ouq1 tOumvDsNCglwYW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1hbHQ6R3Vs aW07DQoJbXNvLWZvbnQtY2hhcnNldDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9k ZXJuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTM0 MjE3NjU5MyAxNzc1NzI5OTE1IDQ4IDAgNTI0NDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBp dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZToxNjI3NDIxMzE5IC0yMTQ3NDgzNjQ4 IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA6rW066a8IjsNCglw YW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOuwlO2DlSI7DQoJcGFub3NlLTE6MiAz IDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTEzNDIxNzY1OTMgMTc3NTcyOTkxNSA0OCAwIDUyNDQ0NyAwO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrqtbTrprw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk66rW066a8O30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk66rW066a8Ow0KCW1zby1hc2NpaS1mb250LWZhbWlseTrqtbTrprw7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk66rW066a8Ow0KCW1zby1oYW5zaS1mb250LWZhbWlseTpBcmlh bDsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCnNwYW4uU3Bl bGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0Kc3Bhbi5HcmFtRQ0K CXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQpAcGFnZSBTZWN0aW9uMQ0K CXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46OTkuMjVwdCAzLjBjbSAzLjBjbSAzLjBj bTsNCgltc28taGVhZGVyLW1hcmdpbjo0Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZw dDsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7 fQ0KLS0+DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFt ZToi7ZGc7KSAIO2RnCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxl LWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wYXJl bnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEt bWFyZ2luOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUtP IHN0eWxlPSJ0YWItaW50ZXJ2YWw6IDQwLjBwdCIgdkxpbms9Ymx1ZSBsaW5rPWJsdWUgYmdDb2xv cj13aGl0ZT4NCjxESVY+PEZPTlQgZmFjZT3qtbTrprwgc2l6ZT0yPklubGluZXMgOi0pPC9GT05U PjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCDqtbTrprwiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgDQog IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IOq1tOumvDsgZm9udC1jb2xv cjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgdGl0bGU9amtuYUBwb3BleWUuc251LmFjLmty IGhyZWY9Im1haWx0bzpqa25hQHBvcGV5ZS5zbnUuYWMua3IiPk5hLCBKb25nIA0KICBLZXVuPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCDqtbTrprwiPjxCPlRvOjwvQj4gPEEg dGl0bGU9cGF1bEBldHJpLnJlLmtyIA0KICBocmVmPSJtYWlsdG86cGF1bEBldHJpLnJlLmtyIj4n SmFlaG9vbiBKZW9uZyc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IOq1tOum vCI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1uZW1vQG5hbC5tb3RsYWJzLmNvbSANCiAgaHJlZj0ibWFp bHRvOm5lbW9AbmFsLm1vdGxhYnMuY29tIj4nTkVNTyBXRyc8L0E+IDsgPEEgdGl0bGU9cGpzQGV0 cmkucmUua3IgDQogIGhyZWY9Im1haWx0bzpwanNAZXRyaS5yZS5rciI+J+uwleygleyImCc8L0E+ IDsgPEEgdGl0bGU9a2hqQGV0cmkucmUua3IgDQogIGhyZWY9Im1haWx0bzpraGpAZXRyaS5yZS5r ciI+J+q5gO2YleykgCc8L0E+IDsgPEEgdGl0bGU9bGVla2pAZXRyaS5yZS5rciANCiAgaHJlZj0i bWFpbHRvOmxlZWtqQGV0cmkucmUua3IiPifsnbTqsr3sp4QnPC9BPiA7IDxBIHRpdGxlPXNreWxh bmVAZXRyaS5yZS5rciANCiAgaHJlZj0ibWFpbHRvOnNreWxhbmVAZXRyaS5yZS5rciI+J+q5gOuz keyXvSc8L0E+IDsgPEEgdGl0bGU9amFmeUBldHJpLnJlLmtyIA0KICBocmVmPSJtYWlsdG86amFm eUBldHJpLnJlLmtyIj4n7LCo7ZiE7JqxJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDEwcHQg6rW066a8Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwgSnVuZSAxNywgMjAwMyA3OjIxIFBN PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW066a8Ij48Qj5TdWJqZWN0OjwvQj4g UkU6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIA0KICBjb21tZW50cyBvbiBhIG5ldyBSTyBkcmFm dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28t aGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkhp IA0KICA8U1BBTiBjbGFzcz1TcGVsbEU+SmFlaG9vbjwvU1BBTj4sIDxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1z by1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+ VGhhbmtzIA0KICBmb3IgeW91ciBxdWljayByZXBseS48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9 RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2kt Zm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkF0IA0KICB0 aGVzZSBkYXlzLCBJPC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1hc2NpaS1mb250LWZhbWlseTog6rW066a8Ij7i gJk8L1NQQU4+PC9GT05UPjxGT05UIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZv bnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5tIA0KICBjb25z aWRlcmluZyBob3cgdG8gc29sdmUgdGhlIG5lc3RlZCB0dW5uZWxzIHByb2JsZW0uPC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij4tJmd0OyZuYnNwO0l0IA0KICBpcyBpbXBvcnRhbnQmbmJzcDt0byBzb2x2ZSB0aGUgcHJvYmxl bSwgSSBhZ3JlZS48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlk aS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFy aWFsIj5JTUhPLCANCiAgdGhpcyBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24gaXMgdmVyeSBp bXBvcnRhbnQgaW4gdGhlIGFyZWEgb2YgTkVNTyBSTyANCiAgcHJvYmxlbS48bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwg Y29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiBBcmlhbCI+SW4gDQogIHRoaXMgYXNwZWN0LCBJIHRoaW5rIGl0IGlzIG5l ZWRlZCB0byBjb25zaWRlciB0aGlzIGtpbmQgb2Ygb3B0aW1pemF0aW9uIGluIA0KICB5b3VyIGRy YWZ0LjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+LSZndDsgDQogIEluIHRoaXMgcmVzcGVjdCwgSSBk aXNhZ3JlZS48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFs OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgQmVjYXVzZSBteSBzY2hlbWUgaXMgYmFzZWQgb24gbXVsdGktbGluayBzdWJuZXQsIHRoZXJl IGhhcHBlbnMgbm8gbmVzdGVkIA0KICB0dW5uZWwgcHJvYmxlbTwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7 IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlh bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBmb3IgbW9iaWxlIG5vZGVzIHdpdGhpbiBO RU1PLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86cD48L286cD48L1NQQU4+PC9GT05UPiZuYnNw OzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWls eTogQXJpYWwiPkhvdyANCiAgYWJvdXQgPFNQQU4gY2xhc3M9U3BlbGxFPk1SczwvU1BBTj4gPFNQ QU4gY2xhc3M9R3JhbUU+ZG88L1NQQU4+IE5ELXByb3h5IGJhc2VkIA0KICBSTyBhYm91dCB0aGVp ciBlZ3Jlc3MgaW50ZXJmYWNlPzwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZh bWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+LSZndDsgDQogIEluIG15 IGRyYWZ0LCBsaWtlIHlvdXIgc3VnZ2VzdGlvbiwgTVJzIHBsYXlzIHRoZSByb2xlIG9mIE5ELXBy b3h5IGZvciB0aGVpciANCiAgb3duIGVncmVzcyBpbnRlcmZhY2UgYW5kPC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IEFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHBsYXlzIHRoZSBub3JtYWwgcm91 dGVyIGZvciB0aGVpciBvd24gaW5ncmVzcyBpbnRlcmZhY2UuPC9TUEFOPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFJlZmVyIHRvICJNdWx0aS1saW5rIFN1Ym5l dCBTdXBwb3J0IGluIElQdjYiIGRyYWZ0IGZvciBkZXRhaWxlZCANCiAgbWVjaGFuaXNtLjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZv bnQtZmFtaWx5OiBBcmlhbCI+PEZPTlQgDQogIGNvbG9yPSMwMDAwMDA+Jm5ic3A7PC9GT05UPiZu YnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBjb2xvcj0jMDAwMDAwPjxBIA0KICBocmVmPSJodHRwOi8v d3d3LmFtYXJhbnRobmV0d29ya3MuY29tL2lldGYvZHJhZnRzL2RyYWZ0LWlldGYtaXB2Ni1tdWx0 aWxpbmstc3VibmV0cy0wMC50eHQiPmh0dHA6Ly93d3cuYW1hcmFudGhuZXR3b3Jrcy5jb20vaWV0 Zi9kcmFmdHMvZHJhZnQtaWV0Zi1pcHY2LW11bHRpbGluay1zdWJuZXRzLTAwLnR4dDwvQT48L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1 tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNv LWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiBBcmlhbCI+SWYgDQogIE1SIGNhbiBkbyB0aGF0LCB0aGUgbm9kZXMgYmVoaW5kIE1SIHdpbGwg Z2V0IHRoZSBlZmZlY3Qgb2YgbmVzdGVkIHR1bm5lbHMgDQogIG9wdGltaXphdGlvbi48bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+VGhlcmUgDQogIHdpbGwgYmUgbm8gbW9yZSBuZXN0 ZWQgdHVubmVsIGlmIDxTUEFOIGNsYXNzPVNwZWxsRT48U1BBTiANCiAgY2xhc3M9R3JhbUU+TVJz PC9TUEFOPjwvU1BBTj4gdXNlIG9uZSBhZGRyZXNzIGFsbG9jYXRlZCBpbiBhY2Nlc3MgbGluayBw cmVmaXggDQogIGFzIHRoZWlyIDxTUEFOIGNsYXNzPVNwZWxsRT5Db0E8L1NQQU4+IG9mIHRoZSBl Z3Jlc3MgaW50ZXJmYWNlIGFuZCA8U1BBTiANCiAgY2xhc3M9U3BlbGxFPk1SczwvU1BBTj4gb24g dGhlIHBhdGggb3BlcmF0ZSBpbiBORC1Qcm94eSBtb2RlLiANCiAgPC9TUEFOPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFy aWFsIj4tJmd0OyANCiAgUmlnaHQuIEJlY2F1c2UmbmJzcDt0aGVyZSZuYnNwO2FyZSBubyBuZXN0 ZWQgdHVubmVscyBiZXR3ZWVuIHJvb3QtTVIgYW5kIA0KICBzdWItTVImbmJzcDtvd2luZyB0byZu YnNwO211bHRpLWxpbmsgc3VibmV0LDwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250 LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIA0KICBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24gaXMg bm90IHJlbGF0ZWQgdG8gbXkgc2hlbWUuIFRoZXJlZm9yZSwgbXkgc2NoZW1lIA0KICBuZWVkIG5v dCBjb25zaWRlcjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJp YWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIA0KICBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24uPC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkkgDQogIHRoaW5rIGl0PC9TUEFO PjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t VVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTog QXJpYWw7IG1zby1hc2NpaS1mb250LWZhbWlseTog6rW066a8Ij7igJk8L1NQQU4+PC9GT05UPjxG T05UIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsg bXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5zIA0KICBwb3NzaWJsZSB0aGlzIGFwcHJvYWNo IGNhbiBiZSBhIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdGhlIG5lc3RlZCB0dW5uZWxzIA0KICBv cHRpbWl6YXRpb24gYWxyZWFkeSB0b3VjaGVkIGJ5IFJSSC1iYXNlZCBhbmQgQVJPLWJhc2VkIHBy b3Bvc2VkIHNvbHV0aW9ucywgDQogIGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBzb21lIGFyZ3VtZW50 cyBvbiB0aGUgZ2VuZXJhbCBmZWFzaWJpbGl0eSBvZiBORC1wcm94eSANCiAgYmFzZWQgc29sdXRp b24uPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PEZPTlQgDQogIGNvbG9y PSMwMDAwMDA+LSZndDsgSSBhZ3JlZS4gSSBhbSB0aGlua2luZyB0aGUgc2NhbGFiaWxpdHkgb2Yg bXkgc2NoZW1lIA0KICBub3cuPC9GT05UPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1o YW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86 cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEkmbmJzcDt0aGluayBteSBzY2hlbWUgaXMg dXNlZnVsIGZvciBhIGZldyBsZXZlbCBORU1PLCBub3QgZGVlcCBsZXZlbCANCk5FTU8uPC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBB cmlhbCI+PG86cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEZvciBleGFtcGxlLCBpdCB3 aWxsIGJlIHVzZWQgZm9yIE5FTU8gd2l0aGluIEludGVybmV0IGNhciBhbmQgDQogIGJ1cy48L286 cD48L1NQQU4+PC9GT05UPjwvUD48L286cD48L1NQQU4+PC9GT05UPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1m b250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86cD4mbmJz cDsmbmJzcDsmbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPeq1tOumvCBj b2xvcj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBt c28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFt aWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5EbyANCiAgeW91IHRoaW5r IG9mIHRoaXMgb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlPyBQbGVhc2UgbGV0IG1lIGtub3cgeW91 ciBvcGluaW9uLiANCiAgVGhhbmtzLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U96rW066a8IGNvbG9yPSMw MDAwMDAgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250 LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj4v PFNQQU4gDQogIGNsYXNzPVNwZWxsRT5Kb25nPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1p bHk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1o YW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86 cD4tJmd0OyANCiAgVGhhbmtzIGZvciB5b3VyIGdvb2QgY29tbWVudHMuPC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj0j MDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xv cj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgL0ph ZWhvb248L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U96rW066a8IGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBj b2xvcj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsg bXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogVGFob21hIj4tLS0tLU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+PEI+PFNQQU4gc3R5 bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Gcm9tOjwvU1BBTj48L0I+IA0KICBuZW1vLWFkbWluQGll dGYub3JnIFttYWlsdG86bmVtby1hZG1pbkBpZXRmLm9yZ10gPEI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVdFSUdIVDogYm9sZCI+T24gQmVoYWxmIE9mIDwvU1BBTj48L0I+SmFlaG9vbiBKZW9uZzxC Uj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+ IE1vbmRheSwgSnVuZSAxNiwgMjAwMyAzOjUxIA0KICBQTTxCUj48Qj48U1BBTiBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IE5hLCBKb25nIA0KICBLZXVuPEJSPjxCPjxT UEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gTkVNTyBXRzsgDQog IDwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IFRhaG9tYTsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBUYWhvbWEiPuuwleygleyImDwvU1BBTj48 L0ZPTlQ+PEZPTlQgDQogIGZhY2U9VGFob21hIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj47IDwvU1BBTj48L0ZP TlQ+PEZPTlQgDQogIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiBUYWhvbWE7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBUYWhvbWE7 IG1zby1hc2NpaS1mb250LWZhbWlseTogVGFob21hIj7quYDtmJXspIA8L1NQQU4+PC9GT05UPjxG T05UIA0KICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+OyA8L1NQQU4+PC9GT05UPjxGT05U IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1oYW5zaS1m b250LWZhbWlseTogVGFob21hOyBtc28tYmlkaS1mb250LWZhbWlseTogVGFob21hOyBtc28tYXNj aWktZm9udC1mYW1pbHk6IFRhaG9tYSI+7J206rK97KeEPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAg ZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPjsgPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28taGFuc2ktZm9udC1mYW1p bHk6IFRhaG9tYTsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OiBUYWhvbWEiPuq5gOuzkeyXvTwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9VGFo b21hIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogVGFob21hIj47IDwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mj48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBUYWhv bWE7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBUYWhvbWE7IG1zby1hc2NpaS1mb250LWZhbWlseTog VGFob21hIj7ssKjtmITsmrE8L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPVRhaG9tYSBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IFRhaG9tYSI+OyA8L1NQQU4+PC9GT05UPjxGT05UIA0KICBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1oYW5zaS1mb250LWZhbWlseTogVGFob21hOyBtc28t YmlkaS1mb250LWZhbWlseTogVGFob21hOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFRhaG9tYSI+ 7KCV7J6s7ZuIPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhv bWEiPjxCUj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0Ojwv U1BBTj48L0I+IFJlOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciANCiAgY29tbWVudHMgb24gYSBu ZXcgUk8gZHJhZnQ8L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBz dHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2Qi PjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg PERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1 cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBz aXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5IaSwgSm9uZyAN CiAgS2V1bi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBh cmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BB TiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5pbmxpbmVzOi0pPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0 OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48QlI+Jmd0OyAtLS0tLSBPcmlnaW5hbCANCiAgTWVzc2Fn ZSAtLS0tLSA8QlI+Jmd0OyBGcm9tOiBOYSwgSm9uZyBLZXVuIDxCUj4mZ3Q7IFRvOiAnSmFlaG9v biBKZW9uZycgOyANCiAgbmVtb0BuYWwubW90bGFicy5jb20gPEJSPiZndDsgU2VudDogPC9TUEFO PjwvRk9OVD48c3QxOmRhdGUgWWVhcj0iMjAwMyIgDQogIERheT0iMTYiIE1vbnRoPSI2Ij48U1BB TiBsYW5nPUVOLVVTPk1vbmRheSwgSnVuZSAxNiwgDQogIDIwMDM8L1NQQU4+PC9zdDE6ZGF0ZT48 U1BBTiBsYW5nPUVOLVVTPiA8L1NQQU4+PHN0MTp0aW1lIE1pbnV0ZT0iMTUiIA0KICBIb3VyPSIx MCI+PFNQQU4gbGFuZz1FTi1VUz4xMDoxNSBBTTwvU1BBTj48L3N0MTp0aW1lPjxTUEFOIGxhbmc9 RU4tVVM+PEJSPiZndDsgDQogIFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciBj b21tZW50cyBvbiBhIG5ldyBSTyANCiAgZHJhZnQ8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSGkg SmFlaG9vbiw8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7IEkgaGF2ZSBhIA0KICBjb25jZXJuIGluIHlv dXIgZHJhZnQuPEJSPiZndDsgSXMgaXQgcmlnaHQgZGlyZWN0aW9uIHRvIGdpdmUgdGhlIGJ1cmRl biBvZiANCiAgbW9iaWxpdHkgbWFuYWdlbWVudCB0byBlYWNoIE1OTnMsIG5vdCBNUnM/PEJSPjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIFJvdXRlIA0KICBPcHRpbWl6YXRpb24gKFJPKSwgSSB0 aGluaywgZWFjaCBNTk4gKFZNTiBvciBMTU4pIHNob3VsZCBwZXJmb3JtIA0KICA8bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzOS45NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy4zM2dkIj48 Rk9OVCBmYWNlPeq1tOumvCANCiAgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIA0KICBtb2JpbGl0eSBtYW5h Z2VtZW50IHJlbGF0ZWQgdG8gUk8uPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JlY2F1c2Ug Uk8gdXNlcyANCiAgdGhlIGFjY2VzcyBuZXR3b3JrIGRpcmVjdGx5LCBlYWNoIG1vYmlsZSBub2Rl IGlzIGVmZmljaWVudCB0byBwZXJmb3JtIGl0cyANCiAgUk88bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQg ZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8U1BBTiANCiAgY2xhc3M9R3JhbUU+aW48L1NQQU4+ IHRoZSBzYW1lJm5ic3A7bWFubmVyIGFzIE1JUHY2LiANCiAgPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0i TUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxTUEFO IA0KICBjbGFzcz1HcmFtRT48Rk9OVCBmYWNlPeq1tOumvCBzaXplPTM+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IA0KICA8QlI+Jmd0OzwvU1BBTj48L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+IFRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgSW4g DQogIE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCBmb3IgTVIgdG8gbWFuYWdlIHRoZSBt b2JpbGl0eSBvZiA8QlI+Jmd0OyBtb2JpbGUgDQogIG5ldHdvcmsgdHJhbnNwYXJlbnRseSB0byBu b2RlcyBiZWhpbmQgaXQuPEJSPiZndDsmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBP bmx5IHdoZW4gUk8gaXMgZXhjbHVkZWQgaW4gTkVOTyBvcGVyYXRpb24sIGl0IGlzIA0KICByaWdo dC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIGxvY2FsIGZpeGVkIG5vZGUgKExGTiks IHRoZSBtb2JpbGl0eSBvZiANCiAgTkVNTyBpcyBzdGlsbCB0cmFuc3BhcmVudC48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzOS45NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy4zM2dkIj48 Rk9OVCBmYWNlPeq1tOumvCANCiAgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzY29wZSANCiAgb2YgUk8gb2YgbXkg ZHJhZnQgaXMgZm9yIG1vYmlsZSBub2RlcywgZWl0aGVyIGxvY2FsIG1vYmlsZSBub2RlIA0KICAo TE1OKSZuYnNwO29yJm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAg PERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1 cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBz aXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgdmlzaXRpbmcgDQogIG1vYmlsZSZuYnNwO25vZGUgKFZNTikuJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdp bi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IDxCUj4mZ3Q7IElmIG5vZGVzIGJlaGlu ZCANCiAgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2VzcyBsaW5rIHZpYSBQcm94eS1ORCBlYWNo IHRpbWUgTVIgY2hhbmdlcyANCiAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5 Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0K ICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IHRo ZSBwb2ludCBvZiBhdHRhY2htZW50LCANCiAgYWxsIG9mIG5vZGVzIGhhdmUgdG8gZGlyZWN0bHkg cHJvY2VzcyBlYWNoIHRoZWlyIGhhbmRvdmVyKEwzIGFkZHJlc3MgDQogIGNoYW5nZWQpLjxCUj48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO0FsbCBtb2JpbGUgbm9kZXMgbmVlZCBub3QgDQog IHBhcnRpY2lwYXRlIGluIHRoZSBSTyBzdWdnZXN0ZWQgaW4gbXkgZHJhZnQuIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSG93IA0KICBhYm91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5l ZWQgUk8gcGVyZm9ybWluZyB0aGUgUk8/IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJPIGNhbiBiZSBwZXJmb3JtZWQgb25seSBieSBtb2JpbGUgbm9kZXMgdGhhdCBjYW4gDQogIHVu ZGVyc3RhbmQgdGhlIGV4dGVuZGVkIHByZWZpeCBpbmZvcm1hdGlvbiANCiAgb3B0aW9uPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0 OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7b2YgUkEgDQog IG1lc3NhZ2UsIGluY2x1ZGluZyB0aGUgcHJlZml4IG9mIGEgbmV3IGFjY2VzcyANCiAgbmV0d29y ay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlYXNvbmFibGUsIEkgDQogIHRo aW5rLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gY29uY2x1c2lvbiwgZm9yIFJPLCBl YWNoIG1vYmlsZSBub2RlIGlzIA0KICByZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVybiBy b3V0YWJpbGl0eSBhbmQgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgYmluZGluZyB1 cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwv RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVG VDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT3qtbTr prwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZn dDsgPEJSPiZndDsgSG93IGRvIHlvdSB0aGluayANCiAgb2YgbXkgcG9pbnQ/PEJSPiZndDsgSWYg c29tZXRoaW5nIG1pc3NlZCwgcGxlYXNlIGNvcnJlY3QgbWUuIA0KICBUaGFua3MuPEJSPiZndDsm bmJzcDsmbmJzcDs8QlI+Jmd0OyAvSm9uZzxCUj48QlI+Jm5ic3A7Jm5ic3A7ICZuYnNwO1RoYW5r cyBmb3IgDQogIHlvdXIgaW50ZXJlc3QuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwg DQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMu MzNnZCI+PEZPTlQgZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgL0phZWhvb248QlI+PEJS PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiANCiAgbmVtby1h ZG1pbkBpZXRmLm9yZyBbbWFpbHRvOm5lbW8tYWRtaW5AaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK YWVob29uIA0KICBKZW9uZzxCUj4mZ3Q7IFNlbnQ6IDwvU1BBTj48L0ZPTlQ+PHN0MTpkYXRlIFll YXI9IjIwMDMiIERheT0iMTUiIA0KICBNb250aD0iNiI+PFNQQU4gbGFuZz1FTi1VUz5TdW5kYXks IEp1bmUgMTUsIDIwMDM8L1NQQU4+PC9zdDE6ZGF0ZT48U1BBTiANCiAgbGFuZz1FTi1VUz4gPC9T UEFOPjxzdDE6dGltZSBNaW51dGU9IjI1IiBIb3VyPSIxMiI+PFNQQU4gbGFuZz1FTi1VUz4xMjoy NSANCiAgUE08L1NQQU4+PC9zdDE6dGltZT48U1BBTiBsYW5nPUVOLVVTPjxCUj4mZ3Q7IFRvOiBu ZW1vQG5hbC5tb3RsYWJzLmNvbTxCUj4mZ3Q7IA0KICBTdWJqZWN0OiBbbmVtb10gUmVxdWVzdCBm b3IgeW91ciBjb21tZW50cyBvbiBhIG5ldyBSTyANCiAgZHJhZnQ8QlI+Jmd0OyZuYnNwOyZuYnNw OzxCUj4mZ3Q7IEhlbGxvLCBuZW1vIGd1eXMhIA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4m Z3Q7IEkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHRoZSBSb3V0ZSANCiAgT3B0aW1pemF0 aW9uIChSTykgZm9yIG1vYmlsZSBub2RlcyBpbiBtb2JpbGUgbmV0d29yay4gDQogIDxCUj4mZ3Q7 Jm5ic3A7Jm5ic3A7PEJSPiZndDsmbmJzcDsmbmJzcDtUaXRsZSA6IE5ELVByb3h5IGJhc2VkIFJv dXRlIA0KICBPcHRpbWl6YXRpb24gZm9yIE1vYmlsZSBOb2RlcyBpbiBNb2JpbGUgTmV0d29yayA8 QlI+Jmd0OyZuYnNwOyZuYnNwO1VSTCBmb3IgDQogIHRoZSBEcmFmdCA6IA0KICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDAu dHh0IA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IEl0IGlzIGJhc2VkIG9uIE5ELVBy b3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxpbmsgDQogIHN1Ym5ldC48QlI+Jmd0OyBXaGVuZXZl ciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFjY2VzcyBuZXR3b3JrLCANCiAg PEJSPiZndDsgaXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdpdGggdGhlIG5l dHdvcmsgcHJlZml4IG9mIHRoZSANCiAgYWNjZXNzIG5ldHdvcmsuPEJSPiZndDsgVGhpcyBzY2hl bWUgbWFrZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGFuZCBtb2JpbGUgDQogIG5ldHdvcmsgYmVjb21l IGEgbXVsdGktbGluayBzdWJuZXQsIDxCUj4mZ3Q7IGFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNp dGluZyANCiAgbW9iaWxlIG5vZGVzIHdpdGhpbiB0aGUgbW9iaWxlIG5ldHdvcms8QlI+Jmd0OyB0 byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRlIGZvciANCiAgcm91dGUgb3B0aW1pemF0aW9uLjxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsgVGhvdWdoIFJPIGlzIG5vdCB0aGUgY3VycmVudCANCiAg aXNzdWUgaW4gbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBpbXBvcnRh bnQgaW4gbmVtby4gPEJSPiZndDsgDQogIFRocm91Z2ggb24tbGluZSBkaXNjdXNzaW9uIGFib3V0 IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFyZSBSTyBpc3N1ZSANCiAgPEJSPiZn dDsgdGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIGVhcm5lc3QgbmV4dCB5ZWFyLiA8QlI+Jmd0OyBT bywgSSdkIGxpa2UgdG8gDQogIHJlcXVlc3QgeW91ciBjb21tZW50cyBvbiBteSBkcmFmdC4gPEJS PiZndDsgVGhhbmtzLiANCiAgPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBSZWdhcmRzLCA8 QlI+Jmd0OyBKYWVob29uIA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000B_01C335EB.601BFEE0-- From exim@www1.ietf.org Wed Jun 18 13:53:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18457 for ; Wed, 18 Jun 2003 13:53:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IHqVs21238 for nemo-archive@odin.ietf.org; Wed, 18 Jun 2003 13:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sgcu-0003rn-1Q for nemo-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 13:21:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17233 for ; Wed, 18 Jun 2003 13:21:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sgad-0006yl-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 13:19:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sgac-0006yi-00 for nemo-web-archive@ietf.org; Wed, 18 Jun 2003 13:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sg1V-0002PG-HK; Wed, 18 Jun 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdHX-0001Y7-AJ for nemo@optimus.ietf.org; Wed, 18 Jun 2003 09:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06832 for ; Wed, 18 Jun 2003 09:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdFG-0004mg-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:45:02 -0400 Received: from dns1.nal.motlabs.com ([195.212.111.242] helo=jessica.nal.motlabs.com) by ietf-mx with esmtp (Exim 4.12) id 19SdF9-0004mZ-00 for nemo@ietf.org; Wed, 18 Jun 2003 09:44:58 -0400 Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h5IDl7dJ001443 for ; Wed, 18 Jun 2003 15:47:08 +0200 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5IDxt705249; Wed, 18 Jun 2003 22:59:55 +0900 (KST) Message-ID: <000e01c3359f$f0d1a850$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Na, Jong Keun" Cc: "NEMO WG" , "autonet" References: <02b301c334ba$3d3264a0$dbf02e93@jongkn02> Subject: Re: [nemo] Request for your comments on a new RO draft Date: Wed, 18 Jun 2003 22:45:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C335EB.601BFEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C335EB.601BFEE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lcyA6LSkNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogTmEs IEpvbmcgS2V1biANCiAgVG86ICdKYWVob29uIEplb25nJyANCiAgQ2M6ICdORU1PIFdHJyA7ICfr sJXsoJXsiJgnIDsgJ+q5gO2YleykgCcgOyAn7J206rK97KeEJyA7ICfquYDrs5Hsl70nIDsgJ+yw qO2YhOyasScgDQogIFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTcsIDIwMDMgNzoyMSBQTQ0KICBTdWJq ZWN0OiBSRTogW25lbW9dIFJlcXVlc3QgZm9yIHlvdXIgY29tbWVudHMgb24gYSBuZXcgUk8gZHJh ZnQNCg0KDQogIEhpIEphZWhvb24sIA0KDQogICANCg0KICBUaGFua3MgZm9yIHlvdXIgcXVpY2sg cmVwbHkuDQoNCiAgIA0KDQogIEF0IHRoZXNlIGRheXMsIEnigJltIGNvbnNpZGVyaW5nIGhvdyB0 byBzb2x2ZSB0aGUgbmVzdGVkIHR1bm5lbHMgcHJvYmxlbS4NCg0KICAtPiBJdCBpcyBpbXBvcnRh bnQgdG8gc29sdmUgdGhlIHByb2JsZW0sIEkgYWdyZWUuDQoNCg0KDQogIElNSE8sIHRoaXMgbmVz dGVkIHR1bm5lbHMgb3B0aW1pemF0aW9uIGlzIHZlcnkgaW1wb3J0YW50IGluIHRoZSBhcmVhIG9m IE5FTU8gUk8gcHJvYmxlbS4NCg0KICBJbiB0aGlzIGFzcGVjdCwgSSB0aGluayBpdCBpcyBuZWVk ZWQgdG8gY29uc2lkZXIgdGhpcyBraW5kIG9mIG9wdGltaXphdGlvbiBpbiB5b3VyIGRyYWZ0Lg0K DQogIC0+IEluIHRoaXMgcmVzcGVjdCwgSSBkaXNhZ3JlZS4NCg0KICAgICAgIEJlY2F1c2UgbXkg c2NoZW1lIGlzIGJhc2VkIG9uIG11bHRpLWxpbmsgc3VibmV0LCB0aGVyZSBoYXBwZW5zIG5vIG5l c3RlZCB0dW5uZWwgcHJvYmxlbQ0KDQogICAgICAgZm9yIG1vYmlsZSBub2RlcyB3aXRoaW4gTkVN Ty4NCg0KDQoNCiAgSG93IGFib3V0IE1ScyBkbyBORC1wcm94eSBiYXNlZCBSTyBhYm91dCB0aGVp ciBlZ3Jlc3MgaW50ZXJmYWNlPw0KDQogIC0+IEluIG15IGRyYWZ0LCBsaWtlIHlvdXIgc3VnZ2Vz dGlvbiwgTVJzIHBsYXlzIHRoZSByb2xlIG9mIE5ELXByb3h5IGZvciB0aGVpciBvd24gZWdyZXNz IGludGVyZmFjZSBhbmQNCg0KICAgICAgIHBsYXlzIHRoZSBub3JtYWwgcm91dGVyIGZvciB0aGVp ciBvd24gaW5ncmVzcyBpbnRlcmZhY2UuDQoNCiAgICAgICBSZWZlciB0byAiTXVsdGktbGluayBT dWJuZXQgU3VwcG9ydCBpbiBJUHY2IiBkcmFmdCBmb3IgZGV0YWlsZWQgbWVjaGFuaXNtLg0KDQog ICAgICAgaHR0cDovL3d3dy5hbWFyYW50aG5ldHdvcmtzLmNvbS9pZXRmL2RyYWZ0cy9kcmFmdC1p ZXRmLWlwdjYtbXVsdGlsaW5rLXN1Ym5ldHMtMDAudHh0DQoNCg0KDQogIElmIE1SIGNhbiBkbyB0 aGF0LCB0aGUgbm9kZXMgYmVoaW5kIE1SIHdpbGwgZ2V0IHRoZSBlZmZlY3Qgb2YgbmVzdGVkIHR1 bm5lbHMgb3B0aW1pemF0aW9uLg0KDQogIFRoZXJlIHdpbGwgYmUgbm8gbW9yZSBuZXN0ZWQgdHVu bmVsIGlmIE1ScyB1c2Ugb25lIGFkZHJlc3MgYWxsb2NhdGVkIGluIGFjY2VzcyBsaW5rIHByZWZp eCBhcyB0aGVpciBDb0Egb2YgdGhlIGVncmVzcyBpbnRlcmZhY2UgYW5kIE1ScyBvbiB0aGUgcGF0 aCBvcGVyYXRlIGluIE5ELVByb3h5IG1vZGUuIA0KDQogIC0+IFJpZ2h0LiBCZWNhdXNlIHRoZXJl IGFyZSBubyBuZXN0ZWQgdHVubmVscyBiZXR3ZWVuIHJvb3QtTVIgYW5kIHN1Yi1NUiBvd2luZyB0 byBtdWx0aS1saW5rIHN1Ym5ldCwNCg0KICAgICAgIHRoZSBuZXN0ZWQgdHVubmVscyBvcHRpbWl6 YXRpb24gaXMgbm90IHJlbGF0ZWQgdG8gbXkgc2hlbWUuIFRoZXJlZm9yZSwgbXkgc2NoZW1lIG5l ZWQgbm90IGNvbnNpZGVyDQoNCiAgICAgICB0aGUgbmVzdGVkIHR1bm5lbHMgb3B0aW1pemF0aW9u Lg0KDQoNCg0KICBJIHRoaW5rIGl04oCZcyBwb3NzaWJsZSB0aGlzIGFwcHJvYWNoIGNhbiBiZSBh IGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdGhlIG5lc3RlZCB0dW5uZWxzIG9wdGltaXphdGlvbiBh bHJlYWR5IHRvdWNoZWQgYnkgUlJILWJhc2VkIGFuZCBBUk8tYmFzZWQgcHJvcG9zZWQgc29sdXRp b25zLCBldmVuIHRob3VnaCB0aGVyZSBhcmUgc29tZSBhcmd1bWVudHMgb24gdGhlIGdlbmVyYWwg ZmVhc2liaWxpdHkgb2YgTkQtcHJveHkgYmFzZWQgc29sdXRpb24uDQoNCiAgLT4gSSBhZ3JlZS4g SSBhbSB0aGlua2luZyB0aGUgc2NhbGFiaWxpdHkgb2YgbXkgc2NoZW1lIG5vdy4NCg0KICAgICAg IEkgdGhpbmsgbXkgc2NoZW1lIGlzIHVzZWZ1bCBmb3IgYSBmZXcgbGV2ZWwgTkVNTywgbm90IGRl ZXAgbGV2ZWwgTkVNTy4NCg0KICAgICAgIEZvciBleGFtcGxlLCBpdCB3aWxsIGJlIHVzZWQgZm9y IE5FTU8gd2l0aGluIEludGVybmV0IGNhciBhbmQgYnVzLg0KDQogICAgICAgICAgDQoNCiAgRG8g eW91IHRoaW5rIG9mIHRoaXMgb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlPyBQbGVhc2UgbGV0IG1l IGtub3cgeW91ciBvcGluaW9uLiBUaGFua3MuDQoNCg0KDQogIC9Kb25nDQoNCiAgIA0KDQogIC0+ IFRoYW5rcyBmb3IgeW91ciBnb29kIGNvbW1lbnRzLg0KDQogICAgICANCg0KICAgICAgIC9KYWVo b29uDQoNCg0KDQoNCg0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICBGcm9tOiBuZW1v LWFkbWluQGlldGYub3JnIFttYWlsdG86bmVtby1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEphZWhvb24gSmVvbmcNCiAgU2VudDogTW9uZGF5LCBKdW5lIDE2LCAyMDAzIDM6NTEgUE0NCiAg VG86IE5hLCBKb25nIEtldW4NCiAgQ2M6IE5FTU8gV0c7IOuwleygleyImDsg6rmA7ZiV7KSAOyDs nbTqsr3sp4Q7IOq5gOuzkeyXvTsg7LCo7ZiE7JqxOyDsoJXsnqztm4gNCiAgU3ViamVjdDogUmU6 IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEgbmV3IFJPIGRyYWZ0DQoNCiAg IA0KDQogIEhpLCBKb25nIEtldW4uDQoNCiAgaW5saW5lczotKQ0KDQoNCiAgPiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KICA+IEZyb206IE5hLCBKb25nIEtldW4gDQogID4gVG86ICdK YWVob29uIEplb25nJyA7IG5lbW9AbmFsLm1vdGxhYnMuY29tIA0KICA+IFNlbnQ6IE1vbmRheSwg SnVuZSAxNiwgMjAwMyAxMDoxNSBBTQ0KICA+IFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBm b3IgeW91ciBjb21tZW50cyBvbiBhIG5ldyBSTyBkcmFmdA0KICA+DQogID4NCiAgPiBIaSBKYWVo b29uLA0KICA+IA0KICA+IEkgaGF2ZSBhIGNvbmNlcm4gaW4geW91ciBkcmFmdC4NCiAgPiBJcyBp dCByaWdodCBkaXJlY3Rpb24gdG8gZ2l2ZSB0aGUgYnVyZGVuIG9mIG1vYmlsaXR5IG1hbmFnZW1l bnQgdG8gZWFjaCBNTk5zLCBub3QgTVJzPw0KDQogICAgICBGb3IgUm91dGUgT3B0aW1pemF0aW9u IChSTyksIEkgdGhpbmssIGVhY2ggTU5OIChWTU4gb3IgTE1OKSBzaG91bGQgcGVyZm9ybSANCg0K ICAgICAgdGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgcmVsYXRlZCB0byBSTy4NCiAgICAgIEJlY2F1 c2UgUk8gdXNlcyB0aGUgYWNjZXNzIG5ldHdvcmsgZGlyZWN0bHksIGVhY2ggbW9iaWxlIG5vZGUg aXMgZWZmaWNpZW50IHRvIHBlcmZvcm0gaXRzIFJPDQoNCiAgICAgIGluIHRoZSBzYW1lIG1hbm5l ciBhcyBNSVB2Ni4gDQoNCiAgPiANCiAgPiBUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIElu IE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCBmb3IgTVIgdG8gbWFuYWdlIHRoZSBtb2Jp bGl0eSBvZiANCiAgPiBtb2JpbGUgbmV0d29yayB0cmFuc3BhcmVudGx5IHRvIG5vZGVzIGJlaGlu ZCBpdC4NCiAgPiANCiAgICAgIE9ubHkgd2hlbiBSTyBpcyBleGNsdWRlZCBpbiBORU5PIG9wZXJh dGlvbiwgaXQgaXMgcmlnaHQuDQogICAgICBGb3IgbG9jYWwgZml4ZWQgbm9kZSAoTEZOKSwgdGhl IG1vYmlsaXR5IG9mIE5FTU8gaXMgc3RpbGwgdHJhbnNwYXJlbnQuDQoNCiAgICAgIFRoZSBzY29w ZSBvZiBSTyBvZiBteSBkcmFmdCBpcyBmb3IgbW9iaWxlIG5vZGVzLCBlaXRoZXIgbG9jYWwgbW9i aWxlIG5vZGUgKExNTikgb3IgDQoNCiAgICAgIHZpc2l0aW5nIG1vYmlsZSBub2RlIChWTU4pLiAg DQoNCiAgPiANCiAgPiBJZiBub2RlcyBiZWhpbmQgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2Vz cyBsaW5rIHZpYSBQcm94eS1ORCBlYWNoIHRpbWUgTVIgY2hhbmdlcyANCg0KICA+IHRoZSBwb2lu dCBvZiBhdHRhY2htZW50LCBhbGwgb2Ygbm9kZXMgaGF2ZSB0byBkaXJlY3RseSBwcm9jZXNzIGVh Y2ggdGhlaXIgaGFuZG92ZXIoTDMgYWRkcmVzcyBjaGFuZ2VkKS4NCg0KICAgICAgIEFsbCBtb2Jp bGUgbm9kZXMgbmVlZCBub3QgcGFydGljaXBhdGUgaW4gdGhlIFJPIHN1Z2dlc3RlZCBpbiBteSBk cmFmdC4gDQogICAgICAgSG93IGFib3V0IG9ubHkgbW9iaWxlIG5vZGVzIHRoYXQgbmVlZCBSTyBw ZXJmb3JtaW5nIHRoZSBSTz8gDQogICAgICAgUk8gY2FuIGJlIHBlcmZvcm1lZCBvbmx5IGJ5IG1v YmlsZSBub2RlcyB0aGF0IGNhbiB1bmRlcnN0YW5kIHRoZSBleHRlbmRlZCBwcmVmaXggaW5mb3Jt YXRpb24gb3B0aW9uDQoNCiAgICAgICBvZiBSQSBtZXNzYWdlLCBpbmNsdWRpbmcgdGhlIHByZWZp eCBvZiBhIG5ldyBhY2Nlc3MgbmV0d29yay4NCiAgICAgICBJdCBpcyByZWFzb25hYmxlLCBJIHRo aW5rLg0KICAgICAgIEluIGNvbmNsdXNpb24sIGZvciBSTywgZWFjaCBtb2JpbGUgbm9kZSBpcyBy ZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVybiByb3V0YWJpbGl0eSBhbmQgDQogICAgICAg YmluZGluZyB1cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi4NCg0KICA+IA0KICA+IEhvdyBkbyB5 b3UgdGhpbmsgb2YgbXkgcG9pbnQ/DQogID4gSWYgc29tZXRoaW5nIG1pc3NlZCwgcGxlYXNlIGNv cnJlY3QgbWUuIFRoYW5rcy4NCiAgPiAgDQogID4gL0pvbmcNCg0KICAgICAgVGhhbmtzIGZvciB5 b3VyIGludGVyZXN0Lg0KICAgICAgDQoNCiAgICAgIC9KYWVob29uDQoNCiAgPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICA+IEZyb206IG5lbW8tYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpu ZW1vLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFlaG9vbiBKZW9uZw0KICA+IFNlbnQ6 IFN1bmRheSwgSnVuZSAxNSwgMjAwMyAxMjoyNSBQTQ0KICA+IFRvOiBuZW1vQG5hbC5tb3RsYWJz LmNvbQ0KICA+IFN1YmplY3Q6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIGNvbW1lbnRzIG9uIGEg bmV3IFJPIGRyYWZ0DQogID4gIA0KICA+IEhlbGxvLCBuZW1vIGd1eXMhIA0KICA+ICANCiAgPiBJ IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCB0aGUgUm91dGUgT3B0aW1pemF0aW9uIChSTykg Zm9yIG1vYmlsZSBub2RlcyBpbiBtb2JpbGUgbmV0d29yay4gDQogID4gIA0KICA+ICBUaXRsZSA6 IE5ELVByb3h5IGJhc2VkIFJvdXRlIE9wdGltaXphdGlvbiBmb3IgTW9iaWxlIE5vZGVzIGluIE1v YmlsZSBOZXR3b3JrIA0KICA+ICBVUkwgZm9yIHRoZSBEcmFmdCA6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLW5lbW8tcm8tbmRwcm94eS0wMC50eHQgDQog ID4gIA0KICA+IEl0IGlzIGJhc2VkIG9uIE5ELVByb3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxp bmsgc3VibmV0Lg0KICA+IFdoZW5ldmVyIGEgbW9iaWxlIHJvdXRlciBtb3ZlcyBpbnRvIGFub3Ro ZXIgYWNjZXNzIG5ldHdvcmssIA0KICA+IGl0IHByb3ZpZGVzIGl0cyBtb2JpbGUgbmV0d29yayBu b2RlcyB3aXRoIHRoZSBuZXR3b3JrIHByZWZpeCBvZiB0aGUgYWNjZXNzIG5ldHdvcmsuDQogID4g VGhpcyBzY2hlbWUgbWFrZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGFuZCBtb2JpbGUgbmV0d29yayBi ZWNvbWUgYSBtdWx0aS1saW5rIHN1Ym5ldCwgDQogID4gYWxsb3dpbmcgdGhlIGxvY2FsIG9yIHZp c2l0aW5nIG1vYmlsZSBub2RlcyB3aXRoaW4gdGhlIG1vYmlsZSBuZXR3b3JrDQogID4gdG8gcGVy Zm9ybSBiaW5kaW5nIHVwZGF0ZSBmb3Igcm91dGUgb3B0aW1pemF0aW9uLg0KICA+ICANCiAgPiBU aG91Z2ggUk8gaXMgbm90IHRoZSBjdXJyZW50IGlzc3VlIGluIG5lbW8gd2csIEkgdGhpbmssIHRo ZSByZXNlYXJjaCBmb3IgUk8gaXMgaW1wb3J0YW50IGluIG5lbW8uIA0KICA+IFRocm91Z2ggb24t bGluZSBkaXNjdXNzaW9uIGFib3V0IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFy ZSBSTyBpc3N1ZSANCiAgPiB0aGF0IGNhbiBiZSBkaXNjdXNzZWQgaW4gZWFybmVzdCBuZXh0IHll YXIuIA0KICA+IFNvLCBJJ2QgbGlrZSB0byByZXF1ZXN0IHlvdXIgY29tbWVudHMgb24gbXkgZHJh ZnQuIA0KICA+IFRoYW5rcy4gDQogID4gIA0KICA+IFJlZ2FyZHMsIA0KICA+IEphZWhvb24gDQo= ------=_NextPart_000_000B_01C335EB.601BFEE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxN RVRBIGNvbnRlbnQ9V29yZC5Eb2N1bWVudCBuYW1lPVByb2dJZD4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxMCIgbmFtZT1PcmlnaW5hdG9yPjxMSU5LIA0KaHJlZj0iY2lkOmZpbGVsaXN0 LnhtbEAwMUMzMzUwNS5BNzFGNzBCMCIgcmVsPUZpbGUtTGlzdD48bzpTbWFydFRhZ1R5cGUgDQpu YW1lPSJ0aW1lIiANCm5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzIj48L286U21hcnRUYWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9ImRh dGUiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86T2Zm aWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25DU1MvPg0KIDwvbzpPZmZpY2VE b2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0YXRlPkNsZWFuPC93OlNwZWxs aW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFtbWFyU3RhdGU+DQogIDx3 OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4NCiAgPHc6RW52ZWxv cGVWaXMvPg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6 Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9y ZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT5zdDFcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjaWVvb3VpKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPg0KPCEtLQ0KIC8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuuwlO2DlTsN CglwYW5vc2UtMToyIDMgNiAwIDAgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpCYXRhbmc7DQoJ bXNvLWZvbnQtY2hhcnNldDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJ bXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkz IDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ouq1 tOumvDsNCglwYW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1hbHQ6R3Vs aW07DQoJbXNvLWZvbnQtY2hhcnNldDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9k ZXJuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTM0 MjE3NjU5MyAxNzc1NzI5OTE1IDQ4IDAgNTI0NDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBp dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZToxNjI3NDIxMzE5IC0yMTQ3NDgzNjQ4 IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA6rW066a8IjsNCglw YW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOuwlO2DlSI7DQoJcGFub3NlLTE6MiAz IDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTEzNDIxNzY1OTMgMTc3NTcyOTkxNSA0OCAwIDUyNDQ0NyAwO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrqtbTrprw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk66rW066a8O30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk66rW066a8Ow0KCW1zby1hc2NpaS1mb250LWZhbWlseTrqtbTrprw7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk66rW066a8Ow0KCW1zby1oYW5zaS1mb250LWZhbWlseTpBcmlh bDsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCnNwYW4uU3Bl bGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0Kc3Bhbi5HcmFtRQ0K CXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQpAcGFnZSBTZWN0aW9uMQ0K CXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46OTkuMjVwdCAzLjBjbSAzLjBjbSAzLjBj bTsNCgltc28taGVhZGVyLW1hcmdpbjo0Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZw dDsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7 fQ0KLS0+DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFt ZToi7ZGc7KSAIO2RnCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxl LWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wYXJl bnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEt bWFyZ2luOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUtP IHN0eWxlPSJ0YWItaW50ZXJ2YWw6IDQwLjBwdCIgdkxpbms9Ymx1ZSBsaW5rPWJsdWUgYmdDb2xv cj13aGl0ZT4NCjxESVY+PEZPTlQgZmFjZT3qtbTrprwgc2l6ZT0yPklubGluZXMgOi0pPC9GT05U PjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCDqtbTrprwiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgDQog IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IOq1tOumvDsgZm9udC1jb2xv cjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgdGl0bGU9amtuYUBwb3BleWUuc251LmFjLmty IGhyZWY9Im1haWx0bzpqa25hQHBvcGV5ZS5zbnUuYWMua3IiPk5hLCBKb25nIA0KICBLZXVuPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCDqtbTrprwiPjxCPlRvOjwvQj4gPEEg dGl0bGU9cGF1bEBldHJpLnJlLmtyIA0KICBocmVmPSJtYWlsdG86cGF1bEBldHJpLnJlLmtyIj4n SmFlaG9vbiBKZW9uZyc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IOq1tOum vCI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1uZW1vQG5hbC5tb3RsYWJzLmNvbSANCiAgaHJlZj0ibWFp bHRvOm5lbW9AbmFsLm1vdGxhYnMuY29tIj4nTkVNTyBXRyc8L0E+IDsgPEEgdGl0bGU9cGpzQGV0 cmkucmUua3IgDQogIGhyZWY9Im1haWx0bzpwanNAZXRyaS5yZS5rciI+J+uwleygleyImCc8L0E+ IDsgPEEgdGl0bGU9a2hqQGV0cmkucmUua3IgDQogIGhyZWY9Im1haWx0bzpraGpAZXRyaS5yZS5r ciI+J+q5gO2YleykgCc8L0E+IDsgPEEgdGl0bGU9bGVla2pAZXRyaS5yZS5rciANCiAgaHJlZj0i bWFpbHRvOmxlZWtqQGV0cmkucmUua3IiPifsnbTqsr3sp4QnPC9BPiA7IDxBIHRpdGxlPXNreWxh bmVAZXRyaS5yZS5rciANCiAgaHJlZj0ibWFpbHRvOnNreWxhbmVAZXRyaS5yZS5rciI+J+q5gOuz keyXvSc8L0E+IDsgPEEgdGl0bGU9amFmeUBldHJpLnJlLmtyIA0KICBocmVmPSJtYWlsdG86amFm eUBldHJpLnJlLmtyIj4n7LCo7ZiE7JqxJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDEwcHQg6rW066a8Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwgSnVuZSAxNywgMjAwMyA3OjIxIFBN PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW066a8Ij48Qj5TdWJqZWN0OjwvQj4g UkU6IFtuZW1vXSBSZXF1ZXN0IGZvciB5b3VyIA0KICBjb21tZW50cyBvbiBhIG5ldyBSTyBkcmFm dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28t aGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkhp IA0KICA8U1BBTiBjbGFzcz1TcGVsbEU+SmFlaG9vbjwvU1BBTj4sIDxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1z by1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+ VGhhbmtzIA0KICBmb3IgeW91ciBxdWljayByZXBseS48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9 RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2kt Zm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkF0IA0KICB0 aGVzZSBkYXlzLCBJPC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1hc2NpaS1mb250LWZhbWlseTog6rW066a8Ij7i gJk8L1NQQU4+PC9GT05UPjxGT05UIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZv bnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5tIA0KICBjb25z aWRlcmluZyBob3cgdG8gc29sdmUgdGhlIG5lc3RlZCB0dW5uZWxzIHByb2JsZW0uPC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij4tJmd0OyZuYnNwO0l0IA0KICBpcyBpbXBvcnRhbnQmbmJzcDt0byBzb2x2ZSB0aGUgcHJvYmxl bSwgSSBhZ3JlZS48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlk aS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFy aWFsIj5JTUhPLCANCiAgdGhpcyBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24gaXMgdmVyeSBp bXBvcnRhbnQgaW4gdGhlIGFyZWEgb2YgTkVNTyBSTyANCiAgcHJvYmxlbS48bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwg Y29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiBBcmlhbCI+SW4gDQogIHRoaXMgYXNwZWN0LCBJIHRoaW5rIGl0IGlzIG5l ZWRlZCB0byBjb25zaWRlciB0aGlzIGtpbmQgb2Ygb3B0aW1pemF0aW9uIGluIA0KICB5b3VyIGRy YWZ0LjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+LSZndDsgDQogIEluIHRoaXMgcmVzcGVjdCwgSSBk aXNhZ3JlZS48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFs OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgQmVjYXVzZSBteSBzY2hlbWUgaXMgYmFzZWQgb24gbXVsdGktbGluayBzdWJuZXQsIHRoZXJl IGhhcHBlbnMgbm8gbmVzdGVkIA0KICB0dW5uZWwgcHJvYmxlbTwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7 IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlh bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBmb3IgbW9iaWxlIG5vZGVzIHdpdGhpbiBO RU1PLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86cD48L286cD48L1NQQU4+PC9GT05UPiZuYnNw OzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWls eTogQXJpYWwiPkhvdyANCiAgYWJvdXQgPFNQQU4gY2xhc3M9U3BlbGxFPk1SczwvU1BBTj4gPFNQ QU4gY2xhc3M9R3JhbUU+ZG88L1NQQU4+IE5ELXByb3h5IGJhc2VkIA0KICBSTyBhYm91dCB0aGVp ciBlZ3Jlc3MgaW50ZXJmYWNlPzwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZh bWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+LSZndDsgDQogIEluIG15 IGRyYWZ0LCBsaWtlIHlvdXIgc3VnZ2VzdGlvbiwgTVJzIHBsYXlzIHRoZSByb2xlIG9mIE5ELXBy b3h5IGZvciB0aGVpciANCiAgb3duIGVncmVzcyBpbnRlcmZhY2UgYW5kPC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IEFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHBsYXlzIHRoZSBub3JtYWwgcm91 dGVyIGZvciB0aGVpciBvd24gaW5ncmVzcyBpbnRlcmZhY2UuPC9TUEFOPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFJlZmVyIHRvICJNdWx0aS1saW5rIFN1Ym5l dCBTdXBwb3J0IGluIElQdjYiIGRyYWZ0IGZvciBkZXRhaWxlZCANCiAgbWVjaGFuaXNtLjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZv bnQtZmFtaWx5OiBBcmlhbCI+PEZPTlQgDQogIGNvbG9yPSMwMDAwMDA+Jm5ic3A7PC9GT05UPiZu YnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBjb2xvcj0jMDAwMDAwPjxBIA0KICBocmVmPSJodHRwOi8v d3d3LmFtYXJhbnRobmV0d29ya3MuY29tL2lldGYvZHJhZnRzL2RyYWZ0LWlldGYtaXB2Ni1tdWx0 aWxpbmstc3VibmV0cy0wMC50eHQiPmh0dHA6Ly93d3cuYW1hcmFudGhuZXR3b3Jrcy5jb20vaWV0 Zi9kcmFmdHMvZHJhZnQtaWV0Zi1pcHY2LW11bHRpbGluay1zdWJuZXRzLTAwLnR4dDwvQT48L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1 tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNv LWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiBBcmlhbCI+SWYgDQogIE1SIGNhbiBkbyB0aGF0LCB0aGUgbm9kZXMgYmVoaW5kIE1SIHdpbGwg Z2V0IHRoZSBlZmZlY3Qgb2YgbmVzdGVkIHR1bm5lbHMgDQogIG9wdGltaXphdGlvbi48bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3q tbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1z by1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+VGhlcmUgDQogIHdpbGwgYmUgbm8gbW9yZSBuZXN0 ZWQgdHVubmVsIGlmIDxTUEFOIGNsYXNzPVNwZWxsRT48U1BBTiANCiAgY2xhc3M9R3JhbUU+TVJz PC9TUEFOPjwvU1BBTj4gdXNlIG9uZSBhZGRyZXNzIGFsbG9jYXRlZCBpbiBhY2Nlc3MgbGluayBw cmVmaXggDQogIGFzIHRoZWlyIDxTUEFOIGNsYXNzPVNwZWxsRT5Db0E8L1NQQU4+IG9mIHRoZSBl Z3Jlc3MgaW50ZXJmYWNlIGFuZCA8U1BBTiANCiAgY2xhc3M9U3BlbGxFPk1SczwvU1BBTj4gb24g dGhlIHBhdGggb3BlcmF0ZSBpbiBORC1Qcm94eSBtb2RlLiANCiAgPC9TUEFOPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFy aWFsIj4tJmd0OyANCiAgUmlnaHQuIEJlY2F1c2UmbmJzcDt0aGVyZSZuYnNwO2FyZSBubyBuZXN0 ZWQgdHVubmVscyBiZXR3ZWVuIHJvb3QtTVIgYW5kIA0KICBzdWItTVImbmJzcDtvd2luZyB0byZu YnNwO211bHRpLWxpbmsgc3VibmV0LDwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250 LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIA0KICBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24gaXMg bm90IHJlbGF0ZWQgdG8gbXkgc2hlbWUuIFRoZXJlZm9yZSwgbXkgc2NoZW1lIA0KICBuZWVkIG5v dCBjb25zaWRlcjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJp YWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIA0KICBuZXN0ZWQgdHVubmVscyBvcHRpbWl6YXRpb24uPC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPkkgDQogIHRoaW5rIGl0PC9TUEFO PjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t VVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTog QXJpYWw7IG1zby1hc2NpaS1mb250LWZhbWlseTog6rW066a8Ij7igJk8L1NQQU4+PC9GT05UPjxG T05UIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsg bXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5zIA0KICBwb3NzaWJsZSB0aGlzIGFwcHJvYWNo IGNhbiBiZSBhIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdGhlIG5lc3RlZCB0dW5uZWxzIA0KICBv cHRpbWl6YXRpb24gYWxyZWFkeSB0b3VjaGVkIGJ5IFJSSC1iYXNlZCBhbmQgQVJPLWJhc2VkIHBy b3Bvc2VkIHNvbHV0aW9ucywgDQogIGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBzb21lIGFyZ3VtZW50 cyBvbiB0aGUgZ2VuZXJhbCBmZWFzaWJpbGl0eSBvZiBORC1wcm94eSANCiAgYmFzZWQgc29sdXRp b24uPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PEZPTlQgDQogIGNvbG9y PSMwMDAwMDA+LSZndDsgSSBhZ3JlZS4gSSBhbSB0aGlua2luZyB0aGUgc2NhbGFiaWxpdHkgb2Yg bXkgc2NoZW1lIA0KICBub3cuPC9GT05UPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1o YW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86 cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEkmbmJzcDt0aGluayBteSBzY2hlbWUgaXMg dXNlZnVsIGZvciBhIGZldyBsZXZlbCBORU1PLCBub3QgZGVlcCBsZXZlbCANCk5FTU8uPC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBB cmlhbCI+PG86cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEZvciBleGFtcGxlLCBpdCB3 aWxsIGJlIHVzZWQgZm9yIE5FTU8gd2l0aGluIEludGVybmV0IGNhciBhbmQgDQogIGJ1cy48L286 cD48L1NQQU4+PC9GT05UPjwvUD48L286cD48L1NQQU4+PC9GT05UPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1oYW5zaS1m b250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86cD4mbmJz cDsmbmJzcDsmbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPeq1tOumvCBj b2xvcj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U96rW066a8IGNvbG9yPW5hdnkgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBt c28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFt aWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj5EbyANCiAgeW91IHRoaW5r IG9mIHRoaXMgb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlPyBQbGVhc2UgbGV0IG1lIGtub3cgeW91 ciBvcGluaW9uLiANCiAgVGhhbmtzLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFs Ij48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U96rW066a8IGNvbG9yPSMw MDAwMDAgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250 LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsIj4v PFNQQU4gDQogIGNsYXNzPVNwZWxsRT5Kb25nPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1p bHk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3qtbTrprwgY29sb3I9IzAwMDAwMCBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IG1zby1o YW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbCI+PG86 cD4tJmd0OyANCiAgVGhhbmtzIGZvciB5b3VyIGdvb2QgY29tbWVudHMuPC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xvcj0j MDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBjb2xv cj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgL0ph ZWhvb248L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U96rW066a8IGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPeq1tOumvCBj b2xvcj0jMDAwMDAwIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IEFyaWFsIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsg bXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogVGFob21hIj4tLS0tLU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+PEI+PFNQQU4gc3R5 bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Gcm9tOjwvU1BBTj48L0I+IA0KICBuZW1vLWFkbWluQGll dGYub3JnIFttYWlsdG86bmVtby1hZG1pbkBpZXRmLm9yZ10gPEI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVdFSUdIVDogYm9sZCI+T24gQmVoYWxmIE9mIDwvU1BBTj48L0I+SmFlaG9vbiBKZW9uZzxC Uj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+ IE1vbmRheSwgSnVuZSAxNiwgMjAwMyAzOjUxIA0KICBQTTxCUj48Qj48U1BBTiBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IE5hLCBKb25nIA0KICBLZXVuPEJSPjxCPjxT UEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gTkVNTyBXRzsgDQog IDwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IFRhaG9tYTsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBUYWhvbWEiPuuwleygleyImDwvU1BBTj48 L0ZPTlQ+PEZPTlQgDQogIGZhY2U9VGFob21hIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj47IDwvU1BBTj48L0ZP TlQ+PEZPTlQgDQogIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiBUYWhvbWE7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBUYWhvbWE7 IG1zby1hc2NpaS1mb250LWZhbWlseTogVGFob21hIj7quYDtmJXspIA8L1NQQU4+PC9GT05UPjxG T05UIA0KICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+OyA8L1NQQU4+PC9GT05UPjxGT05U IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1oYW5zaS1m b250LWZhbWlseTogVGFob21hOyBtc28tYmlkaS1mb250LWZhbWlseTogVGFob21hOyBtc28tYXNj aWktZm9udC1mYW1pbHk6IFRhaG9tYSI+7J206rK97KeEPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAg ZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPjsgPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28taGFuc2ktZm9udC1mYW1p bHk6IFRhaG9tYTsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OiBUYWhvbWEiPuq5gOuzkeyXvTwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9VGFo b21hIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogVGFob21hIj47IDwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mj48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBUYWhv bWE7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBUYWhvbWE7IG1zby1hc2NpaS1mb250LWZhbWlseTog VGFob21hIj7ssKjtmITsmrE8L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPVRhaG9tYSBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IFRhaG9tYSI+OyA8L1NQQU4+PC9GT05UPjxGT05UIA0KICBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1oYW5zaS1mb250LWZhbWlseTogVGFob21hOyBtc28t YmlkaS1mb250LWZhbWlseTogVGFob21hOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFRhaG9tYSI+ 7KCV7J6s7ZuIPC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhv bWEiPjxCUj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0Ojwv U1BBTj48L0I+IFJlOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciANCiAgY29tbWVudHMgb24gYSBu ZXcgUk8gZHJhZnQ8L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBz dHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2Qi PjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg PERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1 cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBz aXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5IaSwgSm9uZyAN CiAgS2V1bi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBh cmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BB TiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5pbmxpbmVzOi0pPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0 OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48QlI+Jmd0OyAtLS0tLSBPcmlnaW5hbCANCiAgTWVzc2Fn ZSAtLS0tLSA8QlI+Jmd0OyBGcm9tOiBOYSwgSm9uZyBLZXVuIDxCUj4mZ3Q7IFRvOiAnSmFlaG9v biBKZW9uZycgOyANCiAgbmVtb0BuYWwubW90bGFicy5jb20gPEJSPiZndDsgU2VudDogPC9TUEFO PjwvRk9OVD48c3QxOmRhdGUgWWVhcj0iMjAwMyIgDQogIERheT0iMTYiIE1vbnRoPSI2Ij48U1BB TiBsYW5nPUVOLVVTPk1vbmRheSwgSnVuZSAxNiwgDQogIDIwMDM8L1NQQU4+PC9zdDE6ZGF0ZT48 U1BBTiBsYW5nPUVOLVVTPiA8L1NQQU4+PHN0MTp0aW1lIE1pbnV0ZT0iMTUiIA0KICBIb3VyPSIx MCI+PFNQQU4gbGFuZz1FTi1VUz4xMDoxNSBBTTwvU1BBTj48L3N0MTp0aW1lPjxTUEFOIGxhbmc9 RU4tVVM+PEJSPiZndDsgDQogIFN1YmplY3Q6IFJFOiBbbmVtb10gUmVxdWVzdCBmb3IgeW91ciBj b21tZW50cyBvbiBhIG5ldyBSTyANCiAgZHJhZnQ8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSGkg SmFlaG9vbiw8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7IEkgaGF2ZSBhIA0KICBjb25jZXJuIGluIHlv dXIgZHJhZnQuPEJSPiZndDsgSXMgaXQgcmlnaHQgZGlyZWN0aW9uIHRvIGdpdmUgdGhlIGJ1cmRl biBvZiANCiAgbW9iaWxpdHkgbWFuYWdlbWVudCB0byBlYWNoIE1OTnMsIG5vdCBNUnM/PEJSPjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIFJvdXRlIA0KICBPcHRpbWl6YXRpb24gKFJPKSwgSSB0 aGluaywgZWFjaCBNTk4gKFZNTiBvciBMTU4pIHNob3VsZCBwZXJmb3JtIA0KICA8bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzOS45NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy4zM2dkIj48 Rk9OVCBmYWNlPeq1tOumvCANCiAgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIA0KICBtb2JpbGl0eSBtYW5h Z2VtZW50IHJlbGF0ZWQgdG8gUk8uPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JlY2F1c2Ug Uk8gdXNlcyANCiAgdGhlIGFjY2VzcyBuZXR3b3JrIGRpcmVjdGx5LCBlYWNoIG1vYmlsZSBub2Rl IGlzIGVmZmljaWVudCB0byBwZXJmb3JtIGl0cyANCiAgUk88bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQg ZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8U1BBTiANCiAgY2xhc3M9R3JhbUU+aW48L1NQQU4+ IHRoZSBzYW1lJm5ic3A7bWFubmVyIGFzIE1JUHY2LiANCiAgPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0i TUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxTUEFO IA0KICBjbGFzcz1HcmFtRT48Rk9OVCBmYWNlPeq1tOumvCBzaXplPTM+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IA0KICA8QlI+Jmd0OzwvU1BBTj48L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+IFRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgSW4g DQogIE5FTU8sIGl04oCZcyBhIGJhc2ljIHByaW5jaXBhbCBmb3IgTVIgdG8gbWFuYWdlIHRoZSBt b2JpbGl0eSBvZiA8QlI+Jmd0OyBtb2JpbGUgDQogIG5ldHdvcmsgdHJhbnNwYXJlbnRseSB0byBu b2RlcyBiZWhpbmQgaXQuPEJSPiZndDsmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBP bmx5IHdoZW4gUk8gaXMgZXhjbHVkZWQgaW4gTkVOTyBvcGVyYXRpb24sIGl0IGlzIA0KICByaWdo dC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIGxvY2FsIGZpeGVkIG5vZGUgKExGTiks IHRoZSBtb2JpbGl0eSBvZiANCiAgTkVNTyBpcyBzdGlsbCB0cmFuc3BhcmVudC48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzOS45NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy4zM2dkIj48 Rk9OVCBmYWNlPeq1tOumvCANCiAgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzY29wZSANCiAgb2YgUk8gb2YgbXkg ZHJhZnQgaXMgZm9yIG1vYmlsZSBub2RlcywgZWl0aGVyIGxvY2FsIG1vYmlsZSBub2RlIA0KICAo TE1OKSZuYnNwO29yJm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAg PERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1 cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBz aXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgdmlzaXRpbmcgDQogIG1vYmlsZSZuYnNwO25vZGUgKFZNTikuJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdp bi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IDxCUj4mZ3Q7IElmIG5vZGVzIGJlaGlu ZCANCiAgTVIgZ2V0IG5ldyBDb0Egb2YgdGhlIGFjY2VzcyBsaW5rIHZpYSBQcm94eS1ORCBlYWNo IHRpbWUgTVIgY2hhbmdlcyANCiAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5 Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0K ICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mZ3Q7IHRo ZSBwb2ludCBvZiBhdHRhY2htZW50LCANCiAgYWxsIG9mIG5vZGVzIGhhdmUgdG8gZGlyZWN0bHkg cHJvY2VzcyBlYWNoIHRoZWlyIGhhbmRvdmVyKEwzIGFkZHJlc3MgDQogIGNoYW5nZWQpLjxCUj48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO0FsbCBtb2JpbGUgbm9kZXMgbmVlZCBub3QgDQog IHBhcnRpY2lwYXRlIGluIHRoZSBSTyBzdWdnZXN0ZWQgaW4gbXkgZHJhZnQuIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSG93IA0KICBhYm91dCBvbmx5IG1vYmlsZSBub2RlcyB0aGF0IG5l ZWQgUk8gcGVyZm9ybWluZyB0aGUgUk8/IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJPIGNhbiBiZSBwZXJmb3JtZWQgb25seSBieSBtb2JpbGUgbm9kZXMgdGhhdCBjYW4gDQogIHVu ZGVyc3RhbmQgdGhlIGV4dGVuZGVkIHByZWZpeCBpbmZvcm1hdGlvbiANCiAgb3B0aW9uPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM5Ljk1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0 OiAzLjMzZ2QiPjxGT05UIGZhY2U96rW066a8IA0KICBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7b2YgUkEgDQog IG1lc3NhZ2UsIGluY2x1ZGluZyB0aGUgcHJlZml4IG9mIGEgbmV3IGFjY2VzcyANCiAgbmV0d29y ay48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlYXNvbmFibGUsIEkgDQogIHRo aW5rLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gY29uY2x1c2lvbiwgZm9yIFJPLCBl YWNoIG1vYmlsZSBub2RlIGlzIA0KICByZWFzb25hYmxlIHRvIHBlcmZvcm0gaXRzIHJldHVybiBy b3V0YWJpbGl0eSBhbmQgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgYmluZGluZyB1 cGRhdGUgcHJvY2VkdXJlIGJ5IGl0c2VsZi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwv RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU4tTEVG VDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuMzNnZCI+PEZPTlQgZmFjZT3qtbTr prwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZn dDsgPEJSPiZndDsgSG93IGRvIHlvdSB0aGluayANCiAgb2YgbXkgcG9pbnQ/PEJSPiZndDsgSWYg c29tZXRoaW5nIG1pc3NlZCwgcGxlYXNlIGNvcnJlY3QgbWUuIA0KICBUaGFua3MuPEJSPiZndDsm bmJzcDsmbmJzcDs8QlI+Jmd0OyAvSm9uZzxCUj48QlI+Jm5ic3A7Jm5ic3A7ICZuYnNwO1RoYW5r cyBmb3IgDQogIHlvdXIgaW50ZXJlc3QuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwg DQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMzkuOTVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMu MzNnZCI+PEZPTlQgZmFjZT3qtbTrprwgDQogIHNpemU9Mz48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgL0phZWhvb248QlI+PEJS PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiANCiAgbmVtby1h ZG1pbkBpZXRmLm9yZyBbbWFpbHRvOm5lbW8tYWRtaW5AaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK YWVob29uIA0KICBKZW9uZzxCUj4mZ3Q7IFNlbnQ6IDwvU1BBTj48L0ZPTlQ+PHN0MTpkYXRlIFll YXI9IjIwMDMiIERheT0iMTUiIA0KICBNb250aD0iNiI+PFNQQU4gbGFuZz1FTi1VUz5TdW5kYXks IEp1bmUgMTUsIDIwMDM8L1NQQU4+PC9zdDE6ZGF0ZT48U1BBTiANCiAgbGFuZz1FTi1VUz4gPC9T UEFOPjxzdDE6dGltZSBNaW51dGU9IjI1IiBIb3VyPSIxMiI+PFNQQU4gbGFuZz1FTi1VUz4xMjoy NSANCiAgUE08L1NQQU4+PC9zdDE6dGltZT48U1BBTiBsYW5nPUVOLVVTPjxCUj4mZ3Q7IFRvOiBu ZW1vQG5hbC5tb3RsYWJzLmNvbTxCUj4mZ3Q7IA0KICBTdWJqZWN0OiBbbmVtb10gUmVxdWVzdCBm b3IgeW91ciBjb21tZW50cyBvbiBhIG5ldyBSTyANCiAgZHJhZnQ8QlI+Jmd0OyZuYnNwOyZuYnNw OzxCUj4mZ3Q7IEhlbGxvLCBuZW1vIGd1eXMhIA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4m Z3Q7IEkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHRoZSBSb3V0ZSANCiAgT3B0aW1pemF0 aW9uIChSTykgZm9yIG1vYmlsZSBub2RlcyBpbiBtb2JpbGUgbmV0d29yay4gDQogIDxCUj4mZ3Q7 Jm5ic3A7Jm5ic3A7PEJSPiZndDsmbmJzcDsmbmJzcDtUaXRsZSA6IE5ELVByb3h5IGJhc2VkIFJv dXRlIA0KICBPcHRpbWl6YXRpb24gZm9yIE1vYmlsZSBOb2RlcyBpbiBNb2JpbGUgTmV0d29yayA8 QlI+Jmd0OyZuYnNwOyZuYnNwO1VSTCBmb3IgDQogIHRoZSBEcmFmdCA6IA0KICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDAu dHh0IA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOzxCUj4mZ3Q7IEl0IGlzIGJhc2VkIG9uIE5ELVBy b3h5IGZvciBzdXBwb3J0aW5nIG11bHRpLWxpbmsgDQogIHN1Ym5ldC48QlI+Jmd0OyBXaGVuZXZl ciBhIG1vYmlsZSByb3V0ZXIgbW92ZXMgaW50byBhbm90aGVyIGFjY2VzcyBuZXR3b3JrLCANCiAg PEJSPiZndDsgaXQgcHJvdmlkZXMgaXRzIG1vYmlsZSBuZXR3b3JrIG5vZGVzIHdpdGggdGhlIG5l dHdvcmsgcHJlZml4IG9mIHRoZSANCiAgYWNjZXNzIG5ldHdvcmsuPEJSPiZndDsgVGhpcyBzY2hl bWUgbWFrZXMgdGhlIGFjY2VzcyBuZXR3b3JrIGFuZCBtb2JpbGUgDQogIG5ldHdvcmsgYmVjb21l IGEgbXVsdGktbGluayBzdWJuZXQsIDxCUj4mZ3Q7IGFsbG93aW5nIHRoZSBsb2NhbCBvciB2aXNp dGluZyANCiAgbW9iaWxlIG5vZGVzIHdpdGhpbiB0aGUgbW9iaWxlIG5ldHdvcms8QlI+Jmd0OyB0 byBwZXJmb3JtIGJpbmRpbmcgdXBkYXRlIGZvciANCiAgcm91dGUgb3B0aW1pemF0aW9uLjxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7PEJSPiZndDsgVGhvdWdoIFJPIGlzIG5vdCB0aGUgY3VycmVudCANCiAg aXNzdWUgaW4gbmVtbyB3ZywgSSB0aGluaywgdGhlIHJlc2VhcmNoIGZvciBSTyBpcyBpbXBvcnRh bnQgaW4gbmVtby4gPEJSPiZndDsgDQogIFRocm91Z2ggb24tbGluZSBkaXNjdXNzaW9uIGFib3V0 IFJPLCBpdCBtYXkgYmUgZ29vZCBmb3IgdXMgdG8gcHJlcGFyZSBSTyBpc3N1ZSANCiAgPEJSPiZn dDsgdGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIGVhcm5lc3QgbmV4dCB5ZWFyLiA8QlI+Jmd0OyBT bywgSSdkIGxpa2UgdG8gDQogIHJlcXVlc3QgeW91ciBjb21tZW50cyBvbiBteSBkcmFmdC4gPEJS PiZndDsgVGhhbmtzLiANCiAgPEJSPiZndDsmbmJzcDsmbmJzcDs8QlI+Jmd0OyBSZWdhcmRzLCA8 QlI+Jmd0OyBKYWVob29uIA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000B_01C335EB.601BFEE0-- From nemo-admin@ietf.org Thu Jun 19 03:01:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02591 for ; Thu, 19 Jun 2003 03:01:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19StCH-0005qK-Oy; Thu, 19 Jun 2003 02:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sszq-0004zA-S3 for nemo@optimus.ietf.org; Thu, 19 Jun 2003 02:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01133 for ; Thu, 19 Jun 2003 02:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SsxY-0007cW-00 for nemo@ietf.org; Thu, 19 Jun 2003 02:31:48 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19SsxX-0007cS-00 for nemo@ietf.org; Thu, 19 Jun 2003 02:31:47 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Thu, 19 Jun 2003 16:34:01 +1000 From: "Muhammad Ali Malik" To: Date: Thu, 19 Jun 2003 16:33:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C33680.8EEF7F40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [nemo] Signal secured over bi-directional tunnel .... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C33680.8EEF7F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Why there is a need to secure signal traveling over bi-directional tunnel. By signal, u means any control signal. ~Muhammad Ali Malik ------=_NextPart_000_0010_01C33680.8EEF7F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Why there is a need to secure signal traveling over = bi-directional tunnel. By signal, u means any control = signal.

 

~Muhammad Ali Malik

------=_NextPart_000_0010_01C33680.8EEF7F40-- From exim@www1.ietf.org Thu Jun 19 03:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03144 for ; Thu, 19 Jun 2003 03:17:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J7H5i26942 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 03:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19StQ0-0006Gn-UQ for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 03:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02587 for ; Thu, 19 Jun 2003 03:01:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19StNi-0000EB-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 02:58:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19StNh-0000E8-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 02:58:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19StCH-0005qK-Oy; Thu, 19 Jun 2003 02:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sszq-0004zA-S3 for nemo@optimus.ietf.org; Thu, 19 Jun 2003 02:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01133 for ; Thu, 19 Jun 2003 02:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SsxY-0007cW-00 for nemo@ietf.org; Thu, 19 Jun 2003 02:31:48 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19SsxX-0007cS-00 for nemo@ietf.org; Thu, 19 Jun 2003 02:31:47 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Thu, 19 Jun 2003 16:34:01 +1000 From: "Muhammad Ali Malik" To: Date: Thu, 19 Jun 2003 16:33:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C33680.8EEF7F40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [nemo] Signal secured over bi-directional tunnel .... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C33680.8EEF7F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Why there is a need to secure signal traveling over bi-directional tunnel. By signal, u means any control signal. ~Muhammad Ali Malik ------=_NextPart_000_0010_01C33680.8EEF7F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Why there is a need to secure signal traveling over = bi-directional tunnel. By signal, u means any control = signal.

 

~Muhammad Ali Malik

------=_NextPart_000_0010_01C33680.8EEF7F40-- From nemo-admin@ietf.org Thu Jun 19 16:06:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15953 for ; Thu, 19 Jun 2003 16:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fV-0004IB-A9; Thu, 19 Jun 2003 16:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5eq-0004Hl-2H for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15906 for ; Thu, 19 Jun 2003 16:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5cX-0002lL-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:02:57 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5cW-0002lH-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:02:56 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK5YER023022 for ; Thu, 19 Jun 2003 13:05:34 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:15 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EDFBDB1.7B0737EF@kniveton.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, The subject of IPR has come up on the design team mailing list and we had a discussion about it. In the interests of full disclosure to the whole NEMO group, I would like to also present these messages here on the main list so everybody can know what's going on. I have checked with the DT mailing list members and no one has objected to this, so I will forward the messages here for anyone who's interested. thanks, TJ ------ Forwarded Message From: "T.J. Kniveton" Date: Thu, 05 Jun 2003 15:01:21 -0700 To: nemo-base-dt@nal.motlabs.com Subject: [nemo-base-dt] IPRs on base solution Hi all, This subject came up last week and I would like to say a little more on it so we can get as full a picture as possible. As was already mentioned, Cisco asserted they may have IPR which may affect draft-kniveton-mobrtr-02. I talked with their patent attorney via e-mail, and I was not able to get a full picture of exactly what their IPR claims would cover. Apparently they have not yet been issued patents on this, but it appears to spring out of their earlier Mobile IPv4-based mobile router work a couple of years ago. In addition, I need to remind people that we at Nokia have IPR that would apply to a basic mobile router solution, as was disclosed when the draft was submitted. As far as I personally know, both Nokia and Cisco have IETF policies that allow free licensing as long as reciprocity is granted, and are mainly defensive postures. I have contacted our own patent attorneys to get a better statement regarding this Nokia IPR that applies to mobile routers. I know there are a lot of concerns about IPR, and it is hard to be totally sure what the situation is. I don't know about others who may have any IPR claims on mobile routers, but I just want to share my knowledge as soon as possible, which the is all the info I have right now. When I hear back from our lawyers I'll give an update. -TJ ------ End of Forwarded Message From exim@www1.ietf.org Thu Jun 19 16:06:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15968 for ; Thu, 19 Jun 2003 16:06:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JK6BU16561 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 16:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5ff-0004J2-9x for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 16:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15937 for ; Thu, 19 Jun 2003 16:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5dM-0002lk-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:03:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T5dM-0002lg-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fV-0004IB-A9; Thu, 19 Jun 2003 16:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5eq-0004Hl-2H for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15906 for ; Thu, 19 Jun 2003 16:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5cX-0002lL-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:02:57 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5cW-0002lH-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:02:56 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK5YER023022 for ; Thu, 19 Jun 2003 13:05:34 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:15 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EDFBDB1.7B0737EF@kniveton.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, The subject of IPR has come up on the design team mailing list and we had a discussion about it. In the interests of full disclosure to the whole NEMO group, I would like to also present these messages here on the main list so everybody can know what's going on. I have checked with the DT mailing list members and no one has objected to this, so I will forward the messages here for anyone who's interested. thanks, TJ ------ Forwarded Message From: "T.J. Kniveton" Date: Thu, 05 Jun 2003 15:01:21 -0700 To: nemo-base-dt@nal.motlabs.com Subject: [nemo-base-dt] IPRs on base solution Hi all, This subject came up last week and I would like to say a little more on it so we can get as full a picture as possible. As was already mentioned, Cisco asserted they may have IPR which may affect draft-kniveton-mobrtr-02. I talked with their patent attorney via e-mail, and I was not able to get a full picture of exactly what their IPR claims would cover. Apparently they have not yet been issued patents on this, but it appears to spring out of their earlier Mobile IPv4-based mobile router work a couple of years ago. In addition, I need to remind people that we at Nokia have IPR that would apply to a basic mobile router solution, as was disclosed when the draft was submitted. As far as I personally know, both Nokia and Cisco have IETF policies that allow free licensing as long as reciprocity is granted, and are mainly defensive postures. I have contacted our own patent attorneys to get a better statement regarding this Nokia IPR that applies to mobile routers. I know there are a lot of concerns about IPR, and it is hard to be totally sure what the situation is. I don't know about others who may have any IPR claims on mobile routers, but I just want to share my knowledge as soon as possible, which the is all the info I have right now. When I hear back from our lawyers I'll give an update. -TJ ------ End of Forwarded Message From nemo-admin@ietf.org Thu Jun 19 16:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16038 for ; Thu, 19 Jun 2003 16:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gT-0004Z7-36; Thu, 19 Jun 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fn-0004JN-LQ for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15942 for ; Thu, 19 Jun 2003 16:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5dU-0002lt-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:56 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5dT-0002lU-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:55 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK5nER023026 for ; Thu, 19 Jun 2003 13:05:49 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:29 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EE0579B.1020809@nal.motlabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Alexandru Petrescu Date: Fri, 06 Jun 2003 10:58:03 +0200 To: "T.J. Kniveton" Cc: nemo-base-dt@nal.motlabs.com Subject: Re: [nemo-base-dt] IPRs on base solution Hello TJ, thank you for the update. > I know there are a lot of concerns about IPR, and it is hard to be > totally sure what the situation is. Exactly, that fits my view too; it is hard for me to find out what the best practice at IETF is. Please allow me to take one possible aspect of the situation. I'm not claiming that this is covering entirely the IPR issues, it is just one possibility. I've heard some people at IETF saying that WG's and the IESG are trying to stay away from anything that is "encumbered". (more specifically, a Mobile IP WG co-chair wrote in private; at last manet WG meeting an IESG member said that people in IESG are trying to avoid "encumbered" drafts; and a Mobile IP WG member who wrote on the list saying he doesn't "want to become a lawyer" when I suggested him that defensive IPR's are probably not very bad). So that resumes my understanding of one possible aspect of how IPR and IETF. It might very well be that my interpretation is wrong, and I'm in no position to make knowledgeable claims. So, if I take that reasoning, may I... > IPR that would apply to a basic mobile router solution, as was > disclosed when the draft was submitted. May I ask what parts of the draft would fit perfectly in the most important claims of the IPR document. For example, would the echo req/rep technique be protected by the claims in that IPR? If yes, then that is very good news, because I think we previously discussed that it is not that relevant for the base solution, so that IPR claim would not harm at all. Overall, _if_ existing IPR on a draft represents a problem for that draft's advancement, maybe identifying which part of the draft is protected and re-writing it, might be a good solution. If, on the other hand, it is acknowledged that defensive IPR's on a draft is ok, then no need to get rid of that IPR. Thanks, Alex ------ End of Forwarded Message From nemo-admin@ietf.org Thu Jun 19 16:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16053 for ; Thu, 19 Jun 2003 16:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gT-0004a9-NZ; Thu, 19 Jun 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fn-0004JS-TV for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15943 for ; Thu, 19 Jun 2003 16:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5dV-0002lu-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:57 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5dT-0002lV-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:56 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK6BER023029 for ; Thu, 19 Jun 2003 13:06:12 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:52 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EE757C6.D222D8DE@kniveton.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ------ Forwarded Message From: "T.J. Kniveton" Date: Wed, 11 Jun 2003 09:24:38 -0700 To: Alexandru Petrescu Cc: nemo-base-dt@nal.motlabs.com Subject: Re: [nemo-base-dt] IPRs on base solution Alexandru Petrescu wrote: > > Hello TJ, thank you for the update. > > > I know there are a lot of concerns about IPR, and it is hard to be > > totally sure what the situation is. > > Exactly, that fits my view too; it is hard for me to find out what the > best practice at IETF is. > > Please allow me to take one possible aspect of the situation. I'm not > claiming that this is covering entirely the IPR issues, it is just one > possibility. I've heard some people at IETF saying that WG's and the > IESG are trying to stay away from anything that is "encumbered". (more > specifically, a Mobile IP WG co-chair wrote in private; at last manet WG > meeting an IESG member said that people in IESG are trying to > avoid "encumbered" drafts; and a Mobile IP WG member who wrote on the > list saying he doesn't "want to become a lawyer" when I suggested him > that defensive IPR's are probably not very bad). Yes, we can see that this is an unchartered area and everyone reacts in a slightly different way! Of course being a researcher, I recognize that unencumbered technology may be the most flexible. I also agree with you that defensive IPRs are not that bad, but what I have come to understand after talking to the lawyers is that this would be fine in a perfect world with no malicious companies. But unfortunately, defensive stances cause the defense-only company to pay royalties to a non-defensive company (especially if it doesn't compete in the same market segment), and not vice-versa. Nokia already has a statement registered on the IETF web site and is committed to "play fair." So anyhow, back to this specific case.. I have gotten a response from our lawyers and they are concerned to make sure that we conform to the IETF process and play by the rules. At this early stage, we can give a statement identifying the application, the work it affects and some licensing statement. We can give more detailed statements when the std is frozen or the patent is granted. And I will personally make sure that future necessary clarifications will be addressed by the lawyers. Thanks, TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center ------ End of Forwarded Message From exim@www1.ietf.org Thu Jun 19 16:07:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16068 for ; Thu, 19 Jun 2003 16:07:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JK72M18064 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 16:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gU-0004gM-ER for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 16:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15994 for ; Thu, 19 Jun 2003 16:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5eB-0002mS-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:04:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T5eB-0002mP-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:04:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gT-0004Z7-36; Thu, 19 Jun 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fn-0004JN-LQ for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15942 for ; Thu, 19 Jun 2003 16:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5dU-0002lt-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:56 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5dT-0002lU-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:55 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK5nER023026 for ; Thu, 19 Jun 2003 13:05:49 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:29 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EE0579B.1020809@nal.motlabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Alexandru Petrescu Date: Fri, 06 Jun 2003 10:58:03 +0200 To: "T.J. Kniveton" Cc: nemo-base-dt@nal.motlabs.com Subject: Re: [nemo-base-dt] IPRs on base solution Hello TJ, thank you for the update. > I know there are a lot of concerns about IPR, and it is hard to be > totally sure what the situation is. Exactly, that fits my view too; it is hard for me to find out what the best practice at IETF is. Please allow me to take one possible aspect of the situation. I'm not claiming that this is covering entirely the IPR issues, it is just one possibility. I've heard some people at IETF saying that WG's and the IESG are trying to stay away from anything that is "encumbered". (more specifically, a Mobile IP WG co-chair wrote in private; at last manet WG meeting an IESG member said that people in IESG are trying to avoid "encumbered" drafts; and a Mobile IP WG member who wrote on the list saying he doesn't "want to become a lawyer" when I suggested him that defensive IPR's are probably not very bad). So that resumes my understanding of one possible aspect of how IPR and IETF. It might very well be that my interpretation is wrong, and I'm in no position to make knowledgeable claims. So, if I take that reasoning, may I... > IPR that would apply to a basic mobile router solution, as was > disclosed when the draft was submitted. May I ask what parts of the draft would fit perfectly in the most important claims of the IPR document. For example, would the echo req/rep technique be protected by the claims in that IPR? If yes, then that is very good news, because I think we previously discussed that it is not that relevant for the base solution, so that IPR claim would not harm at all. Overall, _if_ existing IPR on a draft represents a problem for that draft's advancement, maybe identifying which part of the draft is protected and re-writing it, might be a good solution. If, on the other hand, it is acknowledged that defensive IPR's on a draft is ok, then no need to get rid of that IPR. Thanks, Alex ------ End of Forwarded Message From exim@www1.ietf.org Thu Jun 19 16:07:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16083 for ; Thu, 19 Jun 2003 16:07:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JK73318088 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 16:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gV-0004hf-5H for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 16:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15999 for ; Thu, 19 Jun 2003 16:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5eC-0002mY-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:04:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T5eB-0002mV-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 16:04:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5gT-0004a9-NZ; Thu, 19 Jun 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5fn-0004JS-TV for nemo@optimus.ietf.org; Thu, 19 Jun 2003 16:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15943 for ; Thu, 19 Jun 2003 16:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5dV-0002lu-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:57 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19T5dT-0002lV-00 for nemo@ietf.org; Thu, 19 Jun 2003 16:03:56 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5JK6BER023029 for ; Thu, 19 Jun 2003 13:06:12 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Jun 2003 13:05:52 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3EE757C6.D222D8DE@kniveton.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ------ Forwarded Message From: "T.J. Kniveton" Date: Wed, 11 Jun 2003 09:24:38 -0700 To: Alexandru Petrescu Cc: nemo-base-dt@nal.motlabs.com Subject: Re: [nemo-base-dt] IPRs on base solution Alexandru Petrescu wrote: > > Hello TJ, thank you for the update. > > > I know there are a lot of concerns about IPR, and it is hard to be > > totally sure what the situation is. > > Exactly, that fits my view too; it is hard for me to find out what the > best practice at IETF is. > > Please allow me to take one possible aspect of the situation. I'm not > claiming that this is covering entirely the IPR issues, it is just one > possibility. I've heard some people at IETF saying that WG's and the > IESG are trying to stay away from anything that is "encumbered". (more > specifically, a Mobile IP WG co-chair wrote in private; at last manet WG > meeting an IESG member said that people in IESG are trying to > avoid "encumbered" drafts; and a Mobile IP WG member who wrote on the > list saying he doesn't "want to become a lawyer" when I suggested him > that defensive IPR's are probably not very bad). Yes, we can see that this is an unchartered area and everyone reacts in a slightly different way! Of course being a researcher, I recognize that unencumbered technology may be the most flexible. I also agree with you that defensive IPRs are not that bad, but what I have come to understand after talking to the lawyers is that this would be fine in a perfect world with no malicious companies. But unfortunately, defensive stances cause the defense-only company to pay royalties to a non-defensive company (especially if it doesn't compete in the same market segment), and not vice-versa. Nokia already has a statement registered on the IETF web site and is committed to "play fair." So anyhow, back to this specific case.. I have gotten a response from our lawyers and they are concerned to make sure that we conform to the IETF process and play by the rules. At this early stage, we can give a statement identifying the application, the work it affects and some licensing statement. We can give more detailed statements when the std is frozen or the patent is granted. And I will personally make sure that future necessary clarifications will be addressed by the lawyers. Thanks, TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center ------ End of Forwarded Message From nemo-admin@ietf.org Thu Jun 19 22:01:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29170 for ; Thu, 19 Jun 2003 22:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBD3-000285-G5; Thu, 19 Jun 2003 22:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBCb-00027f-8i for nemo@optimus.ietf.org; Thu, 19 Jun 2003 22:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29143 for ; Thu, 19 Jun 2003 22:00:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBAH-0005bo-00 for nemo@ietf.org; Thu, 19 Jun 2003 21:58:09 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19TBAG-0005bg-00 for nemo@ietf.org; Thu, 19 Jun 2003 21:58:08 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5K1qt418292; Fri, 20 Jun 2003 09:52:56 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 5E8A410E95DA; Fri, 20 Jun 2003 10:00:44 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: "Paik, Eun Kyoung" Cc: IETF NEMO WG In-Reply-To: <200306200112.KAA18177@mail1.hanmir.com> References: <200306200112.KAA18177@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056074443.1787.2.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 20 Jun 2003 10:00:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-06-20 at 09:12, Paik, Eun Kyoung wrote: > Hi all, Hi Chan-wah, > > The taxonomy of your draft is very clear. Thank you for your work. > I am glad that you find it useful. > While I was working on multi-homed NEMO, I have found many problems > other than the listed problems in your draft (at the end of section > 4). > The problems. e.g. BU, egress selection, etc., are differ as the > taxonomy. > > IMHO, we'd better to define the problems and make a consensus on them, > since R12 in the requirement draft defines that the NEMO solution must > function for multihoming. Of-course, that's the purpose of the draft. Would you care to list those problems you'd encountered? /rgds /cwng From exim@www1.ietf.org Thu Jun 19 22:01:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29188 for ; Thu, 19 Jun 2003 22:01:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K218k08238 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 22:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBD9-00028n-Vt for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 22:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29161 for ; Thu, 19 Jun 2003 22:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBAq-0005c5-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 21:58:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TBAp-0005c2-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 21:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBD3-000285-G5; Thu, 19 Jun 2003 22:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBCb-00027f-8i for nemo@optimus.ietf.org; Thu, 19 Jun 2003 22:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29143 for ; Thu, 19 Jun 2003 22:00:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBAH-0005bo-00 for nemo@ietf.org; Thu, 19 Jun 2003 21:58:09 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19TBAG-0005bg-00 for nemo@ietf.org; Thu, 19 Jun 2003 21:58:08 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5K1qt418292; Fri, 20 Jun 2003 09:52:56 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 5E8A410E95DA; Fri, 20 Jun 2003 10:00:44 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: "Paik, Eun Kyoung" Cc: IETF NEMO WG In-Reply-To: <200306200112.KAA18177@mail1.hanmir.com> References: <200306200112.KAA18177@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056074443.1787.2.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 20 Jun 2003 10:00:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-06-20 at 09:12, Paik, Eun Kyoung wrote: > Hi all, Hi Chan-wah, > > The taxonomy of your draft is very clear. Thank you for your work. > I am glad that you find it useful. > While I was working on multi-homed NEMO, I have found many problems > other than the listed problems in your draft (at the end of section > 4). > The problems. e.g. BU, egress selection, etc., are differ as the > taxonomy. > > IMHO, we'd better to define the problems and make a consensus on them, > since R12 in the requirement draft defines that the NEMO solution must > function for multihoming. Of-course, that's the purpose of the draft. Would you care to list those problems you'd encountered? /rgds /cwng From exim@www1.ietf.org Thu Jun 19 22:29:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00151 for ; Thu, 19 Jun 2003 22:29:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K2T2217125 for nemo-archive@odin.ietf.org; Thu, 19 Jun 2003 22:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBeA-0004S8-KA for nemo-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 22:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00141 for ; Thu, 19 Jun 2003 22:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBbq-0005r9-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 22:26:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TBbp-0005r6-00 for nemo-web-archive@ietf.org; Thu, 19 Jun 2003 22:26:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBe9-0004QE-3r; Thu, 19 Jun 2003 22:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBdW-0004Pm-CU for nemo@optimus.ietf.org; Thu, 19 Jun 2003 22:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00111 for ; Thu, 19 Jun 2003 22:28:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBbC-0005qr-00 for nemo@ietf.org; Thu, 19 Jun 2003 22:25:58 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19TBbB-0005qa-00 for nemo@ietf.org; Thu, 19 Jun 2003 22:25:57 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Jun 2003 22:27:48 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> From: Soliman Hesham To: "'T.J. Kniveton'" , nemo@ietf.org Subject: RE: [nemo] FW: [nemo-base-dt] IPRs on base solution Date: Thu, 19 Jun 2003 22:27:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , TJ, We might need some feedback from the ADs about IETF policy here. But, having been through this in other WGs. I was always told that the IETF does not want base solutions to be IPRed. Examples of these has taken place in other WGs like VRRP, SEND..etc. In the case where a base spec were encumbered, the second best solution is specified. In this case this might be the PSBU. My 2 cents Hesham > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: Thursday, June 19, 2003 4:06 PM > To: nemo@ietf.org > Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution > > > > ------ Forwarded Message > From: "T.J. Kniveton" > Date: Wed, 11 Jun 2003 09:24:38 -0700 > To: Alexandru Petrescu > Cc: nemo-base-dt@nal.motlabs.com > Subject: Re: [nemo-base-dt] IPRs on base solution > > Alexandru Petrescu wrote: > > > > Hello TJ, thank you for the update. > > > > > I know there are a lot of concerns about IPR, and it is > hard to be > > > totally sure what the situation is. > > > > Exactly, that fits my view too; it is hard for me to find > out what the > > best practice at IETF is. > > > > Please allow me to take one possible aspect of the > situation. I'm not > > claiming that this is covering entirely the IPR issues, it > is just one > > possibility. I've heard some people at IETF saying that > WG's and the > > IESG are trying to stay away from anything that is > "encumbered". (more > > specifically, a Mobile IP WG co-chair wrote in private; at > last manet WG > > meeting an IESG member said that people in IESG are trying to > > avoid "encumbered" drafts; and a Mobile IP WG member who > wrote on the > > list saying he doesn't "want to become a lawyer" when I > suggested him > > that defensive IPR's are probably not very bad). > > > Yes, we can see that this is an unchartered area and > everyone reacts in a > slightly different way! Of course being a researcher, I > recognize that > unencumbered technology may be the most flexible. I also > agree with you that > defensive IPRs are not that bad, but what I have come to > understand after > talking to the lawyers is that this would be fine in a > perfect world with no > malicious companies. But unfortunately, defensive stances cause the > defense-only company to pay royalties to a non-defensive > company (especially > if > it doesn't compete in the same market segment), and not > vice-versa. Nokia > already has a statement registered on the IETF web site and > is committed to > "play fair." > > So anyhow, back to this specific case.. I have gotten a > response from our > lawyers and they are concerned to make sure that we conform > to the IETF > process > and play by the rules. At this early stage, we can give a statement > identifying > the application, the work it affects and some licensing > statement. We can > give > more detailed statements when the std is frozen or the > patent is granted. > And I > will personally make sure that future necessary > clarifications will be > addressed by the lawyers. > > Thanks, TJ > > -- > T.J. Kniveton > Communication Systems Lab > Nokia Research Center > > > ------ End of Forwarded Message > > From nemo-admin@ietf.org Thu Jun 19 23:17:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00149 for ; Thu, 19 Jun 2003 22:29:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBe9-0004QE-3r; Thu, 19 Jun 2003 22:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TBdW-0004Pm-CU for nemo@optimus.ietf.org; Thu, 19 Jun 2003 22:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00111 for ; Thu, 19 Jun 2003 22:28:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TBbC-0005qr-00 for nemo@ietf.org; Thu, 19 Jun 2003 22:25:58 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19TBbB-0005qa-00 for nemo@ietf.org; Thu, 19 Jun 2003 22:25:57 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Jun 2003 22:27:48 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> From: Soliman Hesham To: "'T.J. Kniveton'" , nemo@ietf.org Subject: RE: [nemo] FW: [nemo-base-dt] IPRs on base solution Date: Thu, 19 Jun 2003 22:27:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , TJ, We might need some feedback from the ADs about IETF policy here. But, having been through this in other WGs. I was always told that the IETF does not want base solutions to be IPRed. Examples of these has taken place in other WGs like VRRP, SEND..etc. In the case where a base spec were encumbered, the second best solution is specified. In this case this might be the PSBU. My 2 cents Hesham > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: Thursday, June 19, 2003 4:06 PM > To: nemo@ietf.org > Subject: [nemo] FW: [nemo-base-dt] IPRs on base solution > > > > ------ Forwarded Message > From: "T.J. Kniveton" > Date: Wed, 11 Jun 2003 09:24:38 -0700 > To: Alexandru Petrescu > Cc: nemo-base-dt@nal.motlabs.com > Subject: Re: [nemo-base-dt] IPRs on base solution > > Alexandru Petrescu wrote: > > > > Hello TJ, thank you for the update. > > > > > I know there are a lot of concerns about IPR, and it is > hard to be > > > totally sure what the situation is. > > > > Exactly, that fits my view too; it is hard for me to find > out what the > > best practice at IETF is. > > > > Please allow me to take one possible aspect of the > situation. I'm not > > claiming that this is covering entirely the IPR issues, it > is just one > > possibility. I've heard some people at IETF saying that > WG's and the > > IESG are trying to stay away from anything that is > "encumbered". (more > > specifically, a Mobile IP WG co-chair wrote in private; at > last manet WG > > meeting an IESG member said that people in IESG are trying to > > avoid "encumbered" drafts; and a Mobile IP WG member who > wrote on the > > list saying he doesn't "want to become a lawyer" when I > suggested him > > that defensive IPR's are probably not very bad). > > > Yes, we can see that this is an unchartered area and > everyone reacts in a > slightly different way! Of course being a researcher, I > recognize that > unencumbered technology may be the most flexible. I also > agree with you that > defensive IPRs are not that bad, but what I have come to > understand after > talking to the lawyers is that this would be fine in a > perfect world with no > malicious companies. But unfortunately, defensive stances cause the > defense-only company to pay royalties to a non-defensive > company (especially > if > it doesn't compete in the same market segment), and not > vice-versa. Nokia > already has a statement registered on the IETF web site and > is committed to > "play fair." > > So anyhow, back to this specific case.. I have gotten a > response from our > lawyers and they are concerned to make sure that we conform > to the IETF > process > and play by the rules. At this early stage, we can give a statement > identifying > the application, the work it affects and some licensing > statement. We can > give > more detailed statements when the std is frozen or the > patent is granted. > And I > will personally make sure that future necessary > clarifications will be > addressed by the lawyers. > > Thanks, TJ > > -- > T.J. Kniveton > Communication Systems Lab > Nokia Research Center > > > ------ End of Forwarded Message > > From nemo-admin@ietf.org Fri Jun 20 02:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12120 for ; Fri, 20 Jun 2003 02:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TF1B-0008Pd-Us; Fri, 20 Jun 2003 02:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TF0x-0008Ma-0p for nemo@optimus.ietf.org; Fri, 20 Jun 2003 02:04:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11304 for ; Fri, 20 Jun 2003 02:04:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TEyc-0007RC-00 for nemo@ietf.org; Fri, 20 Jun 2003 02:02:22 -0400 Received: from ua64d22hel.dial.kolumbus.fi ([62.248.149.64] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19TEyb-0007R2-00 for nemo@ietf.org; Fri, 20 Jun 2003 02:02:21 -0400 Received: from kolumbus.fi (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h5K61otF006174; Fri, 20 Jun 2003 09:01:52 +0300 Message-ID: <3EF2A34E.40501@kolumbus.fi> Date: Fri, 20 Jun 2003 09:01:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'T.J. Kniveton'" , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit TJ, Hesham, I agree with Hesham here. IPRs *are* an issue, and I'm not sure labeling some of the IPR as "defensive" is very useful. Here's one practical problem: how does this technology get deployed in Linux & BSD? If the IPR licenses grant a free (not just "fair") use, then we are OK. If not, we have a problem. At the very least there should be a base solution which is free of IPRs, even if advanced optimizations etc. would be IPR-only stuff. --Jari Soliman Hesham wrote: > TJ, > > We might need some feedback from the ADs about > IETF policy here. But, having been through this > in other WGs. I was always told that the IETF > does not want base solutions to be IPRed. Examples > of these has taken place in other WGs like VRRP, SEND..etc. > > In the case where a base spec were encumbered, the > second best solution is specified. In this case > this might be the PSBU. From exim@www1.ietf.org Fri Jun 20 02:05:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12154 for ; Fri, 20 Jun 2003 02:05:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K65AQ32472 for nemo-archive@odin.ietf.org; Fri, 20 Jun 2003 02:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TF1K-0008Rb-Fq for nemo-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 02:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11726 for ; Fri, 20 Jun 2003 02:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TEz0-0007RP-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 02:02:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TEyz-0007RM-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 02:02:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TF1B-0008Pd-Us; Fri, 20 Jun 2003 02:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TF0x-0008Ma-0p for nemo@optimus.ietf.org; Fri, 20 Jun 2003 02:04:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11304 for ; Fri, 20 Jun 2003 02:04:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TEyc-0007RC-00 for nemo@ietf.org; Fri, 20 Jun 2003 02:02:22 -0400 Received: from ua64d22hel.dial.kolumbus.fi ([62.248.149.64] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19TEyb-0007R2-00 for nemo@ietf.org; Fri, 20 Jun 2003 02:02:21 -0400 Received: from kolumbus.fi (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h5K61otF006174; Fri, 20 Jun 2003 09:01:52 +0300 Message-ID: <3EF2A34E.40501@kolumbus.fi> Date: Fri, 20 Jun 2003 09:01:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'T.J. Kniveton'" , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit TJ, Hesham, I agree with Hesham here. IPRs *are* an issue, and I'm not sure labeling some of the IPR as "defensive" is very useful. Here's one practical problem: how does this technology get deployed in Linux & BSD? If the IPR licenses grant a free (not just "fair") use, then we are OK. If not, we have a problem. At the very least there should be a base solution which is free of IPRs, even if advanced optimizations etc. would be IPR-only stuff. --Jari Soliman Hesham wrote: > TJ, > > We might need some feedback from the ADs about > IETF policy here. But, having been through this > in other WGs. I was always told that the IETF > does not want base solutions to be IPRed. Examples > of these has taken place in other WGs like VRRP, SEND..etc. > > In the case where a base spec were encumbered, the > second best solution is specified. In this case > this might be the PSBU. From nemo-admin@ietf.org Fri Jun 20 05:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23465 for ; Fri, 20 Jun 2003 05:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIfd-0007la-D3; Fri, 20 Jun 2003 05:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIfQ-0007lO-GI for nemo@optimus.ietf.org; Fri, 20 Jun 2003 05:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23442 for ; Fri, 20 Jun 2003 05:58:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TId3-0001BK-00 for nemo@ietf.org; Fri, 20 Jun 2003 05:56:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19TId1-0001B9-00 for nemo@ietf.org; Fri, 20 Jun 2003 05:56:20 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5K9lM429901; Fri, 20 Jun 2003 17:47:22 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 762F810E95DA; Fri, 20 Jun 2003 17:55:10 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , eun@mmlab.snu.ac.kr, hscho@mmlab.snu.ac.kr In-Reply-To: <200306200905.SAA13502@mail1.hanmir.com> References: <200306200905.SAA13502@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056102909.2174.12.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 20 Jun 2003 17:55:10 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Eun Kyoung, On Fri, 2003-06-20 at 17:05, Paik, Eun Kyoung wrote: > Hi, Chan-Wah, > > > > IMHO, we'd better to define the problems and make a consensus on > them, > > > since R12 in the requirement draft defines that the NEMO solution > must > > > function for multihoming. > > > > Of-course, that's the purpose of the draft. Would you care to list > > those problems you'd encountered? > > I and my collegue Ho-sik classified the problems into three main parts > as follows. > The three categories are devided again into many sub-problems. > Insted of listing all of them at once, we may start from following > considerations. > > 1. Egress interface availability and selection: > Multiple egress interfaces of MR can be used simultaneously or one at > a time ? I don't see any reason to prevent them from being used simultaneously. If not used simultaneously, one can argue that it is not multihomed. > If only a egress interface is used at a time, how to select it ? and > who select it ? > I personally feel that selection of egress interface is an implementation issue. But there may be something I missed. > 2. Scalability: > draft-montavont-mobileip-mmi-00.txt and > draft-wakikawa-multiplecoa-00.txt are proposed for different > scenarios. > Do we need a scalable and flexible solution for all the eight > variations of (w, x, y) mentioned in your draft ? > The 8 variations are just different possible scenarios. They share some similar set of problems. Ideally, we should have a solution that solves all the problems, but that is subjected to (a) scope of NEMO WG, (b) practicability, and (c) significance of the problem. > With multiple HAs, there are further issues since it may have multiple > HoAs. > Are we going to allow multiple HoAs ? Then we have much more problems > to discuss. Which are ... ? It will useful to list the problems so that the WG can make a decision whether multiple HoAs should be supported or not. > > 3. RO Considerations: > The way of egress interface availability and selection will affect RO. Hmmm.. most likely so. Highly dependent on the RO solution used, which may be a bit early. > > I think we also have to analyze security considerations. > Definitely. Any inputs from you (or other members in the WG) on this regard? >From your 3 main categories, I see the need to quickly address the Scalablity problem you mentioned. You might want to elaborate on that. Similarly for egress interface selection. As for RO, we may be able to wait a while. /rgds /cwng From exim@www1.ietf.org Fri Jun 20 05:59:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23480 for ; Fri, 20 Jun 2003 05:59:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K9x4M29910 for nemo-archive@odin.ietf.org; Fri, 20 Jun 2003 05:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIfg-0007mL-Lf for nemo-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 05:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23453 for ; Fri, 20 Jun 2003 05:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TIdK-0001BS-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 05:56:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TIdJ-0001BP-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 05:56:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIfd-0007la-D3; Fri, 20 Jun 2003 05:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIfQ-0007lO-GI for nemo@optimus.ietf.org; Fri, 20 Jun 2003 05:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23442 for ; Fri, 20 Jun 2003 05:58:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TId3-0001BK-00 for nemo@ietf.org; Fri, 20 Jun 2003 05:56:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19TId1-0001B9-00 for nemo@ietf.org; Fri, 20 Jun 2003 05:56:20 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5K9lM429901; Fri, 20 Jun 2003 17:47:22 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 762F810E95DA; Fri, 20 Jun 2003 17:55:10 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , eun@mmlab.snu.ac.kr, hscho@mmlab.snu.ac.kr In-Reply-To: <200306200905.SAA13502@mail1.hanmir.com> References: <200306200905.SAA13502@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056102909.2174.12.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 20 Jun 2003 17:55:10 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Eun Kyoung, On Fri, 2003-06-20 at 17:05, Paik, Eun Kyoung wrote: > Hi, Chan-Wah, > > > > IMHO, we'd better to define the problems and make a consensus on > them, > > > since R12 in the requirement draft defines that the NEMO solution > must > > > function for multihoming. > > > > Of-course, that's the purpose of the draft. Would you care to list > > those problems you'd encountered? > > I and my collegue Ho-sik classified the problems into three main parts > as follows. > The three categories are devided again into many sub-problems. > Insted of listing all of them at once, we may start from following > considerations. > > 1. Egress interface availability and selection: > Multiple egress interfaces of MR can be used simultaneously or one at > a time ? I don't see any reason to prevent them from being used simultaneously. If not used simultaneously, one can argue that it is not multihomed. > If only a egress interface is used at a time, how to select it ? and > who select it ? > I personally feel that selection of egress interface is an implementation issue. But there may be something I missed. > 2. Scalability: > draft-montavont-mobileip-mmi-00.txt and > draft-wakikawa-multiplecoa-00.txt are proposed for different > scenarios. > Do we need a scalable and flexible solution for all the eight > variations of (w, x, y) mentioned in your draft ? > The 8 variations are just different possible scenarios. They share some similar set of problems. Ideally, we should have a solution that solves all the problems, but that is subjected to (a) scope of NEMO WG, (b) practicability, and (c) significance of the problem. > With multiple HAs, there are further issues since it may have multiple > HoAs. > Are we going to allow multiple HoAs ? Then we have much more problems > to discuss. Which are ... ? It will useful to list the problems so that the WG can make a decision whether multiple HoAs should be supported or not. > > 3. RO Considerations: > The way of egress interface availability and selection will affect RO. Hmmm.. most likely so. Highly dependent on the RO solution used, which may be a bit early. > > I think we also have to analyze security considerations. > Definitely. Any inputs from you (or other members in the WG) on this regard? >From your 3 main categories, I see the need to quickly address the Scalablity problem you mentioned. You might want to elaborate on that. Similarly for egress interface selection. As for RO, we may be able to wait a while. /rgds /cwng From nemo-admin@ietf.org Fri Jun 20 09:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05134 for ; Fri, 20 Jun 2003 09:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLcW-0003iz-MZ; Fri, 20 Jun 2003 09:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLbr-0003Yn-Ix for nemo@optimus.ietf.org; Fri, 20 Jun 2003 09:07:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05095 for ; Fri, 20 Jun 2003 09:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLbq-0003sF-00 for nemo@ietf.org; Fri, 20 Jun 2003 09:07:18 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19TLbp-0003sB-00 for nemo@ietf.org; Fri, 20 Jun 2003 09:07:17 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5KD7DbL019375; Fri, 20 Jun 2003 06:07:13 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5KD7A0J013368; Fri, 20 Jun 2003 08:07:12 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 791CB2EC8B; Fri, 20 Jun 2003 15:07:10 +0200 (CEST) Message-ID: <3EF306FE.6050904@nal.motlabs.com> Date: Fri, 20 Jun 2003 15:07:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Soliman Hesham , "'T.J. Kniveton'" , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> <3EF2A34E.40501@kolumbus.fi> In-Reply-To: <3EF2A34E.40501@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari, Hesham, thanks for following up on this. I agree with most of your comments. One conclusion seems to lack a basis though. I prefer wait the base spec is out when it is out so we have a base for discussion. Alex GBU Jari Arkko wrote: > > TJ, Hesham, > > I agree with Hesham here. IPRs *are* an issue, and I'm not sure > labeling some of the IPR as "defensive" is very useful. Here's one > practical problem: how does this technology get deployed in Linux & > BSD? If the IPR licenses grant a free (not just "fair") use, then we > are OK. If not, we have a problem. At the very least there should be > a base solution which is free of IPRs, even if advanced optimizations > etc. would be IPR-only stuff. > > --Jari > > Soliman Hesham wrote: > >> TJ, We might need some feedback from the ADs about IETF policy >> here. But, having been through this in other WGs. I was always told >> that the IETF does not want base solutions to be IPRed. Examples >> of these has taken place in other WGs like VRRP, SEND..etc. In the >> case where a base spec were encumbered, the second best solution is >> specified. In this case this might be the PSBU. > > > > From exim@www1.ietf.org Fri Jun 20 09:08:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05149 for ; Fri, 20 Jun 2003 09:08:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KD88P14371 for nemo-archive@odin.ietf.org; Fri, 20 Jun 2003 09:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLce-0003ji-7Q for nemo-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 09:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05129 for ; Fri, 20 Jun 2003 09:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLcc-0003sn-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 09:08:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TLcc-0003sk-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 09:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLcW-0003iz-MZ; Fri, 20 Jun 2003 09:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLbr-0003Yn-Ix for nemo@optimus.ietf.org; Fri, 20 Jun 2003 09:07:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05095 for ; Fri, 20 Jun 2003 09:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLbq-0003sF-00 for nemo@ietf.org; Fri, 20 Jun 2003 09:07:18 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19TLbp-0003sB-00 for nemo@ietf.org; Fri, 20 Jun 2003 09:07:17 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5KD7DbL019375; Fri, 20 Jun 2003 06:07:13 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5KD7A0J013368; Fri, 20 Jun 2003 08:07:12 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 791CB2EC8B; Fri, 20 Jun 2003 15:07:10 +0200 (CEST) Message-ID: <3EF306FE.6050904@nal.motlabs.com> Date: Fri, 20 Jun 2003 15:07:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Soliman Hesham , "'T.J. Kniveton'" , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: <748C6D0A58C0F94CA63C198B6674697A0141BB03@ftmail.lab.flarion.com> <3EF2A34E.40501@kolumbus.fi> In-Reply-To: <3EF2A34E.40501@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari, Hesham, thanks for following up on this. I agree with most of your comments. One conclusion seems to lack a basis though. I prefer wait the base spec is out when it is out so we have a base for discussion. Alex GBU Jari Arkko wrote: > > TJ, Hesham, > > I agree with Hesham here. IPRs *are* an issue, and I'm not sure > labeling some of the IPR as "defensive" is very useful. Here's one > practical problem: how does this technology get deployed in Linux & > BSD? If the IPR licenses grant a free (not just "fair") use, then we > are OK. If not, we have a problem. At the very least there should be > a base solution which is free of IPRs, even if advanced optimizations > etc. would be IPR-only stuff. > > --Jari > > Soliman Hesham wrote: > >> TJ, We might need some feedback from the ADs about IETF policy >> here. But, having been through this in other WGs. I was always told >> that the IETF does not want base solutions to be IPRed. Examples >> of these has taken place in other WGs like VRRP, SEND..etc. In the >> case where a base spec were encumbered, the second best solution is >> specified. In this case this might be the PSBU. > > > > From nemo-admin@ietf.org Fri Jun 20 22:40:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17597 for ; Fri, 20 Jun 2003 22:40:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TYIN-0007kU-4R; Fri, 20 Jun 2003 22:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TYHN-0007jg-Vk for nemo@optimus.ietf.org; Fri, 20 Jun 2003 22:39:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17560 for ; Fri, 20 Jun 2003 22:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TYHK-00055D-00 for nemo@ietf.org; Fri, 20 Jun 2003 22:38:58 -0400 Received: from bb-203-125-111-66.singnet.com.sg ([203.125.111.66] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19TYHJ-000559-00 for nemo@ietf.org; Fri, 20 Jun 2003 22:38:57 -0400 Received: by fox (Postfix, from userid 1000) id 57AEF11F64CB; Sat, 21 Jun 2003 10:40:17 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , hscho@mmlab.snu.ac.kr, eun@mmlab.snu.ac.kr In-Reply-To: <200306201059.TAA12019@mail1.hanmir.com> References: <200306201059.TAA12019@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056163216.10582.5.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 21 Jun 2003 10:40:17 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Eun Kyoung, On Fri, 2003-06-20 at 18:59, Paik, Eun Kyoung wrote: > > > 1. Egress interface availability and selection: > > > Multiple egress interfaces of MR can be used simultaneously or one > at > > > a time ? > > > > I don't see any reason to prevent them from being used > simultaneously. > > If not used simultaneously, one can argue that it is not multihomed. > > I agree with you. > If we use them simutaneously, we first face BU problem as you > mentioned in your draft. > > > > If only a egress interface is used at a time, how to select it ? > and > > > who select it ? > > > > > I personally feel that selection of egress interface is an > > implementation issue. But there may be something I missed. > > Good point. > We first distinguish the implementation issues from the standadization > issues. > If we have to make a consensus ons election of egress interface, > there may be some different choices, e.g. HA, MRs, and MNN. > What do other people on the NEMO WG feels about this? > > > 2. Scalability: > > > draft-montavont-mobileip-mmi-00.txt and > > > draft-wakikawa-multiplecoa-00.txt are proposed for different > > > scenarios. > > > Do we need a scalable and flexible solution for all the eight > > > variations of (w, x, y) mentioned in your draft ? > > > > > > > The 8 variations are just different possible scenarios. They share > some > > similar set of problems. Ideally, we should have a solution that > solves > > all the problems, but that is subjected to (a) scope of NEMO WG, (b) > > practicability, and (c) significance of the problem. > > Yes, ideally we shoud do. > But, we'd better to talk about above (a), (b), (c) more in this maling > list, > since a solution which meets all the 8 scenarios will not be easily > come. > > > > With multiple HAs, there are further issues since it may have > multiple > > > HoAs. > > > Are we going to allow multiple HoAs ? Then we have much more > problems > > > to discuss. > > > > Which are ... ? It will useful to list the problems so that the WG > can > > make a decision whether multiple HoAs should be supported or not. > > Before we go further, we can analyze the reason we need multiple HAs. > For example, > - HAs can be multiplied according to locations. > - HAs can be multiplied according to access technologies. > - HAs can be multiplied according to ISPs. > > > > 3. RO Considerations: > > > The way of egress interface availability and selection will affect > RO. > > > > Hmmm.. most likely so. Highly dependent on the RO solution used, > which > > may be a bit early. > > > > > I think we also have to analyze security considerations. > > > > > Definitely. Any inputs from you (or other members in the WG) on this > > regard? > > Yes, RO and Security Considerations are dependant on the solution we > will have. > So, we may discuss it after we make a consensus on the above problems. > > In fact, we have been listing detailed problems as a form of I-D > since they are a bit diferent from scenario to scenario. > If you think it will be useful for us, we can share it as soon as it > is completed. I would very much like to see the I-D you are preparing. And yes, it will be useful to release it soon so that everyone in the WG can have a clearer picture on the impact of multihoming on the basic solution while we are formulating it. /rgds /cwng From exim@www1.ietf.org Fri Jun 20 22:40:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17612 for ; Fri, 20 Jun 2003 22:40:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5L2eFQ29867 for nemo-archive@odin.ietf.org; Fri, 20 Jun 2003 22:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TYIZ-0007le-B5 for nemo-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 22:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17594 for ; Fri, 20 Jun 2003 22:40:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TYIV-00055t-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 22:40:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TYIV-00055p-00 for nemo-web-archive@ietf.org; Fri, 20 Jun 2003 22:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TYIN-0007kU-4R; Fri, 20 Jun 2003 22:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TYHN-0007jg-Vk for nemo@optimus.ietf.org; Fri, 20 Jun 2003 22:39:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17560 for ; Fri, 20 Jun 2003 22:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TYHK-00055D-00 for nemo@ietf.org; Fri, 20 Jun 2003 22:38:58 -0400 Received: from bb-203-125-111-66.singnet.com.sg ([203.125.111.66] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19TYHJ-000559-00 for nemo@ietf.org; Fri, 20 Jun 2003 22:38:57 -0400 Received: by fox (Postfix, from userid 1000) id 57AEF11F64CB; Sat, 21 Jun 2003 10:40:17 +0800 (SGT) Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , hscho@mmlab.snu.ac.kr, eun@mmlab.snu.ac.kr In-Reply-To: <200306201059.TAA12019@mail1.hanmir.com> References: <200306201059.TAA12019@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056163216.10582.5.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 21 Jun 2003 10:40:17 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Eun Kyoung, On Fri, 2003-06-20 at 18:59, Paik, Eun Kyoung wrote: > > > 1. Egress interface availability and selection: > > > Multiple egress interfaces of MR can be used simultaneously or one > at > > > a time ? > > > > I don't see any reason to prevent them from being used > simultaneously. > > If not used simultaneously, one can argue that it is not multihomed. > > I agree with you. > If we use them simutaneously, we first face BU problem as you > mentioned in your draft. > > > > If only a egress interface is used at a time, how to select it ? > and > > > who select it ? > > > > > I personally feel that selection of egress interface is an > > implementation issue. But there may be something I missed. > > Good point. > We first distinguish the implementation issues from the standadization > issues. > If we have to make a consensus ons election of egress interface, > there may be some different choices, e.g. HA, MRs, and MNN. > What do other people on the NEMO WG feels about this? > > > 2. Scalability: > > > draft-montavont-mobileip-mmi-00.txt and > > > draft-wakikawa-multiplecoa-00.txt are proposed for different > > > scenarios. > > > Do we need a scalable and flexible solution for all the eight > > > variations of (w, x, y) mentioned in your draft ? > > > > > > > The 8 variations are just different possible scenarios. They share > some > > similar set of problems. Ideally, we should have a solution that > solves > > all the problems, but that is subjected to (a) scope of NEMO WG, (b) > > practicability, and (c) significance of the problem. > > Yes, ideally we shoud do. > But, we'd better to talk about above (a), (b), (c) more in this maling > list, > since a solution which meets all the 8 scenarios will not be easily > come. > > > > With multiple HAs, there are further issues since it may have > multiple > > > HoAs. > > > Are we going to allow multiple HoAs ? Then we have much more > problems > > > to discuss. > > > > Which are ... ? It will useful to list the problems so that the WG > can > > make a decision whether multiple HoAs should be supported or not. > > Before we go further, we can analyze the reason we need multiple HAs. > For example, > - HAs can be multiplied according to locations. > - HAs can be multiplied according to access technologies. > - HAs can be multiplied according to ISPs. > > > > 3. RO Considerations: > > > The way of egress interface availability and selection will affect > RO. > > > > Hmmm.. most likely so. Highly dependent on the RO solution used, > which > > may be a bit early. > > > > > I think we also have to analyze security considerations. > > > > > Definitely. Any inputs from you (or other members in the WG) on this > > regard? > > Yes, RO and Security Considerations are dependant on the solution we > will have. > So, we may discuss it after we make a consensus on the above problems. > > In fact, we have been listing detailed problems as a form of I-D > since they are a bit diferent from scenario to scenario. > If you think it will be useful for us, we can share it as soon as it > is completed. I would very much like to see the I-D you are preparing. And yes, it will be useful to release it soon so that everyone in the WG can have a clearer picture on the impact of multihoming on the basic solution while we are formulating it. /rgds /cwng From nemo-admin@ietf.org Sat Jun 21 23:00:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21349 for ; Sat, 21 Jun 2003 23:00:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tv5F-0007jt-FB; Sat, 21 Jun 2003 23:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tv4v-0007jJ-Oe for nemo@optimus.ietf.org; Sat, 21 Jun 2003 22:59:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21298 for ; Sat, 21 Jun 2003 22:59:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tv4s-0002B8-00 for nemo@ietf.org; Sat, 21 Jun 2003 22:59:38 -0400 Received: from bb-203-125-106-175.singnet.com.sg ([203.125.106.175] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19Tv4q-0002Az-00 for nemo@ietf.org; Sat, 21 Jun 2003 22:59:37 -0400 Received: by fox (Postfix, from userid 1000) id 5D905104BECD; Sun, 22 Jun 2003 11:00:54 +0800 (SGT) Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , eun@mmlab.snu.ac.kr, hscho@mmlab.snu.ac.kr In-Reply-To: <200306210747.QAA21197@mail1.hanmir.com> References: <200306210747.QAA21197@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056250854.1603.24.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 22 Jun 2003 11:00:54 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Eun Kyoung, On Sat, 2003-06-21 at 15:47, Paik, Eun Kyoung wrote: > Hello, Chan-Wha, > > > > > I personally feel that selection of egress interface is an > > > > implementation issue. But there may be something I missed. > > > > > > Good point. > > > We first distinguish the implementation issues from the > standadization > > > issues. > > > If we have to make a consensus ons election of egress interface, > > > there may be some different choices, e.g. HA, MRs, and MNN. > > > > > What do other people on the NEMO WG feels about this? > > If we allow multiple BU with multiple CoAs(Care of Prefixes) of > multiple MRs, > HA may select the egress interface. > I think you meant this: "given two routes to the same network prefix, HA has to make the selection which route to use." It can be based on routing metric, load balancing, or even just a default route selection. There shouldn't be any problem in doing that. > We may also consider the cases that MRs or MNNs select the egress > interface, however. > For example, let's imagine the situation as follows. > There is a big vehicle supports NEMO with multiple MRs. > As time goes, availability may differes from egress interface to > egress interface. > Then, MRs should know and decide which MR's egress interface is > connected to > the Internet. So, MRs need to communicate with each other. > In this case, MRs select the egress interface as their availability, > don't they ? > Right, but I am not too sure if communications between MRs is within the scope of NEMO. I don't know if you have read the -00 version of the multihomng draft, but in there, I have described a simple solution to solve this without requiring special communications. The solution is left out of the -01 draft since we want to first identify the problem before describing solution. Anyway, here is a brief description: each MR will actively listen to the RA in their ingress link(s) to detect the presence of another router which advertise an egress route to the Internet (lifetime!=0). When an MR looses its egress link, it can then set up a temporary tunnel with its HA that passes through the other MR. This way, we don't need any special communications between MRs, and the MR can decide which route to use specifically. Another way to do it is for the MR to simply response with an ICMP re-direct message when it looses its egress link. The first way, the lost of egress link is transparent to MNNs. The second way, the MR inform MNNs that it has lost a route, and force MNNs to re-direct their packets to other MRs. /rgds /cwng From exim@www1.ietf.org Sat Jun 21 23:00:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21364 for ; Sat, 21 Jun 2003 23:00:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5M30Ar29802 for nemo-archive@odin.ietf.org; Sat, 21 Jun 2003 23:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tv5O-0007kb-KV for nemo-web-archive@optimus.ietf.org; Sat, 21 Jun 2003 23:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21337 for ; Sat, 21 Jun 2003 23:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tv5L-0002Be-00 for nemo-web-archive@ietf.org; Sat, 21 Jun 2003 23:00:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Tv5K-0002Ba-00 for nemo-web-archive@ietf.org; Sat, 21 Jun 2003 23:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tv5F-0007jt-FB; Sat, 21 Jun 2003 23:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tv4v-0007jJ-Oe for nemo@optimus.ietf.org; Sat, 21 Jun 2003 22:59:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21298 for ; Sat, 21 Jun 2003 22:59:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tv4s-0002B8-00 for nemo@ietf.org; Sat, 21 Jun 2003 22:59:38 -0400 Received: from bb-203-125-106-175.singnet.com.sg ([203.125.106.175] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19Tv4q-0002Az-00 for nemo@ietf.org; Sat, 21 Jun 2003 22:59:37 -0400 Received: by fox (Postfix, from userid 1000) id 5D905104BECD; Sun, 22 Jun 2003 11:00:54 +0800 (SGT) Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: "Paik, Eun Kyoung" Cc: IETF NEMO WG , eun@mmlab.snu.ac.kr, hscho@mmlab.snu.ac.kr In-Reply-To: <200306210747.QAA21197@mail1.hanmir.com> References: <200306210747.QAA21197@mail1.hanmir.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056250854.1603.24.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 22 Jun 2003 11:00:54 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Eun Kyoung, On Sat, 2003-06-21 at 15:47, Paik, Eun Kyoung wrote: > Hello, Chan-Wha, > > > > > I personally feel that selection of egress interface is an > > > > implementation issue. But there may be something I missed. > > > > > > Good point. > > > We first distinguish the implementation issues from the > standadization > > > issues. > > > If we have to make a consensus ons election of egress interface, > > > there may be some different choices, e.g. HA, MRs, and MNN. > > > > > What do other people on the NEMO WG feels about this? > > If we allow multiple BU with multiple CoAs(Care of Prefixes) of > multiple MRs, > HA may select the egress interface. > I think you meant this: "given two routes to the same network prefix, HA has to make the selection which route to use." It can be based on routing metric, load balancing, or even just a default route selection. There shouldn't be any problem in doing that. > We may also consider the cases that MRs or MNNs select the egress > interface, however. > For example, let's imagine the situation as follows. > There is a big vehicle supports NEMO with multiple MRs. > As time goes, availability may differes from egress interface to > egress interface. > Then, MRs should know and decide which MR's egress interface is > connected to > the Internet. So, MRs need to communicate with each other. > In this case, MRs select the egress interface as their availability, > don't they ? > Right, but I am not too sure if communications between MRs is within the scope of NEMO. I don't know if you have read the -00 version of the multihomng draft, but in there, I have described a simple solution to solve this without requiring special communications. The solution is left out of the -01 draft since we want to first identify the problem before describing solution. Anyway, here is a brief description: each MR will actively listen to the RA in their ingress link(s) to detect the presence of another router which advertise an egress route to the Internet (lifetime!=0). When an MR looses its egress link, it can then set up a temporary tunnel with its HA that passes through the other MR. This way, we don't need any special communications between MRs, and the MR can decide which route to use specifically. Another way to do it is for the MR to simply response with an ICMP re-direct message when it looses its egress link. The first way, the lost of egress link is transparent to MNNs. The second way, the MR inform MNNs that it has lost a route, and force MNNs to re-direct their packets to other MRs. /rgds /cwng From nemo-admin@ietf.org Sun Jun 22 00:08:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22529 for ; Sun, 22 Jun 2003 00:08:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw94-0001J4-Eg; Sun, 22 Jun 2003 00:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw81-00013N-Qq for nemo@optimus.ietf.org; Sun, 22 Jun 2003 00:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22470 for ; Sun, 22 Jun 2003 00:06:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tw7k-0002TM-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:06:40 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19Tw7P-0002T5-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:06:19 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5M45JER037331; Sat, 21 Jun 2003 21:05:19 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 Jun 2003 21:04:51 -0700 Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution From: "T.J. Kniveton" To: Jari Arkko , Soliman Hesham CC: Message-ID: In-Reply-To: <3EF2A34E.40501@kolumbus.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for your comments Jari; it sounds like everyone is interested in making sure we are on top of the IPR issue, which is good. The purpose for labeling IPR as "defensive" is the same as getting a free license -- it is helpful for those implementing something to know that they will not be targeted for using a technology by predatory licensing practices. I would suppose this technology would be deployed in Linux & BSD by an interested party implementing it as open source. I believe that Nokia already has created and/or specified many, many technologies that have been used in this way, and I don't see why the existing IPR policy or future clarifications within NEMO would have to be any different. As for other companies' IPR, I can not speak for them. Hopefully they would be equally cooperative. Can you suggest a way to ensure that no other companies have any IPR on a possible basic solution that we use? TJ On 6/19/03 11:01 PM, "Jari Arkko" wrote: > > TJ, Hesham, > > I agree with Hesham here. IPRs *are* an issue, and > I'm not sure labeling some of the IPR as "defensive" > is very useful. Here's one practical problem: how does > this technology get deployed in Linux & BSD? If the > IPR licenses grant a free (not just "fair") use, > then we are OK. If not, we have a problem. At the > very least there should be a base solution which is > free of IPRs, even if advanced optimizations etc. > would be IPR-only stuff. > > --Jari > From exim@www1.ietf.org Sun Jun 22 00:09:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22546 for ; Sun, 22 Jun 2003 00:09:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5M48Ym05303 for nemo-archive@odin.ietf.org; Sun, 22 Jun 2003 00:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw9L-0001NJ-BI for nemo-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 00:08:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22525 for ; Sun, 22 Jun 2003 00:08:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tw9J-0002UC-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 00:08:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Tw9D-0002U9-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 00:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw94-0001J4-Eg; Sun, 22 Jun 2003 00:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Tw81-00013N-Qq for nemo@optimus.ietf.org; Sun, 22 Jun 2003 00:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22470 for ; Sun, 22 Jun 2003 00:06:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Tw7k-0002TM-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:06:40 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19Tw7P-0002T5-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:06:19 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5M45JER037331; Sat, 21 Jun 2003 21:05:19 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 Jun 2003 21:04:51 -0700 Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution From: "T.J. Kniveton" To: Jari Arkko , Soliman Hesham CC: Message-ID: In-Reply-To: <3EF2A34E.40501@kolumbus.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your comments Jari; it sounds like everyone is interested in making sure we are on top of the IPR issue, which is good. The purpose for labeling IPR as "defensive" is the same as getting a free license -- it is helpful for those implementing something to know that they will not be targeted for using a technology by predatory licensing practices. I would suppose this technology would be deployed in Linux & BSD by an interested party implementing it as open source. I believe that Nokia already has created and/or specified many, many technologies that have been used in this way, and I don't see why the existing IPR policy or future clarifications within NEMO would have to be any different. As for other companies' IPR, I can not speak for them. Hopefully they would be equally cooperative. Can you suggest a way to ensure that no other companies have any IPR on a possible basic solution that we use? TJ On 6/19/03 11:01 PM, "Jari Arkko" wrote: > > TJ, Hesham, > > I agree with Hesham here. IPRs *are* an issue, and > I'm not sure labeling some of the IPR as "defensive" > is very useful. Here's one practical problem: how does > this technology get deployed in Linux & BSD? If the > IPR licenses grant a free (not just "fair") use, > then we are OK. If not, we have a problem. At the > very least there should be a base solution which is > free of IPRs, even if advanced optimizations etc. > would be IPR-only stuff. > > --Jari > From nemo-admin@ietf.org Sun Jun 22 00:31:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22882 for ; Sun, 22 Jun 2003 00:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TwVI-0001gi-Nx; Sun, 22 Jun 2003 00:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TwUX-0001gH-CI for nemo@optimus.ietf.org; Sun, 22 Jun 2003 00:30:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22843 for ; Sun, 22 Jun 2003 00:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TwUU-0002Xw-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:30:10 -0400 Received: from hank-fep6-0.inet.fi ([194.251.242.201] helo=fep06.tmt.tele.fi) by ietf-mx with esmtp (Exim 4.12) id 19TwUJ-0002Xj-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:30:00 -0400 Received: from [10.105.21.14] ([62.71.9.164]) by fep06.tmt.tele.fi (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20030622042922.HKGR13416.fep06.tmt.tele.fi@[10.105.21.14]>; Sun, 22 Jun 2003 07:29:22 +0300 From: Jari Arkko Reply-to: Jari Arkko To: "T.J. Kniveton" , Soliman Hesham Cc: nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution Date: Sun, 22 Jun 2003 07:29:27 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable It is hard to know what other companies are doing. If they participate this = WG, then in principle they should tell the IETF if they have IPRs, and if = yes, what their licensing conditions are. But lets get back to the Nokia IPR question. I don't find terms such as = defensive or predatory very useful. Have you made a specific IPR claim = about Nemo to the IETF? If yes, does it grant free use to public domain = implementations and other vendor implementations or not? It is typically ok = to require the user to do the same for their IPR if any. This may also help = against at least some of the other IPR holders... --Jari ________________ Reply Header ________________ Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution Author: T.J. Kniveton Date: 21st June 2003 9:04:51 pm Thanks for your comments Jari; it sounds like everyone is interested = in making sure we are on top of the IPR issue, which is good. The purpose = for labeling IPR as "defensive" is the same as getting a free license -- it = is helpful for those implementing something to know that they will not = be targeted for using a technology by predatory licensing practices. I would suppose this technology would be deployed in Linux & BSD by = an interested party implementing it as open source. I believe that Nokia already has created and/or specified many, many technologies that have = been used in this way, and I don't see why the existing IPR policy or = future clarifications within NEMO would have to be any different. As for = other companies' IPR, I can not speak for them. Hopefully they would be = equally cooperative. Can you suggest a way to ensure that no other companies = have any IPR on a possible basic solution that we use? TJ On 6/19/03 11:01 PM, "Jari Arkko" wrote: >=20 > TJ, Hesham, >=20 > I agree with Hesham here. IPRs *are* an issue, and > I'm not sure labeling some of the IPR as "defensive" > is very useful. Here's one practical problem: how does > this technology get deployed in Linux & BSD? If the > IPR licenses grant a free (not just "fair") use, > then we are OK. If not, we have a problem. At the > very least there should be a base solution which is > free of IPRs, even if advanced optimizations etc. > would be IPR-only stuff. >=20 > --Jari >=20 From exim@www1.ietf.org Sun Jun 22 00:31:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22897 for ; Sun, 22 Jun 2003 00:31:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5M4V7A06612 for nemo-archive@odin.ietf.org; Sun, 22 Jun 2003 00:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TwVP-0001iZ-9y for nemo-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 00:31:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22874 for ; Sun, 22 Jun 2003 00:31:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TwVM-0002YZ-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 00:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TwVH-0002YW-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 00:30:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TwVI-0001gi-Nx; Sun, 22 Jun 2003 00:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TwUX-0001gH-CI for nemo@optimus.ietf.org; Sun, 22 Jun 2003 00:30:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22843 for ; Sun, 22 Jun 2003 00:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TwUU-0002Xw-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:30:10 -0400 Received: from hank-fep6-0.inet.fi ([194.251.242.201] helo=fep06.tmt.tele.fi) by ietf-mx with esmtp (Exim 4.12) id 19TwUJ-0002Xj-00 for nemo@ietf.org; Sun, 22 Jun 2003 00:30:00 -0400 Received: from [10.105.21.14] ([62.71.9.164]) by fep06.tmt.tele.fi (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20030622042922.HKGR13416.fep06.tmt.tele.fi@[10.105.21.14]>; Sun, 22 Jun 2003 07:29:22 +0300 From: Jari Arkko Reply-to: Jari Arkko To: "T.J. Kniveton" , Soliman Hesham Cc: nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution Date: Sun, 22 Jun 2003 07:29:27 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It is hard to know what other companies are doing. If they participate this = WG, then in principle they should tell the IETF if they have IPRs, and if = yes, what their licensing conditions are. But lets get back to the Nokia IPR question. I don't find terms such as = defensive or predatory very useful. Have you made a specific IPR claim = about Nemo to the IETF? If yes, does it grant free use to public domain = implementations and other vendor implementations or not? It is typically ok = to require the user to do the same for their IPR if any. This may also help = against at least some of the other IPR holders... --Jari ________________ Reply Header ________________ Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution Author: T.J. Kniveton Date: 21st June 2003 9:04:51 pm Thanks for your comments Jari; it sounds like everyone is interested = in making sure we are on top of the IPR issue, which is good. The purpose = for labeling IPR as "defensive" is the same as getting a free license -- it = is helpful for those implementing something to know that they will not = be targeted for using a technology by predatory licensing practices. I would suppose this technology would be deployed in Linux & BSD by = an interested party implementing it as open source. I believe that Nokia already has created and/or specified many, many technologies that have = been used in this way, and I don't see why the existing IPR policy or = future clarifications within NEMO would have to be any different. As for = other companies' IPR, I can not speak for them. Hopefully they would be = equally cooperative. Can you suggest a way to ensure that no other companies = have any IPR on a possible basic solution that we use? TJ On 6/19/03 11:01 PM, "Jari Arkko" wrote: >=20 > TJ, Hesham, >=20 > I agree with Hesham here. IPRs *are* an issue, and > I'm not sure labeling some of the IPR as "defensive" > is very useful. Here's one practical problem: how does > this technology get deployed in Linux & BSD? If the > IPR licenses grant a free (not just "fair") use, > then we are OK. If not, we have a problem. At the > very least there should be a base solution which is > free of IPRs, even if advanced optimizations etc. > would be IPR-only stuff. >=20 > --Jari >=20 From nemo-admin@ietf.org Sun Jun 22 07:14:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09796 for ; Sun, 22 Jun 2003 07:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nJ-0006Eu-Bg; Sun, 22 Jun 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2lz-0006EM-OF for nemo@optimus.ietf.org; Sun, 22 Jun 2003 07:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09777 for ; Sun, 22 Jun 2003 07:12:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2lk-00040B-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:12:24 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19U2lZ-0003zw-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:12:13 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5MBBZYb024628; Sun, 22 Jun 2003 04:11:36 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.10]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h5MBBMPa019557; Sun, 22 Jun 2003 06:11:26 -0500 Message-ID: <3EF5AAEB.4000509@nal.motlabs.com> Date: Sun, 22 Jun 2003 15:11:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Soliman Hesham , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It is hard to know what other companies are doing. If they > participate this WG, then in principle they should tell the IETF if > they have IPRs, and if yes, what their licensing conditions are. Informally speaking, I've not been asked by my employer to write technical disclosures on any form of basic support for NEMO. Neither have I asked my employer to pursue protection of such ideas. Alex GBU From exim@www1.ietf.org Sun Jun 22 07:14:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09823 for ; Sun, 22 Jun 2003 07:14:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MBECH24078 for nemo-archive@odin.ietf.org; Sun, 22 Jun 2003 07:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nU-0006GG-B6 for nemo-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 07:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09788 for ; Sun, 22 Jun 2003 07:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2nT-00040T-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 07:14:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19U2nO-00040N-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 07:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nJ-0006Eu-Bg; Sun, 22 Jun 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2lz-0006EM-OF for nemo@optimus.ietf.org; Sun, 22 Jun 2003 07:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09777 for ; Sun, 22 Jun 2003 07:12:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2lk-00040B-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:12:24 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19U2lZ-0003zw-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:12:13 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5MBBZYb024628; Sun, 22 Jun 2003 04:11:36 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.10]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h5MBBMPa019557; Sun, 22 Jun 2003 06:11:26 -0500 Message-ID: <3EF5AAEB.4000509@nal.motlabs.com> Date: Sun, 22 Jun 2003 15:11:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Soliman Hesham , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It is hard to know what other companies are doing. If they > participate this WG, then in principle they should tell the IETF if > they have IPRs, and if yes, what their licensing conditions are. Informally speaking, I've not been asked by my employer to write technical disclosures on any form of basic support for NEMO. Neither have I asked my employer to pursue protection of such ideas. Alex GBU From nemo-admin@ietf.org Sun Jun 22 08:03:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09797 for ; Sun, 22 Jun 2003 07:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nJ-0006Em-0v; Sun, 22 Jun 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2mb-0006ES-NG for nemo@optimus.ietf.org; Sun, 22 Jun 2003 07:13:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09781 for ; Sun, 22 Jun 2003 07:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2mb-00040H-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:13:17 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19U2mQ-00040E-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:13:06 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5MBChEe026572; Sun, 22 Jun 2003 04:12:44 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.10]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h5MBCUPa019916; Sun, 22 Jun 2003 06:12:34 -0500 Message-ID: <3EF5AB30.7010509@nal.motlabs.com> Date: Sun, 22 Jun 2003 15:12:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Soliman Hesham , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It is hard to know what other companies are doing. If they > participate this WG, then in principle they should tell the IETF if > they have IPRs, and if yes, what their licensing conditions are. Informally speaking, I've not been asked by my employer to write technical disclosures on any form of basic support for NEMO. Neither have I asked my employer to pursue protection of said support. Alex GBU From exim@www1.ietf.org Sun Jun 22 08:03:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09824 for ; Sun, 22 Jun 2003 07:14:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MBECt24094 for nemo-archive@odin.ietf.org; Sun, 22 Jun 2003 07:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nU-0006GH-CM for nemo-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 07:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09789 for ; Sun, 22 Jun 2003 07:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2nT-00040Q-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 07:14:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19U2nN-00040M-00 for nemo-web-archive@ietf.org; Sun, 22 Jun 2003 07:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2nJ-0006Em-0v; Sun, 22 Jun 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19U2mb-0006ES-NG for nemo@optimus.ietf.org; Sun, 22 Jun 2003 07:13:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09781 for ; Sun, 22 Jun 2003 07:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19U2mb-00040H-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:13:17 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19U2mQ-00040E-00 for nemo@ietf.org; Sun, 22 Jun 2003 07:13:06 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5MBChEe026572; Sun, 22 Jun 2003 04:12:44 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.10]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h5MBCUPa019916; Sun, 22 Jun 2003 06:12:34 -0500 Message-ID: <3EF5AB30.7010509@nal.motlabs.com> Date: Sun, 22 Jun 2003 15:12:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Soliman Hesham , nemo@ietf.org Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It is hard to know what other companies are doing. If they > participate this WG, then in principle they should tell the IETF if > they have IPRs, and if yes, what their licensing conditions are. Informally speaking, I've not been asked by my employer to write technical disclosures on any form of basic support for NEMO. Neither have I asked my employer to pursue protection of said support. Alex GBU From nemo-admin@ietf.org Sun Jun 22 17:43:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19274 for ; Sun, 22 Jun 2003 17:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCc1-0004Gg-CH; Sun, 22 Jun 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T1Ml-0007iV-77 for nemo@optimus.ietf.org; Thu, 19 Jun 2003 11:30:23 -0400 Received: from mail1.hanmir.com ([211.39.138.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25362 for ; Thu, 19 Jun 2003 11:30:19 -0400 (EDT) Received: (from nobody@localhost) by mail1.hanmir.com (8.9.3/8.9.3) id AAA08505; Fri, 20 Jun 2003 00:20:01 +0900 (KST) Date: Fri, 20 Jun 2003 00:20:01 +0900 (KST) Message-Id: <200306191520.AAA08505@mail1.hanmir.com> To: cwng@psl.com.sg, nemo@ietf.org Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: "Paik, Eun Kyoung" Reply-To: "Paik, Eun Kyoung" Content-Type: text/html; charset=euc-kr Status: O Content-Transfer-Encoding: 8bit X-Mailer: HanMir Mailer X-IP: 220.121.192.22 X-html: 1 Content-Transfer-Encoding: 8bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Hi Chan-wah,

The taxonomy of your draft is very clear. Thank you for your work.

While I was working on multi-homed NEMO, I have found many problems
other than the listed problems in your draft (at the end of section 4).
The problems. e.g. BU, egress selection, etc., are differ as the taxonomy.

IMHO, we'd better to define the problems and make a consensus on them,
since R12 in the requirement draft defines that the NEMO solution must function for multihoming.

Regards,
Eun Kyoung Paik
Seoul National University

> -----Original Message-----
> From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of Chan-
> Wah Ng
> Sent: Monday, May 26, 2003 6:56 PM
> To: IETF NEMO WG
> Subject: [nemo] draft-ng-nemo-multihoming-issues-01.txt
>
>
> Hello, all,
>
> We have submitted a new version of the multihoming draft for
> publication. It might take sometime for the draft to appear in the IETF
> repository. Meanwhile, it can be accessed via the following link:
>
> http://www.sfc.wide.ad.jp/~julien/papers/draft-ng-nemo-multihoming
> -issues-01.txt
>
> Please give us your comments. Hopefully, we can get it updated and
> ready for discussion by the Vienna IETF.
>
> Thanks.
>
> --
> Chan-Wah Ng
> Panasonic Singapore Laboratories
>
>


____________________________________________________________________________

Unique & Best, Çѹ̸£ ¾Æ¹ÙŸ! (http://avatar.hanmir.com/)


From nemo-admin@ietf.org Mon Jun 23 03:50:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11884 for ; Mon, 23 Jun 2003 03:50:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UM5T-000691-9u; Mon, 23 Jun 2003 03:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UM4c-00067v-M7 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 03:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11823 for ; Mon, 23 Jun 2003 03:49:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UM4a-0000L1-00 for nemo@ietf.org; Mon, 23 Jun 2003 03:49:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19UM4P-0000Ko-00 for nemo@ietf.org; Mon, 23 Jun 2003 03:48:57 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 09:48:33 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5N7kKTq026720; Mon, 23 Jun 2003 09:46:20 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 09:48:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Mon, 23 Jun 2003 08:48:15 +0100 Message-ID: Thread-Topic: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM5B1IGhkpy9msrRyKJhKt5i6Qp2AAU3rxgAAAsbHA= From: "Pascal Thubert (pthubert)" To: , <'cwng@psl.com.sg>, X-OriginalArrivalTime: 23 Jun 2003 07:48:15.0737 (UTC) FILETIME=[CDFF3E90:01C3395B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Some spam filter dropped this mail. Resending > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: lundi 23 juin 2003 09:43 > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi Eun Kyoung, >=20 > This is also what I tried to do :) >=20 > Did you get the threads talking about the problems named Tarzan, Shinkansen, JetSet and > DoubleBed? >=20 > Pascal >=20 > -----Original Message----- > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > Sent: jeudi 19 juin 2003 17:20 > To: cwng@psl.com.sg; nemo@ietf.org > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi all, Hi Chan-wah, >=20 > The taxonomy of your draft is very clear. Thank you for your work. >=20 > While I was working on multi-homed NEMO, I have found many problems > other than the listed problems in your draft (at the end of section 4). > The problems. e.g. BU, egress selection, etc., are differ as the taxonomy. >=20 > IMHO, we'd better to define the problems and make a consensus on them, > since R12 in the requirement draft defines that the NEMO solution must function for > multihoming. >=20 > Regards, > Eun Kyoung Paik > Seoul National University From exim@www1.ietf.org Mon Jun 23 03:50:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11900 for ; Mon, 23 Jun 2003 03:50:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N7oTl23678 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 03:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UM5t-00069p-8Y for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 03:50:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11876 for ; Mon, 23 Jun 2003 03:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UM5q-0000Ln-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 03:50:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UM5k-0000Lh-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 03:50:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UM5T-000691-9u; Mon, 23 Jun 2003 03:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UM4c-00067v-M7 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 03:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11823 for ; Mon, 23 Jun 2003 03:49:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UM4a-0000L1-00 for nemo@ietf.org; Mon, 23 Jun 2003 03:49:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19UM4P-0000Ko-00 for nemo@ietf.org; Mon, 23 Jun 2003 03:48:57 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 09:48:33 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5N7kKTq026720; Mon, 23 Jun 2003 09:46:20 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 09:48:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Mon, 23 Jun 2003 08:48:15 +0100 Message-ID: Thread-Topic: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM5B1IGhkpy9msrRyKJhKt5i6Qp2AAU3rxgAAAsbHA= From: "Pascal Thubert (pthubert)" To: , <'cwng@psl.com.sg>, X-OriginalArrivalTime: 23 Jun 2003 07:48:15.0737 (UTC) FILETIME=[CDFF3E90:01C3395B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Some spam filter dropped this mail. Resending > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: lundi 23 juin 2003 09:43 > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi Eun Kyoung, >=20 > This is also what I tried to do :) >=20 > Did you get the threads talking about the problems named Tarzan, Shinkansen, JetSet and > DoubleBed? >=20 > Pascal >=20 > -----Original Message----- > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > Sent: jeudi 19 juin 2003 17:20 > To: cwng@psl.com.sg; nemo@ietf.org > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi all, Hi Chan-wah, >=20 > The taxonomy of your draft is very clear. Thank you for your work. >=20 > While I was working on multi-homed NEMO, I have found many problems > other than the listed problems in your draft (at the end of section 4). > The problems. e.g. BU, egress selection, etc., are differ as the taxonomy. >=20 > IMHO, we'd better to define the problems and make a consensus on them, > since R12 in the requirement draft defines that the NEMO solution must function for > multihoming. >=20 > Regards, > Eun Kyoung Paik > Seoul National University From nemo-admin@ietf.org Mon Jun 23 04:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12274 for ; Mon, 23 Jun 2003 04:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMI1-0006dP-Fw; Mon, 23 Jun 2003 04:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMHQ-0006d6-L1 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:02:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12248 for ; Mon, 23 Jun 2003 04:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMH9-0000RP-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:02:07 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19UMGt-0000R7-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:01:56 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Mon, 23 Jun 2003 18:00:32 +1000 From: "Muhammad Ali Malik" To: Date: Mon, 23 Jun 2003 18:00:29 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C339B1.5520BF70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] MR care-of-address Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C339B1.5520BF70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I just want to confirm that In order to support network transparency for mobile network node, do we need to have single care-of-address for mobile router on behalf of mobile network. This means that when mobile network moves, the mobile router will only obtain the care-of-address in foreign location. Cheers Muhammad ------=_NextPart_000_001E_01C339B1.5520BF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I just want to confirm that In order to support network = transparency for mobile network node, do we need to have single care-of-address for = mobile router on behalf of mobile network.

 

This means that when mobile network moves, the mobile router will = only obtain the care-of-address in foreign = location.

 

Cheers

Muhammad

 

 

------=_NextPart_000_001E_01C339B1.5520BF70-- From exim@www1.ietf.org Mon Jun 23 04:03:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12289 for ; Mon, 23 Jun 2003 04:03:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N838I25627 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 04:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMI8-0006fG-S3 for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 04:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12262 for ; Mon, 23 Jun 2003 04:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMI6-0000Rm-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:03:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UMI0-0000Rj-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMI1-0006dP-Fw; Mon, 23 Jun 2003 04:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMHQ-0006d6-L1 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:02:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12248 for ; Mon, 23 Jun 2003 04:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMH9-0000RP-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:02:07 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19UMGt-0000R7-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:01:56 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Mon, 23 Jun 2003 18:00:32 +1000 From: "Muhammad Ali Malik" To: Date: Mon, 23 Jun 2003 18:00:29 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C339B1.5520BF70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] MR care-of-address Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C339B1.5520BF70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I just want to confirm that In order to support network transparency for mobile network node, do we need to have single care-of-address for mobile router on behalf of mobile network. This means that when mobile network moves, the mobile router will only obtain the care-of-address in foreign location. Cheers Muhammad ------=_NextPart_000_001E_01C339B1.5520BF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I just want to confirm that In order to support network = transparency for mobile network node, do we need to have single care-of-address for = mobile router on behalf of mobile network.

 

This means that when mobile network moves, the mobile router will = only obtain the care-of-address in foreign = location.

 

Cheers

Muhammad

 

 

------=_NextPart_000_001E_01C339B1.5520BF70-- From nemo-admin@ietf.org Mon Jun 23 04:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12586 for ; Mon, 23 Jun 2003 04:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMUe-00075O-7a; Mon, 23 Jun 2003 04:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMTG-00073W-CF for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12516 for ; Mon, 23 Jun 2003 04:14:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMSy-0000VQ-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:14:20 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19UMSn-0000Um-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:14:09 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5N85T425882; Mon, 23 Jun 2003 16:05:29 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 3F40210E95DA; Mon, 23 Jun 2003 16:13:06 +0800 (SGT) Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: eun007@hanmir.com, IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056355985.1806.20.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 23 Jun 2003 16:13:06 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Pascal and Eun Kyoung, On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > Some spam filter dropped this mail. Resending > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO mailing list. > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: lundi 23 juin 2003 09:43 > > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > Hi Eun Kyoung, > > > > This is also what I tried to do :) > > > > Did you get the threads talking about the problems named Tarzan, > Shinkansen, JetSet and > > DoubleBed? > > By the way, Pascal, now that the multihoming draft is published and I have attempted to list the problems, what are your comments? Is is it in line with your problem set? /rgds /cwng From exim@www1.ietf.org Mon Jun 23 04:16:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12601 for ; Mon, 23 Jun 2003 04:16:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N8GDU27480 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 04:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMUm-000799-3n for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 04:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12552 for ; Mon, 23 Jun 2003 04:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMUj-0000W6-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:16:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UMUd-0000W3-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMUe-00075O-7a; Mon, 23 Jun 2003 04:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMTG-00073W-CF for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12516 for ; Mon, 23 Jun 2003 04:14:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMSy-0000VQ-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:14:20 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19UMSn-0000Um-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:14:09 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5N85T425882; Mon, 23 Jun 2003 16:05:29 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 3F40210E95DA; Mon, 23 Jun 2003 16:13:06 +0800 (SGT) Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: eun007@hanmir.com, IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056355985.1806.20.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 23 Jun 2003 16:13:06 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Pascal and Eun Kyoung, On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > Some spam filter dropped this mail. Resending > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO mailing list. > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: lundi 23 juin 2003 09:43 > > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > Hi Eun Kyoung, > > > > This is also what I tried to do :) > > > > Did you get the threads talking about the problems named Tarzan, > Shinkansen, JetSet and > > DoubleBed? > > By the way, Pascal, now that the multihoming draft is published and I have attempted to list the problems, what are your comments? Is is it in line with your problem set? /rgds /cwng From nemo-admin@ietf.org Mon Jun 23 04:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12640 for ; Mon, 23 Jun 2003 04:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMVZ-0007C9-5K; Mon, 23 Jun 2003 04:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMVN-0007Bg-1v for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12585 for ; Mon, 23 Jun 2003 04:16:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMV5-0000Wb-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:16:31 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19UMUu-0000Vs-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:16:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h5N8FrP1011346; Mon, 23 Jun 2003 01:15:53 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5N8FnHh008237; Mon, 23 Jun 2003 03:15:51 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DC3CB2EC95; Mon, 23 Jun 2003 10:15:47 +0200 (CEST) Message-ID: <3EF6B733.2060101@motorola.com> Date: Mon, 23 Jun 2003 10:15:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] MR care-of-address References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > Hi > > I just want to confirm that In order to support network transparency > for mobile network node, do we need to have single care-of-address > for mobile router on behalf of mobile network. I think yes. I think that if a Mobile Node visits a mobile network then the Mobile Node will obtain a Care-of Address for itself (which is different than the Care-of Address of the Mobile Router). > This means that when mobile network moves, the mobile router will > only obtain the care-of-address in foreign location. I think yes. But what is your doubt, why wouldn't that suffice? Alex GBU From exim@www1.ietf.org Mon Jun 23 04:17:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12657 for ; Mon, 23 Jun 2003 04:17:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N8H7g27906 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 04:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMVf-0007G1-A7 for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 04:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12628 for ; Mon, 23 Jun 2003 04:17:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMVc-0000X1-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UMVX-0000Wy-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:16:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMVZ-0007C9-5K; Mon, 23 Jun 2003 04:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMVN-0007Bg-1v for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12585 for ; Mon, 23 Jun 2003 04:16:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMV5-0000Wb-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:16:31 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19UMUu-0000Vs-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:16:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h5N8FrP1011346; Mon, 23 Jun 2003 01:15:53 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5N8FnHh008237; Mon, 23 Jun 2003 03:15:51 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DC3CB2EC95; Mon, 23 Jun 2003 10:15:47 +0200 (CEST) Message-ID: <3EF6B733.2060101@motorola.com> Date: Mon, 23 Jun 2003 10:15:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] MR care-of-address References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > Hi > > I just want to confirm that In order to support network transparency > for mobile network node, do we need to have single care-of-address > for mobile router on behalf of mobile network. I think yes. I think that if a Mobile Node visits a mobile network then the Mobile Node will obtain a Care-of Address for itself (which is different than the Care-of Address of the Mobile Router). > This means that when mobile network moves, the mobile router will > only obtain the care-of-address in foreign location. I think yes. But what is your doubt, why wouldn't that suffice? Alex GBU From nemo-admin@ietf.org Mon Jun 23 04:57:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13258 for ; Mon, 23 Jun 2003 04:57:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMnx-0007ZW-Di; Mon, 23 Jun 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMnd-0007ZB-HE for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:35:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12915 for ; Mon, 23 Jun 2003 04:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMnL-0000bM-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:35:23 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19UMnA-0000bH-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:35:12 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 41E005B344; Mon, 23 Jun 2003 16:39:24 +0800 (HKT) From: Wanrong Yu To: Alexandru Petrescu Reply-To: Wanrong Yu Cc: nemo@ietf.org References: <3EF6B733.2060101@motorola.com> In-Reply-To: <3EF6B733.2060101@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030623083924.41E005B344@ds20.nudt.edu.cn> Date: Mon, 23 Jun 2003 16:39:24 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBNUiBjYXJlLW9mLWFkZHJlc3M=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Alexandru Petrescu wrote > Muhammad Ali Malik wrote: > > Hi > > > > I just want to confirm that In order to support network transparency > > for mobile network node, do we need to have single care-of-address > > for mobile router on behalf of mobile network. > > I think yes. > > I think that if a Mobile Node visits a mobile network then the Mobile > Node will obtain a Care-of Address for itself (which is different than > the Care-of Address of the Mobile Router). > > > This means that when mobile network moves, the mobile router will > > only obtain the care-of-address in foreign location. > > I think yes. But what is your doubt, why wouldn't that suffice? But how about multiple CoA? I think MR should have the ability to obtain multiple CoA as mobile host will be. Wanrong Yu From exim@www1.ietf.org Mon Jun 23 05:46:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14067 for ; Mon, 23 Jun 2003 05:46:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N9kCm04235 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 05:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNts-00016E-E3 for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 05:46:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14054 for ; Mon, 23 Jun 2003 05:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNto-0000t5-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 05:46:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UNtj-0000t2-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 05:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNth-00014Q-60; Mon, 23 Jun 2003 05:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNt0-000149-1z for nemo@optimus.ietf.org; Mon, 23 Jun 2003 05:45:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14025 for ; Mon, 23 Jun 2003 05:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNsw-0000sh-00 for nemo@ietf.org; Mon, 23 Jun 2003 05:45:14 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19UNsl-0000sU-00 for nemo@ietf.org; Mon, 23 Jun 2003 05:45:03 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 11:44:34 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5N9gKTx023040; Mon, 23 Jun 2003 11:42:21 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 11:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Mon, 23 Jun 2003 10:44:21 +0100 Message-ID: Thread-Topic: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM5X0X2DRPD0ZGIQhyjQtm+ybuRQwADFAaA From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 23 Jun 2003 09:44:22.0079 (UTC) FILETIME=[0642ACF0:01C3396C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Chan Wah: I need some time on that one :) Pascal > -----Original Message----- > From: Chan-Wah Ng [mailto:cwng@psl.com.sg] > Sent: lundi 23 juin 2003 10:13 > To: Pascal Thubert (pthubert) > Cc: eun007@hanmir.com; IETF NEMO WG > Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hello, Pascal and Eun Kyoung, >=20 > On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > > Some spam filter dropped this mail. Resending > > > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO > mailing list. >=20 > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) > > > Sent: lundi 23 juin 2003 09:43 > > > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > > > Hi Eun Kyoung, > > > > > > This is also what I tried to do :) > > > > > > Did you get the threads talking about the problems named Tarzan, > > Shinkansen, JetSet and > > > DoubleBed? > > > >=20 > By the way, Pascal, now that the multihoming draft is published and I > have attempted to list the problems, what are your comments? Is is it > in line with your problem set? >=20 > /rgds > /cwng From nemo-admin@ietf.org Mon Jun 23 06:33:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14066 for ; Mon, 23 Jun 2003 05:46:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNth-00014Q-60; Mon, 23 Jun 2003 05:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNt0-000149-1z for nemo@optimus.ietf.org; Mon, 23 Jun 2003 05:45:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14025 for ; Mon, 23 Jun 2003 05:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNsw-0000sh-00 for nemo@ietf.org; Mon, 23 Jun 2003 05:45:14 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19UNsl-0000sU-00 for nemo@ietf.org; Mon, 23 Jun 2003 05:45:03 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 11:44:34 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5N9gKTx023040; Mon, 23 Jun 2003 11:42:21 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 11:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Mon, 23 Jun 2003 10:44:21 +0100 Message-ID: Thread-Topic: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM5X0X2DRPD0ZGIQhyjQtm+ybuRQwADFAaA From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 23 Jun 2003 09:44:22.0079 (UTC) FILETIME=[0642ACF0:01C3396C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Chan Wah: I need some time on that one :) Pascal > -----Original Message----- > From: Chan-Wah Ng [mailto:cwng@psl.com.sg] > Sent: lundi 23 juin 2003 10:13 > To: Pascal Thubert (pthubert) > Cc: eun007@hanmir.com; IETF NEMO WG > Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hello, Pascal and Eun Kyoung, >=20 > On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > > Some spam filter dropped this mail. Resending > > > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO > mailing list. >=20 > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) > > > Sent: lundi 23 juin 2003 09:43 > > > To: 'Paik, Eun Kyoung'; 'cwng@psl.com.sg'; 'nemo@ietf.org' > > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > > > Hi Eun Kyoung, > > > > > > This is also what I tried to do :) > > > > > > Did you get the threads talking about the problems named Tarzan, > > Shinkansen, JetSet and > > > DoubleBed? > > > >=20 > By the way, Pascal, now that the multihoming draft is published and I > have attempted to list the problems, what are your comments? Is is it > in line with your problem set? >=20 > /rgds > /cwng From nemo-admin@ietf.org Mon Jun 23 14:01:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01400 for ; Mon, 23 Jun 2003 14:01:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVcj-0005Bb-9B; Mon, 23 Jun 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVcb-0005Ar-Q0 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 14:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01335 for ; Mon, 23 Jun 2003 14:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVcK-0004K5-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:00:36 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19UVby-0004Jd-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:00:15 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5NHxhER043341 for ; Mon, 23 Jun 2003 10:59:43 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 Jun 2003 10:59:11 -0700 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Design Team draft for NEMO Basic Solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic Support Protocol draft. After the last few months of work by Vijay, Ryuji, Alexandru, and Pascal (and some help from Thierry and myself), we would like to share the results with the larger WG audience and open it up for comments and suggestions. You may download the draft from http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt Thanks, TJ, Thierry, & NEMO DT From exim@www1.ietf.org Mon Jun 23 14:01:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01416 for ; Mon, 23 Jun 2003 14:01:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NI1D320091 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 14:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVcv-0005Dy-LU for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 14:01:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01376 for ; Mon, 23 Jun 2003 14:01:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVct-0004KX-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 14:01:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UVcn-0004KU-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 14:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVcj-0005Bb-9B; Mon, 23 Jun 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVcb-0005Ar-Q0 for nemo@optimus.ietf.org; Mon, 23 Jun 2003 14:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01335 for ; Mon, 23 Jun 2003 14:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVcK-0004K5-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:00:36 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19UVby-0004Jd-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:00:15 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5NHxhER043341 for ; Mon, 23 Jun 2003 10:59:43 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 Jun 2003 10:59:11 -0700 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Design Team draft for NEMO Basic Solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic Support Protocol draft. After the last few months of work by Vijay, Ryuji, Alexandru, and Pascal (and some help from Thierry and myself), we would like to share the results with the larger WG audience and open it up for comments and suggestions. You may download the draft from http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt Thanks, TJ, Thierry, & NEMO DT From nemo-admin@ietf.org Mon Jun 23 14:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02822 for ; Mon, 23 Jun 2003 14:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UW0v-00062a-Ch; Mon, 23 Jun 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzj-0005oX-0J for nemo@optimus.ietf.org; Mon, 23 Jun 2003 14:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02567 for ; Mon, 23 Jun 2003 14:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVfC-0004MQ-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:03:34 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19UVem-0004Kp-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:03:13 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5NI2UER043361; Mon, 23 Jun 2003 11:02:31 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 Jun 2003 11:01:58 -0700 Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution From: "T.J. Kniveton" To: Jari Arkko CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 6/21/03 10:29 PM, "Jari Arkko" wrote: > It is hard to know what other companies are doing. If they participate this > WG, then in principle they should tell the IETF if they have IPRs, and if yes, > what their licensing conditions are. > > But lets get back to the Nokia IPR question. I don't find terms such as > defensive or predatory very useful. Have you made a specific IPR claim about > Nemo to the IETF? If yes, does it grant free use to public domain > implementations and other vendor implementations or not? It is typically ok to > require the user to do the same for their IPR if any. This may also help > against at least some of the other IPR holders... > > --Jari > Yes, when we submitted the original draft, I expressed that we have possible IPR claims on it, spoke with an AD, and gave him all the information he requested regarding the IPR. There is an IPR section in the draft, and Nokia complies with all IETF IPR guidelines and requirements. As for the related IPR to the NEMO draft, it was impossible to say what applies before the draft was completed (i.e. today) and/or possible patents issued. As I said in the prior e-mails, I have spoken with our attorneys and they intend to make appropriate arrangements as will be requested by the IETF. You said you don't like the terms "defensive" or "predatory", and they are only helpful insofar as there is some amount of uncertainty and unknown regarding many IPR questions and how companies could use their IPR in the future to make claims or agreements. But I agree with you that it is better to talk about specific terms and definite claims regarding the technology we're looking at. Nevertheless, there is no specific licensing statement regarding this particular draft, yet, so it's not possible to share it with you, yet. I have given all the information I personally have at the moment. TJ From exim@www1.ietf.org Mon Jun 23 14:27:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02857 for ; Mon, 23 Jun 2003 14:27:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIQZQ24058 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 14:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UW1T-0006Fx-OL for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 14:26:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02818 for ; Mon, 23 Jun 2003 14:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UW0v-00062a-Ch; Mon, 23 Jun 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzj-0005oX-0J for nemo@optimus.ietf.org; Mon, 23 Jun 2003 14:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02567 for ; Mon, 23 Jun 2003 14:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVfC-0004MQ-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:03:34 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19UVem-0004Kp-00 for nemo@ietf.org; Mon, 23 Jun 2003 14:03:13 -0400 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h5NI2UER043361; Mon, 23 Jun 2003 11:02:31 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 Jun 2003 11:01:58 -0700 Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution From: "T.J. Kniveton" To: Jari Arkko CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 6/21/03 10:29 PM, "Jari Arkko" wrote: > It is hard to know what other companies are doing. If they participate this > WG, then in principle they should tell the IETF if they have IPRs, and if yes, > what their licensing conditions are. > > But lets get back to the Nokia IPR question. I don't find terms such as > defensive or predatory very useful. Have you made a specific IPR claim about > Nemo to the IETF? If yes, does it grant free use to public domain > implementations and other vendor implementations or not? It is typically ok to > require the user to do the same for their IPR if any. This may also help > against at least some of the other IPR holders... > > --Jari > Yes, when we submitted the original draft, I expressed that we have possible IPR claims on it, spoke with an AD, and gave him all the information he requested regarding the IPR. There is an IPR section in the draft, and Nokia complies with all IETF IPR guidelines and requirements. As for the related IPR to the NEMO draft, it was impossible to say what applies before the draft was completed (i.e. today) and/or possible patents issued. As I said in the prior e-mails, I have spoken with our attorneys and they intend to make appropriate arrangements as will be requested by the IETF. You said you don't like the terms "defensive" or "predatory", and they are only helpful insofar as there is some amount of uncertainty and unknown regarding many IPR questions and how companies could use their IPR in the future to make claims or agreements. But I agree with you that it is better to talk about specific terms and definite claims regarding the technology we're looking at. Nevertheless, there is no specific licensing statement regarding this particular draft, yet, so it's not possible to share it with you, yet. I have given all the information I personally have at the moment. TJ From nemo-admin@ietf.org Mon Jun 23 17:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11506 for ; Mon, 23 Jun 2003 17:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZ7V-0005wC-Bx; Mon, 23 Jun 2003 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZ5w-0005vf-Ut for nemo@optimus.ietf.org; Mon, 23 Jun 2003 17:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11473 for ; Mon, 23 Jun 2003 17:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZ5u-0005xV-00 for nemo@ietf.org; Mon, 23 Jun 2003 17:43:22 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19UZ5j-0005xN-00 for nemo@ietf.org; Mon, 23 Jun 2003 17:43:11 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5N8OkYb029489; Mon, 23 Jun 2003 01:24:46 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5N8Oi0J018582; Mon, 23 Jun 2003 03:24:45 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 32A2F2EC8B; Mon, 23 Jun 2003 10:24:44 +0200 (CEST) Message-ID: <3EF6B94B.1020803@motorola.com> Date: Mon, 23 Jun 2003 10:24:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "Pascal \"Thubert (pthubert)\"" , eun007@hanmir.com, IETF NEMO WG References: <1056355985.1806.20.camel@beethoven> In-Reply-To: <1056355985.1806.20.camel@beethoven> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] admin (was: draft-ng-nemo-multihoming-issues-01.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > Hello, Pascal and Eun Kyoung, > > On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > >> Some spam filter dropped this mail. Resending >> > > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO > mailing list. Mail delivery might have something to do with the encoding of the language that was used to post. I know the language was English, but encoding of English was probably not English, I don't know. So i fyou have time you might have a look at an email "spamcontrol" managed by IETF that nemo-admin received related to the message in question, and teach us what happened (I can send that in private). Alex GBU From exim@www1.ietf.org Mon Jun 23 17:45:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11525 for ; Mon, 23 Jun 2003 17:45:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLjA522882 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 17:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZ7e-0005wz-06 for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 17:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11496 for ; Mon, 23 Jun 2003 17:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZ7b-0005xh-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 17:45:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UZ7V-0005xe-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 17:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZ7V-0005wC-Bx; Mon, 23 Jun 2003 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZ5w-0005vf-Ut for nemo@optimus.ietf.org; Mon, 23 Jun 2003 17:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11473 for ; Mon, 23 Jun 2003 17:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZ5u-0005xV-00 for nemo@ietf.org; Mon, 23 Jun 2003 17:43:22 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19UZ5j-0005xN-00 for nemo@ietf.org; Mon, 23 Jun 2003 17:43:11 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5N8OkYb029489; Mon, 23 Jun 2003 01:24:46 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5N8Oi0J018582; Mon, 23 Jun 2003 03:24:45 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 32A2F2EC8B; Mon, 23 Jun 2003 10:24:44 +0200 (CEST) Message-ID: <3EF6B94B.1020803@motorola.com> Date: Mon, 23 Jun 2003 10:24:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "Pascal \"Thubert (pthubert)\"" , eun007@hanmir.com, IETF NEMO WG References: <1056355985.1806.20.camel@beethoven> In-Reply-To: <1056355985.1806.20.camel@beethoven> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] admin (was: draft-ng-nemo-multihoming-issues-01.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > Hello, Pascal and Eun Kyoung, > > On Mon, 2003-06-23 at 15:48, Pascal Thubert (pthubert) wrote: > >> Some spam filter dropped this mail. Resending >> > > Yep, it puzzle me why Eun Kyoung's mail is not reflected on the NEMO > mailing list. Mail delivery might have something to do with the encoding of the language that was used to post. I know the language was English, but encoding of English was probably not English, I don't know. So i fyou have time you might have a look at an email "spamcontrol" managed by IETF that nemo-admin received related to the message in question, and teach us what happened (I can send that in private). Alex GBU From nemo-admin@ietf.org Mon Jun 23 23:49:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20142 for ; Mon, 23 Jun 2003 23:49:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uenl-0006uy-Jq; Mon, 23 Jun 2003 23:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UenG-0006um-Vb for nemo@optimus.ietf.org; Mon, 23 Jun 2003 23:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20130 for ; Mon, 23 Jun 2003 23:48:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UenE-0007mH-00 for nemo@ietf.org; Mon, 23 Jun 2003 23:48:28 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Uen3-0007m7-00 for nemo@ietf.org; Mon, 23 Jun 2003 23:48:18 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5O446h08912; Tue, 24 Jun 2003 13:04:06 +0900 (KST) (envelope-from eun) Date: Tue, 24 Jun 2003 13:04:06 +0900 From: eun To: cwng@psl.com.sg Cc: nemo@ietf.org Subject: RE:[nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030624130406.A8802@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Chan-Wah, Thank you for your comments. Please see inlines. > > If we allow multiple BU with multiple CoAs(Care of Prefixes) of > > multiple MRs, > > HA may select the egress interface. > > I think you meant this: "given two routes to the same network prefix, HA > has to make the selection which route to use." Yes. > It can be based on routing metric, load balancing, or even just a > default route selection. There shouldn't be any problem in doing that. Maybe it is just an implementation issue. Or we may propose something optimal for NEMO. I wonder what people in NEMO maling list think. > > We may also consider the cases that MRs or MNNs select the egress > > interface, however. > > For example, let's imagine the situation as follows. > > There is a big vehicle supports NEMO with multiple MRs. > > As time goes, availability may differes from egress interface to > > egress interface. > > Then, MRs should know and decide which MR's egress interface is > > connected to > > the Internet. So, MRs need to communicate with each other. > > In this case, MRs select the egress interface as their availability, > > don't they ? > > > Right, but I am not too sure if communications between MRs is within the > scope of NEMO. I don't know if you have read the -00 version of the > multihomng draft, but in there, I have described a simple solution to > solve this without requiring special communications. The solution is > left out of the -01 draft since we want to first identify the problem > before describing solution. > > Anyway, here is a brief description: each MR will actively listen to > the RA in their ingress link(s) to detect the presence of another router > which advertise an egress route to the Internet (lifetime!=0). When an > MR looses its egress link, it can then set up a temporary tunnel with > its HA that passes through the other MR. This way, we don't need any > special communications between MRs, and the MR can decide which route to > use specifically. > > Another way to do it is for the MR to simply response with an ICMP > re-direct message when it looses its egress link. > > The first way, the lost of egress link is transparent to MNNs. The > second way, the MR inform MNNs that it has lost a route, and force MNNs > to re-direct their packets to other MRs. The first way is included in what I called "communication between MRs". They listen each other MR's RA and set up tunnel. (If you think the term "communication" is not appropriate for this, i.e. just exchange signaling for tunnel set-up, we may paraphrase it.) The second way does not seem to provide mobility transparency to MNNs. So, it is not recommandable, IMHO. Regards, Eun Kyoung From exim@www1.ietf.org Mon Jun 23 23:49:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20157 for ; Mon, 23 Jun 2003 23:49:44 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O3nH226645 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 23:49:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ueo1-0006vg-8Q for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 23:49:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20134 for ; Mon, 23 Jun 2003 23:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uenz-0007mR-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 23:49:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uent-0007mO-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 23:49:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uenl-0006uy-Jq; Mon, 23 Jun 2003 23:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UenG-0006um-Vb for nemo@optimus.ietf.org; Mon, 23 Jun 2003 23:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20130 for ; Mon, 23 Jun 2003 23:48:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UenE-0007mH-00 for nemo@ietf.org; Mon, 23 Jun 2003 23:48:28 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Uen3-0007m7-00 for nemo@ietf.org; Mon, 23 Jun 2003 23:48:18 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5O446h08912; Tue, 24 Jun 2003 13:04:06 +0900 (KST) (envelope-from eun) Date: Tue, 24 Jun 2003 13:04:06 +0900 From: eun To: cwng@psl.com.sg Cc: nemo@ietf.org Subject: RE:[nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030624130406.A8802@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Chan-Wah, Thank you for your comments. Please see inlines. > > If we allow multiple BU with multiple CoAs(Care of Prefixes) of > > multiple MRs, > > HA may select the egress interface. > > I think you meant this: "given two routes to the same network prefix, HA > has to make the selection which route to use." Yes. > It can be based on routing metric, load balancing, or even just a > default route selection. There shouldn't be any problem in doing that. Maybe it is just an implementation issue. Or we may propose something optimal for NEMO. I wonder what people in NEMO maling list think. > > We may also consider the cases that MRs or MNNs select the egress > > interface, however. > > For example, let's imagine the situation as follows. > > There is a big vehicle supports NEMO with multiple MRs. > > As time goes, availability may differes from egress interface to > > egress interface. > > Then, MRs should know and decide which MR's egress interface is > > connected to > > the Internet. So, MRs need to communicate with each other. > > In this case, MRs select the egress interface as their availability, > > don't they ? > > > Right, but I am not too sure if communications between MRs is within the > scope of NEMO. I don't know if you have read the -00 version of the > multihomng draft, but in there, I have described a simple solution to > solve this without requiring special communications. The solution is > left out of the -01 draft since we want to first identify the problem > before describing solution. > > Anyway, here is a brief description: each MR will actively listen to > the RA in their ingress link(s) to detect the presence of another router > which advertise an egress route to the Internet (lifetime!=0). When an > MR looses its egress link, it can then set up a temporary tunnel with > its HA that passes through the other MR. This way, we don't need any > special communications between MRs, and the MR can decide which route to > use specifically. > > Another way to do it is for the MR to simply response with an ICMP > re-direct message when it looses its egress link. > > The first way, the lost of egress link is transparent to MNNs. The > second way, the MR inform MNNs that it has lost a route, and force MNNs > to re-direct their packets to other MRs. The first way is included in what I called "communication between MRs". They listen each other MR's RA and set up tunnel. (If you think the term "communication" is not appropriate for this, i.e. just exchange signaling for tunnel set-up, we may paraphrase it.) The second way does not seem to provide mobility transparency to MNNs. So, it is not recommandable, IMHO. Regards, Eun Kyoung From nemo-admin@ietf.org Tue Jun 24 00:21:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20646 for ; Tue, 24 Jun 2003 00:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfIk-0007hN-5P; Tue, 24 Jun 2003 00:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfIB-0007fQ-H5 for nemo@optimus.ietf.org; Tue, 24 Jun 2003 00:20:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20635 for ; Tue, 24 Jun 2003 00:20:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UfI9-00005m-00 for nemo@ietf.org; Tue, 24 Jun 2003 00:20:25 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19UfHx-00005R-00 for nemo@ietf.org; Tue, 24 Jun 2003 00:20:13 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5O4CH409562; Tue, 24 Jun 2003 12:12:17 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id DD1ED10E95DA; Tue, 24 Jun 2003 12:19:51 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: "T.J. Kniveton" Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056428391.1789.56.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 24 Jun 2003 12:19:51 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-06-24 at 01:59, T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > I applaud the efforts of the design team on coming up with the initial version of the basic solution. Some clarifying questions and cosmetic comments follow. o Conceptual clarifications: In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home Agent should not forward packets destined for mobile network if R flag is not set. So, does this means that for a static route configuration where the next hop for the Mobile Network Prefix is the Mobile Router, the Home Agent should discard packets sent to the Mobile Network Prefix if it receives a BU from Mobile Router with R=0? Perhaps the response of the Home Agent in this case can be specified? In [Section 5.1, page 14], it is said that the Binding Update List should hold the prefix information. For a MR with multiple prefixes, are all these prefixes going to be stored in the Binding Update List? So each entry in the Binding Update List is going to be dynamic in size (since the maximum number of prefixes is not known)? Nothing is said about the Data Structure of the Home Agent. Shouldn't there be changes to the Binding Cache as well? Nothing is mentioned about the Home Agent performing ND proxy for the Mobile Network Prefix. Is it deemed not necessary by the design team? Nothing is mentioned in the operation of Mobile Router about checks on received tunnelled packets from Home Agent. Shouldn't the Mobile Router verify that the inner packet has a destination address that is within its Mobile Network Prefix? o Some cosmetic comments: In [Section 3, page 8, middle paragraph], the abbreviation CN is used without explanation, while in the rest of the section, Correspondent Node is always used in full. In [Section 4.1, page 10, the explanation of Mobility Options], "... in addition to what is defined [1]...", perhaps it should read "... in addition to what is defined in [1]..."? In [Section 4.3, page 12, and Section 4.4, page 13], perhaps the explanation of the "Reserved" field should follow the style of IPv6, and MIPv6, something like: "This field is unused for now. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver". In [Section 4.4, page 13], the explanation of Prefix Length field seems to be questionable. It says "length of the IPv6 prefix contained in the option", but there is no prefix in this option. Also, a full-stop punctuation is missing. In [Section 5, page 14, right at the bottom], "Similarly to a Mobile Host, ..." should be "Similar to a Mobile Host, ...". In [Section 5.4, page 16-17], there are a few instances of the term "should" is used without capitalization. In addition, a few instances of the expression "... Mobile Router will discard ...". The "will" should be changed to "MUST", "SHOULD", etc as described in RFC2119. In [Section 5.4, page 17, right at the top], " ... MAY try try ..." => duplicate 'try'. In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is missing for the first bullet. In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A Mobile ..." In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP based ...". Pardon my ignorance, but I am not familiar with the abbreviation MNLP. Perhaps it should be expanded or referenced? In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop punctuation is missing. Throughout Sections 5 and 6, the terms "Home Agent", "Mobile Network", and "Mobile Network Prefix" are sometimes used with all lower case, sometimes used with first letter capitalized. It will be nice to be consistent. That's all for now, I am still digesting the draft. /rgds /cwng From exim@www1.ietf.org Tue Jun 24 01:09:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20648 for ; Tue, 24 Jun 2003 00:21:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O4L9w29716 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 00:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfIr-0007jD-Gv for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 00:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20640 for ; Tue, 24 Jun 2003 00:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UfIp-00005t-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 00:21:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UfIj-00005q-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 00:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfIk-0007hN-5P; Tue, 24 Jun 2003 00:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfIB-0007fQ-H5 for nemo@optimus.ietf.org; Tue, 24 Jun 2003 00:20:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20635 for ; Tue, 24 Jun 2003 00:20:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UfI9-00005m-00 for nemo@ietf.org; Tue, 24 Jun 2003 00:20:25 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19UfHx-00005R-00 for nemo@ietf.org; Tue, 24 Jun 2003 00:20:13 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5O4CH409562; Tue, 24 Jun 2003 12:12:17 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id DD1ED10E95DA; Tue, 24 Jun 2003 12:19:51 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: "T.J. Kniveton" Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056428391.1789.56.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 24 Jun 2003 12:19:51 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-06-24 at 01:59, T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > I applaud the efforts of the design team on coming up with the initial version of the basic solution. Some clarifying questions and cosmetic comments follow. o Conceptual clarifications: In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home Agent should not forward packets destined for mobile network if R flag is not set. So, does this means that for a static route configuration where the next hop for the Mobile Network Prefix is the Mobile Router, the Home Agent should discard packets sent to the Mobile Network Prefix if it receives a BU from Mobile Router with R=0? Perhaps the response of the Home Agent in this case can be specified? In [Section 5.1, page 14], it is said that the Binding Update List should hold the prefix information. For a MR with multiple prefixes, are all these prefixes going to be stored in the Binding Update List? So each entry in the Binding Update List is going to be dynamic in size (since the maximum number of prefixes is not known)? Nothing is said about the Data Structure of the Home Agent. Shouldn't there be changes to the Binding Cache as well? Nothing is mentioned about the Home Agent performing ND proxy for the Mobile Network Prefix. Is it deemed not necessary by the design team? Nothing is mentioned in the operation of Mobile Router about checks on received tunnelled packets from Home Agent. Shouldn't the Mobile Router verify that the inner packet has a destination address that is within its Mobile Network Prefix? o Some cosmetic comments: In [Section 3, page 8, middle paragraph], the abbreviation CN is used without explanation, while in the rest of the section, Correspondent Node is always used in full. In [Section 4.1, page 10, the explanation of Mobility Options], "... in addition to what is defined [1]...", perhaps it should read "... in addition to what is defined in [1]..."? In [Section 4.3, page 12, and Section 4.4, page 13], perhaps the explanation of the "Reserved" field should follow the style of IPv6, and MIPv6, something like: "This field is unused for now. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver". In [Section 4.4, page 13], the explanation of Prefix Length field seems to be questionable. It says "length of the IPv6 prefix contained in the option", but there is no prefix in this option. Also, a full-stop punctuation is missing. In [Section 5, page 14, right at the bottom], "Similarly to a Mobile Host, ..." should be "Similar to a Mobile Host, ...". In [Section 5.4, page 16-17], there are a few instances of the term "should" is used without capitalization. In addition, a few instances of the expression "... Mobile Router will discard ...". The "will" should be changed to "MUST", "SHOULD", etc as described in RFC2119. In [Section 5.4, page 17, right at the top], " ... MAY try try ..." => duplicate 'try'. In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is missing for the first bullet. In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A Mobile ..." In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP based ...". Pardon my ignorance, but I am not familiar with the abbreviation MNLP. Perhaps it should be expanded or referenced? In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop punctuation is missing. Throughout Sections 5 and 6, the terms "Home Agent", "Mobile Network", and "Mobile Network Prefix" are sometimes used with all lower case, sometimes used with first letter capitalized. It will be nice to be consistent. That's all for now, I am still digesting the draft. /rgds /cwng From nemo-admin@ietf.org Tue Jun 24 01:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22119 for ; Tue, 24 Jun 2003 01:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UgZ7-0001eE-Qb; Tue, 24 Jun 2003 01:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UgY5-0001c8-Fk for nemo@optimus.ietf.org; Tue, 24 Jun 2003 01:41:12 -0400 Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22090 for ; Tue, 24 Jun 2003 01:40:54 -0400 (EDT) Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5O5pnr10843; Tue, 24 Jun 2003 14:51:49 +0900 (KST) (envelope-from eun) Date: Tue, 24 Jun 2003 14:51:49 +0900 From: Eun Kyoung Paik To: "Pascal Thubert (pthubert)" Cc: eun007@hanmir.com, 'cwng@psl.com.sg, nemo@ietf.org Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030624145149.A10628@mmlab.snu.ac.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pthubert@cisco.com on Mon, Jun 23, 2003 at 08:48:15AM +0100 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Pascal, Yes, I read your taxonomy. It was clear to understand. And the terms, e.g. Tarzan, are interesting, but I could not find out the relationship between the term and the texanomy, e.g. why Tarzan means the case of single HA. I think it would be easy to remember the taxonomy if I know the relationship.:) Regards, Eun Kyoung On Mon, Jun 23, 2003 at 08:48:15AM +0100, Pascal Thubert (pthubert) wrote: > > Hi Eun Kyoung, > > > > This is also what I tried to do :) > > > > Did you get the threads talking about the problems named Tarzan, > Shinkansen, JetSet and > > DoubleBed? > > > > Pascal > > > > -----Original Message----- > > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > > Sent: jeudi 19 juin 2003 17:20 > > To: cwng@psl.com.sg; nemo@ietf.org > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > Hi all, Hi Chan-wah, > > > > The taxonomy of your draft is very clear. Thank you for your work. > > > > While I was working on multi-homed NEMO, I have found many problems > > other than the listed problems in your draft (at the end of section > 4). > > The problems. e.g. BU, egress selection, etc., are differ as the > taxonomy. > > > > IMHO, we'd better to define the problems and make a consensus on them, > > since R12 in the requirement draft defines that the NEMO solution must > function for > > multihoming. > > > > Regards, > > Eun Kyoung Paik > > Seoul National University > > From exim@www1.ietf.org Tue Jun 24 01:42:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22138 for ; Tue, 24 Jun 2003 01:42:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O5g8c06388 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 01:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UgZE-0001ex-Ri for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 01:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22111 for ; Tue, 24 Jun 2003 01:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UgZB-0000Rd-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 01:42:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UgZ6-0000Ra-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 01:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UgZ7-0001eE-Qb; Tue, 24 Jun 2003 01:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UgY5-0001c8-Fk for nemo@optimus.ietf.org; Tue, 24 Jun 2003 01:41:12 -0400 Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22090 for ; Tue, 24 Jun 2003 01:40:54 -0400 (EDT) Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5O5pnr10843; Tue, 24 Jun 2003 14:51:49 +0900 (KST) (envelope-from eun) Date: Tue, 24 Jun 2003 14:51:49 +0900 From: Eun Kyoung Paik To: "Pascal Thubert (pthubert)" Cc: eun007@hanmir.com, 'cwng@psl.com.sg, nemo@ietf.org Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030624145149.A10628@mmlab.snu.ac.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pthubert@cisco.com on Mon, Jun 23, 2003 at 08:48:15AM +0100 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Pascal, Yes, I read your taxonomy. It was clear to understand. And the terms, e.g. Tarzan, are interesting, but I could not find out the relationship between the term and the texanomy, e.g. why Tarzan means the case of single HA. I think it would be easy to remember the taxonomy if I know the relationship.:) Regards, Eun Kyoung On Mon, Jun 23, 2003 at 08:48:15AM +0100, Pascal Thubert (pthubert) wrote: > > Hi Eun Kyoung, > > > > This is also what I tried to do :) > > > > Did you get the threads talking about the problems named Tarzan, > Shinkansen, JetSet and > > DoubleBed? > > > > Pascal > > > > -----Original Message----- > > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > > Sent: jeudi 19 juin 2003 17:20 > > To: cwng@psl.com.sg; nemo@ietf.org > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > Hi all, Hi Chan-wah, > > > > The taxonomy of your draft is very clear. Thank you for your work. > > > > While I was working on multi-homed NEMO, I have found many problems > > other than the listed problems in your draft (at the end of section > 4). > > The problems. e.g. BU, egress selection, etc., are differ as the > taxonomy. > > > > IMHO, we'd better to define the problems and make a consensus on them, > > since R12 in the requirement draft defines that the NEMO solution must > function for > > multihoming. > > > > Regards, > > Eun Kyoung Paik > > Seoul National University > > From nemo-admin@ietf.org Tue Jun 24 01:47:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22207 for ; Tue, 24 Jun 2003 01:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ugdx-0001n5-Fo; Tue, 24 Jun 2003 01:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ugcy-0001lm-LL for nemo@optimus.ietf.org; Tue, 24 Jun 2003 01:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22191 for ; Tue, 24 Jun 2003 01:45:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UgcU-0000Sc-00 for nemo@ietf.org; Tue, 24 Jun 2003 01:45:30 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19UgcJ-0000SM-00 for nemo@ietf.org; Tue, 24 Jun 2003 01:45:20 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Tue, 24 Jun 2003 15:37:41 +1000 From: "Muhammad Ali Malik" To: Date: Tue, 24 Jun 2003 15:37:37 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C33A66.89F13F30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] nemo basic support ptotocol draft. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C33A66.89F13F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I have following question about multicast group for mobile router. >> If mobile router want to join a multicast group while MR is in foreign location, it needs to join the multicast group via bidirectional tunnel. >> Is there any way by which mobile network node can individually join the multicast group. Cheers Muhammad ------=_NextPart_000_0007_01C33A66.89F13F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I have following question about multicast group for mobile = router.

 

>> If mobile router want to join a multicast group while MR = is in foreign location, it needs to join the multicast group via bidirectional tunnel.

 

>> Is there any way by which mobile network node can = individually join the multicast group.

 

Cheers

Muhammad

------=_NextPart_000_0007_01C33A66.89F13F30-- From exim@www1.ietf.org Tue Jun 24 01:47:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22222 for ; Tue, 24 Jun 2003 01:47:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O5l8W07149 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 01:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uge4-0001rE-13 for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 01:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22204 for ; Tue, 24 Jun 2003 01:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uge0-0000Sv-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 01:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ugdv-0000Ss-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 01:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ugdx-0001n5-Fo; Tue, 24 Jun 2003 01:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ugcy-0001lm-LL for nemo@optimus.ietf.org; Tue, 24 Jun 2003 01:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22191 for ; Tue, 24 Jun 2003 01:45:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UgcU-0000Sc-00 for nemo@ietf.org; Tue, 24 Jun 2003 01:45:30 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19UgcJ-0000SM-00 for nemo@ietf.org; Tue, 24 Jun 2003 01:45:20 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Tue, 24 Jun 2003 15:37:41 +1000 From: "Muhammad Ali Malik" To: Date: Tue, 24 Jun 2003 15:37:37 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C33A66.89F13F30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] nemo basic support ptotocol draft. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C33A66.89F13F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I have following question about multicast group for mobile router. >> If mobile router want to join a multicast group while MR is in foreign location, it needs to join the multicast group via bidirectional tunnel. >> Is there any way by which mobile network node can individually join the multicast group. Cheers Muhammad ------=_NextPart_000_0007_01C33A66.89F13F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I have following question about multicast group for mobile = router.

 

>> If mobile router want to join a multicast group while MR = is in foreign location, it needs to join the multicast group via bidirectional tunnel.

 

>> Is there any way by which mobile network node can = individually join the multicast group.

 

Cheers

Muhammad

------=_NextPart_000_0007_01C33A66.89F13F30-- From nemo-admin@ietf.org Tue Jun 24 02:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05532 for ; Tue, 24 Jun 2003 02:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uhcv-00066s-8x; Tue, 24 Jun 2003 02:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UhcU-000638-Ba for nemo@optimus.ietf.org; Tue, 24 Jun 2003 02:49:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05485 for ; Tue, 24 Jun 2003 02:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UhcQ-00010v-00 for nemo@ietf.org; Tue, 24 Jun 2003 02:49:30 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19UhcF-00010k-00 for nemo@ietf.org; Tue, 24 Jun 2003 02:49:20 -0400 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXHA7C33PY9B8EKE@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 24 Jun 2003 16:47:56 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 63C9E12C00E; Tue, 24 Jun 2003 16:47:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 5056112C00D; Tue, 24 Jun 2003 16:47:56 +1000 (EST) Date: Tue, 24 Jun 2003 16:47:56 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: Muhammad Ali Malik Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EF7F41C.8080403@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Muhammad, I guess that the Mobile Router will be running PIM, rather than MLD/IGMP. In this case, MLD/IGMP Reports/Group joins will be handled the same way in which fixed network traffic is handled. The MR makes a request for routing a multicast group/source over its tunnelled interface. This allows MNNs to have the full multicast capabilities of a fixed node. It may be a valuable situation if the MR could join groups on visited networks (like a host), although this would require significant investigation, in my guess. Greg Muhammad Ali Malik wrote: > Hi > > > > I have following question about multicast group for mobile router. > > > >>> If mobile router want to join a multicast group while MR is in foreign > location, it needs to join the multicast group via bidirectional tunnel. > > > >>> Is there any way by which mobile network node can individually join > the multicast group. > > > > Cheers > > Muhammad > From exim@www1.ietf.org Tue Jun 24 02:50:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05548 for ; Tue, 24 Jun 2003 02:50:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O6oC123688 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 02:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uhd6-00069z-0z for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 02:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05513 for ; Tue, 24 Jun 2003 02:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uhd2-00011C-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 02:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uhcw-000119-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 02:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uhcv-00066s-8x; Tue, 24 Jun 2003 02:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UhcU-000638-Ba for nemo@optimus.ietf.org; Tue, 24 Jun 2003 02:49:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05485 for ; Tue, 24 Jun 2003 02:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UhcQ-00010v-00 for nemo@ietf.org; Tue, 24 Jun 2003 02:49:30 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19UhcF-00010k-00 for nemo@ietf.org; Tue, 24 Jun 2003 02:49:20 -0400 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXHA7C33PY9B8EKE@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 24 Jun 2003 16:47:56 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 63C9E12C00E; Tue, 24 Jun 2003 16:47:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 5056112C00D; Tue, 24 Jun 2003 16:47:56 +1000 (EST) Date: Tue, 24 Jun 2003 16:47:56 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: Muhammad Ali Malik Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EF7F41C.8080403@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Muhammad, I guess that the Mobile Router will be running PIM, rather than MLD/IGMP. In this case, MLD/IGMP Reports/Group joins will be handled the same way in which fixed network traffic is handled. The MR makes a request for routing a multicast group/source over its tunnelled interface. This allows MNNs to have the full multicast capabilities of a fixed node. It may be a valuable situation if the MR could join groups on visited networks (like a host), although this would require significant investigation, in my guess. Greg Muhammad Ali Malik wrote: > Hi > > > > I have following question about multicast group for mobile router. > > > >>> If mobile router want to join a multicast group while MR is in foreign > location, it needs to join the multicast group via bidirectional tunnel. > > > >>> Is there any way by which mobile network node can individually join > the multicast group. > > > > Cheers > > Muhammad > From nemo-admin@ietf.org Tue Jun 24 03:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06089 for ; Tue, 24 Jun 2003 03:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ui9q-0007Au-44; Tue, 24 Jun 2003 03:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ui8s-0007AN-QC for nemo@optimus.ietf.org; Tue, 24 Jun 2003 03:23:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06055 for ; Tue, 24 Jun 2003 03:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ui8q-0001AE-00 for nemo@ietf.org; Tue, 24 Jun 2003 03:23:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Ui8f-0001A5-00 for nemo@ietf.org; Tue, 24 Jun 2003 03:22:50 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2003 09:22:09 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5O7Ju09006947; Tue, 24 Jun 2003 09:19:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 09:21:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Tue, 24 Jun 2003 08:21:58 +0100 Message-ID: Thread-Topic: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM6EniNcEND7jfzTiaWZArFId059wADbQdQ From: "Pascal Thubert (pthubert)" To: "Eun Kyoung Paik" Cc: , , X-OriginalArrivalTime: 24 Jun 2003 07:21:58.0955 (UTC) FILETIME=[4C9327B0:01C33A21] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable You're right. The trouble is that there's not a one to one match between the problems and the cases in the taxonomy. The taxonomy is a tool to help uncover the problems. It builds a tree of cases. But some problems may be present on many leaves. And leaves may actually represent more than one problem (they do!). Actually, there is an huge number of variables for such a taxonomy and our approach in the ML was biased because we had a priori ideas about the problems we expected, so we chose the variables very carefully.=20 In any case, I agree with you. The taxonomy is a step but it's not a result. With the help of the taxonomy, we need to list the problems. And then choose which ones we address and move forward to solutions. I made my proposals on that. Did not get much success, but it may have been too early. I also gave some indications at the time about some mapping of the taxonomy and the problems, but it was not based on the latest draft and was not complete. I'm not sure whether the full mapping is needed, maybe it is to help people understand what I had in mind at the time? Pascal > -----Original Message----- > From: Eun Kyoung Paik [mailto:eun@mmlab.snu.ac.kr] > Sent: mardi 24 juin 2003 07:52 > To: Pascal Thubert (pthubert) > Cc: eun007@hanmir.com; cwng@psl.com.sg; nemo@ietf.org > Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi, Pascal, >=20 > Yes, I read your taxonomy. > It was clear to understand. >=20 > And the terms, e.g. Tarzan, are interesting, but > I could not find out the relationship between the term > and the texanomy, e.g. why Tarzan means the case of single HA. > I think it would be easy to remember the taxonomy > if I know the relationship.:) >=20 > Regards, > Eun Kyoung >=20 >=20 > On Mon, Jun 23, 2003 at 08:48:15AM +0100, Pascal Thubert (pthubert) wrote: > > > Hi Eun Kyoung, > > > > > > This is also what I tried to do :) > > > > > > Did you get the threads talking about the problems named Tarzan, > > Shinkansen, JetSet and > > > DoubleBed? > > > > > > Pascal > > > > > > -----Original Message----- > > > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > > > Sent: jeudi 19 juin 2003 17:20 > > > To: cwng@psl.com.sg; nemo@ietf.org > > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > > > Hi all, Hi Chan-wah, > > > > > > The taxonomy of your draft is very clear. Thank you for your work. > > > > > > While I was working on multi-homed NEMO, I have found many problems > > > other than the listed problems in your draft (at the end of section > > 4). > > > The problems. e.g. BU, egress selection, etc., are differ as the > > taxonomy. > > > > > > IMHO, we'd better to define the problems and make a consensus on them, > > > since R12 in the requirement draft defines that the NEMO solution must > > function for > > > multihoming. > > > > > > Regards, > > > Eun Kyoung Paik > > > Seoul National University > > > > From exim@www1.ietf.org Tue Jun 24 03:24:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06109 for ; Tue, 24 Jun 2003 03:24:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O7O9U27704 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 03:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ui9x-0007Cl-CK for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 03:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06068 for ; Tue, 24 Jun 2003 03:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ui9v-0001AS-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 03:24:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ui9p-0001AP-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 03:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ui9q-0007Au-44; Tue, 24 Jun 2003 03:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ui8s-0007AN-QC for nemo@optimus.ietf.org; Tue, 24 Jun 2003 03:23:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06055 for ; Tue, 24 Jun 2003 03:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ui8q-0001AE-00 for nemo@ietf.org; Tue, 24 Jun 2003 03:23:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Ui8f-0001A5-00 for nemo@ietf.org; Tue, 24 Jun 2003 03:22:50 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2003 09:22:09 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5O7Ju09006947; Tue, 24 Jun 2003 09:19:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 09:21:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Date: Tue, 24 Jun 2003 08:21:58 +0100 Message-ID: Thread-Topic: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt Thread-Index: AcM6EniNcEND7jfzTiaWZArFId059wADbQdQ From: "Pascal Thubert (pthubert)" To: "Eun Kyoung Paik" Cc: , , X-OriginalArrivalTime: 24 Jun 2003 07:21:58.0955 (UTC) FILETIME=[4C9327B0:01C33A21] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You're right. The trouble is that there's not a one to one match between the problems and the cases in the taxonomy. The taxonomy is a tool to help uncover the problems. It builds a tree of cases. But some problems may be present on many leaves. And leaves may actually represent more than one problem (they do!). Actually, there is an huge number of variables for such a taxonomy and our approach in the ML was biased because we had a priori ideas about the problems we expected, so we chose the variables very carefully.=20 In any case, I agree with you. The taxonomy is a step but it's not a result. With the help of the taxonomy, we need to list the problems. And then choose which ones we address and move forward to solutions. I made my proposals on that. Did not get much success, but it may have been too early. I also gave some indications at the time about some mapping of the taxonomy and the problems, but it was not based on the latest draft and was not complete. I'm not sure whether the full mapping is needed, maybe it is to help people understand what I had in mind at the time? Pascal > -----Original Message----- > From: Eun Kyoung Paik [mailto:eun@mmlab.snu.ac.kr] > Sent: mardi 24 juin 2003 07:52 > To: Pascal Thubert (pthubert) > Cc: eun007@hanmir.com; cwng@psl.com.sg; nemo@ietf.org > Subject: Re: FW: [nemo] draft-ng-nemo-multihoming-issues-01.txt >=20 > Hi, Pascal, >=20 > Yes, I read your taxonomy. > It was clear to understand. >=20 > And the terms, e.g. Tarzan, are interesting, but > I could not find out the relationship between the term > and the texanomy, e.g. why Tarzan means the case of single HA. > I think it would be easy to remember the taxonomy > if I know the relationship.:) >=20 > Regards, > Eun Kyoung >=20 >=20 > On Mon, Jun 23, 2003 at 08:48:15AM +0100, Pascal Thubert (pthubert) wrote: > > > Hi Eun Kyoung, > > > > > > This is also what I tried to do :) > > > > > > Did you get the threads talking about the problems named Tarzan, > > Shinkansen, JetSet and > > > DoubleBed? > > > > > > Pascal > > > > > > -----Original Message----- > > > From: Paik, Eun Kyoung [mailto:eun007@hanmir.com] > > > Sent: jeudi 19 juin 2003 17:20 > > > To: cwng@psl.com.sg; nemo@ietf.org > > > Subject: RE: [nemo] draft-ng-nemo-multihoming-issues-01.txt > > > > > > Hi all, Hi Chan-wah, > > > > > > The taxonomy of your draft is very clear. Thank you for your work. > > > > > > While I was working on multi-homed NEMO, I have found many problems > > > other than the listed problems in your draft (at the end of section > > 4). > > > The problems. e.g. BU, egress selection, etc., are differ as the > > taxonomy. > > > > > > IMHO, we'd better to define the problems and make a consensus on them, > > > since R12 in the requirement draft defines that the NEMO solution must > > function for > > > multihoming. > > > > > > Regards, > > > Eun Kyoung Paik > > > Seoul National University > > > > From nemo-admin@ietf.org Tue Jun 24 06:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08837 for ; Tue, 24 Jun 2003 06:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukfd-0003AQ-6g; Tue, 24 Jun 2003 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWtO-0000Yg-Nd for nemo@optimus.ietf.org; Mon, 23 Jun 2003 15:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06303 for ; Mon, 23 Jun 2003 15:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWt8-00052C-00 for nemo@ietf.org; Mon, 23 Jun 2003 15:22:02 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19UWsi-00051P-00 for nemo@ietf.org; Mon, 23 Jun 2003 15:21:36 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 33FDDB845 for ; Mon, 23 Jun 2003 14:19:55 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 1DAA016EE for ; Mon, 23 Jun 2003 12:19:54 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id PAA0002188649; Mon, 23 Jun 2003 15:19:54 -0400 (EDT) Message-ID: <3EF752D9.4080204@hp.com> Date: Mon, 23 Jun 2003 15:19:53 -0400 From: Brian Haley Organization: Tru64 UNIX Networking User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a comment on the draft regarding Proxy Neighbor Disovery on the Home Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in 10.4.1): The Router (R) bit in the Advertisement MUST be set to zero. I would assume you would want to add text in this draft to override that behavior when the R-bit is set in the Binding Update since the node really is a router. -Brian T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > > From exim@www1.ietf.org Tue Jun 24 06:05:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08870 for ; Tue, 24 Jun 2003 06:05:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OA5Fc12305 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 06:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukfr-0003CN-5G for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:05:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08827 for ; Tue, 24 Jun 2003 06:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ukfn-0001p8-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:05:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ukfh-0001p2-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:05:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukfd-0003AQ-6g; Tue, 24 Jun 2003 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWtO-0000Yg-Nd for nemo@optimus.ietf.org; Mon, 23 Jun 2003 15:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06303 for ; Mon, 23 Jun 2003 15:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWt8-00052C-00 for nemo@ietf.org; Mon, 23 Jun 2003 15:22:02 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19UWsi-00051P-00 for nemo@ietf.org; Mon, 23 Jun 2003 15:21:36 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 33FDDB845 for ; Mon, 23 Jun 2003 14:19:55 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 1DAA016EE for ; Mon, 23 Jun 2003 12:19:54 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id PAA0002188649; Mon, 23 Jun 2003 15:19:54 -0400 (EDT) Message-ID: <3EF752D9.4080204@hp.com> Date: Mon, 23 Jun 2003 15:19:53 -0400 From: Brian Haley Organization: Tru64 UNIX Networking User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a comment on the draft regarding Proxy Neighbor Disovery on the Home Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in 10.4.1): The Router (R) bit in the Advertisement MUST be set to zero. I would assume you would want to add text in this draft to override that behavior when the R-bit is set in the Binding Update since the node really is a router. -Brian T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > > From nemo-admin@ietf.org Tue Jun 24 06:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09187 for ; Tue, 24 Jun 2003 06:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukx3-0003qr-7C; Tue, 24 Jun 2003 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkwM-0003ik-Db for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09127 for ; Tue, 24 Jun 2003 06:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ukw3-0001sF-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:21:59 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19Ukvs-0001s3-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:21:48 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h5OALAHK021859; Tue, 24 Jun 2003 03:21:10 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5OAL6Hh003738; Tue, 24 Jun 2003 05:21:08 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 31FE12EC86; Tue, 24 Jun 2003 12:21:05 +0200 (CEST) Message-ID: <3EF82610.6040803@motorola.com> Date: Tue, 24 Jun 2003 12:21:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> In-Reply-To: <3EF752D9.4080204@hp.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian Haley wrote: > I have a comment on the draft regarding Proxy Neighbor Disovery on > the Home Agent. The base MIPv6 draft talks about sending Neighbor > Advertisements (in 10.4.1): > > The Router (R) bit in the Advertisement MUST be set to zero. > > I would assume you would want to add text in this draft to override > that behavior when the R-bit is set in the Binding Update since the > node really is a router. Yes, that is one distinguishing feature of a Home Agent supporting Mobile Routers (not only Mobile Hosts), and should appear in the draft in the section Home Agent Operation. Alex GBU From exim@www1.ietf.org Tue Jun 24 06:23:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09217 for ; Tue, 24 Jun 2003 06:23:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OAN8A14951 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 06:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukx9-0003t4-TV for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:23:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09172 for ; Tue, 24 Jun 2003 06:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ukx6-0001t6-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:23:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ukx0-0001t3-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:22:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ukx3-0003qr-7C; Tue, 24 Jun 2003 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UkwM-0003ik-Db for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09127 for ; Tue, 24 Jun 2003 06:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ukw3-0001sF-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:21:59 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19Ukvs-0001s3-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:21:48 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h5OALAHK021859; Tue, 24 Jun 2003 03:21:10 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5OAL6Hh003738; Tue, 24 Jun 2003 05:21:08 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 31FE12EC86; Tue, 24 Jun 2003 12:21:05 +0200 (CEST) Message-ID: <3EF82610.6040803@motorola.com> Date: Tue, 24 Jun 2003 12:21:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> In-Reply-To: <3EF752D9.4080204@hp.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haley wrote: > I have a comment on the draft regarding Proxy Neighbor Disovery on > the Home Agent. The base MIPv6 draft talks about sending Neighbor > Advertisements (in 10.4.1): > > The Router (R) bit in the Advertisement MUST be set to zero. > > I would assume you would want to add text in this draft to override > that behavior when the R-bit is set in the Binding Update since the > node really is a router. Yes, that is one distinguishing feature of a Home Agent supporting Mobile Routers (not only Mobile Hosts), and should appear in the draft in the section Home Agent Operation. Alex GBU From nemo-admin@ietf.org Tue Jun 24 06:36:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09983 for ; Tue, 24 Jun 2003 06:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul9c-0004Ki-Uo; Tue, 24 Jun 2003 06:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul8Q-0004Hl-G6 for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09858 for ; Tue, 24 Jun 2003 06:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ul8M-0001yR-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:34:42 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19Ul8B-0001yO-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:34:31 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h5OAYMHK026355; Tue, 24 Jun 2003 03:34:23 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h5OAYIMT002201; Tue, 24 Jun 2003 05:34:19 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 76AA42EC86; Tue, 24 Jun 2003 12:34:17 +0200 (CEST) Message-ID: <3EF82928.1080004@motorola.com> Date: Tue, 24 Jun 2003 12:34:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] nemo basic support ptotocol draft. References: <3EF7F41C.8080403@eng.monash.edu.au> In-Reply-To: <3EF7F41C.8080403@eng.monash.edu.au> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greg Daley wrote: > Hi Muhammad, > > I guess that the Mobile Router will be running PIM, rather than > MLD/IGMP. I would say both. Interaction between MR and HA would be with PIM but MR would also send MLD packets towards the first underlying segment of the mobile network. > It may be a valuable situation if the MR could join groups on visited > networks (like a host), although this would require significant > investigation, in my guess. I'd say that MR, or MH for that matter, joining a multicast group on the foreign link other than link scope ("remote subsription") amounts to MR using routing protocol interactions with the foreign network, and more. I agree with you that this would demand significant research results. In fact I'm searching for these research results since some time, I have a bunch of paper references, if you're interested, but none addresses this issue directly. Alex GBU From exim@www1.ietf.org Tue Jun 24 06:36:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10020 for ; Tue, 24 Jun 2003 06:36:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OAa8D17144 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 06:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul9j-0004SR-Up for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09955 for ; Tue, 24 Jun 2003 06:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ul9f-0001yr-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:36:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ul9a-0001yo-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:35:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul9c-0004Ki-Uo; Tue, 24 Jun 2003 06:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ul8Q-0004Hl-G6 for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09858 for ; Tue, 24 Jun 2003 06:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ul8M-0001yR-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:34:42 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19Ul8B-0001yO-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:34:31 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h5OAYMHK026355; Tue, 24 Jun 2003 03:34:23 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h5OAYIMT002201; Tue, 24 Jun 2003 05:34:19 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 76AA42EC86; Tue, 24 Jun 2003 12:34:17 +0200 (CEST) Message-ID: <3EF82928.1080004@motorola.com> Date: Tue, 24 Jun 2003 12:34:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] nemo basic support ptotocol draft. References: <3EF7F41C.8080403@eng.monash.edu.au> In-Reply-To: <3EF7F41C.8080403@eng.monash.edu.au> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg Daley wrote: > Hi Muhammad, > > I guess that the Mobile Router will be running PIM, rather than > MLD/IGMP. I would say both. Interaction between MR and HA would be with PIM but MR would also send MLD packets towards the first underlying segment of the mobile network. > It may be a valuable situation if the MR could join groups on visited > networks (like a host), although this would require significant > investigation, in my guess. I'd say that MR, or MH for that matter, joining a multicast group on the foreign link other than link scope ("remote subsription") amounts to MR using routing protocol interactions with the foreign network, and more. I agree with you that this would demand significant research results. In fact I'm searching for these research results since some time, I have a bunch of paper references, if you're interested, but none addresses this issue directly. Alex GBU From nemo-admin@ietf.org Tue Jun 24 06:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10214 for ; Tue, 24 Jun 2003 06:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlDW-0004vo-5g; Tue, 24 Jun 2003 06:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlDE-0004v9-To for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:39:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10200 for ; Tue, 24 Jun 2003 06:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlCv-00020c-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:39:25 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19UlCf-00020S-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:39:10 -0400 Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5OAapgx028586 for ; Tue, 24 Jun 2003 19:36:51 +0900 From: "Na, Jong Keun" To: Date: Tue, 24 Jun 2003 19:38:29 +0900 Message-ID: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0258_01C33A88.31A36160" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] About NEMO simulator Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0258_01C33A88.31A36160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I think that we need NEMO simulator for the verification of the proposed protocols/algorithms and extensions. Is there any action or plan for this work? Anyway, I'm considering mobiwan package as a starting point that implemented the minimum level of MIPv6 for NEMO. I already got mobiwan-021513.tar.gz distribution package. But it doesn't work in ns2 all-in-one 2.26. Is there any modified or ported to that ns version? If yes and anybody know, please let me know. If not exists and porting is apparently necessary, I will do. By the way, also I'd like to know how this work is valuable to us before starting this work. Any comments and suggestions to the way of making simulation package for NEMO would be very helpful to me. Thanks. /jong ------=_NextPart_000_0258_01C33A88.31A36160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable About NEMO simulator

Hi = there,

I think that we = need NEMO = simulator for the verification of = the proposed protocols/algorithms and extensions.

Is there any = action or plan for this work?

Anyway, I’m considering mobiwan package as a starting point that implemented the minimum level of MIPv6 for = NEMO.

I already got mobiwan-021513.tar.gz distribution = package. But it doesn’t work in ns2 all-in-one = 2.26.

Is there any = modified or ported to that ns version? If yes and anybody know, please let me = know.

If not = exists = and porting is apparently necessary, I will do. =

By the = way, also I’d like to know how this work is valuable to = us before starting this work.

Any comments and suggestions to = the way of making simulation = package for NEMO would be very helpful to me.

Thanks.

/jong

------=_NextPart_000_0258_01C33A88.31A36160-- From exim@www1.ietf.org Tue Jun 24 06:40:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10229 for ; Tue, 24 Jun 2003 06:40:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OAe8I19215 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 06:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlDc-0004zq-Ct for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10207 for ; Tue, 24 Jun 2003 06:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlDY-000215-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:40:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UlDS-000212-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 06:39:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlDW-0004vo-5g; Tue, 24 Jun 2003 06:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlDE-0004v9-To for nemo@optimus.ietf.org; Tue, 24 Jun 2003 06:39:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10200 for ; Tue, 24 Jun 2003 06:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlCv-00020c-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:39:25 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19UlCf-00020S-00 for nemo@ietf.org; Tue, 24 Jun 2003 06:39:10 -0400 Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5OAapgx028586 for ; Tue, 24 Jun 2003 19:36:51 +0900 From: "Na, Jong Keun" To: Date: Tue, 24 Jun 2003 19:38:29 +0900 Message-ID: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0258_01C33A88.31A36160" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] About NEMO simulator Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0258_01C33A88.31A36160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I think that we need NEMO simulator for the verification of the proposed protocols/algorithms and extensions. Is there any action or plan for this work? Anyway, I'm considering mobiwan package as a starting point that implemented the minimum level of MIPv6 for NEMO. I already got mobiwan-021513.tar.gz distribution package. But it doesn't work in ns2 all-in-one 2.26. Is there any modified or ported to that ns version? If yes and anybody know, please let me know. If not exists and porting is apparently necessary, I will do. By the way, also I'd like to know how this work is valuable to us before starting this work. Any comments and suggestions to the way of making simulation package for NEMO would be very helpful to me. Thanks. /jong ------=_NextPart_000_0258_01C33A88.31A36160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable About NEMO simulator

Hi = there,

I think that we = need NEMO = simulator for the verification of = the proposed protocols/algorithms and extensions.

Is there any = action or plan for this work?

Anyway, I’m considering mobiwan package as a starting point that implemented the minimum level of MIPv6 for = NEMO.

I already got mobiwan-021513.tar.gz distribution = package. But it doesn’t work in ns2 all-in-one = 2.26.

Is there any = modified or ported to that ns version? If yes and anybody know, please let me = know.

If not = exists = and porting is apparently necessary, I will do. =

By the = way, also I’d like to know how this work is valuable to = us before starting this work.

Any comments and suggestions to = the way of making simulation = package for NEMO would be very helpful to me.

Thanks.

/jong

------=_NextPart_000_0258_01C33A88.31A36160-- From nemo-admin@ietf.org Tue Jun 24 08:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13294 for ; Tue, 24 Jun 2003 08:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Umbd-0008C7-Qz; Tue, 24 Jun 2003 08:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Umb0-0008Bd-GA for nemo@optimus.ietf.org; Tue, 24 Jun 2003 08:08:52 -0400 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13266 for ; Tue, 24 Jun 2003 08:08:20 -0400 (EDT) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5OC34Yb017744; Tue, 24 Jun 2003 05:03:05 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h5OC303D012256; Tue, 24 Jun 2003 07:03:02 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1F3832EC86; Tue, 24 Jun 2003 14:03:00 +0200 (CEST) Message-ID: <3EF83DF3.5080607@motorola.com> Date: Tue, 24 Jun 2003 14:02:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eun Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt References: <20030624130406.A8802@mmlab.snu.ac.kr> In-Reply-To: <20030624130406.A8802@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit eun wrote: >> It can be based on routing metric, load balancing, or even just a >> default route selection. There shouldn't be any problem in doing >> that. > > > Maybe it is just an implementation issue. Or we may propose something > optimal for NEMO. I wonder what people in NEMO maling list think. I think that it is very good to propose improvements. But I also think that it might be needed to propose it in a more multi-homing focused Working Group, such as multi6. What do you think? Alex GBU From exim@www1.ietf.org Tue Jun 24 08:09:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13309 for ; Tue, 24 Jun 2003 08:09:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OC9Cf31558 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 08:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Umbo-0008Cv-6V for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 08:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13285 for ; Tue, 24 Jun 2003 08:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Umbn-0002Ut-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 08:09:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Umbh-0002Uq-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 08:09:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Umbd-0008C7-Qz; Tue, 24 Jun 2003 08:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Umb0-0008Bd-GA for nemo@optimus.ietf.org; Tue, 24 Jun 2003 08:08:52 -0400 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13266 for ; Tue, 24 Jun 2003 08:08:20 -0400 (EDT) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5OC34Yb017744; Tue, 24 Jun 2003 05:03:05 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h5OC303D012256; Tue, 24 Jun 2003 07:03:02 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1F3832EC86; Tue, 24 Jun 2003 14:03:00 +0200 (CEST) Message-ID: <3EF83DF3.5080607@motorola.com> Date: Tue, 24 Jun 2003 14:02:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eun Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt References: <20030624130406.A8802@mmlab.snu.ac.kr> In-Reply-To: <20030624130406.A8802@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit eun wrote: >> It can be based on routing metric, load balancing, or even just a >> default route selection. There shouldn't be any problem in doing >> that. > > > Maybe it is just an implementation issue. Or we may propose something > optimal for NEMO. I wonder what people in NEMO maling list think. I think that it is very good to propose improvements. But I also think that it might be needed to propose it in a more multi-homing focused Working Group, such as multi6. What do you think? Alex GBU From nemo-admin@ietf.org Tue Jun 24 08:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14185 for ; Tue, 24 Jun 2003 08:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnK9-0000l6-Qy; Tue, 24 Jun 2003 08:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnJN-0000kb-Qw for nemo@optimus.ietf.org; Tue, 24 Jun 2003 08:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14151 for ; Tue, 24 Jun 2003 08:54:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnJM-0002hO-00 for nemo@ietf.org; Tue, 24 Jun 2003 08:54:12 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19UnJB-0002hB-00 for nemo@ietf.org; Tue, 24 Jun 2003 08:54:01 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5OCrTEe012112; Tue, 24 Jun 2003 05:53:30 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5OCrOnT003435; Tue, 24 Jun 2003 07:53:27 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 005D82EC86; Tue, 24 Jun 2003 14:53:23 +0200 (CEST) Message-ID: <3EF849C3.9080502@motorola.com> Date: Tue, 24 Jun 2003 14:53:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "T.J. Kniveton" , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> In-Reply-To: <1056428391.1789.56.camel@beethoven> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > o Conceptual clarifications: > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the > Home Agent should not forward packets destined for mobile network if > R flag is not set. So, does this means that for a static route > configuration where the next hop for the Mobile Network Prefix is the > Mobile Router, the Home Agent should discard packets sent to the > Mobile Network Prefix if it receives a BU from Mobile Router with > R=0? Perhaps the response of the Home Agent in this case can be > specified? Good issue, should be discussed. Remark it has implications on many things; > In [Section 5.1, page 14], it is said that the Binding Update List > should hold the prefix information. For a MR with multiple prefixes, > are all these prefixes going to be stored in the Binding Update > List? So each entry in the Binding Update List is going to be dynamic > in size (since the maximum number of prefixes is not known)? Good issue, same. > Nothing is said about the Data Structure of the Home Agent. Shouldn't > there be changes to the Binding Cache as well? I suppose that not even when the Explicit mode is used (prefixes in the BU) there is no need to modify the Binding Cache of HA. > Nothing is mentioned about the Home Agent performing ND proxy for the > Mobile Network Prefix. Is it deemed not necessary by the design > team? I personally think that there is a strong need for such a section in the Home Agent Operation, but that section should only contain the list of enhancements of the HA for Mobile Routers. > Nothing is mentioned in the operation of Mobile Router about checks > on received tunnelled packets from Home Agent. Shouldn't the Mobile > Router verify that the inner packet has a destination address that > is within its Mobile Network Prefix? Good issue. It is true that the HA has some ingress filtering language so the MR should have that too. Care should be taken here, though. It is difficult to talk about _the_ "inner" packet because there could be several levels of encapsulation. > In [Section 3, page 8, middle paragraph], the abbreviation CN is used > without explanation, while in the rest of the section, Correspondent > Node is always used in full. Ok. > In [Section 4.1, page 10, the explanation of Mobility Options], "... > in addition to what is defined [1]...", perhaps it should read "... > in addition to what is defined in [1]..."? Ok. > In [Section 4.4, page 13], the explanation of Prefix Length field > seems to be questionable. It says "length of the IPv6 prefix > contained in the option", but there is no prefix in this option. Good issue. (how about this: 8 bit unsigned integer indicating the number of bits, when counted left to right (or most significant to least significant) of the Home Address, that constitute the mobile network prefix.) > Also, a full-stop punctuation is missing. Ok. > In [Section 5, page 14, right at the bottom], "Similarly to a Mobile > Host, ..." should be "Similar to a Mobile Host, ...". Ok. > In [Section 5.4, page 16-17], there are a few instances of the term > "should" is used without capitalization. In addition, a few > instances of the expression "... Mobile Router will discard ...". The > "will" should be changed to "MUST", "SHOULD", etc as described in > RFC2119. Ok all. > In [Section 5.4, page 17, right at the top], " ... MAY try try ..." > => duplicate 'try'. Ok. > In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is > missing for the first bullet. Ok. > In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A > Mobile ..." Ok. > In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP > based ...". Pardon my ignorance, but I am not familiar with the > abbreviation MNLP. Perhaps it should be expanded or referenced? Ok, it's Mobile Network Prefix Length option. > In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop > punctuation is missing. Ok. > Throughout Sections 5 and 6, the terms "Home Agent", "Mobile > Network", and "Mobile Network Prefix" are sometimes used with all > lower case, sometimes used with first letter capitalized. It will be > nice to be consistent. Ok how about lower case "mobile network" for "Mobile Network" alone, but still use "Mobile Network" when suffixed by Prefix Option, or when in a field of a Binding Ack. > That's all for now, I am still digesting the draft. Hope it's easily digestible, Alex GBU From exim@www1.ietf.org Tue Jun 24 08:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14202 for ; Tue, 24 Jun 2003 08:55:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OCtCP03179 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 08:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnKK-0000pC-Aq for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 08:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14178 for ; Tue, 24 Jun 2003 08:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnKI-0002hh-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 08:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UnKD-0002he-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 08:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnK9-0000l6-Qy; Tue, 24 Jun 2003 08:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnJN-0000kb-Qw for nemo@optimus.ietf.org; Tue, 24 Jun 2003 08:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14151 for ; Tue, 24 Jun 2003 08:54:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnJM-0002hO-00 for nemo@ietf.org; Tue, 24 Jun 2003 08:54:12 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19UnJB-0002hB-00 for nemo@ietf.org; Tue, 24 Jun 2003 08:54:01 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5OCrTEe012112; Tue, 24 Jun 2003 05:53:30 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5OCrOnT003435; Tue, 24 Jun 2003 07:53:27 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 005D82EC86; Tue, 24 Jun 2003 14:53:23 +0200 (CEST) Message-ID: <3EF849C3.9080502@motorola.com> Date: Tue, 24 Jun 2003 14:53:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "T.J. Kniveton" , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> In-Reply-To: <1056428391.1789.56.camel@beethoven> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > o Conceptual clarifications: > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the > Home Agent should not forward packets destined for mobile network if > R flag is not set. So, does this means that for a static route > configuration where the next hop for the Mobile Network Prefix is the > Mobile Router, the Home Agent should discard packets sent to the > Mobile Network Prefix if it receives a BU from Mobile Router with > R=0? Perhaps the response of the Home Agent in this case can be > specified? Good issue, should be discussed. Remark it has implications on many things; > In [Section 5.1, page 14], it is said that the Binding Update List > should hold the prefix information. For a MR with multiple prefixes, > are all these prefixes going to be stored in the Binding Update > List? So each entry in the Binding Update List is going to be dynamic > in size (since the maximum number of prefixes is not known)? Good issue, same. > Nothing is said about the Data Structure of the Home Agent. Shouldn't > there be changes to the Binding Cache as well? I suppose that not even when the Explicit mode is used (prefixes in the BU) there is no need to modify the Binding Cache of HA. > Nothing is mentioned about the Home Agent performing ND proxy for the > Mobile Network Prefix. Is it deemed not necessary by the design > team? I personally think that there is a strong need for such a section in the Home Agent Operation, but that section should only contain the list of enhancements of the HA for Mobile Routers. > Nothing is mentioned in the operation of Mobile Router about checks > on received tunnelled packets from Home Agent. Shouldn't the Mobile > Router verify that the inner packet has a destination address that > is within its Mobile Network Prefix? Good issue. It is true that the HA has some ingress filtering language so the MR should have that too. Care should be taken here, though. It is difficult to talk about _the_ "inner" packet because there could be several levels of encapsulation. > In [Section 3, page 8, middle paragraph], the abbreviation CN is used > without explanation, while in the rest of the section, Correspondent > Node is always used in full. Ok. > In [Section 4.1, page 10, the explanation of Mobility Options], "... > in addition to what is defined [1]...", perhaps it should read "... > in addition to what is defined in [1]..."? Ok. > In [Section 4.4, page 13], the explanation of Prefix Length field > seems to be questionable. It says "length of the IPv6 prefix > contained in the option", but there is no prefix in this option. Good issue. (how about this: 8 bit unsigned integer indicating the number of bits, when counted left to right (or most significant to least significant) of the Home Address, that constitute the mobile network prefix.) > Also, a full-stop punctuation is missing. Ok. > In [Section 5, page 14, right at the bottom], "Similarly to a Mobile > Host, ..." should be "Similar to a Mobile Host, ...". Ok. > In [Section 5.4, page 16-17], there are a few instances of the term > "should" is used without capitalization. In addition, a few > instances of the expression "... Mobile Router will discard ...". The > "will" should be changed to "MUST", "SHOULD", etc as described in > RFC2119. Ok all. > In [Section 5.4, page 17, right at the top], " ... MAY try try ..." > => duplicate 'try'. Ok. > In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is > missing for the first bullet. Ok. > In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A > Mobile ..." Ok. > In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP > based ...". Pardon my ignorance, but I am not familiar with the > abbreviation MNLP. Perhaps it should be expanded or referenced? Ok, it's Mobile Network Prefix Length option. > In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop > punctuation is missing. Ok. > Throughout Sections 5 and 6, the terms "Home Agent", "Mobile > Network", and "Mobile Network Prefix" are sometimes used with all > lower case, sometimes used with first letter capitalized. It will be > nice to be consistent. Ok how about lower case "mobile network" for "Mobile Network" alone, but still use "Mobile Network" when suffixed by Prefix Option, or when in a field of a Binding Ack. > That's all for now, I am still digesting the draft. Hope it's easily digestible, Alex GBU From nemo-admin@ietf.org Tue Jun 24 09:06:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14752 for ; Tue, 24 Jun 2003 09:06:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnUo-0001H8-1K; Tue, 24 Jun 2003 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnU0-0001FP-2A for nemo@optimus.ietf.org; Tue, 24 Jun 2003 09:05:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14665 for ; Tue, 24 Jun 2003 09:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnTy-0002nM-00 for nemo@ietf.org; Tue, 24 Jun 2003 09:05:10 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19UnTn-0002mO-00 for nemo@ietf.org; Tue, 24 Jun 2003 09:04:59 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5OD4GYl028406; Tue, 24 Jun 2003 06:04:16 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5OD4CnT011088; Tue, 24 Jun 2003 08:04:13 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 76D832EC86; Tue, 24 Jun 2003 15:04:11 +0200 (CEST) Message-ID: <3EF84C4A.1060202@motorola.com> Date: Tue, 24 Jun 2003 15:04:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] nemo basic support ptotocol draft. References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > I have following question about multicast group for mobile router. > >>> If mobile router want to join a multicast group while MR is in > foreign location, it needs to join the multicast group via > bidirectional tunnel. > >>> Is there any way by which mobile network node can individually >>> join > the multicast group. I think that hosts in the mobile network, that are placed immediately under the MR, e.g. on a link immediately below MR will indeed individually join the multicast groups with MLD. Those hosts will see no change in the multicast tree when the MR changes its Care-of Address. I think that routers in the mobile network will join groups but not with MLD. Alex GBU From exim@www1.ietf.org Tue Jun 24 09:06:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14796 for ; Tue, 24 Jun 2003 09:06:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OD6Aq05026 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 09:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnUw-0001Iz-2U for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:06:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14739 for ; Tue, 24 Jun 2003 09:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnUu-0002nq-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 09:06:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UnUo-0002nn-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 09:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnUo-0001H8-1K; Tue, 24 Jun 2003 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnU0-0001FP-2A for nemo@optimus.ietf.org; Tue, 24 Jun 2003 09:05:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14665 for ; Tue, 24 Jun 2003 09:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnTy-0002nM-00 for nemo@ietf.org; Tue, 24 Jun 2003 09:05:10 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19UnTn-0002mO-00 for nemo@ietf.org; Tue, 24 Jun 2003 09:04:59 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5OD4GYl028406; Tue, 24 Jun 2003 06:04:16 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5OD4CnT011088; Tue, 24 Jun 2003 08:04:13 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 76D832EC86; Tue, 24 Jun 2003 15:04:11 +0200 (CEST) Message-ID: <3EF84C4A.1060202@motorola.com> Date: Tue, 24 Jun 2003 15:04:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] nemo basic support ptotocol draft. References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > I have following question about multicast group for mobile router. > >>> If mobile router want to join a multicast group while MR is in > foreign location, it needs to join the multicast group via > bidirectional tunnel. > >>> Is there any way by which mobile network node can individually >>> join > the multicast group. I think that hosts in the mobile network, that are placed immediately under the MR, e.g. on a link immediately below MR will indeed individually join the multicast groups with MLD. Those hosts will see no change in the multicast tree when the MR changes its Care-of Address. I think that routers in the mobile network will join groups but not with MLD. Alex GBU From nemo-admin@ietf.org Tue Jun 24 11:00:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19338 for ; Tue, 24 Jun 2003 11:00:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpH7-000610-8Z; Tue, 24 Jun 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpB3-0005jZ-0g for nemo@optimus.ietf.org; Tue, 24 Jun 2003 10:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19102 for ; Tue, 24 Jun 2003 10:53:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpB0-0003RH-00 for nemo@ietf.org; Tue, 24 Jun 2003 10:53:42 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 19UpAp-0003Qg-00 for nemo@ietf.org; Tue, 24 Jun 2003 10:53:31 -0400 Received: by jazz.mei.co.jp (8.12.9/3.7W/bulls) with ESMTP id h5OEqaBW028319; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id h5OEqbb29521; Tue, 24 Jun 2003 23:52:37 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id h5OEqai18994; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Received: from atomic (mie [202.221.32.171] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id h5OEqapB025063; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Message-Id: <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> Date: Tue, 24 Jun 2003 23:52:35 +0900 From: MATSUMOTO Taisuke Subject: Re: [nemo] Design Team draft for NEMO Basic Solution To: Alexandru Petrescu Cc: Chan-Wah Ng , "T.J. Kniveton" , IETF NEMO WG Organization: =?ISO-8859-1?Q?=8F=BC=89=BA=93d=8A=ED=8EY=8B=C6=28=8A=94=29?= In-Reply-To: <3EF849C3.9080502@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Alex, Chan-Wah and all, I'm most grateful for the efforts of the design team. At Tue, 24 Jun 2003 14:53:23 +0200, Alexandru Petrescu wrote : > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design > > team? > > I personally think that there is a strong need for such a section in the > Home Agent Operation, but that section should only contain the list of > enhancements of the HA for Mobile Routers. I'm sorry but I can't imagine the necessity of ND proxy on HA. When the border router (BR) of the home link has the entry which contains the HoA of the MR as the next hop of the Mobile Network Prefix, the BR may perform the Neighbor Solicitation. And then HA will answer with the proxy Neighbor Advertisement. But I think it is a Mobile IP specific, not a NEMO specific, isn't it? Is there another kind of ND proxy on HA? *** I found one typo in the section 5.6. page 18. In the 4th line of the 3rd paragraph, the word 'visisted' may be 'visited'. Best regards, Taisuke -- Taisuke Matsumoto <> From exim@www1.ietf.org Tue Jun 24 11:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19353 for ; Tue, 24 Jun 2003 11:00:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OF0Du23278 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 11:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpHJ-00063N-RW for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19322 for ; Tue, 24 Jun 2003 11:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpHG-0003UM-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 11:00:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpHB-0003UI-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 11:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpH7-000610-8Z; Tue, 24 Jun 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpB3-0005jZ-0g for nemo@optimus.ietf.org; Tue, 24 Jun 2003 10:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19102 for ; Tue, 24 Jun 2003 10:53:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpB0-0003RH-00 for nemo@ietf.org; Tue, 24 Jun 2003 10:53:42 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 19UpAp-0003Qg-00 for nemo@ietf.org; Tue, 24 Jun 2003 10:53:31 -0400 Received: by jazz.mei.co.jp (8.12.9/3.7W/bulls) with ESMTP id h5OEqaBW028319; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id h5OEqbb29521; Tue, 24 Jun 2003 23:52:37 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id h5OEqai18994; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Received: from atomic (mie [202.221.32.171] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id h5OEqapB025063; Tue, 24 Jun 2003 23:52:36 +0900 (JST) Message-Id: <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> Date: Tue, 24 Jun 2003 23:52:35 +0900 From: MATSUMOTO Taisuke Subject: Re: [nemo] Design Team draft for NEMO Basic Solution To: Alexandru Petrescu Cc: Chan-Wah Ng , "T.J. Kniveton" , IETF NEMO WG Organization: =?ISO-8859-1?Q?=8F=BC=89=BA=93d=8A=ED=8EY=8B=C6=28=8A=94=29?= In-Reply-To: <3EF849C3.9080502@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Alex, Chan-Wah and all, I'm most grateful for the efforts of the design team. At Tue, 24 Jun 2003 14:53:23 +0200, Alexandru Petrescu wrote : > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design > > team? > > I personally think that there is a strong need for such a section in the > Home Agent Operation, but that section should only contain the list of > enhancements of the HA for Mobile Routers. I'm sorry but I can't imagine the necessity of ND proxy on HA. When the border router (BR) of the home link has the entry which contains the HoA of the MR as the next hop of the Mobile Network Prefix, the BR may perform the Neighbor Solicitation. And then HA will answer with the proxy Neighbor Advertisement. But I think it is a Mobile IP specific, not a NEMO specific, isn't it? Is there another kind of ND proxy on HA? *** I found one typo in the section 5.6. page 18. In the 4th line of the 3rd paragraph, the word 'visisted' may be 'visited'. Best regards, Taisuke -- Taisuke Matsumoto <> From nemo-admin@ietf.org Tue Jun 24 11:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20619 for ; Tue, 24 Jun 2003 11:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upo0-0007U5-Q9; Tue, 24 Jun 2003 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upnh-0007Tn-CA for nemo@optimus.ietf.org; Tue, 24 Jun 2003 11:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20583 for ; Tue, 24 Jun 2003 11:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upng-0003jW-00 for nemo@ietf.org; Tue, 24 Jun 2003 11:33:40 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19UpnV-0003jO-00 for nemo@ietf.org; Tue, 24 Jun 2003 11:33:29 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h5OFWwP1027998; Tue, 24 Jun 2003 08:32:58 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5OFWu0J027961; Tue, 24 Jun 2003 10:32:58 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id AE0D02EC86; Tue, 24 Jun 2003 17:32:55 +0200 (CEST) Message-ID: <3EF86F27.9010402@motorola.com> Date: Tue, 24 Jun 2003 17:32:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke Cc: Chan-Wah Ng , "T.J. Kniveton" , IETF NEMO WG , Brian Haley Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> In-Reply-To: <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit MATSUMOTO Taisuke wrote: >> I personally think that there is a strong need for such a section >> in the Home Agent Operation, but that section should only contain >> the list of enhancements of the HA for Mobile Routers. > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > When the border router (BR) of the home link has the entry which > contains the HoA of the MR as the next hop of the Mobile Network > Prefix, the BR may perform the Neighbor Solicitation. And then HA > will answer with the proxy Neighbor Advertisement. Ok. I think Brian mentioned that the 'R' bit should be set in this NA, when it corresponds to a Home Address whose Binding Cache entry corresponds to a received BU that had the 'R' bit set. More specifically, Mobile IPv6 HA says in the "Intercepting" section 10.4.1 that: o The Router (R) bit in the Advertisement MUST be set to zero. So, it is probably not very logic for a HA that is itself a router and moreover sends NA's on behalf of a router, to keep that bit set to zero. (Also, maybe it is good for the respective Binding Cache entry at the HA to probably have an additional 'R' bit to ease implementation. I think someone raised this issue recently.) > But I think it is a Mobile IP specific, not a NEMO specific, isn't > it? So you think that probably this should be suggested to the Mobile IP Working Group instead of the NEMO Working Group? I guess that can only be a good alternative. > Is there another kind of ND proxy on HA? Please be more specific with the question? What do you think? > I found one typo in the section 5.6. page 18. In the 4th line of the > 3rd paragraph, the word 'visisted' may be 'visited'. Ok. Alex GBU From exim@www1.ietf.org Tue Jun 24 11:34:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20638 for ; Tue, 24 Jun 2003 11:34:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OFYPt29035 for nemo-archive@odin.ietf.org; Tue, 24 Jun 2003 11:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpoA-0007Vw-Js for nemo-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20592 for ; Tue, 24 Jun 2003 11:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upo9-0003jm-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 11:34:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Upo4-0003jj-00 for nemo-web-archive@ietf.org; Tue, 24 Jun 2003 11:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upo0-0007U5-Q9; Tue, 24 Jun 2003 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Upnh-0007Tn-CA for nemo@optimus.ietf.org; Tue, 24 Jun 2003 11:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20583 for ; Tue, 24 Jun 2003 11:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Upng-0003jW-00 for nemo@ietf.org; Tue, 24 Jun 2003 11:33:40 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19UpnV-0003jO-00 for nemo@ietf.org; Tue, 24 Jun 2003 11:33:29 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h5OFWwP1027998; Tue, 24 Jun 2003 08:32:58 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5OFWu0J027961; Tue, 24 Jun 2003 10:32:58 -0500 Received: from motorola.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id AE0D02EC86; Tue, 24 Jun 2003 17:32:55 +0200 (CEST) Message-ID: <3EF86F27.9010402@motorola.com> Date: Tue, 24 Jun 2003 17:32:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke Cc: Chan-Wah Ng , "T.J. Kniveton" , IETF NEMO WG , Brian Haley Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> In-Reply-To: <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit MATSUMOTO Taisuke wrote: >> I personally think that there is a strong need for such a section >> in the Home Agent Operation, but that section should only contain >> the list of enhancements of the HA for Mobile Routers. > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > When the border router (BR) of the home link has the entry which > contains the HoA of the MR as the next hop of the Mobile Network > Prefix, the BR may perform the Neighbor Solicitation. And then HA > will answer with the proxy Neighbor Advertisement. Ok. I think Brian mentioned that the 'R' bit should be set in this NA, when it corresponds to a Home Address whose Binding Cache entry corresponds to a received BU that had the 'R' bit set. More specifically, Mobile IPv6 HA says in the "Intercepting" section 10.4.1 that: o The Router (R) bit in the Advertisement MUST be set to zero. So, it is probably not very logic for a HA that is itself a router and moreover sends NA's on behalf of a router, to keep that bit set to zero. (Also, maybe it is good for the respective Binding Cache entry at the HA to probably have an additional 'R' bit to ease implementation. I think someone raised this issue recently.) > But I think it is a Mobile IP specific, not a NEMO specific, isn't > it? So you think that probably this should be suggested to the Mobile IP Working Group instead of the NEMO Working Group? I guess that can only be a good alternative. > Is there another kind of ND proxy on HA? Please be more specific with the question? What do you think? > I found one typo in the section 5.6. page 18. In the 4th line of the > 3rd paragraph, the word 'visisted' may be 'visited'. Ok. Alex GBU From nemo-admin@ietf.org Wed Jun 25 11:37:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16368 for ; Wed, 25 Jun 2003 11:37:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJN-0001oW-Lo; Wed, 25 Jun 2003 11:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxm-0008Bp-AR for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04115 for ; Wed, 25 Jun 2003 03:48:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V50h-0002cp-00 for nemo@ietf.org; Wed, 25 Jun 2003 03:48:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19V50X-0002cZ-00 for nemo@ietf.org; Wed, 25 Jun 2003 03:47:57 -0400 Received: from huez.nautilus6.org (unknown [203.178.138.5]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id AA38E5D0D0; Wed, 25 Jun 2003 16:47:01 +0900 (JST) Date: Wed, 25 Jun 2003 16:46:21 +0900 From: Thierry Ernst To: "Na, Jong Keun" Cc: nemo@ietf.org Subject: Re: [nemo] About NEMO simulator Message-Id: <20030625164621.1f555531.ernst@sfc.wide.ad.jp> In-Reply-To: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> References: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Jong Keun, all, I reply to you directly since I developped Mobiwan ... Mobiwan is not supposed to work in a NS version other than ns-2.1b6. Also, it is not supposed to fulfill all simulation needs. It worked well for what I had to demonstrate, but I've received many negative reports from people that couldn't make it work under different situations. Besides this, the code is out-dated (developped in 1999-2000, released in 2001). Although it's for ages in my todo-list, I've never found the time to port the code the latest NS version and to adapt it to NEMO. > I think that we need NEMO simulator for the verification of the proposed > protocols/algorithms and extensions. > Is there any action or plan for this work? Probably useful, but not part of NEMO WG (or any IETF WG) goals. > Anyway, I'm considering mobiwan package as a starting point that > implemented the minimum level of MIPv6 for NEMO. > I already got mobiwan-021513.tar.gz distribution package. But it doesn't > work in ns2 all-in-one 2.26. Right. Mobiwan was developped under ns-2.1b6, so it's unlikely it can be ported easily. > Is there any modified or ported to that ns version? If yes and anybody > know, please let me know. Many people have reported me they are willing to extend the code (not for NEMO, but for other mobility-related simulations), but I don't know if anyone has been succesful in it (or let's say it: motivated enough to do it) AND is willing to contribute the extensions (I'm aware of some success in some private companies, but they are not willing to publish the extensions). > If not exists and porting is apparently necessary, I will do. > By the way, also I'd like to know how this work is valuable to us before > starting this work. > Any comments and suggestions to the way of making simulation package for > NEMO would be very helpful to me. The IETF probably doesn't care much, but some people on the list will find it useful to conduct their own research. Me included. However, this is a time-consuming task. Any such work should be conducted by someone having enough time to interact with the NS developpers so that it becomes fully integrated in NS forthcoming releases. I'm happy to participate is there are volunteers, but not to do it alone. Thierry From nemo-admin@ietf.org Wed Jun 25 11:40:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16562 for ; Wed, 25 Jun 2003 11:40:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJS-0001t2-0T; Wed, 25 Jun 2003 11:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxS-0008AG-6J for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04857 for ; Wed, 25 Jun 2003 04:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5ge-0002p1-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:31:28 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19V5gT-0002oy-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:31:17 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5P8lCW26574; Wed, 25 Jun 2003 17:47:12 +0900 (KST) (envelope-from eun) Date: Wed, 25 Jun 2003 17:47:12 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030625174712.A26407@mmlab.snu.ac.kr> References: <20030624130406.A8802@mmlab.snu.ac.kr> <3EF83DF3.5080607@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3EF83DF3.5080607@motorola.com>; from alexandru.petrescu@motorola.com on Tue, Jun 24, 2003 at 02:02:59PM +0200 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , On Tue, Jun 24, 2003 at 02:02:59PM +0200, Alexandru Petrescu wrote: > eun wrote: > >> It can be based on routing metric, load balancing, or even just a > >> default route selection. There shouldn't be any problem in doing > >> that. > > > > > > Maybe it is just an implementation issue. Or we may propose something > > optimal for NEMO. I wonder what people in NEMO maling list think. > > I think that it is very good to propose improvements. But I also think > that it might be needed to propose it in a more multi-homing focused > Working Group, such as multi6. What do you think? > Yes, it might be. However, if the improvement is NEMO specific, e.g. if it is related to mobility characteristics, NEMO people may want discuss it in NEMO WG, IMO. Regards, Eun Kyoung From nemo-admin@ietf.org Wed Jun 25 11:44:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17058 for ; Wed, 25 Jun 2003 11:44:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCRR-00052C-VD; Wed, 25 Jun 2003 11:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzE-0008Cz-Cm for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03461 for ; Tue, 24 Jun 2003 22:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V01x-0001Y1-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:29:05 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19V01m-0001Xy-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:28:54 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Wed, 25 Jun 2003 12:26:55 +1000 From: "Muhammad Ali Malik" To: Date: Wed, 25 Jun 2003 12:20:22 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C33B14.269A3190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] Nemo basic support protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C33B14.269A3190 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA03465 Content-Transfer-Encoding: quoted-printable Hi Why the NEMO basic support is based on Mobile IPv6. Still there is no RFC for Mobile IPv6. I Why can=92t NEMO basic support protocol depends on IPv4. Regards, Muhammad ------=_NextPart_000_0015_01C33B14.269A3190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Why the NEMO basic support is based on Mobile IPv6. Still there = is no RFC for Mobile IPv6. I

 

Why can’t NEMO basic support protocol depends on = IPv4.

 

Regards,

 

Muhammad

------=_NextPart_000_0015_01C33B14.269A3190-- From nemo-admin@ietf.org Wed Jun 25 11:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17218 for ; Wed, 25 Jun 2003 11:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSB-0005S1-Sz; Wed, 25 Jun 2003 11:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzA-0007wP-Og for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03756 for ; Tue, 24 Jun 2003 22:45:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V0Hh-0001ap-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:45:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19V0HW-0001ai-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:45:10 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5P2b8427373; Wed, 25 Jun 2003 10:37:09 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id BA71F10E95DA; Wed, 25 Jun 2003 10:44:40 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: Alexandru Petrescu Cc: "T.J. Kniveton" , IETF NEMO WG In-Reply-To: <3EF849C3.9080502@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056509080.1486.27.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 25 Jun 2003 10:44:40 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Alex, On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > there be changes to the Binding Cache as well? > > I suppose that not even when the Explicit mode is used (prefixes in the > BU) there is no need to modify the Binding Cache of HA. > Why wouldn't the HA want to store the prefixes into the BCE? Anyway, the R bit should be added to BCE. > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design > > team? > > I personally think that there is a strong need for such a section in the > Home Agent Operation, but that section should only contain the list of > enhancements of the HA for Mobile Routers. > I will comment on this on the other fork of this thread. > > That's all for now, I am still digesting the draft. > > Hope it's easily digestible, :) /rgds /cwng From nemo-admin@ietf.org Wed Jun 25 11:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17250 for ; Wed, 25 Jun 2003 11:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSE-0005dD-UE; Wed, 25 Jun 2003 11:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzM-0006YL-Qp for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01264 for ; Tue, 24 Jun 2003 21:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uys0-00011P-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:14:44 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19Uyrp-00011L-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:14:34 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXICP4TB609B8HDF@vaxh.its.monash.edu.au> for nemo@ietf.org; Wed, 25 Jun 2003 11:10:21 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C30F712C006 for ; Wed, 25 Jun 2003 11:10:20 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id AB51E12C004 for ; Wed, 25 Jun 2003 11:10:20 +1000 (EST) Date: Wed, 25 Jun 2003 11:10:20 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: nemo Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EF8F67C.6090603@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Muhammad, Muhammad Ali Malik wrote: > Hi Greg > > This means that mobile network node (MNN) should request MR, if it > wants to join any multicast group. Even with multicasting, all message > From MNN to CH will have to travel on bi-directional tunnels. The MNN has to join the group on its AR which may or may not be an MR. Multicast routing could be run on the NEMO, over the tunnel, but the packet flow is unidirectional for client multicast traffic. > Is there any way we can avoid the bi-directional tunneling by > requesting MR to join the multicast group on behalf of Mobile Network. Yes, Maybe. There's nothing defined yet. (there's not even much work done for mobile hosts in this case, that would have to be done first, since the MR is a host to the visited net). Greg From nemo-admin@ietf.org Wed Jun 25 11:46:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17398 for ; Wed, 25 Jun 2003 11:45:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSh-0005yF-49; Wed, 25 Jun 2003 11:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzQ-0007wP-RJ for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02614 for ; Tue, 24 Jun 2003 21:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UzYA-0001QG-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:58:18 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 19UzXz-0001Pw-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:58:07 -0400 Received: by jazz.mei.co.jp (8.12.9/3.7W/bulls) with ESMTP id h5P1vFBW016047 for ; Wed, 25 Jun 2003 10:57:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id h5P1vHu20422 for ; Wed, 25 Jun 2003 10:57:17 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id h5P1vFF24044 for ; Wed, 25 Jun 2003 10:57:15 +0900 (JST) Received: from GIULIA (julia [133.185.27.249] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id h5P1vEpB090502 for ; Wed, 25 Jun 2003 10:57:14 +0900 (JST) Message-Id: <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> Date: Wed, 25 Jun 2003 10:57:45 +0900 From: MATSUMOTO Taisuke Subject: Re: [nemo] Design Team draft for NEMO Basic Solution To: IETF NEMO WG Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3EF86F27.9010402@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Alex, On Tue, 24 Jun 2003 17:32:55 +0200, Alexandru Petrescu wrote : > MATSUMOTO Taisuke wrote: > >> I personally think that there is a strong need for such a section > >> in the Home Agent Operation, but that section should only contain > >> the list of enhancements of the HA for Mobile Routers. > > > > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > > > When the border router (BR) of the home link has the entry which > > contains the HoA of the MR as the next hop of the Mobile Network > > Prefix, the BR may perform the Neighbor Solicitation. And then HA > > will answer with the proxy Neighbor Advertisement. > > Ok. I think Brian mentioned that the 'R' bit should be set in this NA, > when it corresponds to a Home Address whose Binding Cache entry > corresponds to a received BU that had the 'R' bit set. > > More specifically, Mobile IPv6 HA says in the "Intercepting" section > 10.4.1 that: > > o The Router (R) bit in the Advertisement MUST be set to zero. > > So, it is probably not very logic for a HA that is itself a router and > moreover sends NA's on behalf of a router, to keep that bit set to zero. Now I get it. I failed to notice of 'R' bit in NA. > (Also, maybe it is good for the respective Binding Cache entry at the > HA to probably have an additional 'R' bit to ease implementation. I > think someone raised this issue recently.) I agree. > > But I think it is a Mobile IP specific, not a NEMO specific, isn't > > it? > > So you think that probably this should be suggested to the Mobile IP > Working Group instead of the NEMO Working Group? I guess that can only > be a good alternative. In my previous mail, I was convinced that what is necessary is just to perform ND proxy as description of Mobile IP. But I'm clear now. I agree with you on the necessity of discussion about the HA operations. > > Is there another kind of ND proxy on HA? > > Please be more specific with the question? Sorry. I had thought that the description in the Mobile IP draft was enough to specify the behavior of ND proxy on HA. Therefore I wondered if there were other ND proxies, for instance proxy RS, proxy RA.... Thank you for your kind guidance. BR, Taisuke From nemo-admin@ietf.org Wed Jun 25 11:48:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17745 for ; Wed, 25 Jun 2003 11:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCV6-0006pD-7g; Wed, 25 Jun 2003 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCQJ-0004gS-D5 for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:43:03 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16846 for ; Wed, 25 Jun 2003 11:42:59 -0400 (EDT) Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5PFa3gx002045; Thu, 26 Jun 2003 00:36:04 +0900 From: "Jongkeun Na" To: "'Thierry Ernst'" Cc: Subject: RE: [nemo] About NEMO simulator Date: Thu, 26 Jun 2003 00:37:39 +0900 Message-ID: <03a801c33b2f$b79bab40$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030625164621.1f555531.ernst@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Thierry, Thank you for good comments. I also feel that it's hard to do this work as my fulltime job. But, whenever I get spare time I will continuously try to get the base code of mobiwan that works on ns-allinone-2.26. Honestly speaking, as of now, I need more technical understandings on ns such as C++/TCL object binding and other environment/tools. But, if I can focus on this work more than now, I expect that the stable code will be readied in time. If it well done, I will let you all know about the result of work. Afterward, I think, we can more talk. Best Regards, /Jongkeun > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: Wednesday, June 25, 2003 4:46 PM > To: Na, Jong Keun > Cc: nemo@ietf.org > Subject: Re: [nemo] About NEMO simulator > > > Dear Jong Keun, all, > > I reply to you directly since I developped Mobiwan ... Mobiwan is not > supposed to work in a NS version other than ns-2.1b6. Also, it is not > supposed to fulfill all simulation needs. It worked well for what I had > to demonstrate, but I've received many negative reports from people that > couldn't make it work under different situations. Besides this, the code > is out-dated (developped in 1999-2000, released in 2001). > > Although it's for ages in my todo-list, I've never found the time to > port the code the latest NS version and to adapt it to NEMO. > > > I think that we need NEMO simulator for the verification of the proposed > > protocols/algorithms and extensions. > > Is there any action or plan for this work? > > Probably useful, but not part of NEMO WG (or any IETF WG) goals. > > > Anyway, I'm considering mobiwan package as a starting point that > > implemented the minimum level of MIPv6 for NEMO. > > I already got mobiwan-021513.tar.gz distribution package. But it doesn't > > work in ns2 all-in-one 2.26. > > Right. Mobiwan was developped under ns-2.1b6, so it's unlikely it can be > ported easily. > > > Is there any modified or ported to that ns version? If yes and anybody > > know, please let me know. > > Many people have reported me they are willing to extend the code (not > for NEMO, but for other mobility-related simulations), but I don't know > if anyone has been succesful in it (or let's say it: motivated enough to > do it) AND is willing to contribute the extensions (I'm aware of some > success in some private companies, but they are not willing to publish > the extensions). > > > If not exists and porting is apparently necessary, I will do. > > By the way, also I'd like to know how this work is valuable to us before > > starting this work. > > Any comments and suggestions to the way of making simulation package for > > NEMO would be very helpful to me. > > The IETF probably doesn't care much, but some people on the list will > find it useful to conduct their own research. Me included. However, this > is a time-consuming task. Any such work should be conducted by someone > having enough time to interact with the NS developpers so that it > becomes fully integrated in NS forthcoming releases. I'm happy to > participate is there are volunteers, but not to do it alone. > > > Thierry > From nemo-admin@ietf.org Wed Jun 25 11:48:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17776 for ; Wed, 25 Jun 2003 11:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVH-00073n-Om; Wed, 25 Jun 2003 11:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VC0Q-0007wP-1G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12746 for ; Tue, 24 Jun 2003 17:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvl2-0007bL-00 for nemo@ietf.org; Tue, 24 Jun 2003 17:55:20 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Uvkl-0007b0-00 for nemo@ietf.org; Tue, 24 Jun 2003 17:55:04 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04799; Tue, 24 Jun 2003 14:33:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5OLX9G09253; Tue, 24 Jun 2003 14:33:09 -0700 X-mProtect: <200306242133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd30TVIr; Tue, 24 Jun 2003 14:33:08 PDT Message-ID: <3EF8C394.F91C155F@iprg.nokia.com> Date: Tue, 24 Jun 2003 14:33:08 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Chan-Wah, thanks for the detailed comments. Chan-Wah Ng wrote: > > > o Conceptual clarifications: > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home > Agent should not forward packets destined for mobile network if R flag > is not set. if the Mobile Router set the R bit to 0 in the Binding Update, it means it is going to behave as a mobile host. > So, does this means that for a static route configuration > where the next hop for the Mobile Network Prefix is the Mobile Router, > the Home Agent should discard packets sent to the Mobile Network Prefix > if it receives a BU from Mobile Router with R=0? Perhaps the response > of the Home Agent in this case can be specified? even in static route configuartion, the HA must consult the binding cache for the MR's current CoA. if there is no binding cache entry, then the packets are sent on link. if there is a binding cache entry and the R bit set to 0, the HA must not forward the packets. is this an acceptable solution? > In [Section 5.1, page 14], it is said that the Binding Update List > should hold the prefix information. For a MR with multiple prefixes, > are all these prefixes going to be stored in the Binding Update List? yup. it would be a prefix list. > So each entry in the Binding Update List is going to be dynamic in size > (since the maximum number of prefixes is not known)? it is a conceptual data structure. you can implement it any way you want. > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > there be changes to the Binding Cache as well? yes. you are right. the HA should store the prefixes that was sent in the Binding Update. it needs this list of prefixes later on to delete all the routes, if the binding cache entry expires. I will add some text. > > Nothing is mentioned about the Home Agent performing ND proxy for the > Mobile Network Prefix. Is it deemed not necessary by the design team? it should do the same as described in MIPv6. in addition it should set the R bit to 1. that is missing. we will add some text. > Nothing is mentioned in the operation of Mobile Router about checks on > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > verify that the inner packet has a destination address that is within > its Mobile Network Prefix? it should perform all the necessary checks when decapsulating and forwarding packets. we will add some text. > > o Some cosmetic comments: > > In [Section 3, page 8, middle paragraph], the abbreviation CN is used > without explanation, while in the rest of the section, Correspondent > Node is always used in full. > > In [Section 4.1, page 10, the explanation of Mobility Options], "... in > addition to what is defined [1]...", perhaps it should read "... in > addition to what is defined in [1]..."? > > In [Section 4.3, page 12, and Section 4.4, page 13], perhaps the > explanation of the "Reserved" field should follow the style of IPv6, and > MIPv6, something like: "This field is unused for now. The value MUST be > initialized to zero by the sender, and MUST be ignored by the receiver". done. > > In [Section 4.4, page 13], the explanation of Prefix Length field seems > to be questionable. It says "length of the IPv6 prefix contained in the > option", but there is no prefix in this option. Also, a full-stop > punctuation is missing. changed it to 8 bit unsigned integer indicating the prefix length of the IPv6 prefix from which the Home Address included in the Binding Update was configured from. > > In [Section 5, page 14, right at the bottom], "Similarly to a Mobile > Host, ..." should be "Similar to a Mobile Host, ...". > > In [Section 5.4, page 16-17], there are a few instances of the term > "should" is used without capitalization. In addition, a few instances > of the expression "... Mobile Router will discard ...". The "will" > should be changed to "MUST", "SHOULD", etc as described in RFC2119. > > In [Section 5.4, page 17, right at the top], " ... MAY try try ..." => > duplicate 'try'. > > In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is > missing for the first bullet. > > In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A Mobile > ..." > > In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP > based ...". Pardon my ignorance, but I am not familiar with the > abbreviation MNLP. Perhaps it should be expanded or referenced? > > In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop > punctuation is missing. > > Throughout Sections 5 and 6, the terms "Home Agent", "Mobile Network", > and "Mobile Network Prefix" are sometimes used with all lower case, > sometimes used with first letter capitalized. It will be nice to be > consistent. > > That's all for now, I am still digesting the draft. thanks, once again. Vijay From nemo-admin@ietf.org Wed Jun 25 12:13:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19522 for ; Wed, 25 Jun 2003 12:13:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJL-0001ff-B0; Wed, 25 Jun 2003 11:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxX-0008Bp-1G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05053 for ; Wed, 25 Jun 2003 04:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5zj-0002rs-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:51:11 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19V5zZ-0002rp-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:51:01 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P8ofvc021900; Wed, 25 Jun 2003 02:50:41 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5P8oeQ23358; Wed, 25 Jun 2003 10:50:40 +0200 (MEST) Date: Wed, 25 Jun 2003 10:40:24 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution To: "T.J. Kniveton" Cc: nemo@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > The subject of IPR has come up on the design team mailing list and we had a > discussion about it. In the interests of full disclosure to the whole NEMO > group, I would like to also present these messages here on the main list so > everybody can know what's going on. I have checked with the DT mailing list > members and no one has objected to this, so I will forward the messages here > for anyone who's interested. TJ, Two questions appear: - Any indication about what licensing Nokia and Cisco might be willing to offer should their claimed IPR be relevant when implementing a standard in this area? - Is there any information what the claimed IPR might actually cover? This is useful for the WG if there is a desire to proceed even though there is IPR, something which the WG is free to choose, or try to work around the IPR. If it's useful for the WG I can give some information on how IPR is usually handled in IETF WGs and answer questions during the meeting in Vienna. Erik From exim@www1.ietf.org Wed Jun 25 12:14:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19565 for ; Wed, 25 Jun 2003 12:14:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGDvW07850 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 12:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCty-000217-1w for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:13:57 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19523 for ; Wed, 25 Jun 2003 12:13:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJL-0001ff-B0; Wed, 25 Jun 2003 11:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxX-0008Bp-1G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05053 for ; Wed, 25 Jun 2003 04:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5zj-0002rs-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:51:11 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19V5zZ-0002rp-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:51:01 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P8ofvc021900; Wed, 25 Jun 2003 02:50:41 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5P8oeQ23358; Wed, 25 Jun 2003 10:50:40 +0200 (MEST) Date: Wed, 25 Jun 2003 10:40:24 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] FW: [nemo-base-dt] IPRs on base solution To: "T.J. Kniveton" Cc: nemo@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > The subject of IPR has come up on the design team mailing list and we had a > discussion about it. In the interests of full disclosure to the whole NEMO > group, I would like to also present these messages here on the main list so > everybody can know what's going on. I have checked with the DT mailing list > members and no one has objected to this, so I will forward the messages here > for anyone who's interested. TJ, Two questions appear: - Any indication about what licensing Nokia and Cisco might be willing to offer should their claimed IPR be relevant when implementing a standard in this area? - Is there any information what the claimed IPR might actually cover? This is useful for the WG if there is a desire to proceed even though there is IPR, something which the WG is free to choose, or try to work around the IPR. If it's useful for the WG I can give some information on how IPR is usually handled in IETF WGs and answer questions during the meeting in Vienna. Erik From exim@www1.ietf.org Wed Jun 25 12:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19939 for ; Wed, 25 Jun 2003 12:23:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGMd609057 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 12:22:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VD2c-0002M0-Tq for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:22:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19930 for ; Wed, 25 Jun 2003 12:22:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VD2c-00058o-00 for nemo-web-archive@ietf.org; Wed, 25 Jun 2003 12:22:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VD2W-00058k-00 for nemo-web-archive@ietf.org; Wed, 25 Jun 2003 12:22:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJN-0001oW-Lo; Wed, 25 Jun 2003 11:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxm-0008Bp-AR for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04115 for ; Wed, 25 Jun 2003 03:48:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V50h-0002cp-00 for nemo@ietf.org; Wed, 25 Jun 2003 03:48:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19V50X-0002cZ-00 for nemo@ietf.org; Wed, 25 Jun 2003 03:47:57 -0400 Received: from huez.nautilus6.org (unknown [203.178.138.5]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id AA38E5D0D0; Wed, 25 Jun 2003 16:47:01 +0900 (JST) Date: Wed, 25 Jun 2003 16:46:21 +0900 From: Thierry Ernst To: "Na, Jong Keun" Cc: nemo@ietf.org Subject: Re: [nemo] About NEMO simulator Message-Id: <20030625164621.1f555531.ernst@sfc.wide.ad.jp> In-Reply-To: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> References: <025701c33a3c$c1bbb960$dbf02e93@jongkn02> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Jong Keun, all, I reply to you directly since I developped Mobiwan ... Mobiwan is not supposed to work in a NS version other than ns-2.1b6. Also, it is not supposed to fulfill all simulation needs. It worked well for what I had to demonstrate, but I've received many negative reports from people that couldn't make it work under different situations. Besides this, the code is out-dated (developped in 1999-2000, released in 2001). Although it's for ages in my todo-list, I've never found the time to port the code the latest NS version and to adapt it to NEMO. > I think that we need NEMO simulator for the verification of the proposed > protocols/algorithms and extensions. > Is there any action or plan for this work? Probably useful, but not part of NEMO WG (or any IETF WG) goals. > Anyway, I'm considering mobiwan package as a starting point that > implemented the minimum level of MIPv6 for NEMO. > I already got mobiwan-021513.tar.gz distribution package. But it doesn't > work in ns2 all-in-one 2.26. Right. Mobiwan was developped under ns-2.1b6, so it's unlikely it can be ported easily. > Is there any modified or ported to that ns version? If yes and anybody > know, please let me know. Many people have reported me they are willing to extend the code (not for NEMO, but for other mobility-related simulations), but I don't know if anyone has been succesful in it (or let's say it: motivated enough to do it) AND is willing to contribute the extensions (I'm aware of some success in some private companies, but they are not willing to publish the extensions). > If not exists and porting is apparently necessary, I will do. > By the way, also I'd like to know how this work is valuable to us before > starting this work. > Any comments and suggestions to the way of making simulation package for > NEMO would be very helpful to me. The IETF probably doesn't care much, but some people on the list will find it useful to conduct their own research. Me included. However, this is a time-consuming task. Any such work should be conducted by someone having enough time to interact with the NS developpers so that it becomes fully integrated in NS forthcoming releases. I'm happy to participate is there are volunteers, but not to do it alone. Thierry From exim@www1.ietf.org Wed Jun 25 12:31:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20281 for ; Wed, 25 Jun 2003 12:31:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGV8F10162 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 12:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCTT-0006Ii-ST for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:46:19 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17400 for ; Wed, 25 Jun 2003 11:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSh-0005yF-49; Wed, 25 Jun 2003 11:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzQ-0007wP-RJ for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02614 for ; Tue, 24 Jun 2003 21:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UzYA-0001QG-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:58:18 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 19UzXz-0001Pw-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:58:07 -0400 Received: by jazz.mei.co.jp (8.12.9/3.7W/bulls) with ESMTP id h5P1vFBW016047 for ; Wed, 25 Jun 2003 10:57:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id h5P1vHu20422 for ; Wed, 25 Jun 2003 10:57:17 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id h5P1vFF24044 for ; Wed, 25 Jun 2003 10:57:15 +0900 (JST) Received: from GIULIA (julia [133.185.27.249] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id h5P1vEpB090502 for ; Wed, 25 Jun 2003 10:57:14 +0900 (JST) Message-Id: <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> Date: Wed, 25 Jun 2003 10:57:45 +0900 From: MATSUMOTO Taisuke Subject: Re: [nemo] Design Team draft for NEMO Basic Solution To: IETF NEMO WG Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3EF86F27.9010402@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Alex, On Tue, 24 Jun 2003 17:32:55 +0200, Alexandru Petrescu wrote : > MATSUMOTO Taisuke wrote: > >> I personally think that there is a strong need for such a section > >> in the Home Agent Operation, but that section should only contain > >> the list of enhancements of the HA for Mobile Routers. > > > > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > > > When the border router (BR) of the home link has the entry which > > contains the HoA of the MR as the next hop of the Mobile Network > > Prefix, the BR may perform the Neighbor Solicitation. And then HA > > will answer with the proxy Neighbor Advertisement. > > Ok. I think Brian mentioned that the 'R' bit should be set in this NA, > when it corresponds to a Home Address whose Binding Cache entry > corresponds to a received BU that had the 'R' bit set. > > More specifically, Mobile IPv6 HA says in the "Intercepting" section > 10.4.1 that: > > o The Router (R) bit in the Advertisement MUST be set to zero. > > So, it is probably not very logic for a HA that is itself a router and > moreover sends NA's on behalf of a router, to keep that bit set to zero. Now I get it. I failed to notice of 'R' bit in NA. > (Also, maybe it is good for the respective Binding Cache entry at the > HA to probably have an additional 'R' bit to ease implementation. I > think someone raised this issue recently.) I agree. > > But I think it is a Mobile IP specific, not a NEMO specific, isn't > > it? > > So you think that probably this should be suggested to the Mobile IP > Working Group instead of the NEMO Working Group? I guess that can only > be a good alternative. In my previous mail, I was convinced that what is necessary is just to perform ND proxy as description of Mobile IP. But I'm clear now. I agree with you on the necessity of discussion about the HA operations. > > Is there another kind of ND proxy on HA? > > Please be more specific with the question? Sorry. I had thought that the description in the Mobile IP draft was enough to specify the behavior of ND proxy on HA. Therefore I wondered if there were other ND proxies, for instance proxy RS, proxy RA.... Thank you for your kind guidance. BR, Taisuke From nemo-admin@ietf.org Wed Jun 25 19:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12713 for ; Wed, 25 Jun 2003 19:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VK7M-0002rV-Gb; Wed, 25 Jun 2003 19:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VK6Z-0002pu-2G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 19:55:11 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12650 for ; Wed, 25 Jun 2003 19:55:05 -0400 (EDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXJO7W9S6C9B7YA3@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 26 Jun 2003 09:50:50 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6254712C017; Thu, 26 Jun 2003 09:50:50 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 1823212C012; Thu, 26 Jun 2003 09:50:48 +1000 (EST) Date: Thu, 26 Jun 2003 09:50:47 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: Muhammad Ali Malik Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFA3557.6070005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Muhammad, (Cc: Nemo). Muhammad Ali Malik wrote: > Hi Greg > > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Wednesday, June 25, 2003 11:09 AM > To: Muhammad Ali Malik > Subject: Re: [nemo] nemo basic support ptotocol draft. > > Hi Muhammad, > > Muhammad Ali Malik wrote: > >> Hi Greg >> >>This means that mobile network node (MNN) should request MR, if it >>wants to join any multicast group. Even with multicasting, all message >>From MNN to CH will have to travel on bi-directional tunnels. > > > The MNN has to join the group on its AR which may or may not > be an MR. > > Multicast routing could be run on the NEMO, > over the tunnel, but the packet flow is > unidirectional for client multicast traffic. > > Can u please elaborate it. What do u mean that the packet flow is > unidirectional for client multicast traffic. If we limit the discussion to only multicast clients: those hosts consuming multicast content, without generating any themselves, then the multicast traffic either originates on the NEMO (in which case it is handled by local multicast routing protocols) or is from the fixed network. There may be one or more multicast clients listening to this traffic on the NEMO, though no multicast packets are forwarded from these hosts to devices on the fixed network: Only routing information is sent off-NEMO in order to ensure that the MR and ARs within the NEMO receive multicast streams to forward to their MNNs. The traffic is flowing toward the hosts on the NEMO. If there is a low-latency requirement in receiving the data stream, then the MR could request it from the visited access network using MLD/IGMP (although how the MR would know which multicast groups to do it for would be difficult to determine). > So this means that even after (MNN or MR) joins the multicast group, we > cannot avoid the tunneling. No, not actually with the existing model (tunnel from MR's home network). It is possible to conceive that the MR could get service from the visited fixed network, although this is not supported in either current mobile-ip or nemo. If we look at the other side of the issue: For multicast traffic sources on the NEMO, there is some significant benefit to sending the traffic over a tunnel to the home network (of the MR or the MNN) in any case, in order to avoid ingress filtering issues in the visited access networks. We do not want the source address to change with multicast sources (because of source-specific multicast), so reverse tunneling of multicast traffic generated from a mobile device (like an MNN) looks likely. (unless we can come up with a way of handling this issue as well). Greg From exim@www1.ietf.org Wed Jun 25 19:57:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12754 for ; Wed, 25 Jun 2003 19:57:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PNuYL11302 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 19:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VK7u-0002wD-J6 for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 19:56:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12712 for ; Wed, 25 Jun 2003 19:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VK7M-0002rV-Gb; Wed, 25 Jun 2003 19:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VK6Z-0002pu-2G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 19:55:11 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12650 for ; Wed, 25 Jun 2003 19:55:05 -0400 (EDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXJO7W9S6C9B7YA3@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 26 Jun 2003 09:50:50 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6254712C017; Thu, 26 Jun 2003 09:50:50 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 1823212C012; Thu, 26 Jun 2003 09:50:48 +1000 (EST) Date: Thu, 26 Jun 2003 09:50:47 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: Muhammad Ali Malik Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFA3557.6070005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Muhammad, (Cc: Nemo). Muhammad Ali Malik wrote: > Hi Greg > > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Wednesday, June 25, 2003 11:09 AM > To: Muhammad Ali Malik > Subject: Re: [nemo] nemo basic support ptotocol draft. > > Hi Muhammad, > > Muhammad Ali Malik wrote: > >> Hi Greg >> >>This means that mobile network node (MNN) should request MR, if it >>wants to join any multicast group. Even with multicasting, all message >>From MNN to CH will have to travel on bi-directional tunnels. > > > The MNN has to join the group on its AR which may or may not > be an MR. > > Multicast routing could be run on the NEMO, > over the tunnel, but the packet flow is > unidirectional for client multicast traffic. > > Can u please elaborate it. What do u mean that the packet flow is > unidirectional for client multicast traffic. If we limit the discussion to only multicast clients: those hosts consuming multicast content, without generating any themselves, then the multicast traffic either originates on the NEMO (in which case it is handled by local multicast routing protocols) or is from the fixed network. There may be one or more multicast clients listening to this traffic on the NEMO, though no multicast packets are forwarded from these hosts to devices on the fixed network: Only routing information is sent off-NEMO in order to ensure that the MR and ARs within the NEMO receive multicast streams to forward to their MNNs. The traffic is flowing toward the hosts on the NEMO. If there is a low-latency requirement in receiving the data stream, then the MR could request it from the visited access network using MLD/IGMP (although how the MR would know which multicast groups to do it for would be difficult to determine). > So this means that even after (MNN or MR) joins the multicast group, we > cannot avoid the tunneling. No, not actually with the existing model (tunnel from MR's home network). It is possible to conceive that the MR could get service from the visited fixed network, although this is not supported in either current mobile-ip or nemo. If we look at the other side of the issue: For multicast traffic sources on the NEMO, there is some significant benefit to sending the traffic over a tunnel to the home network (of the MR or the MNN) in any case, in order to avoid ingress filtering issues in the visited access networks. We do not want the source address to change with multicast sources (because of source-specific multicast), so reverse tunneling of multicast traffic generated from a mobile device (like an MNN) looks likely. (unless we can come up with a way of handling this issue as well). Greg From nemo-admin@ietf.org Thu Jun 26 04:24:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12048 for ; Thu, 26 Jun 2003 04:24:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS38-0005hW-DE; Thu, 26 Jun 2003 04:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRKu-0002un-OZ for nemo@optimus.ietf.org; Thu, 26 Jun 2003 03:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11194 for ; Thu, 26 Jun 2003 03:38:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRKd-0006OK-00 for nemo@ietf.org; Thu, 26 Jun 2003 03:38:11 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VRKS-0006O6-00 for nemo@ietf.org; Thu, 26 Jun 2003 03:38:00 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q7cQcv004892; Thu, 26 Jun 2003 09:38:27 +0200 Received: from era.ericsson.se (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N4L8MGQW; Thu, 26 Jun 2003 09:37:29 +0200 Message-ID: <3EFAA1E8.2030100@era.ericsson.se> Date: Thu, 26 Jun 2003 09:34:00 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think you have produced a good I-D that manages to clear out the worries I had with static/dynamic routing, and BC and routing table interaction. I support this solution. Well done! The only comment I have is regarding section 7 and the associated terminology: it is difficult to understand what you mean. Can you explain it further, maybe with an example? Personally, I will have to read it again. BR /Mattias T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > > From exim@www1.ietf.org Thu Jun 26 04:24:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12096 for ; Thu, 26 Jun 2003 04:24:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OQ522970 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3O-0005yP-Js for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11915 for ; Thu, 26 Jun 2003 04:24:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VS3L-0006aX-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VS3G-0006aU-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS38-0005hW-DE; Thu, 26 Jun 2003 04:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRKu-0002un-OZ for nemo@optimus.ietf.org; Thu, 26 Jun 2003 03:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11194 for ; Thu, 26 Jun 2003 03:38:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRKd-0006OK-00 for nemo@ietf.org; Thu, 26 Jun 2003 03:38:11 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VRKS-0006O6-00 for nemo@ietf.org; Thu, 26 Jun 2003 03:38:00 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q7cQcv004892; Thu, 26 Jun 2003 09:38:27 +0200 Received: from era.ericsson.se (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N4L8MGQW; Thu, 26 Jun 2003 09:37:29 +0200 Message-ID: <3EFAA1E8.2030100@era.ericsson.se> Date: Thu, 26 Jun 2003 09:34:00 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think you have produced a good I-D that manages to clear out the worries I had with static/dynamic routing, and BC and routing table interaction. I support this solution. Well done! The only comment I have is regarding section 7 and the associated terminology: it is difficult to understand what you mean. Can you explain it further, maybe with an example? Personally, I will have to read it again. BR /Mattias T.J. Kniveton wrote: > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > Alexandru, and Pascal (and some help from Thierry and myself), we would like > to share the results with the larger WG audience and open it up for comments > and suggestions. > > You may download the draft from > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > Thanks, > > TJ, Thierry, & NEMO DT > > From nemo-admin@ietf.org Thu Jun 26 04:50:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12823 for ; Thu, 26 Jun 2003 04:50:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSS9-00011I-8U; Thu, 26 Jun 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSRJ-0000w7-1p for nemo@optimus.ietf.org; Thu, 26 Jun 2003 04:49:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12777 for ; Thu, 26 Jun 2003 04:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSRG-0006m8-00 for nemo@ietf.org; Thu, 26 Jun 2003 04:49:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19VSR5-0006ln-00 for nemo@ietf.org; Thu, 26 Jun 2003 04:48:55 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Jun 2003 10:48:03 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5Q8jp1T003042; Thu, 26 Jun 2003 10:45:52 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 10:47:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Design Team draft for NEMO Basic Solution Date: Thu, 26 Jun 2003 09:47:54 +0100 Message-ID: Thread-Topic: [nemo] Design Team draft for NEMO Basic Solution Thread-Index: AcM7vH8rqp35PF9CQW6taBwX1b28IAAAoDHA From: "Pascal Thubert (pthubert)" To: "Mattias Pettersson" , "T.J. Kniveton" Cc: X-OriginalArrivalTime: 26 Jun 2003 08:47:54.0851 (UTC) FILETIME=[A28DF330:01C33BBF] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I understand.=20 It's a bit generic and cryptic; there's a need for illustrations. I'll draw examples for v 01 The goal is to have a generic aggregation that encompasses the home network and the mobile network, and to allow a MR to take its 'home address' from either the home network or its mobile network (draft_ryuji). The generic aggregation is the extended home network, and the 'home address' that can be made out of the mobile network is the extended home address.=20 Pascal > -----Original Message----- > From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se] > Sent: jeudi 26 juin 2003 09:34 > To: T.J. Kniveton > Cc: nemo@ietf.org > Subject: Re: [nemo] Design Team draft for NEMO Basic Solution >=20 > I think you have produced a good I-D that manages to clear out the > worries I had with static/dynamic routing, and BC and routing table > interaction. >=20 > I support this solution. Well done! >=20 > The only comment I have is regarding section 7 and the associated > terminology: it is difficult to understand what you mean. Can you > explain it further, maybe with an example? Personally, I will have to > read it again. >=20 > BR > /Mattias >=20 > T.J. Kniveton wrote: > > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > > Alexandru, and Pascal (and some help from Thierry and myself), we would like > > to share the results with the larger WG audience and open it up for comments > > and suggestions. > > > > You may download the draft from > > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > > > Thanks, > > > > TJ, Thierry, & NEMO DT > > > > From exim@www1.ietf.org Thu Jun 26 04:50:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12838 for ; Thu, 26 Jun 2003 04:50:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8o9F04294 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 04:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSSH-00017A-4d for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:50:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12788 for ; Thu, 26 Jun 2003 04:50:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSSE-0006mU-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 04:50:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VSS8-0006mR-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 04:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSS9-00011I-8U; Thu, 26 Jun 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSRJ-0000w7-1p for nemo@optimus.ietf.org; Thu, 26 Jun 2003 04:49:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12777 for ; Thu, 26 Jun 2003 04:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VSRG-0006m8-00 for nemo@ietf.org; Thu, 26 Jun 2003 04:49:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19VSR5-0006ln-00 for nemo@ietf.org; Thu, 26 Jun 2003 04:48:55 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Jun 2003 10:48:03 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5Q8jp1T003042; Thu, 26 Jun 2003 10:45:52 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 10:47:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Design Team draft for NEMO Basic Solution Date: Thu, 26 Jun 2003 09:47:54 +0100 Message-ID: Thread-Topic: [nemo] Design Team draft for NEMO Basic Solution Thread-Index: AcM7vH8rqp35PF9CQW6taBwX1b28IAAAoDHA From: "Pascal Thubert (pthubert)" To: "Mattias Pettersson" , "T.J. Kniveton" Cc: X-OriginalArrivalTime: 26 Jun 2003 08:47:54.0851 (UTC) FILETIME=[A28DF330:01C33BBF] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I understand.=20 It's a bit generic and cryptic; there's a need for illustrations. I'll draw examples for v 01 The goal is to have a generic aggregation that encompasses the home network and the mobile network, and to allow a MR to take its 'home address' from either the home network or its mobile network (draft_ryuji). The generic aggregation is the extended home network, and the 'home address' that can be made out of the mobile network is the extended home address.=20 Pascal > -----Original Message----- > From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se] > Sent: jeudi 26 juin 2003 09:34 > To: T.J. Kniveton > Cc: nemo@ietf.org > Subject: Re: [nemo] Design Team draft for NEMO Basic Solution >=20 > I think you have produced a good I-D that manages to clear out the > worries I had with static/dynamic routing, and BC and routing table > interaction. >=20 > I support this solution. Well done! >=20 > The only comment I have is regarding section 7 and the associated > terminology: it is difficult to understand what you mean. Can you > explain it further, maybe with an example? Personally, I will have to > read it again. >=20 > BR > /Mattias >=20 > T.J. Kniveton wrote: > > The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic > > Support Protocol draft. After the last few months of work by Vijay, Ryuji, > > Alexandru, and Pascal (and some help from Thierry and myself), we would like > > to share the results with the larger WG audience and open it up for comments > > and suggestions. > > > > You may download the draft from > > http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt > > > > Thanks, > > > > TJ, Thierry, & NEMO DT > > > > From nemo-admin@ietf.org Thu Jun 26 07:07:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15286 for ; Thu, 26 Jun 2003 07:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUak-00038j-SG; Thu, 26 Jun 2003 07:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUOu-0002NN-NK for nemo@optimus.ietf.org; Thu, 26 Jun 2003 06:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15033 for ; Thu, 26 Jun 2003 06:54:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUOb-0007OP-00 for nemo@ietf.org; Thu, 26 Jun 2003 06:54:29 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19VUOQ-0007OL-00 for nemo@ietf.org; Thu, 26 Jun 2003 06:54:18 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5QArwhW020259; Thu, 26 Jun 2003 03:53:59 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5QArrpW006495; Thu, 26 Jun 2003 05:53:55 -0500 Received: from nal.motlabs.com (unknown [10.162.1.141]) by thorgal.crm.mot.com (Postfix) with ESMTP id 4E0FD2EC86; Thu, 26 Jun 2003 12:53:51 +0200 (CEST) Message-ID: <3EFAECC6.34B4D10C@nal.motlabs.com> Date: Thu, 26 Jun 2003 14:53:26 +0200 From: Alexandru Petrescu Reply-To: alexandru.petrescu@motorola.com Organization: Motorola Labs, Paris X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "T.J. Kniveton" , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <1056509080.1486.27.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Hello, Alex, > > On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > there be changes to the Binding Cache as well? > > > > I suppose that not even when the Explicit mode is used (prefixes in the > > BU) there is no need to modify the Binding Cache of HA. > > > > Why wouldn't the HA want to store the prefixes into the BCE? > Anyway, the R bit should be added to BCE. Ok, this is one case in point where I change my mind every now and then. It is possible to have the prefixes in the BC, as well as it is possible to keep the prefixes in the Prefix Table only. My oppinion only. Just need to figure out how to best operate them. If one prefers the prefixes in the BC of HA, one needs to also consider the consequences of the later eventual temptation to use same BC at CN. Alex GBU From exim@www1.ietf.org Thu Jun 26 07:09:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15339 for ; Thu, 26 Jun 2003 07:09:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QB8fK13699 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 07:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUb2-0003Kk-DE for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 07:08:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15259 for ; Thu, 26 Jun 2003 07:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUay-0007Sq-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 07:07:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VUaq-0007Sm-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 07:07:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUak-00038j-SG; Thu, 26 Jun 2003 07:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUOu-0002NN-NK for nemo@optimus.ietf.org; Thu, 26 Jun 2003 06:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15033 for ; Thu, 26 Jun 2003 06:54:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUOb-0007OP-00 for nemo@ietf.org; Thu, 26 Jun 2003 06:54:29 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19VUOQ-0007OL-00 for nemo@ietf.org; Thu, 26 Jun 2003 06:54:18 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5QArwhW020259; Thu, 26 Jun 2003 03:53:59 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h5QArrpW006495; Thu, 26 Jun 2003 05:53:55 -0500 Received: from nal.motlabs.com (unknown [10.162.1.141]) by thorgal.crm.mot.com (Postfix) with ESMTP id 4E0FD2EC86; Thu, 26 Jun 2003 12:53:51 +0200 (CEST) Message-ID: <3EFAECC6.34B4D10C@nal.motlabs.com> Date: Thu, 26 Jun 2003 14:53:26 +0200 From: Alexandru Petrescu Reply-To: alexandru.petrescu@motorola.com Organization: Motorola Labs, Paris X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng Cc: "T.J. Kniveton" , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <1056509080.1486.27.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Hello, Alex, > > On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > there be changes to the Binding Cache as well? > > > > I suppose that not even when the Explicit mode is used (prefixes in the > > BU) there is no need to modify the Binding Cache of HA. > > > > Why wouldn't the HA want to store the prefixes into the BCE? > Anyway, the R bit should be added to BCE. Ok, this is one case in point where I change my mind every now and then. It is possible to have the prefixes in the BC, as well as it is possible to keep the prefixes in the Prefix Table only. My oppinion only. Just need to figure out how to best operate them. If one prefers the prefixes in the BC of HA, one needs to also consider the consequences of the later eventual temptation to use same BC at CN. Alex GBU From nemo-admin@ietf.org Thu Jun 26 11:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00596 for ; Thu, 26 Jun 2003 11:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNu-0008Ma-Ba; Thu, 26 Jun 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNM-0008KY-WF for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00261; Thu, 26 Jun 2003 11:09:24 -0400 (EDT) Message-Id: <200306261509.LAA00261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:09:24 -0400 Subject: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router Author(s) : H. Kang et al. Filename : draft-hkang-nemo-ro-tlmr-00.txt Pages : 9 Date : 2003-6-26 This document shows how to route optimization by using bi-directional tunnel between home agent and top level mobile router. A packet will be transmitted directly from the home link of the mobile node to top level mobile router of the correspondent node through this tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hkang-nemo-ro-tlmr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hkang-nemo-ro-tlmr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100640.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Jun 26 11:11:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00726 for ; Thu, 26 Jun 2003 11:11:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFAaE32709 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 11:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOS-0008VU-HE for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:10:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00600 for ; Thu, 26 Jun 2003 11:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNt-0008M4-NE; Thu, 26 Jun 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYN3-0008Hf-94 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00182; Thu, 26 Jun 2003 11:09:04 -0400 (EDT) Message-Id: <200306261509.LAA00182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:09:04 -0400 Subject: [nemo] I-D ACTION:draft-ohta-multihomed-isps-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihomed ISPs and Policy Control Author(s) : M. Ohta Filename : draft-ohta-multihomed-isps-00.txt Pages : 3 Date : 2003-6-26 Policy control of next level ISPs, delegated address spaces from top level ISPs, is discussed. While global policy coodination requires top level aggregators, local policy can be controlled with next level aggregators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohta-multihomed-isps-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ohta-multihomed-isps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ohta-multihomed-isps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ohta-multihomed-isps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ohta-multihomed-isps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100551.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Jun 26 11:11:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00730 for ; Thu, 26 Jun 2003 11:11:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFAbC32726 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 11:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOS-0008Vl-Rf for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:10:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00599 for ; Thu, 26 Jun 2003 11:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNt-0008Lj-9E; Thu, 26 Jun 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYMy-0008DY-MO for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00158; Thu, 26 Jun 2003 11:08:59 -0400 (EDT) Message-Id: <200306261508.LAA00158@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:08:59 -0400 Subject: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Laboratory and 'Field' Experiments with IPv6 Mobile Networks in Vehicular Environments Author(s) : H. Lach et al. Filename : draft-lach-nemo-experiments-overdrive-00.txt Pages : 10 Date : 2003-6-26 This document gives a short high-level overview of several practical experiments performed with mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while 'field' experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lach-nemo-experiments-overdrive-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lach-nemo-experiments-overdrive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100539.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Jun 26 11:11:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00746 for ; Thu, 26 Jun 2003 11:11:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFAbo32743 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 11:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOT-0008W2-Fi for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:10:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00618 for ; Thu, 26 Jun 2003 11:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNu-0008Ma-Ba; Thu, 26 Jun 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNM-0008KY-WF for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00261; Thu, 26 Jun 2003 11:09:24 -0400 (EDT) Message-Id: <200306261509.LAA00261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:09:24 -0400 Subject: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router Author(s) : H. Kang et al. Filename : draft-hkang-nemo-ro-tlmr-00.txt Pages : 9 Date : 2003-6-26 This document shows how to route optimization by using bi-directional tunnel between home agent and top level mobile router. A packet will be transmitted directly from the home link of the mobile node to top level mobile router of the correspondent node through this tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hkang-nemo-ro-tlmr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hkang-nemo-ro-tlmr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100640.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Jun 26 11:56:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00595 for ; Thu, 26 Jun 2003 11:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNt-0008M4-NE; Thu, 26 Jun 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYN3-0008Hf-94 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00182; Thu, 26 Jun 2003 11:09:04 -0400 (EDT) Message-Id: <200306261509.LAA00182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:09:04 -0400 Subject: [nemo] I-D ACTION:draft-ohta-multihomed-isps-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihomed ISPs and Policy Control Author(s) : M. Ohta Filename : draft-ohta-multihomed-isps-00.txt Pages : 3 Date : 2003-6-26 Policy control of next level ISPs, delegated address spaces from top level ISPs, is discussed. While global policy coodination requires top level aggregators, local policy can be controlled with next level aggregators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohta-multihomed-isps-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ohta-multihomed-isps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ohta-multihomed-isps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ohta-multihomed-isps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ohta-multihomed-isps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100551.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Jun 26 11:56:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00598 for ; Thu, 26 Jun 2003 11:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNt-0008Lj-9E; Thu, 26 Jun 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYMy-0008DY-MO for nemo@optimus.ietf.org; Thu, 26 Jun 2003 11:09:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00158; Thu, 26 Jun 2003 11:08:59 -0400 (EDT) Message-Id: <200306261508.LAA00158@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:08:59 -0400 Subject: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Laboratory and 'Field' Experiments with IPv6 Mobile Networks in Vehicular Environments Author(s) : H. Lach et al. Filename : draft-lach-nemo-experiments-overdrive-00.txt Pages : 10 Date : 2003-6-26 This document gives a short high-level overview of several practical experiments performed with mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while 'field' experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lach-nemo-experiments-overdrive-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lach-nemo-experiments-overdrive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lach-nemo-experiments-overdrive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100539.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Jun 26 14:21:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12813 for ; Thu, 26 Jun 2003 14:21:23 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFeRQ14803 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCNm-0003qe-Dl for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:40:26 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16563 for ; Wed, 25 Jun 2003 11:40:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJS-0001t2-0T; Wed, 25 Jun 2003 11:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxS-0008AG-6J for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:13:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04857 for ; Wed, 25 Jun 2003 04:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5ge-0002p1-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:31:28 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19V5gT-0002oy-00 for nemo@ietf.org; Wed, 25 Jun 2003 04:31:17 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h5P8lCW26574; Wed, 25 Jun 2003 17:47:12 +0900 (KST) (envelope-from eun) Date: Wed, 25 Jun 2003 17:47:12 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-ID: <20030625174712.A26407@mmlab.snu.ac.kr> References: <20030624130406.A8802@mmlab.snu.ac.kr> <3EF83DF3.5080607@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3EF83DF3.5080607@motorola.com>; from alexandru.petrescu@motorola.com on Tue, Jun 24, 2003 at 02:02:59PM +0200 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , On Tue, Jun 24, 2003 at 02:02:59PM +0200, Alexandru Petrescu wrote: > eun wrote: > >> It can be based on routing metric, load balancing, or even just a > >> default route selection. There shouldn't be any problem in doing > >> that. > > > > > > Maybe it is just an implementation issue. Or we may propose something > > optimal for NEMO. I wonder what people in NEMO maling list think. > > I think that it is very good to propose improvements. But I also think > that it might be needed to propose it in a more multi-homing focused > Working Group, such as multi6. What do you think? > Yes, it might be. However, if the improvement is NEMO specific, e.g. if it is related to mobility characteristics, NEMO people may want discuss it in NEMO WG, IMO. Regards, Eun Kyoung From exim@www1.ietf.org Thu Jun 26 14:22:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12976 for ; Thu, 26 Jun 2003 14:22:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N8aBf29359 for nemo-archive@odin.ietf.org; Mon, 23 Jun 2003 04:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMo7-0007dS-PV for nemo-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 04:36:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12925 for ; Mon, 23 Jun 2003 04:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMo4-0000bZ-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:36:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UMnz-0000bW-00 for nemo-web-archive@ietf.org; Mon, 23 Jun 2003 04:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMnx-0007ZW-Di; Mon, 23 Jun 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMnd-0007ZB-HE for nemo@optimus.ietf.org; Mon, 23 Jun 2003 04:35:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12915 for ; Mon, 23 Jun 2003 04:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMnL-0000bM-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:35:23 -0400 Received: from [61.187.56.12] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19UMnA-0000bH-00 for nemo@ietf.org; Mon, 23 Jun 2003 04:35:12 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 41E005B344; Mon, 23 Jun 2003 16:39:24 +0800 (HKT) From: Wanrong Yu To: Alexandru Petrescu Reply-To: Wanrong Yu Cc: nemo@ietf.org References: <3EF6B733.2060101@motorola.com> In-Reply-To: <3EF6B733.2060101@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030623083924.41E005B344@ds20.nudt.edu.cn> Date: Mon, 23 Jun 2003 16:39:24 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBNUiBjYXJlLW9mLWFkZHJlc3M=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Alexandru Petrescu wrote > Muhammad Ali Malik wrote: > > Hi > > > > I just want to confirm that In order to support network transparency > > for mobile network node, do we need to have single care-of-address > > for mobile router on behalf of mobile network. > > I think yes. > > I think that if a Mobile Node visits a mobile network then the Mobile > Node will obtain a Care-of Address for itself (which is different than > the Care-of Address of the Mobile Router). > > > This means that when mobile network moves, the mobile router will > > only obtain the care-of-address in foreign location. > > I think yes. But what is your doubt, why wouldn't that suffice? But how about multiple CoA? I think MR should have the ability to obtain multiple CoA as mobile host will be. Wanrong Yu From exim@www1.ietf.org Thu Jun 26 14:23:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13032 for ; Thu, 26 Jun 2003 14:23:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFjVH22958 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSg-0005xy-DA for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:45:30 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17219 for ; Wed, 25 Jun 2003 11:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSB-0005S1-Sz; Wed, 25 Jun 2003 11:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzA-0007wP-Og for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03756 for ; Tue, 24 Jun 2003 22:45:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V0Hh-0001ap-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:45:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19V0HW-0001ai-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:45:10 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5P2b8427373; Wed, 25 Jun 2003 10:37:09 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id BA71F10E95DA; Wed, 25 Jun 2003 10:44:40 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: Alexandru Petrescu Cc: "T.J. Kniveton" , IETF NEMO WG In-Reply-To: <3EF849C3.9080502@motorola.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056509080.1486.27.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 25 Jun 2003 10:44:40 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Alex, On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > there be changes to the Binding Cache as well? > > I suppose that not even when the Explicit mode is used (prefixes in the > BU) there is no need to modify the Binding Cache of HA. > Why wouldn't the HA want to store the prefixes into the BCE? Anyway, the R bit should be added to BCE. > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design > > team? > > I personally think that there is a strong need for such a section in the > Home Agent Operation, but that section should only contain the list of > enhancements of the HA for Mobile Routers. > I will comment on this on the other fork of this thread. > > That's all for now, I am still digesting the draft. > > Hope it's easily digestible, :) /rgds /cwng From exim@www1.ietf.org Thu Jun 26 14:24:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13056 for ; Thu, 26 Jun 2003 14:24:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFjd923247 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSl-00060g-6Y for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:45:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17251 for ; Wed, 25 Jun 2003 11:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSE-0005dD-UE; Wed, 25 Jun 2003 11:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzM-0006YL-Qp for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01264 for ; Tue, 24 Jun 2003 21:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uys0-00011P-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:14:44 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19Uyrp-00011L-00 for nemo@ietf.org; Tue, 24 Jun 2003 21:14:34 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXICP4TB609B8HDF@vaxh.its.monash.edu.au> for nemo@ietf.org; Wed, 25 Jun 2003 11:10:21 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C30F712C006 for ; Wed, 25 Jun 2003 11:10:20 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id AB51E12C004 for ; Wed, 25 Jun 2003 11:10:20 +1000 (EST) Date: Wed, 25 Jun 2003 11:10:20 +1000 From: Greg Daley Subject: Re: [nemo] nemo basic support ptotocol draft. To: nemo Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EF8F67C.6090603@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Muhammad, Muhammad Ali Malik wrote: > Hi Greg > > This means that mobile network node (MNN) should request MR, if it > wants to join any multicast group. Even with multicasting, all message > From MNN to CH will have to travel on bi-directional tunnels. The MNN has to join the group on its AR which may or may not be an MR. Multicast routing could be run on the NEMO, over the tunnel, but the packet flow is unidirectional for client multicast traffic. > Is there any way we can avoid the bi-directional tunneling by > requesting MR to join the multicast group on behalf of Mobile Network. Yes, Maybe. There's nothing defined yet. (there's not even much work done for mobile hosts in this case, that would have to be done first, since the MR is a host to the visited net). Greg From exim@www1.ietf.org Thu Jun 26 14:42:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14157 for ; Thu, 26 Jun 2003 14:42:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFmdr28013 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVj-0007H6-J9 for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:48:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17746 for ; Wed, 25 Jun 2003 11:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCV6-0006pD-7g; Wed, 25 Jun 2003 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCQJ-0004gS-D5 for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:43:03 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16846 for ; Wed, 25 Jun 2003 11:42:59 -0400 (EDT) Received: from jongkn02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h5PFa3gx002045; Thu, 26 Jun 2003 00:36:04 +0900 From: "Jongkeun Na" To: "'Thierry Ernst'" Cc: Subject: RE: [nemo] About NEMO simulator Date: Thu, 26 Jun 2003 00:37:39 +0900 Message-ID: <03a801c33b2f$b79bab40$dbf02e93@jongkn02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030625164621.1f555531.ernst@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Thierry, Thank you for good comments. I also feel that it's hard to do this work as my fulltime job. But, whenever I get spare time I will continuously try to get the base code of mobiwan that works on ns-allinone-2.26. Honestly speaking, as of now, I need more technical understandings on ns such as C++/TCL object binding and other environment/tools. But, if I can focus on this work more than now, I expect that the stable code will be readied in time. If it well done, I will let you all know about the result of work. Afterward, I think, we can more talk. Best Regards, /Jongkeun > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: Wednesday, June 25, 2003 4:46 PM > To: Na, Jong Keun > Cc: nemo@ietf.org > Subject: Re: [nemo] About NEMO simulator > > > Dear Jong Keun, all, > > I reply to you directly since I developped Mobiwan ... Mobiwan is not > supposed to work in a NS version other than ns-2.1b6. Also, it is not > supposed to fulfill all simulation needs. It worked well for what I had > to demonstrate, but I've received many negative reports from people that > couldn't make it work under different situations. Besides this, the code > is out-dated (developped in 1999-2000, released in 2001). > > Although it's for ages in my todo-list, I've never found the time to > port the code the latest NS version and to adapt it to NEMO. > > > I think that we need NEMO simulator for the verification of the proposed > > protocols/algorithms and extensions. > > Is there any action or plan for this work? > > Probably useful, but not part of NEMO WG (or any IETF WG) goals. > > > Anyway, I'm considering mobiwan package as a starting point that > > implemented the minimum level of MIPv6 for NEMO. > > I already got mobiwan-021513.tar.gz distribution package. But it doesn't > > work in ns2 all-in-one 2.26. > > Right. Mobiwan was developped under ns-2.1b6, so it's unlikely it can be > ported easily. > > > Is there any modified or ported to that ns version? If yes and anybody > > know, please let me know. > > Many people have reported me they are willing to extend the code (not > for NEMO, but for other mobility-related simulations), but I don't know > if anyone has been succesful in it (or let's say it: motivated enough to > do it) AND is willing to contribute the extensions (I'm aware of some > success in some private companies, but they are not willing to publish > the extensions). > > > If not exists and porting is apparently necessary, I will do. > > By the way, also I'd like to know how this work is valuable to us before > > starting this work. > > Any comments and suggestions to the way of making simulation package for > > NEMO would be very helpful to me. > > The IETF probably doesn't care much, but some people on the list will > find it useful to conduct their own research. Me included. However, this > is a time-consuming task. Any such work should be conducted by someone > having enough time to interact with the NS developpers so that it > becomes fully integrated in NS forthcoming releases. I'm happy to > participate is there are volunteers, but not to do it alone. > > > Thierry > From exim@www1.ietf.org Thu Jun 26 14:49:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14543 for ; Thu, 26 Jun 2003 14:49:21 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFim920088 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCS0-0005Dn-HU for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:44:48 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17077 for ; Wed, 25 Jun 2003 11:44:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCRR-00052C-VD; Wed, 25 Jun 2003 11:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzE-0008Cz-Cm for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03461 for ; Tue, 24 Jun 2003 22:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V01x-0001Y1-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:29:05 -0400 Received: from tone.orchestra.cse.unsw.edu.au ([129.94.242.28] ident=root) by ietf-mx with smtp (Exim 4.12) id 19V01m-0001Xy-00 for nemo@ietf.org; Tue, 24 Jun 2003 22:28:54 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Wed, 25 Jun 2003 12:26:55 +1000 From: "Muhammad Ali Malik" To: Date: Wed, 25 Jun 2003 12:20:22 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C33B14.269A3190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] Nemo basic support protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C33B14.269A3190 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA03465 Content-Transfer-Encoding: quoted-printable Hi Why the NEMO basic support is based on Mobile IPv6. Still there is no RFC for Mobile IPv6. I Why can=92t NEMO basic support protocol depends on IPv4. Regards, Muhammad ------=_NextPart_000_0015_01C33B14.269A3190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Why the NEMO basic support is based on Mobile IPv6. Still there = is no RFC for Mobile IPv6. I

 

Why can’t NEMO basic support protocol depends on = IPv4.

 

Regards,

 

Muhammad

------=_NextPart_000_0015_01C33B14.269A3190-- From exim@www1.ietf.org Thu Jun 26 14:50:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14658 for ; Thu, 26 Jun 2003 14:50:52 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFmgJ28192 for nemo-archive@odin.ietf.org; Wed, 25 Jun 2003 11:48:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVm-0007KZ-9s for nemo-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:48:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17777 for ; Wed, 25 Jun 2003 11:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVH-00073n-Om; Wed, 25 Jun 2003 11:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VC0Q-0007wP-1G for nemo@optimus.ietf.org; Wed, 25 Jun 2003 11:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12746 for ; Tue, 24 Jun 2003 17:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uvl2-0007bL-00 for nemo@ietf.org; Tue, 24 Jun 2003 17:55:20 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Uvkl-0007b0-00 for nemo@ietf.org; Tue, 24 Jun 2003 17:55:04 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04799; Tue, 24 Jun 2003 14:33:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5OLX9G09253; Tue, 24 Jun 2003 14:33:09 -0700 X-mProtect: <200306242133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd30TVIr; Tue, 24 Jun 2003 14:33:08 PDT Message-ID: <3EF8C394.F91C155F@iprg.nokia.com> Date: Tue, 24 Jun 2003 14:33:08 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Chan-Wah, thanks for the detailed comments. Chan-Wah Ng wrote: > > > o Conceptual clarifications: > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home > Agent should not forward packets destined for mobile network if R flag > is not set. if the Mobile Router set the R bit to 0 in the Binding Update, it means it is going to behave as a mobile host. > So, does this means that for a static route configuration > where the next hop for the Mobile Network Prefix is the Mobile Router, > the Home Agent should discard packets sent to the Mobile Network Prefix > if it receives a BU from Mobile Router with R=0? Perhaps the response > of the Home Agent in this case can be specified? even in static route configuartion, the HA must consult the binding cache for the MR's current CoA. if there is no binding cache entry, then the packets are sent on link. if there is a binding cache entry and the R bit set to 0, the HA must not forward the packets. is this an acceptable solution? > In [Section 5.1, page 14], it is said that the Binding Update List > should hold the prefix information. For a MR with multiple prefixes, > are all these prefixes going to be stored in the Binding Update List? yup. it would be a prefix list. > So each entry in the Binding Update List is going to be dynamic in size > (since the maximum number of prefixes is not known)? it is a conceptual data structure. you can implement it any way you want. > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > there be changes to the Binding Cache as well? yes. you are right. the HA should store the prefixes that was sent in the Binding Update. it needs this list of prefixes later on to delete all the routes, if the binding cache entry expires. I will add some text. > > Nothing is mentioned about the Home Agent performing ND proxy for the > Mobile Network Prefix. Is it deemed not necessary by the design team? it should do the same as described in MIPv6. in addition it should set the R bit to 1. that is missing. we will add some text. > Nothing is mentioned in the operation of Mobile Router about checks on > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > verify that the inner packet has a destination address that is within > its Mobile Network Prefix? it should perform all the necessary checks when decapsulating and forwarding packets. we will add some text. > > o Some cosmetic comments: > > In [Section 3, page 8, middle paragraph], the abbreviation CN is used > without explanation, while in the rest of the section, Correspondent > Node is always used in full. > > In [Section 4.1, page 10, the explanation of Mobility Options], "... in > addition to what is defined [1]...", perhaps it should read "... in > addition to what is defined in [1]..."? > > In [Section 4.3, page 12, and Section 4.4, page 13], perhaps the > explanation of the "Reserved" field should follow the style of IPv6, and > MIPv6, something like: "This field is unused for now. The value MUST be > initialized to zero by the sender, and MUST be ignored by the receiver". done. > > In [Section 4.4, page 13], the explanation of Prefix Length field seems > to be questionable. It says "length of the IPv6 prefix contained in the > option", but there is no prefix in this option. Also, a full-stop > punctuation is missing. changed it to 8 bit unsigned integer indicating the prefix length of the IPv6 prefix from which the Home Address included in the Binding Update was configured from. > > In [Section 5, page 14, right at the bottom], "Similarly to a Mobile > Host, ..." should be "Similar to a Mobile Host, ...". > > In [Section 5.4, page 16-17], there are a few instances of the term > "should" is used without capitalization. In addition, a few instances > of the expression "... Mobile Router will discard ...". The "will" > should be changed to "MUST", "SHOULD", etc as described in RFC2119. > > In [Section 5.4, page 17, right at the top], " ... MAY try try ..." => > duplicate 'try'. > > In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is > missing for the first bullet. > > In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A Mobile > ..." > > In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP > based ...". Pardon my ignorance, but I am not familiar with the > abbreviation MNLP. Perhaps it should be expanded or referenced? > > In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop > punctuation is missing. > > Throughout Sections 5 and 6, the terms "Home Agent", "Mobile Network", > and "Mobile Network Prefix" are sometimes used with all lower case, > sometimes used with first letter capitalized. It will be nice to be > consistent. > > That's all for now, I am still digesting the draft. thanks, once again. Vijay From nemo-admin@ietf.org Thu Jun 26 16:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20086 for ; Thu, 26 Jun 2003 16:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdHk-0003OX-D9; Thu, 26 Jun 2003 16:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdGc-0003DF-52 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 16:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19962 for ; Thu, 26 Jun 2003 16:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VdGa-0005er-00 for nemo@ietf.org; Thu, 26 Jun 2003 16:22:48 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VdGK-0005dd-00 for nemo@ietf.org; Thu, 26 Jun 2003 16:22:32 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22424 for ; Thu, 26 Jun 2003 13:21:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QKLad17649 for ; Thu, 26 Jun 2003 13:21:36 -0700 X-mProtect: <200306262021> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGlLofv; Thu, 26 Jun 2003 13:21:32 PDT Message-ID: <3EFB55CC.AE7F38EC@iprg.nokia.com> Date: Thu, 26 Jun 2003 13:21:32 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] [Fwd: I-D ACTION:draft-ietf-nemo-basic-support-00.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For some reason, it got announced on nemo@nal.motlabs.com which is the older address. could be because http://www.ietf.org/html.charters/nemo-charter.html still says nemo@nal.motlabs.com. this needs to be updated to nemo@ietf.org. Vijay -------- Original Message -------- Subject: I-D ACTION:draft-ietf-nemo-basic-support-00.txt Date: Thu, 26 Jun 2003 08:05:32 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: nemo@nal.motlabs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Nemo Basic Support Protocol Author(s) : V. Devarapalli et al. Filename : draft-ietf-nemo-basic-support-00.txt Pages : 35 Date : 2003-6-25 This document describes a protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The protocol is based on extensions to Mobile IPv6 [1]. The Mobile Router [2] which connects the network to the Internet runs the NEMO protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-basic-support-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-basic-support-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26080645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26080645.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Jun 26 16:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20107 for ; Thu, 26 Jun 2003 16:24:44 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QKOGt13493 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 16:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdI0-0003VY-P7 for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 16:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20073 for ; Thu, 26 Jun 2003 16:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VdHz-0005hD-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 16:24:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VdHt-0005h1-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 16:24:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdHk-0003OX-D9; Thu, 26 Jun 2003 16:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdGc-0003DF-52 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 16:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19962 for ; Thu, 26 Jun 2003 16:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VdGa-0005er-00 for nemo@ietf.org; Thu, 26 Jun 2003 16:22:48 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VdGK-0005dd-00 for nemo@ietf.org; Thu, 26 Jun 2003 16:22:32 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22424 for ; Thu, 26 Jun 2003 13:21:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QKLad17649 for ; Thu, 26 Jun 2003 13:21:36 -0700 X-mProtect: <200306262021> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGlLofv; Thu, 26 Jun 2003 13:21:32 PDT Message-ID: <3EFB55CC.AE7F38EC@iprg.nokia.com> Date: Thu, 26 Jun 2003 13:21:32 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] [Fwd: I-D ACTION:draft-ietf-nemo-basic-support-00.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For some reason, it got announced on nemo@nal.motlabs.com which is the older address. could be because http://www.ietf.org/html.charters/nemo-charter.html still says nemo@nal.motlabs.com. this needs to be updated to nemo@ietf.org. Vijay -------- Original Message -------- Subject: I-D ACTION:draft-ietf-nemo-basic-support-00.txt Date: Thu, 26 Jun 2003 08:05:32 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: nemo@nal.motlabs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Nemo Basic Support Protocol Author(s) : V. Devarapalli et al. Filename : draft-ietf-nemo-basic-support-00.txt Pages : 35 Date : 2003-6-25 This document describes a protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The protocol is based on extensions to Mobile IPv6 [1]. The Mobile Router [2] which connects the network to the Internet runs the NEMO protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-basic-support-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-basic-support-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26080645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26080645.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Jun 26 17:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23397 for ; Thu, 26 Jun 2003 17:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vea4-0004c9-9m; Thu, 26 Jun 2003 17:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VeZJ-0004RQ-32 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 17:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23319 for ; Thu, 26 Jun 2003 17:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VeZG-0006LU-00 for nemo@ietf.org; Thu, 26 Jun 2003 17:46:10 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VeZ0-0006L1-00 for nemo@ietf.org; Thu, 26 Jun 2003 17:45:54 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA26864 for ; Thu, 26 Jun 2003 14:45:14 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QLjDf08325 for ; Thu, 26 Jun 2003 14:45:13 -0700 X-mProtect: <200306262145> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgvh8Ib; Thu, 26 Jun 2003 14:45:11 PDT Message-ID: <3EFB6968.C3D4CD4F@iprg.nokia.com> Date: Thu, 26 Jun 2003 14:45:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Basic Support Issue List Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, I have created a web page to keep track of issues that are discussed on the basic support. http://people.nokia.net/vijayd/nemo/issues.html it is similar to the Mobile IPv6 issue list. Vijay From exim@www1.ietf.org Thu Jun 26 17:47:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23414 for ; Thu, 26 Jun 2003 17:47:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QLlAi17792 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 17:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VeaE-0004ct-8y for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 17:47:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23382 for ; Thu, 26 Jun 2003 17:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VeaB-0006MU-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 17:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Vea6-0006MR-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 17:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vea4-0004c9-9m; Thu, 26 Jun 2003 17:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VeZJ-0004RQ-32 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 17:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23319 for ; Thu, 26 Jun 2003 17:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VeZG-0006LU-00 for nemo@ietf.org; Thu, 26 Jun 2003 17:46:10 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VeZ0-0006L1-00 for nemo@ietf.org; Thu, 26 Jun 2003 17:45:54 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA26864 for ; Thu, 26 Jun 2003 14:45:14 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QLjDf08325 for ; Thu, 26 Jun 2003 14:45:13 -0700 X-mProtect: <200306262145> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgvh8Ib; Thu, 26 Jun 2003 14:45:11 PDT Message-ID: <3EFB6968.C3D4CD4F@iprg.nokia.com> Date: Thu, 26 Jun 2003 14:45:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Basic Support Issue List Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, I have created a web page to keep track of issues that are discussed on the basic support. http://people.nokia.net/vijayd/nemo/issues.html it is similar to the Mobile IPv6 issue list. Vijay From nemo-admin@ietf.org Thu Jun 26 19:39:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27369 for ; Thu, 26 Jun 2003 19:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgKS-0005tt-Mm; Thu, 26 Jun 2003 19:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgJY-0005tG-32 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 19:38:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27323 for ; Thu, 26 Jun 2003 19:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgJW-00077d-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:38:02 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgJL-00077A-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:37:51 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXL1Y8WBV29FO165@vaxc.its.monash.edu.au> for nemo@ietf.org; Fri, 27 Jun 2003 09:35:30 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CA24812C008; Fri, 27 Jun 2003 09:35:29 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id AF59F12C007; Fri, 27 Jun 2003 09:35:29 +1000 (EST) Date: Fri, 27 Jun 2003 09:35:29 +1000 From: Greg Daley Subject: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: Vijay Devarapalli Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFB8341.60904@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3EFB6968.C3D4CD4F@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Vijay, Vijay Devarapalli wrote: > hi all, > > I have created a web page to keep track of issues > that are discussed on the basic support. > > http://people.nokia.net/vijayd/nemo/issues.html > > it is similar to the Mobile IPv6 issue list. > > Vijay > Thanks for this list. I'm ssure it will be a great boon for the group. Do you think that we need to handle multicast issues for hosts on the NEMO in the base draft? I was thinking that getting Multicast ironed out for moving hosts (rather than networks) would be a good idea first, and then see if we need a document on multicast routing or multicast-ro. Maybe we just need to add a line regarding multicast routing protocols on the MR to section 8? Greg From exim@www1.ietf.org Thu Jun 26 19:39:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27389 for ; Thu, 26 Jun 2003 19:39:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QNdE322870 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 19:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgKg-0005wn-Lh for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 19:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27361 for ; Thu, 26 Jun 2003 19:39:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgKf-00078M-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 19:39:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VgKZ-00078J-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 19:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgKS-0005tt-Mm; Thu, 26 Jun 2003 19:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgJY-0005tG-32 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 19:38:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27323 for ; Thu, 26 Jun 2003 19:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgJW-00077d-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:38:02 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgJL-00077A-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:37:51 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXL1Y8WBV29FO165@vaxc.its.monash.edu.au> for nemo@ietf.org; Fri, 27 Jun 2003 09:35:30 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CA24812C008; Fri, 27 Jun 2003 09:35:29 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id AF59F12C007; Fri, 27 Jun 2003 09:35:29 +1000 (EST) Date: Fri, 27 Jun 2003 09:35:29 +1000 From: Greg Daley Subject: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: Vijay Devarapalli Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFB8341.60904@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3EFB6968.C3D4CD4F@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Vijay, Vijay Devarapalli wrote: > hi all, > > I have created a web page to keep track of issues > that are discussed on the basic support. > > http://people.nokia.net/vijayd/nemo/issues.html > > it is similar to the Mobile IPv6 issue list. > > Vijay > Thanks for this list. I'm ssure it will be a great boon for the group. Do you think that we need to handle multicast issues for hosts on the NEMO in the base draft? I was thinking that getting Multicast ironed out for moving hosts (rather than networks) would be a good idea first, and then see if we need a document on multicast routing or multicast-ro. Maybe we just need to add a line regarding multicast routing protocols on the MR to section 8? Greg From nemo-admin@ietf.org Thu Jun 26 19:50:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27748 for ; Thu, 26 Jun 2003 19:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgV7-00075c-JQ; Thu, 26 Jun 2003 19:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgUp-00074M-N1 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 19:49:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27719 for ; Thu, 26 Jun 2003 19:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgUn-0007E8-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:49:41 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VgUX-0007DC-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:49:26 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA04923; Thu, 26 Jun 2003 16:47:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QNlL226259; Thu, 26 Jun 2003 16:47:21 -0700 X-mProtect: <200306262347> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhrohqb; Thu, 26 Jun 2003 16:47:20 PDT Message-ID: <3EFB8608.D5A0ABB8@iprg.nokia.com> Date: Thu, 26 Jun 2003 16:47:20 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haley CC: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Brian, you are right. here is some text The Home Agent defends the Mobile Router's home address through Proxy Neighbor Discovery. When the Home Agent sends a proxy Neighbor Advertisement for the Mobile Router's Home Address, it MUST set the Router flag 'R' to 1 [9]. The Router flag MUST not be set, if the Mobile Router had sent a Binding Update with the Mobile Router Flag set to 0. it will go in section 6.2. is this enough? Vijay Brian Haley wrote: > > I have a comment on the draft regarding Proxy Neighbor Disovery on the Home > Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in > 10.4.1): > > The Router (R) bit in the Advertisement MUST be set to zero. > > I would assume you would want to add text in this draft to override that > behavior when the R-bit is set in the Binding Update since the node really is a > router. > From exim@www1.ietf.org Thu Jun 26 19:50:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27763 for ; Thu, 26 Jun 2003 19:50:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QNo9B27454 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 19:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgVF-00078j-Cj for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 19:50:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27732 for ; Thu, 26 Jun 2003 19:50:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgVD-0007ES-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 19:50:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VgV7-0007EP-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 19:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgV7-00075c-JQ; Thu, 26 Jun 2003 19:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VgUp-00074M-N1 for nemo@optimus.ietf.org; Thu, 26 Jun 2003 19:49:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27719 for ; Thu, 26 Jun 2003 19:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VgUn-0007E8-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:49:41 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VgUX-0007DC-00 for nemo@ietf.org; Thu, 26 Jun 2003 19:49:26 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA04923; Thu, 26 Jun 2003 16:47:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QNlL226259; Thu, 26 Jun 2003 16:47:21 -0700 X-mProtect: <200306262347> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhrohqb; Thu, 26 Jun 2003 16:47:20 PDT Message-ID: <3EFB8608.D5A0ABB8@iprg.nokia.com> Date: Thu, 26 Jun 2003 16:47:20 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haley CC: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Brian, you are right. here is some text The Home Agent defends the Mobile Router's home address through Proxy Neighbor Discovery. When the Home Agent sends a proxy Neighbor Advertisement for the Mobile Router's Home Address, it MUST set the Router flag 'R' to 1 [9]. The Router flag MUST not be set, if the Mobile Router had sent a Binding Update with the Mobile Router Flag set to 0. it will go in section 6.2. is this enough? Vijay Brian Haley wrote: > > I have a comment on the draft regarding Proxy Neighbor Disovery on the Home > Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in > 10.4.1): > > The Router (R) bit in the Advertisement MUST be set to zero. > > I would assume you would want to add text in this draft to override that > behavior when the R-bit is set in the Binding Update since the node really is a > router. > From nemo-admin@ietf.org Thu Jun 26 20:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29386 for ; Thu, 26 Jun 2003 20:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhU5-0005um-2e; Thu, 26 Jun 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhTv-0005uV-Im for nemo@optimus.ietf.org; Thu, 26 Jun 2003 20:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29363 for ; Thu, 26 Jun 2003 20:52:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VhTt-0007da-00 for nemo@ietf.org; Thu, 26 Jun 2003 20:52:49 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VhTd-0007dA-00 for nemo@ietf.org; Thu, 26 Jun 2003 20:52:33 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08155; Thu, 26 Jun 2003 17:51:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5R0poO13750; Thu, 26 Jun 2003 17:51:50 -0700 X-mProtect: <200306270051> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWyIFmD; Thu, 26 Jun 2003 17:51:48 PDT Message-ID: <3EFB9523.7FEDB155@iprg.nokia.com> Date: Thu, 26 Jun 2003 17:51:47 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: nemo@ietf.org Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greg Daley wrote: > > Do you think that we need to handle multicast > issues for hosts on the NEMO in the base draft? I dont think so. I think more work needs to be done on this and is best handled through a separate specification. > I was thinking that getting Multicast ironed out > for moving hosts (rather than networks) would be a > good idea first, you mean for MIPv6 mobile nodes? if yes, I guess Mobile IPv6 would be the right WG for this work. > and then see if we need a document > on multicast routing or multicast-ro. > > Maybe we just need to add a line regarding multicast > routing protocols on the MR to section 8? for this you would need both the Home Agent and the Mobile Router to run a multicast routing protocol. I am not sure if we should talk about it in the basic support draft.... Vijay From exim@www1.ietf.org Thu Jun 26 20:53:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29401 for ; Thu, 26 Jun 2003 20:53:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R0rAL23204 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 20:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhUE-00062B-FO for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 20:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29370 for ; Thu, 26 Jun 2003 20:53:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VhUC-0007dq-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 20:53:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VhU6-0007dn-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 20:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhU5-0005um-2e; Thu, 26 Jun 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhTv-0005uV-Im for nemo@optimus.ietf.org; Thu, 26 Jun 2003 20:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29363 for ; Thu, 26 Jun 2003 20:52:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VhTt-0007da-00 for nemo@ietf.org; Thu, 26 Jun 2003 20:52:49 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VhTd-0007dA-00 for nemo@ietf.org; Thu, 26 Jun 2003 20:52:33 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08155; Thu, 26 Jun 2003 17:51:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5R0poO13750; Thu, 26 Jun 2003 17:51:50 -0700 X-mProtect: <200306270051> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWyIFmD; Thu, 26 Jun 2003 17:51:48 PDT Message-ID: <3EFB9523.7FEDB155@iprg.nokia.com> Date: Thu, 26 Jun 2003 17:51:47 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: nemo@ietf.org Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg Daley wrote: > > Do you think that we need to handle multicast > issues for hosts on the NEMO in the base draft? I dont think so. I think more work needs to be done on this and is best handled through a separate specification. > I was thinking that getting Multicast ironed out > for moving hosts (rather than networks) would be a > good idea first, you mean for MIPv6 mobile nodes? if yes, I guess Mobile IPv6 would be the right WG for this work. > and then see if we need a document > on multicast routing or multicast-ro. > > Maybe we just need to add a line regarding multicast > routing protocols on the MR to section 8? for this you would need both the Home Agent and the Mobile Router to run a multicast routing protocol. I am not sure if we should talk about it in the basic support draft.... Vijay From nemo-admin@ietf.org Thu Jun 26 22:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02119 for ; Thu, 26 Jun 2003 22:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VjR3-0002F6-GE; Thu, 26 Jun 2003 22:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VjOt-00024m-1j for nemo@optimus.ietf.org; Thu, 26 Jun 2003 22:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02077 for ; Thu, 26 Jun 2003 22:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VjOa-0000U9-00 for nemo@ietf.org; Thu, 26 Jun 2003 22:55:28 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19VjOL-0000Tx-00 for nemo@ietf.org; Thu, 26 Jun 2003 22:55:17 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5R2lP412081; Fri, 27 Jun 2003 10:47:25 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B84C210E95DA; Fri, 27 Jun 2003 10:54:49 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: MATSUMOTO Taisuke Cc: IETF NEMO WG , Vijay Devarapalli , Alexandru Petrescu In-Reply-To: <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056682489.1485.44.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 27 Jun 2003 10:54:49 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Matsumoto-san, Alex, and Vijay, (this mail is a resend since my previous mail did not appear on the list after a 2 day wait). Agreed that HA should respond to NS for the HoA of MR. The response, NA, should have the R-bit set if the R-bit was set in BU from MR. (As mentioned by Brian). Should HA respond to RS on behalf of MR if the R-bit was set in the BU? Regardless of the answer, this need to be explained in the Draft, IMHO. Should the HA broadcast a RA on behalf of MR if the R-bit was set in the BU? Or should the MR send RA broadcast to the home link via the MRHA tunnel? I think it was suggested in the Draft that MR may do so, provided the Lifetime field is set to 0. /rgds /cwng On Wed, 2003-06-25 at 09:57, MATSUMOTO Taisuke wrote: > Dear Alex, > > On Tue, 24 Jun 2003 17:32:55 +0200, > Alexandru Petrescu wrote : > > MATSUMOTO Taisuke wrote: > > >> I personally think that there is a strong need for such a section > > >> in the Home Agent Operation, but that section should only contain > > >> the list of enhancements of the HA for Mobile Routers. > > > > > > > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > > > > > When the border router (BR) of the home link has the entry which > > > contains the HoA of the MR as the next hop of the Mobile Network > > > Prefix, the BR may perform the Neighbor Solicitation. And then HA > > > will answer with the proxy Neighbor Advertisement. > > > > Ok. I think Brian mentioned that the 'R' bit should be set in this NA, > > when it corresponds to a Home Address whose Binding Cache entry > > corresponds to a received BU that had the 'R' bit set. > > > > More specifically, Mobile IPv6 HA says in the "Intercepting" section > > 10.4.1 that: > > > > o The Router (R) bit in the Advertisement MUST be set to zero. > > > > So, it is probably not very logic for a HA that is itself a router and > > moreover sends NA's on behalf of a router, to keep that bit set to zero. > > Now I get it. I failed to notice of 'R' bit in NA. > > > (Also, maybe it is good for the respective Binding Cache entry at the > > HA to probably have an additional 'R' bit to ease implementation. I > > think someone raised this issue recently.) > > I agree. > > > > But I think it is a Mobile IP specific, not a NEMO specific, isn't > > > it? > > > > So you think that probably this should be suggested to the Mobile IP > > Working Group instead of the NEMO Working Group? I guess that can only > > be a good alternative. > > In my previous mail, I was convinced that what is necessary is just to > perform ND proxy as description of Mobile IP. > > But I'm clear now. I agree with you on the necessity of discussion about > the HA operations. > > > > Is there another kind of ND proxy on HA? > > > > Please be more specific with the question? > > Sorry. I had thought that the description in the Mobile IP draft was > enough to specify the behavior of ND proxy on HA. Therefore I wondered > if there were other ND proxies, for instance proxy RS, proxy RA.... > > Thank you for your kind guidance. > > BR, > Taisuke From exim@www1.ietf.org Thu Jun 26 22:58:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02136 for ; Thu, 26 Jun 2003 22:58:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R2wCv08992 for nemo-archive@odin.ietf.org; Thu, 26 Jun 2003 22:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VjRD-0002Kn-Gq for nemo-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 22:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02116 for ; Thu, 26 Jun 2003 22:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VjRA-0000Uy-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 22:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VjR4-0000Uv-00 for nemo-web-archive@ietf.org; Thu, 26 Jun 2003 22:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VjR3-0002F6-GE; Thu, 26 Jun 2003 22:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VjOt-00024m-1j for nemo@optimus.ietf.org; Thu, 26 Jun 2003 22:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02077 for ; Thu, 26 Jun 2003 22:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VjOa-0000U9-00 for nemo@ietf.org; Thu, 26 Jun 2003 22:55:28 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19VjOL-0000Tx-00 for nemo@ietf.org; Thu, 26 Jun 2003 22:55:17 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h5R2lP412081; Fri, 27 Jun 2003 10:47:25 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B84C210E95DA; Fri, 27 Jun 2003 10:54:49 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng To: MATSUMOTO Taisuke Cc: IETF NEMO WG , Vijay Devarapalli , Alexandru Petrescu In-Reply-To: <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056682489.1485.44.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 27 Jun 2003 10:54:49 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Matsumoto-san, Alex, and Vijay, (this mail is a resend since my previous mail did not appear on the list after a 2 day wait). Agreed that HA should respond to NS for the HoA of MR. The response, NA, should have the R-bit set if the R-bit was set in BU from MR. (As mentioned by Brian). Should HA respond to RS on behalf of MR if the R-bit was set in the BU? Regardless of the answer, this need to be explained in the Draft, IMHO. Should the HA broadcast a RA on behalf of MR if the R-bit was set in the BU? Or should the MR send RA broadcast to the home link via the MRHA tunnel? I think it was suggested in the Draft that MR may do so, provided the Lifetime field is set to 0. /rgds /cwng On Wed, 2003-06-25 at 09:57, MATSUMOTO Taisuke wrote: > Dear Alex, > > On Tue, 24 Jun 2003 17:32:55 +0200, > Alexandru Petrescu wrote : > > MATSUMOTO Taisuke wrote: > > >> I personally think that there is a strong need for such a section > > >> in the Home Agent Operation, but that section should only contain > > >> the list of enhancements of the HA for Mobile Routers. > > > > > > > > > I'm sorry but I can't imagine the necessity of ND proxy on HA. > > > > > > When the border router (BR) of the home link has the entry which > > > contains the HoA of the MR as the next hop of the Mobile Network > > > Prefix, the BR may perform the Neighbor Solicitation. And then HA > > > will answer with the proxy Neighbor Advertisement. > > > > Ok. I think Brian mentioned that the 'R' bit should be set in this NA, > > when it corresponds to a Home Address whose Binding Cache entry > > corresponds to a received BU that had the 'R' bit set. > > > > More specifically, Mobile IPv6 HA says in the "Intercepting" section > > 10.4.1 that: > > > > o The Router (R) bit in the Advertisement MUST be set to zero. > > > > So, it is probably not very logic for a HA that is itself a router and > > moreover sends NA's on behalf of a router, to keep that bit set to zero. > > Now I get it. I failed to notice of 'R' bit in NA. > > > (Also, maybe it is good for the respective Binding Cache entry at the > > HA to probably have an additional 'R' bit to ease implementation. I > > think someone raised this issue recently.) > > I agree. > > > > But I think it is a Mobile IP specific, not a NEMO specific, isn't > > > it? > > > > So you think that probably this should be suggested to the Mobile IP > > Working Group instead of the NEMO Working Group? I guess that can only > > be a good alternative. > > In my previous mail, I was convinced that what is necessary is just to > perform ND proxy as description of Mobile IP. > > But I'm clear now. I agree with you on the necessity of discussion about > the HA operations. > > > > Is there another kind of ND proxy on HA? > > > > Please be more specific with the question? > > Sorry. I had thought that the description in the Mobile IP draft was > enough to specify the behavior of ND proxy on HA. Therefore I wondered > if there were other ND proxies, for instance proxy RS, proxy RA.... > > Thank you for your kind guidance. > > BR, > Taisuke From nemo-admin@ietf.org Fri Jun 27 00:38:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04876 for ; Fri, 27 Jun 2003 00:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VkfV-0002fk-IB; Fri, 27 Jun 2003 00:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vkf0-0002Mp-Hh for nemo@optimus.ietf.org; Fri, 27 Jun 2003 00:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04210 for ; Fri, 27 Jun 2003 00:16:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vkej-000114-00 for nemo@ietf.org; Fri, 27 Jun 2003 00:16:13 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19VkeY-00010o-00 for nemo@ietf.org; Fri, 27 Jun 2003 00:16:02 -0400 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXLBQ5WMZ89B933S@vaxh.its.monash.edu.au> for nemo@ietf.org; Fri, 27 Jun 2003 14:15:19 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 00D6D12C028; Fri, 27 Jun 2003 14:15:18 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id CF04612C01F; Fri, 27 Jun 2003 14:15:17 +1000 (EST) Date: Fri, 27 Jun 2003 14:15:17 +1000 From: Greg Daley Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: Vijay Devarapalli Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFBC4D5.2090703@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Vijay, Vijay Devarapalli wrote: > Greg Daley wrote: > >>Do you think that we need to handle multicast >>issues for hosts on the NEMO in the base draft? > > > I dont think so. I think more work needs to be done > on this and is best handled through a separate > specification. Good. That's what I was checking. > >>I was thinking that getting Multicast ironed out >>for moving hosts (rather than networks) would be a >>good idea first, > > > you mean for MIPv6 mobile nodes? if yes, I guess > Mobile IPv6 would be the right WG for this work. Actually, it may even be a MAGMA issue since there's no global signalling (but certainly not NEMO yet). >>and then see if we need a document >>on multicast routing or multicast-ro. >> >>Maybe we just need to add a line regarding multicast >>routing protocols on the MR to section 8? > > > for this you would need both the Home Agent and the > Mobile Router to run a multicast routing protocol. I > am not sure if we should talk about it in the basic > support draft.... OK. We'll let people read between the lines when it says "dynamic routing protocol". I've been having a think about this issue too, and may get a short draft out after the meeting. Greg From nemo-admin@ietf.org Fri Jun 27 14:40:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11976 for ; Fri, 27 Jun 2003 14:40:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7x-0004JC-3I; Fri, 27 Jun 2003 14:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VwvS-0002RS-Sk for nemo@optimus.ietf.org; Fri, 27 Jun 2003 13:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08021 for ; Fri, 27 Jun 2003 13:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VwvQ-0004oS-00 for nemo@ietf.org; Fri, 27 Jun 2003 13:22:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VwvA-0004oC-00 for nemo@ietf.org; Fri, 27 Jun 2003 13:22:01 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20174; Fri, 27 Jun 2003 10:20:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5RHKsx13191; Fri, 27 Jun 2003 10:20:54 -0700 X-mProtect: <200306271720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRVWPl2; Fri, 27 Jun 2003 10:20:52 PDT Message-ID: <3EFC7CF5.C9EEBCC@iprg.nokia.com> Date: Fri, 27 Jun 2003 10:20:53 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: MATSUMOTO Taisuke , IETF NEMO WG , Alexandru Petrescu Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Should HA respond to RS on behalf of MR if the R-bit was set in the BU? > Regardless of the answer, this need to be explained in the Draft, IMHO. RS is typically sent to the all routers multicast address. it is not sent to a particular address. so there is no question of HA responding to an RS on MR's behalf. and anyway this information is useless. > Should the HA broadcast a RA on behalf of MR if the R-bit was set in the > BU? no. the MR is not on the home link. there is no point. > Or should the MR send RA broadcast to the home link via the MRHA > tunnel? it could. but the information is useless again. the HA cant do anything with it. > I think it was suggested in the Draft that MR may do so, > provided the Lifetime field is set to 0. this is when the MR is at home and sends a RA on the link with which it is connected to the home link. the router lifetime is set to 0, so that no other node configures the MR as a default router. Vijay From nemo-admin@ietf.org Fri Jun 27 15:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16077 for ; Fri, 27 Jun 2003 15:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VymN-0001qh-78; Fri, 27 Jun 2003 15:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy4q-00032n-W7 for nemo@optimus.ietf.org; Fri, 27 Jun 2003 14:36:05 -0400 Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11269 for ; Fri, 27 Jun 2003 14:35:27 -0400 (EDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E569F75C; Fri, 27 Jun 2003 14:32:04 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 6B0EC43A; Fri, 27 Jun 2003 14:32:04 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id OAA0002240118; Fri, 27 Jun 2003 14:32:03 -0400 (EDT) Message-ID: <3EFC8DA3.8050706@hp.com> Date: Fri, 27 Jun 2003 14:32:03 -0400 From: Brian Haley Organization: Tru64 UNIX Networking User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> <3EFB8608.D5A0ABB8@iprg.nokia.com> In-Reply-To: <3EFB8608.D5A0ABB8@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stealing some words from the Mipv6 draft: The Home Agent defends the Mobile Router's home address through Proxy Neighbor Discovery by multicasting onto the home like a Neighbor Advertisement message on behalf of the mobile router. All fields in each such Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile router itself if sending this Neighbor Advertisement while at home, as described in [1], with the exception that the Router (R) bit in the Advertisement MUST be set to one if the Mobile Router (R) flag has been specified in the Binding Update. Anything close is good enough since implementors will get the point. -Brian Vijay Devarapalli wrote: > hi Brian, > > you are right. here is some text > > The Home Agent defends the Mobile Router's home address through Proxy > Neighbor Discovery. When the Home Agent sends a proxy Neighbor > Advertisement for the Mobile Router's Home Address, it MUST set the > Router flag 'R' to 1 [9]. The Router flag MUST not be set, if the > Mobile Router had sent a Binding Update with the Mobile Router Flag > set to 0. > > it will go in section 6.2. is this enough? > > Vijay > > Brian Haley wrote: > >>I have a comment on the draft regarding Proxy Neighbor Disovery on the Home >>Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in >>10.4.1): >> >> The Router (R) bit in the Advertisement MUST be set to zero. >> >>I would assume you would want to add text in this draft to override that >>behavior when the R-bit is set in the Binding Update since the node really is a >>router. >> > > From exim@www1.ietf.org Fri Jun 27 15:22:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16236 for ; Fri, 27 Jun 2003 15:22:19 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RJLpx08357 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 15:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vymu-00021A-9c for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 15:21:51 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16076 for ; Fri, 27 Jun 2003 15:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VymN-0001qh-78; Fri, 27 Jun 2003 15:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy4q-00032n-W7 for nemo@optimus.ietf.org; Fri, 27 Jun 2003 14:36:05 -0400 Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11269 for ; Fri, 27 Jun 2003 14:35:27 -0400 (EDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E569F75C; Fri, 27 Jun 2003 14:32:04 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 6B0EC43A; Fri, 27 Jun 2003 14:32:04 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id OAA0002240118; Fri, 27 Jun 2003 14:32:03 -0400 (EDT) Message-ID: <3EFC8DA3.8050706@hp.com> Date: Fri, 27 Jun 2003 14:32:03 -0400 From: Brian Haley Organization: Tru64 UNIX Networking User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <3EF752D9.4080204@hp.com> <3EFB8608.D5A0ABB8@iprg.nokia.com> In-Reply-To: <3EFB8608.D5A0ABB8@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stealing some words from the Mipv6 draft: The Home Agent defends the Mobile Router's home address through Proxy Neighbor Discovery by multicasting onto the home like a Neighbor Advertisement message on behalf of the mobile router. All fields in each such Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile router itself if sending this Neighbor Advertisement while at home, as described in [1], with the exception that the Router (R) bit in the Advertisement MUST be set to one if the Mobile Router (R) flag has been specified in the Binding Update. Anything close is good enough since implementors will get the point. -Brian Vijay Devarapalli wrote: > hi Brian, > > you are right. here is some text > > The Home Agent defends the Mobile Router's home address through Proxy > Neighbor Discovery. When the Home Agent sends a proxy Neighbor > Advertisement for the Mobile Router's Home Address, it MUST set the > Router flag 'R' to 1 [9]. The Router flag MUST not be set, if the > Mobile Router had sent a Binding Update with the Mobile Router Flag > set to 0. > > it will go in section 6.2. is this enough? > > Vijay > > Brian Haley wrote: > >>I have a comment on the draft regarding Proxy Neighbor Disovery on the Home >>Agent. The base MIPv6 draft talks about sending Neighbor Advertisements (in >>10.4.1): >> >> The Router (R) bit in the Advertisement MUST be set to zero. >> >>I would assume you would want to add text in this draft to override that >>behavior when the R-bit is set in the Binding Update since the node really is a >>router. >> > > From nemo-admin@ietf.org Fri Jun 27 22:06:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29888 for ; Fri, 27 Jun 2003 22:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W56H-0000DX-3P; Fri, 27 Jun 2003 22:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W55N-0000Cu-P0 for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29860 for ; Fri, 27 Jun 2003 22:04:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W555-0000Tu-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:04:47 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W54u-0000Tm-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:04:37 -0400 Received: by fox (Postfix, from userid 1000) id 369801080860; Sat, 28 Jun 2003 10:05:15 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: MATSUMOTO Taisuke , IETF NEMO WG , Alexandru Petrescu In-Reply-To: <3EFC7CF5.C9EEBCC@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> <3EFC7CF5.C9EEBCC@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056765914.1602.13.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:05:15 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sat, 2003-06-28 at 01:20, Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > > > > Should HA respond to RS on behalf of MR if the R-bit was set in the BU? > > Regardless of the answer, this need to be explained in the Draft, IMHO. > > RS is typically sent to the all routers multicast address. > it is not sent to a particular address. so there is no > question of HA responding to an RS on MR's behalf. and > anyway this information is useless. > > > Should the HA broadcast a RA on behalf of MR if the R-bit was set in the > > BU? > > no. the MR is not on the home link. there is no point. > > > Or should the MR send RA broadcast to the home link via the MRHA > > tunnel? > > it could. but the information is useless again. the HA > cant do anything with it. > yep, that's right. I failed to realize that RA broadcast can only be single hop. > > I think it was suggested in the Draft that MR may do so, > > provided the Lifetime field is set to 0. > > this is when the MR is at home and sends a RA on the link > with which it is connected to the home link. the router > lifetime is set to 0, so that no other node configures the > MR as a default router. Oh, let me check the wording of the draft ... guess I didn't digest the draft fully, my mistake. /rgds /cwng From exim@www1.ietf.org Fri Jun 27 22:06:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29903 for ; Fri, 27 Jun 2003 22:06:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S26Le00896 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 22:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W56b-0000EN-Mn for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 22:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29879 for ; Fri, 27 Jun 2003 22:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W56Y-0000UB-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:06:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W56T-0000U7-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W56H-0000DX-3P; Fri, 27 Jun 2003 22:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W55N-0000Cu-P0 for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29860 for ; Fri, 27 Jun 2003 22:04:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W555-0000Tu-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:04:47 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W54u-0000Tm-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:04:37 -0400 Received: by fox (Postfix, from userid 1000) id 369801080860; Sat, 28 Jun 2003 10:05:15 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: MATSUMOTO Taisuke , IETF NEMO WG , Alexandru Petrescu In-Reply-To: <3EFC7CF5.C9EEBCC@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> <3EFC7CF5.C9EEBCC@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056765914.1602.13.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:05:15 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2003-06-28 at 01:20, Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > > > > Should HA respond to RS on behalf of MR if the R-bit was set in the BU? > > Regardless of the answer, this need to be explained in the Draft, IMHO. > > RS is typically sent to the all routers multicast address. > it is not sent to a particular address. so there is no > question of HA responding to an RS on MR's behalf. and > anyway this information is useless. > > > Should the HA broadcast a RA on behalf of MR if the R-bit was set in the > > BU? > > no. the MR is not on the home link. there is no point. > > > Or should the MR send RA broadcast to the home link via the MRHA > > tunnel? > > it could. but the information is useless again. the HA > cant do anything with it. > yep, that's right. I failed to realize that RA broadcast can only be single hop. > > I think it was suggested in the Draft that MR may do so, > > provided the Lifetime field is set to 0. > > this is when the MR is at home and sends a RA on the link > with which it is connected to the home link. the router > lifetime is set to 0, so that no other node configures the > MR as a default router. Oh, let me check the wording of the draft ... guess I didn't digest the draft fully, my mistake. /rgds /cwng From nemo-admin@ietf.org Fri Jun 27 22:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29995 for ; Fri, 27 Jun 2003 22:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5D3-0000u7-Fp; Fri, 27 Jun 2003 22:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5CL-0000pi-FW for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:12:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29961 for ; Fri, 27 Jun 2003 22:12:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5CI-0000VD-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:12:14 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W5C7-0000VA-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:12:03 -0400 Received: by fox (Postfix, from userid 1000) id 0F3661080860; Sat, 28 Jun 2003 10:12:59 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3EF8C394.F91C155F@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056766378.1602.21.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:12:58 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Vijay, On Wed, 2003-06-25 at 05:33, Vijay Devarapalli wrote: > hi Chan-Wah, > > thanks for the detailed comments. > > Chan-Wah Ng wrote: > > > > > > o Conceptual clarifications: > > > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home > > Agent should not forward packets destined for mobile network if R flag > > is not set. > > if the Mobile Router set the R bit to 0 in the Binding > Update, it means it is going to behave as a mobile host. > > > So, does this means that for a static route configuration > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > the Home Agent should discard packets sent to the Mobile Network Prefix > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > of the Home Agent in this case can be specified? > > even in static route configuartion, the HA must > consult the binding cache for the MR's current CoA. > if there is no binding cache entry, then the packets > are sent on link. if there is a binding cache entry > and the R bit set to 0, the HA must not forward the > packets. > > is this an acceptable solution? > Yes, it is. I just thought that this should be reflected in the draft. > > In [Section 5.1, page 14], it is said that the Binding Update List > > should hold the prefix information. For a MR with multiple prefixes, > > are all these prefixes going to be stored in the Binding Update List? > > yup. it would be a prefix list. > > > So each entry in the Binding Update List is going to be dynamic in size > > (since the maximum number of prefixes is not known)? > > it is a conceptual data structure. you can implement > it any way you want. > That's perfectly fine. So apart from the theoretical limit due to maximum allowed IPv6 packet size, there is no limit on the number of prefixes, am I correct? > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > there be changes to the Binding Cache as well? > > yes. you are right. the HA should store the prefixes > that was sent in the Binding Update. it needs this list > of prefixes later on to delete all the routes, if the > binding cache entry expires. I will add some text. > OK. > > > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design team? > > it should do the same as described in MIPv6. in addition > it should set the R bit to 1. that is missing. we will > add some text. > Let me think about the consequence of HA not doing RA proxy for MR. > > Nothing is mentioned in the operation of Mobile Router about checks on > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > verify that the inner packet has a destination address that is within > > its Mobile Network Prefix? > > it should perform all the necessary checks when > decapsulating and forwarding packets. we will add some > text. > OK > > > > In [Section 4.4, page 13], the explanation of Prefix Length field seems > > to be questionable. It says "length of the IPv6 prefix contained in the > > option", but there is no prefix in this option. Also, a full-stop > > punctuation is missing. > > changed it to > > 8 bit unsigned integer indicating the prefix length of the > IPv6 prefix from which the Home Address included in the > Binding Update was configured from. > Looks fine. /cwng From exim@www1.ietf.org Fri Jun 27 22:13:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00018 for ; Fri, 27 Jun 2003 22:13:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S2D8V03652 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 22:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5DA-0000wp-Ak for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 22:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29976 for ; Fri, 27 Jun 2003 22:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5D7-0000Vf-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W5D1-0000Vc-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5D3-0000u7-Fp; Fri, 27 Jun 2003 22:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5CL-0000pi-FW for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:12:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29961 for ; Fri, 27 Jun 2003 22:12:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5CI-0000VD-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:12:14 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W5C7-0000VA-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:12:03 -0400 Received: by fox (Postfix, from userid 1000) id 0F3661080860; Sat, 28 Jun 2003 10:12:59 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3EF8C394.F91C155F@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056766378.1602.21.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:12:58 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Vijay, On Wed, 2003-06-25 at 05:33, Vijay Devarapalli wrote: > hi Chan-Wah, > > thanks for the detailed comments. > > Chan-Wah Ng wrote: > > > > > > o Conceptual clarifications: > > > > In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home > > Agent should not forward packets destined for mobile network if R flag > > is not set. > > if the Mobile Router set the R bit to 0 in the Binding > Update, it means it is going to behave as a mobile host. > > > So, does this means that for a static route configuration > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > the Home Agent should discard packets sent to the Mobile Network Prefix > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > of the Home Agent in this case can be specified? > > even in static route configuartion, the HA must > consult the binding cache for the MR's current CoA. > if there is no binding cache entry, then the packets > are sent on link. if there is a binding cache entry > and the R bit set to 0, the HA must not forward the > packets. > > is this an acceptable solution? > Yes, it is. I just thought that this should be reflected in the draft. > > In [Section 5.1, page 14], it is said that the Binding Update List > > should hold the prefix information. For a MR with multiple prefixes, > > are all these prefixes going to be stored in the Binding Update List? > > yup. it would be a prefix list. > > > So each entry in the Binding Update List is going to be dynamic in size > > (since the maximum number of prefixes is not known)? > > it is a conceptual data structure. you can implement > it any way you want. > That's perfectly fine. So apart from the theoretical limit due to maximum allowed IPv6 packet size, there is no limit on the number of prefixes, am I correct? > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > there be changes to the Binding Cache as well? > > yes. you are right. the HA should store the prefixes > that was sent in the Binding Update. it needs this list > of prefixes later on to delete all the routes, if the > binding cache entry expires. I will add some text. > OK. > > > > Nothing is mentioned about the Home Agent performing ND proxy for the > > Mobile Network Prefix. Is it deemed not necessary by the design team? > > it should do the same as described in MIPv6. in addition > it should set the R bit to 1. that is missing. we will > add some text. > Let me think about the consequence of HA not doing RA proxy for MR. > > Nothing is mentioned in the operation of Mobile Router about checks on > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > verify that the inner packet has a destination address that is within > > its Mobile Network Prefix? > > it should perform all the necessary checks when > decapsulating and forwarding packets. we will add some > text. > OK > > > > In [Section 4.4, page 13], the explanation of Prefix Length field seems > > to be questionable. It says "length of the IPv6 prefix contained in the > > option", but there is no prefix in this option. Also, a full-stop > > punctuation is missing. > > changed it to > > 8 bit unsigned integer indicating the prefix length of the > IPv6 prefix from which the Home Address included in the > Binding Update was configured from. > Looks fine. /cwng From nemo-admin@ietf.org Fri Jun 27 22:23:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00198 for ; Fri, 27 Jun 2003 22:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5Mj-0001Lu-19; Fri, 27 Jun 2003 22:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5MA-0001LW-Tv for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00161 for ; Fri, 27 Jun 2003 22:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5Lu-0000Xj-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:22:11 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W5Lk-0000Xf-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:22:00 -0400 Received: by fox (Postfix, from userid 1000) id C949C1080860; Sat, 28 Jun 2003 10:22:55 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Alexandru Petrescu Cc: "T.J. Kniveton" , IETF NEMO WG In-Reply-To: <3EFAECC6.34B4D10C@nal.motlabs.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <1056509080.1486.27.camel@beethoven> <3EFAECC6.34B4D10C@nal.motlabs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056766975.1602.29.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:22:55 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Alex, On Thu, 2003-06-26 at 20:53, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > > > Hello, Alex, > > > > On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > I suppose that not even when the Explicit mode is used (prefixes in the > > > BU) there is no need to modify the Binding Cache of HA. > > > > > > > Why wouldn't the HA want to store the prefixes into the BCE? > > Anyway, the R bit should be added to BCE. > > Ok, this is one case in point where I change my mind every now and > then. It is possible > to have the prefixes in the BC, as well as it is possible to keep the > prefixes in > the Prefix Table only. My oppinion only. > I need to look into this more carefully. The worry on my mind when the prefixes is not in the BCE is that certain prefix routes in the Prefix Table may get stale, or deleted accidentally, when we consider multi-homed mobile network where more than one mobile router handles the same mobile network prefix. > Just need to figure out how to best operate them. > > If one prefers the prefixes in the BC of HA, one needs to also consider > the consequences of the later eventual temptation to use same BC at CN. > Good point. Especially when one consider the possibility of HA itself being a CN to some other mobile nodes. /rgds /cwng From exim@www1.ietf.org Fri Jun 27 22:23:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00223 for ; Fri, 27 Jun 2003 22:23:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S2NB605376 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 22:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5Mt-0001Od-1X for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 22:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00182 for ; Fri, 27 Jun 2003 22:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5Mo-0000Xy-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W5Mj-0000Xv-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 22:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5Mj-0001Lu-19; Fri, 27 Jun 2003 22:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5MA-0001LW-Tv for nemo@optimus.ietf.org; Fri, 27 Jun 2003 22:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00161 for ; Fri, 27 Jun 2003 22:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5Lu-0000Xj-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:22:11 -0400 Received: from bb-203-125-112-141.singnet.com.sg ([203.125.112.141] helo=fox) by ietf-mx with esmtp (Exim 4.12) id 19W5Lk-0000Xf-00 for nemo@ietf.org; Fri, 27 Jun 2003 22:22:00 -0400 Received: by fox (Postfix, from userid 1000) id C949C1080860; Sat, 28 Jun 2003 10:22:55 +0800 (SGT) Subject: Re: [nemo] Design Team draft for NEMO Basic Solution From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Alexandru Petrescu Cc: "T.J. Kniveton" , IETF NEMO WG In-Reply-To: <3EFAECC6.34B4D10C@nal.motlabs.com> References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <1056509080.1486.27.camel@beethoven> <3EFAECC6.34B4D10C@nal.motlabs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1056766975.1602.29.camel@fox> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 Jun 2003 10:22:55 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Alex, On Thu, 2003-06-26 at 20:53, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > > > Hello, Alex, > > > > On Tue, 2003-06-24 at 20:53, Alexandru Petrescu wrote: > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > I suppose that not even when the Explicit mode is used (prefixes in the > > > BU) there is no need to modify the Binding Cache of HA. > > > > > > > Why wouldn't the HA want to store the prefixes into the BCE? > > Anyway, the R bit should be added to BCE. > > Ok, this is one case in point where I change my mind every now and > then. It is possible > to have the prefixes in the BC, as well as it is possible to keep the > prefixes in > the Prefix Table only. My oppinion only. > I need to look into this more carefully. The worry on my mind when the prefixes is not in the BCE is that certain prefix routes in the Prefix Table may get stale, or deleted accidentally, when we consider multi-homed mobile network where more than one mobile router handles the same mobile network prefix. > Just need to figure out how to best operate them. > > If one prefers the prefixes in the BC of HA, one needs to also consider > the consequences of the later eventual temptation to use same BC at CN. > Good point. Especially when one consider the possibility of HA itself being a CN to some other mobile nodes. /rgds /cwng From nemo-admin@ietf.org Mon Jun 30 01:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19494 for ; Mon, 30 Jun 2003 01:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wra4-0000LN-W0; Mon, 30 Jun 2003 01:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrZ3-0000Jm-SH for nemo@optimus.ietf.org; Mon, 30 Jun 2003 01:51:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19434 for ; Mon, 30 Jun 2003 01:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrZ0-0003jG-00 for nemo@ietf.org; Mon, 30 Jun 2003 01:50:54 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19WrYk-0003ig-00 for nemo@ietf.org; Mon, 30 Jun 2003 01:50:38 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA06713; Sun, 29 Jun 2003 22:49:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5U5n7203455; Sun, 29 Jun 2003 22:49:07 -0700 X-mProtect: <200306300549> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.54.137, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5RoNrO; Sun, 29 Jun 2003 22:49:04 PDT Message-ID: <3EFFCF4C.6040909@iprg.nokia.com> Date: Sun, 29 Jun 2003 22:49:00 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cwng@psl.com.sg CC: IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >>>So each entry in the Binding Update List is going to be dynamic in size >>>(since the maximum number of prefixes is not known)? >> >>it is a conceptual data structure. you can implement >>it any way you want. >> > > That's perfectly fine. So apart from the theoretical limit due to > maximum allowed IPv6 packet size, there is no limit on the number of > prefixes, am I correct? right. Vijay From exim@www1.ietf.org Mon Jun 30 01:52:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19509 for ; Mon, 30 Jun 2003 01:52:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U5qH701414 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 01:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WraL-0000Mj-R3 for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 01:52:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19487 for ; Mon, 30 Jun 2003 01:52:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WraI-0003jt-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 01:52:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WraD-0003jm-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 01:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wra4-0000LN-W0; Mon, 30 Jun 2003 01:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrZ3-0000Jm-SH for nemo@optimus.ietf.org; Mon, 30 Jun 2003 01:51:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19434 for ; Mon, 30 Jun 2003 01:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrZ0-0003jG-00 for nemo@ietf.org; Mon, 30 Jun 2003 01:50:54 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19WrYk-0003ig-00 for nemo@ietf.org; Mon, 30 Jun 2003 01:50:38 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA06713; Sun, 29 Jun 2003 22:49:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5U5n7203455; Sun, 29 Jun 2003 22:49:07 -0700 X-mProtect: <200306300549> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.54.137, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5RoNrO; Sun, 29 Jun 2003 22:49:04 PDT Message-ID: <3EFFCF4C.6040909@iprg.nokia.com> Date: Sun, 29 Jun 2003 22:49:00 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cwng@psl.com.sg CC: IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >>>So each entry in the Binding Update List is going to be dynamic in size >>>(since the maximum number of prefixes is not known)? >> >>it is a conceptual data structure. you can implement >>it any way you want. >> > > That's perfectly fine. So apart from the theoretical limit due to > maximum allowed IPv6 packet size, there is no limit on the number of > prefixes, am I correct? right. Vijay From nemo-admin@ietf.org Mon Jun 30 03:02:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02955 for ; Mon, 30 Jun 2003 03:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wsfp-0005sQ-OV; Mon, 30 Jun 2003 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WsfT-0005sE-J9 for nemo@optimus.ietf.org; Mon, 30 Jun 2003 03:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02948 for ; Mon, 30 Jun 2003 03:01:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WsfP-00045z-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:01:35 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 19WsfE-00045s-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:01:25 -0400 Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXPOELCG3A9FPK0J@vaxc.its.monash.edu.au> for nemo@ietf.org; Mon, 30 Jun 2003 17:00:59 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 778F12000B for ; Mon, 30 Jun 2003 17:00:59 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 5F78F2000A for ; Mon, 30 Jun 2003 17:00:59 +1000 (EST) Date: Mon, 30 Jun 2003 17:00:59 +1000 From: Greg Daley To: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFFE02B.2020401@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Content-Transfer-Encoding: 7BIT Subject: [nemo] Security considerations for NEMO? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi All, I've not heard any responses to Thierry's request for NEMO security analysis? Is anyone working on this now? How about we look at issues in 3 areas: Attacks on the MR at the visiting network (similar to MIPv6 host issues, although there may be further consequences for a network). Attacks on the NEMO's Resources, (i.e, Bidirectional tunnel bandwidth, routing attacks) Attacks on nodes within a NEMO (are there any special attacks?) Are there any further areas to look at? It may not look like a particularly interesting area with the basic-NEMO solution, but we need a basic security analysis before we can tackle RO. Greg From exim@www1.ietf.org Mon Jun 30 03:02:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02970 for ; Mon, 30 Jun 2003 03:02:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U72F822693 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 03:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wsg2-0005tw-Vq for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 03:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02952 for ; Mon, 30 Jun 2003 03:02:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wsfz-000467-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 03:02:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wsft-000464-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 03:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wsfp-0005sQ-OV; Mon, 30 Jun 2003 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WsfT-0005sE-J9 for nemo@optimus.ietf.org; Mon, 30 Jun 2003 03:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02948 for ; Mon, 30 Jun 2003 03:01:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WsfP-00045z-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:01:35 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 19WsfE-00045s-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:01:25 -0400 Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXPOELCG3A9FPK0J@vaxc.its.monash.edu.au> for nemo@ietf.org; Mon, 30 Jun 2003 17:00:59 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 778F12000B for ; Mon, 30 Jun 2003 17:00:59 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 5F78F2000A for ; Mon, 30 Jun 2003 17:00:59 +1000 (EST) Date: Mon, 30 Jun 2003 17:00:59 +1000 From: Greg Daley To: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFFE02B.2020401@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Content-Transfer-Encoding: 7BIT Subject: [nemo] Security considerations for NEMO? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi All, I've not heard any responses to Thierry's request for NEMO security analysis? Is anyone working on this now? How about we look at issues in 3 areas: Attacks on the MR at the visiting network (similar to MIPv6 host issues, although there may be further consequences for a network). Attacks on the NEMO's Resources, (i.e, Bidirectional tunnel bandwidth, routing attacks) Attacks on nodes within a NEMO (are there any special attacks?) Are there any further areas to look at? It may not look like a particularly interesting area with the basic-NEMO solution, but we need a basic security analysis before we can tackle RO. Greg From nemo-admin@ietf.org Mon Jun 30 03:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04026 for ; Mon, 30 Jun 2003 03:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WtDg-0007cm-9w; Mon, 30 Jun 2003 03:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WtD8-0007ZL-WF for nemo@optimus.ietf.org; Mon, 30 Jun 2003 03:36:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04009 for ; Mon, 30 Jun 2003 03:36:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WtD6-0004Gq-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:36:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19WtCw-0004GF-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:36:14 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2003 09:34:49 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5U7WRQq003449; Mon, 30 Jun 2003 09:32:28 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Jun 2003 09:34:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Security considerations for NEMO? Date: Mon, 30 Jun 2003 08:34:30 +0100 Message-ID: Thread-Topic: [nemo] Security considerations for NEMO? Thread-Index: AcM+1bESDgPjiXvHT0iZcm/sUPLe9AAAc+FA From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 30 Jun 2003 07:34:31.0060 (UTC) FILETIME=[0B57C540:01C33EDA] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: lundi 30 juin 2003 09:01 > To: nemo@ietf.org > Subject: [nemo] Security considerations for NEMO? >=20 > Hi All, >=20 Hi Greg :) > I've not heard any responses to Thierry's request for > NEMO security analysis? >=20 > Is anyone working on this now? I wrote some thoughts here and there, including RRH draft, but not really. One point that's not seen as an attack is related to anonymity. Could the visitor and the visited entertain an 'anonymous' relationship. We had that discussion with Alex (and you if I remember :) some time ago. >=20 > How about we look at issues in 3 areas: >=20 > Attacks on the MR at the visiting network > (similar to MIPv6 host issues, although > there may be further consequences for a > network). >=20 Maybe the assumption that the egress can not be an ingress network as well will not stand too long. If so, the visited link integrates the mobile network, leading to new problems. But in basic-NEMO, I expect that the MR behaves as a MIP MN so it inherits from the related threats. On top of that, the MR is still a router. When it autoconfigures a CareOf, it also adds connected routes to its Routing table. Which can lead to attacks. So you're right, we have to consider this... > Attacks on the NEMO's Resources, > (i.e, Bidirectional tunnel bandwidth, > routing attacks) Man in the middle, leaks...=20 Do we need to mandate ESP or is there a simplest way, what limitations? >=20 > Attacks on nodes within a NEMO (are there any > special attacks?) >=20 Big surprise, yes! And a lot of SeND / CGA related work should be considered. > Are there any further areas to look at? >=20 Attacks on the HA and the home. - Can we afford to tunnel everything from ingress of MR to HA? - What policy on the HA for MR-HA tunneled packets? - Where should the HA be placed, in DMZ or something?=20 > It may not look like a particularly interesting > area with the basic-NEMO solution, but we need a > basic security analysis before we can tackle RO. >=20 I'd say that RO solutions may change the problem set; from RRH experience, RRH removes some threats and creates new openings. So it may well be difficult to separate RO and security. But sure, it's good to understand the limits of basic-Nemo Pascal From exim@www1.ietf.org Mon Jun 30 03:39:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04122 for ; Mon, 30 Jun 2003 03:39:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U7d6k30714 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 03:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WtFh-0007zD-Qg for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 03:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04085 for ; Mon, 30 Jun 2003 03:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WtFf-0004Ht-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 03:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WtFY-0004Hj-01 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 03:38:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WtDg-0007cm-9w; Mon, 30 Jun 2003 03:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WtD8-0007ZL-WF for nemo@optimus.ietf.org; Mon, 30 Jun 2003 03:36:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04009 for ; Mon, 30 Jun 2003 03:36:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WtD6-0004Gq-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:36:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19WtCw-0004GF-00 for nemo@ietf.org; Mon, 30 Jun 2003 03:36:14 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2003 09:34:49 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5U7WRQq003449; Mon, 30 Jun 2003 09:32:28 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Jun 2003 09:34:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Security considerations for NEMO? Date: Mon, 30 Jun 2003 08:34:30 +0100 Message-ID: Thread-Topic: [nemo] Security considerations for NEMO? Thread-Index: AcM+1bESDgPjiXvHT0iZcm/sUPLe9AAAc+FA From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 30 Jun 2003 07:34:31.0060 (UTC) FILETIME=[0B57C540:01C33EDA] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: lundi 30 juin 2003 09:01 > To: nemo@ietf.org > Subject: [nemo] Security considerations for NEMO? >=20 > Hi All, >=20 Hi Greg :) > I've not heard any responses to Thierry's request for > NEMO security analysis? >=20 > Is anyone working on this now? I wrote some thoughts here and there, including RRH draft, but not really. One point that's not seen as an attack is related to anonymity. Could the visitor and the visited entertain an 'anonymous' relationship. We had that discussion with Alex (and you if I remember :) some time ago. >=20 > How about we look at issues in 3 areas: >=20 > Attacks on the MR at the visiting network > (similar to MIPv6 host issues, although > there may be further consequences for a > network). >=20 Maybe the assumption that the egress can not be an ingress network as well will not stand too long. If so, the visited link integrates the mobile network, leading to new problems. But in basic-NEMO, I expect that the MR behaves as a MIP MN so it inherits from the related threats. On top of that, the MR is still a router. When it autoconfigures a CareOf, it also adds connected routes to its Routing table. Which can lead to attacks. So you're right, we have to consider this... > Attacks on the NEMO's Resources, > (i.e, Bidirectional tunnel bandwidth, > routing attacks) Man in the middle, leaks...=20 Do we need to mandate ESP or is there a simplest way, what limitations? >=20 > Attacks on nodes within a NEMO (are there any > special attacks?) >=20 Big surprise, yes! And a lot of SeND / CGA related work should be considered. > Are there any further areas to look at? >=20 Attacks on the HA and the home. - Can we afford to tunnel everything from ingress of MR to HA? - What policy on the HA for MR-HA tunneled packets? - Where should the HA be placed, in DMZ or something?=20 > It may not look like a particularly interesting > area with the basic-NEMO solution, but we need a > basic security analysis before we can tackle RO. >=20 I'd say that RO solutions may change the problem set; from RRH experience, RRH removes some threats and creates new openings. So it may well be difficult to separate RO and security. But sure, it's good to understand the limits of basic-Nemo Pascal From nemo-admin@ietf.org Mon Jun 30 17:25:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17041 for ; Mon, 30 Jun 2003 17:25:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X690-0002BJ-Eh; Mon, 30 Jun 2003 17:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X68c-00027R-Sk for nemo@optimus.ietf.org; Mon, 30 Jun 2003 17:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17003 for ; Mon, 30 Jun 2003 17:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X68a-0004UE-00 for nemo@ietf.org; Mon, 30 Jun 2003 17:24:36 -0400 Received: from pop12.ucdavis.edu ([169.237.105.22]) by ietf-mx with esmtp (Exim 4.12) id 19X68P-0004Tr-00 for nemo@ietf.org; Mon, 30 Jun 2003 17:24:25 -0400 Received: from SOUHWANSENSQ (nat6-177.cs.ucdavis.edu [169.237.6.177]) by pop12.ucdavis.edu (8.12.9/8.12.9/it-std-5.0.2) with SMTP id h5ULNouL026337; Mon, 30 Jun 2003 14:23:52 -0700 (PDT) Message-ID: <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: , References: <3EFFE02B.2020401@eng.monash.edu.au> Subject: Re: [nemo] Security considerations for NEMO? Date: Tue, 1 Jul 2003 06:23:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgR3JlZyBhbmQgYWxsLA0KDQpXZSBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGUgdGhyZWF0IGFu YWx5c2lzIGZvciBORU1PLCBhbmQgd2Ugc3VibWl0dGVkIGEgZHJhZnQuDQpZb3UgY2FuIGZpbmQg bXkgZHJhZnQgb24gdGhlIGZvbGxvd2luZyBsb2NhdGlvbi4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWp1bmctbmVtby10aHJlYXQtYW5hbHlzaXMtMDAudHh0DQoN Ck91ciBhcHByb2FjaCBpcyB0byBidWlsZCBhIGdlbmVyaWMgdGhyZWF0IG1vZGVsIGFuZCB0byBj b25zaWRlciBhbGwgcG9zc2libGUgdGhyZWF0cyBmcm9tIHRoZSBzY3JhdGNoLCB3aGljaCBtZWFu cyB0aGF0IHRoZSB0aHJlYXRzIGFyZSBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IG5vIHNl Y3VyaXR5IG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJsZSAgZm9yIE5FTU8geWV0LiBUaGlzIG1heSBu b3QgYmUgdHJ1ZSB3aXRoIHRoZSBuZXcgZHJhZnQgb2YgTkVNTyBiYXNpYyBwcm90b2NvbC4NCklu IGZhY3QsIG91ciB3b3JrIHdhcyBkb25lIGJlZm9yZSB0aGUgbmV3IGRyYWZ0IGlzIGFubm91bmNl ZC4NCiANCkFueXdheSwgd2Uga2VlcCB3b3JraW5nIG9uIHVwZGF0aW5nIG91ciBkcmFmdCB3aGls ZSBhbmFseXppbmcgdGhlIGZlYXNpYmlsaXR5IG9mIHRob3NlIHRocmVhdHMgYXNzdW1pbmcgdGhl IHNlY3VyaXR5IG1lY2hhbmlzbXMgYXZhaWxhYmxlIGluIHRoZSBkcmFmdCBvZiBiYXNpYyBORU1P IHByb3RvY29sLg0KDQpBbnkgY29tbWVudHMgdG8gb3VyIGRyYWZ0IHdpbGwgYmUgaGVscGZ1bCBm b3IgdXMgdG8gdXBkYXRlIHRoZSBkcmFmdC4NCg0KVGhhbmtzLg0KDQpTb3Vod2FuDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiR3JlZyBEYWxleSIgPGdyZWcuZGFsZXlA ZW5nLm1vbmFzaC5lZHUuYXU+DQpUbzogPG5lbW9AaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1 bmUgMzAsIDIwMDMgNDowMCBQTQ0KU3ViamVjdDogW25lbW9dIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGZvciBORU1PPw0KDQoNCj4gSGkgQWxsLA0KPiANCj4gSSd2ZSBub3QgaGVhcmQgYW55IHJl c3BvbnNlcyB0byBUaGllcnJ5J3MgcmVxdWVzdCBmb3INCj4gTkVNTyBzZWN1cml0eSBhbmFseXNp cz8NCj4gDQo+IElzIGFueW9uZSB3b3JraW5nIG9uIHRoaXMgbm93Pw0KPiANCj4gSG93IGFib3V0 IHdlIGxvb2sgYXQgaXNzdWVzIGluIDMgYXJlYXM6DQo+IA0KPiBBdHRhY2tzIG9uIHRoZSBNUiBh dCB0aGUgdmlzaXRpbmcgbmV0d29yaw0KPiAoc2ltaWxhciB0byBNSVB2NiBob3N0IGlzc3Vlcywg YWx0aG91Z2gNCj4gdGhlcmUgbWF5IGJlIGZ1cnRoZXIgY29uc2VxdWVuY2VzIGZvciBhDQo+IG5l dHdvcmspLg0KPiANCj4gQXR0YWNrcyBvbiB0aGUgTkVNTydzIFJlc291cmNlcywNCj4gKGkuZSwg QmlkaXJlY3Rpb25hbCB0dW5uZWwgYmFuZHdpZHRoLA0KPiByb3V0aW5nIGF0dGFja3MpDQo+IA0K PiBBdHRhY2tzIG9uIG5vZGVzIHdpdGhpbiBhIE5FTU8gKGFyZSB0aGVyZSBhbnkNCj4gc3BlY2lh bCBhdHRhY2tzPykNCj4gDQo+IEFyZSB0aGVyZSBhbnkgZnVydGhlciBhcmVhcyB0byBsb29rIGF0 Pw0KPiANCj4gSXQgbWF5IG5vdCBsb29rIGxpa2UgYSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RpbmcN Cj4gYXJlYSB3aXRoIHRoZSBiYXNpYy1ORU1PIHNvbHV0aW9uLCBidXQgd2UgbmVlZCBhDQo+IGJh c2ljIHNlY3VyaXR5IGFuYWx5c2lzIGJlZm9yZSB3ZSBjYW4gdGFja2xlIFJPLg0KPiANCj4gR3Jl Zw0KPiANCj4gDQo+IA0KPiA= From exim@www1.ietf.org Mon Jun 30 17:25:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17056 for ; Mon, 30 Jun 2003 17:25:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ULPBT08479 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 17:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X699-0002Cg-MT for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 17:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17023 for ; Mon, 30 Jun 2003 17:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X697-0004Ue-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 17:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X691-0004Ub-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 17:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X690-0002BJ-Eh; Mon, 30 Jun 2003 17:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X68c-00027R-Sk for nemo@optimus.ietf.org; Mon, 30 Jun 2003 17:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17003 for ; Mon, 30 Jun 2003 17:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X68a-0004UE-00 for nemo@ietf.org; Mon, 30 Jun 2003 17:24:36 -0400 Received: from pop12.ucdavis.edu ([169.237.105.22]) by ietf-mx with esmtp (Exim 4.12) id 19X68P-0004Tr-00 for nemo@ietf.org; Mon, 30 Jun 2003 17:24:25 -0400 Received: from SOUHWANSENSQ (nat6-177.cs.ucdavis.edu [169.237.6.177]) by pop12.ucdavis.edu (8.12.9/8.12.9/it-std-5.0.2) with SMTP id h5ULNouL026337; Mon, 30 Jun 2003 14:23:52 -0700 (PDT) Message-ID: <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: , References: <3EFFE02B.2020401@eng.monash.edu.au> Subject: Re: [nemo] Security considerations for NEMO? Date: Tue, 1 Jul 2003 06:23:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgR3JlZyBhbmQgYWxsLA0KDQpXZSBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGUgdGhyZWF0IGFu YWx5c2lzIGZvciBORU1PLCBhbmQgd2Ugc3VibWl0dGVkIGEgZHJhZnQuDQpZb3UgY2FuIGZpbmQg bXkgZHJhZnQgb24gdGhlIGZvbGxvd2luZyBsb2NhdGlvbi4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWp1bmctbmVtby10aHJlYXQtYW5hbHlzaXMtMDAudHh0DQoN Ck91ciBhcHByb2FjaCBpcyB0byBidWlsZCBhIGdlbmVyaWMgdGhyZWF0IG1vZGVsIGFuZCB0byBj b25zaWRlciBhbGwgcG9zc2libGUgdGhyZWF0cyBmcm9tIHRoZSBzY3JhdGNoLCB3aGljaCBtZWFu cyB0aGF0IHRoZSB0aHJlYXRzIGFyZSBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IG5vIHNl Y3VyaXR5IG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJsZSAgZm9yIE5FTU8geWV0LiBUaGlzIG1heSBu b3QgYmUgdHJ1ZSB3aXRoIHRoZSBuZXcgZHJhZnQgb2YgTkVNTyBiYXNpYyBwcm90b2NvbC4NCklu IGZhY3QsIG91ciB3b3JrIHdhcyBkb25lIGJlZm9yZSB0aGUgbmV3IGRyYWZ0IGlzIGFubm91bmNl ZC4NCiANCkFueXdheSwgd2Uga2VlcCB3b3JraW5nIG9uIHVwZGF0aW5nIG91ciBkcmFmdCB3aGls ZSBhbmFseXppbmcgdGhlIGZlYXNpYmlsaXR5IG9mIHRob3NlIHRocmVhdHMgYXNzdW1pbmcgdGhl IHNlY3VyaXR5IG1lY2hhbmlzbXMgYXZhaWxhYmxlIGluIHRoZSBkcmFmdCBvZiBiYXNpYyBORU1P IHByb3RvY29sLg0KDQpBbnkgY29tbWVudHMgdG8gb3VyIGRyYWZ0IHdpbGwgYmUgaGVscGZ1bCBm b3IgdXMgdG8gdXBkYXRlIHRoZSBkcmFmdC4NCg0KVGhhbmtzLg0KDQpTb3Vod2FuDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiR3JlZyBEYWxleSIgPGdyZWcuZGFsZXlA ZW5nLm1vbmFzaC5lZHUuYXU+DQpUbzogPG5lbW9AaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1 bmUgMzAsIDIwMDMgNDowMCBQTQ0KU3ViamVjdDogW25lbW9dIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGZvciBORU1PPw0KDQoNCj4gSGkgQWxsLA0KPiANCj4gSSd2ZSBub3QgaGVhcmQgYW55IHJl c3BvbnNlcyB0byBUaGllcnJ5J3MgcmVxdWVzdCBmb3INCj4gTkVNTyBzZWN1cml0eSBhbmFseXNp cz8NCj4gDQo+IElzIGFueW9uZSB3b3JraW5nIG9uIHRoaXMgbm93Pw0KPiANCj4gSG93IGFib3V0 IHdlIGxvb2sgYXQgaXNzdWVzIGluIDMgYXJlYXM6DQo+IA0KPiBBdHRhY2tzIG9uIHRoZSBNUiBh dCB0aGUgdmlzaXRpbmcgbmV0d29yaw0KPiAoc2ltaWxhciB0byBNSVB2NiBob3N0IGlzc3Vlcywg YWx0aG91Z2gNCj4gdGhlcmUgbWF5IGJlIGZ1cnRoZXIgY29uc2VxdWVuY2VzIGZvciBhDQo+IG5l dHdvcmspLg0KPiANCj4gQXR0YWNrcyBvbiB0aGUgTkVNTydzIFJlc291cmNlcywNCj4gKGkuZSwg QmlkaXJlY3Rpb25hbCB0dW5uZWwgYmFuZHdpZHRoLA0KPiByb3V0aW5nIGF0dGFja3MpDQo+IA0K PiBBdHRhY2tzIG9uIG5vZGVzIHdpdGhpbiBhIE5FTU8gKGFyZSB0aGVyZSBhbnkNCj4gc3BlY2lh bCBhdHRhY2tzPykNCj4gDQo+IEFyZSB0aGVyZSBhbnkgZnVydGhlciBhcmVhcyB0byBsb29rIGF0 Pw0KPiANCj4gSXQgbWF5IG5vdCBsb29rIGxpa2UgYSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RpbmcN Cj4gYXJlYSB3aXRoIHRoZSBiYXNpYy1ORU1PIHNvbHV0aW9uLCBidXQgd2UgbmVlZCBhDQo+IGJh c2ljIHNlY3VyaXR5IGFuYWx5c2lzIGJlZm9yZSB3ZSBjYW4gdGFja2xlIFJPLg0KPiANCj4gR3Jl Zw0KPiANCj4gDQo+IA0KPiA= From nemo-admin@ietf.org Mon Jun 30 20:23:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23640 for ; Mon, 30 Jun 2003 20:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X8vF-0003b0-KV; Mon, 30 Jun 2003 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X8uG-0003Xe-Ux for nemo@optimus.ietf.org; Mon, 30 Jun 2003 20:22:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23622 for ; Mon, 30 Jun 2003 20:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X8uE-0005WH-00 for nemo@ietf.org; Mon, 30 Jun 2003 20:21:58 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 19X8u1-0005WD-00 for nemo@ietf.org; Mon, 30 Jun 2003 20:21:45 -0400 Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXQOPSAX5Q9FPPMH@vaxc.its.monash.edu.au> for nemo@ietf.org; Tue, 01 Jul 2003 10:20:48 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 597AE20006; Tue, 01 Jul 2003 10:20:48 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 3FABD20003; Tue, 01 Jul 2003 10:20:48 +1000 (EST) Date: Tue, 01 Jul 2003 10:20:48 +1000 From: Greg Daley Subject: Re: [nemo] Security considerations for NEMO? To: Souhwan Jung Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F00D3E0.9060400@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3EFFE02B.2020401@eng.monash.edu.au> <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Souhwan Souhwan Jung wrote: > Hi Greg and all, > > We have been working on the threat analysis for NEMO, and we submitted a draft. > You can find my draft on the following location. > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt > > Our approach is to build a generic threat model and to consider all possible threats from the scratch, which means that the threats are based on the assumption that no security mechanisms are available for NEMO yet. This may not be true with the new draft of NEMO basic protocol. > In fact, our work was done before the new draft is announced. > > Anyway, we keep working on updating our draft while analyzing the feasibility of those threats assuming the security mechanisms available in the draft of basic NEMO protocol. > > Any comments to our draft will be helpful for us to update the draft. I'll have to have a read of this before the meeting. It may be a good thing to discuss some of the issues on the list so that we get wide discussion of the topics, and are able to identify additional areas to cover. I'll try to get some comments back as soon as possible. Greg From exim@www1.ietf.org Mon Jun 30 20:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23655 for ; Mon, 30 Jun 2003 20:24:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h610Nej14015 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 20:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X8vs-0003dy-1k for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 20:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23637 for ; Mon, 30 Jun 2003 20:23:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X8vl-0005WW-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 20:23:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X8vU-0005WT-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 20:23:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X8vF-0003b0-KV; Mon, 30 Jun 2003 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X8uG-0003Xe-Ux for nemo@optimus.ietf.org; Mon, 30 Jun 2003 20:22:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23622 for ; Mon, 30 Jun 2003 20:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X8uE-0005WH-00 for nemo@ietf.org; Mon, 30 Jun 2003 20:21:58 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 19X8u1-0005WD-00 for nemo@ietf.org; Mon, 30 Jun 2003 20:21:45 -0400 Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KXQOPSAX5Q9FPPMH@vaxc.its.monash.edu.au> for nemo@ietf.org; Tue, 01 Jul 2003 10:20:48 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 597AE20006; Tue, 01 Jul 2003 10:20:48 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 3FABD20003; Tue, 01 Jul 2003 10:20:48 +1000 (EST) Date: Tue, 01 Jul 2003 10:20:48 +1000 From: Greg Daley Subject: Re: [nemo] Security considerations for NEMO? To: Souhwan Jung Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F00D3E0.9060400@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3EFFE02B.2020401@eng.monash.edu.au> <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Souhwan Souhwan Jung wrote: > Hi Greg and all, > > We have been working on the threat analysis for NEMO, and we submitted a draft. > You can find my draft on the following location. > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt > > Our approach is to build a generic threat model and to consider all possible threats from the scratch, which means that the threats are based on the assumption that no security mechanisms are available for NEMO yet. This may not be true with the new draft of NEMO basic protocol. > In fact, our work was done before the new draft is announced. > > Anyway, we keep working on updating our draft while analyzing the feasibility of those threats assuming the security mechanisms available in the draft of basic NEMO protocol. > > Any comments to our draft will be helpful for us to update the draft. I'll have to have a read of this before the meeting. It may be a good thing to discuss some of the issues on the list so that we get wide discussion of the topics, and are able to identify additional areas to cover. I'll try to get some comments back as soon as possible. Greg From nemo-admin@ietf.org Mon Jun 30 21:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25446 for ; Mon, 30 Jun 2003 21:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9uD-0007V9-37; Mon, 30 Jun 2003 21:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9tK-0007Uj-7v for nemo@optimus.ietf.org; Mon, 30 Jun 2003 21:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25434 for ; Mon, 30 Jun 2003 21:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X9tH-0005uK-00 for nemo@ietf.org; Mon, 30 Jun 2003 21:25:03 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 19X9t5-0005uC-00 for nemo@ietf.org; Mon, 30 Jun 2003 21:24:52 -0400 Received: from broink.its.monash.edu.au ([130.194.1.70]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXQQPL4KZI9B9GUU@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 1 Jul 2003 11:17:55 +1000 Received: from broink.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C5C438003; Tue, 01 Jul 2003 11:17:54 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 6E97A38002; Tue, 01 Jul 2003 11:17:54 +1000 (EST) Date: Tue, 01 Jul 2003 11:17:54 +1000 From: Greg Daley Subject: Re: [nemo] Security considerations for NEMO? To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F00E142.9090500@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT G'Day Pascal, Pascal Thubert (pthubert) wrote: > >>-----Original Message----- >>From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] >>Sent: lundi 30 juin 2003 09:01 >>To: nemo@ietf.org >>Subject: [nemo] Security considerations for NEMO? >> >>Hi All, >> > > > Hi Greg :) > > >>I've not heard any responses to Thierry's request for >>NEMO security analysis? >> >>Is anyone working on this now? > > > I wrote some thoughts here and there, including RRH draft, but not > really. > > One point that's not seen as an attack is related to anonymity. Could > the visitor and the visited entertain an 'anonymous' relationship. We > had that discussion with Alex (and you if I remember :) some time ago. I believe I remember it. I think I was talking about using AAA, so privacy from the NEMO wasn't my focus at the time. I think that Basic NEMO allows a limited knowledge environment to exist (for example, the visited network needn't know that a device is an MR), nor does a visitor know that it is on a NEMO (necessarily) but still guess that AAA or PKI will be used to authorize visitors. SEND seems to allow some security without necessarily divulging identities (if CGA is used). I'm not exactly sure how all this works with RO though. Did you have a separate draft on visitor anonymity? >>How about we look at issues in 3 areas: >> >>Attacks on the MR at the visiting network >>(similar to MIPv6 host issues, although >>there may be further consequences for a >>network). >> > > > Maybe the assumption that the egress can not be an ingress network as > well will not stand too long. If so, the visited link integrates the > mobile network, leading to new problems. But in basic-NEMO, I expect > that the MR behaves as a MIP MN so it inherits from the related threats. > > On top of that, the MR is still a router. When it autoconfigures a > CareOf, it also adds connected routes to its Routing table. Which can > lead to attacks. So you're right, we have to consider this... It may be relatively simple in basic NEMO, though. > >>Attacks on the NEMO's Resources, >>(i.e, Bidirectional tunnel bandwidth, >>routing attacks) > > > Man in the middle, leaks... > > Do we need to mandate ESP or is there a simplest way, what limitations? Obviously tunnel MTUs are an issue. If there's a problem with ICMP Too Big reception then DoS occurs... > >>Attacks on nodes within a NEMO (are there any >>special attacks?) >> > > > Big surprise, yes! And a lot of SeND / CGA related work should be > considered. I agree, Although I think that CGA is over-rated when the routing infrastructure is not able to be implicitly trusted (as in NEMO). > >>Are there any further areas to look at? >> > > > Attacks on the HA and the home. > > - Can we afford to tunnel everything from ingress of MR to HA? I think we have to determine what circumstances this will occur under... I think that we have to look at the Basic NEMO case as the main issue (at least initially). Nesting may exacerbate this though. Is there a way that MRs know that they are being nested? > - What policy on the HA for MR-HA tunneled packets? Are we talking Basic or RO? > - Where should the HA be placed, in DMZ or something? This is worth consideration. I think that if we're talking about Basic NEMO with bidirectional IKE/ESP tunnels, then we have no greater risk to the network from attacks occurring on the NEMO from the Internet. We're possibly providing carriage for untrusted hosts though, which significantly changes how we'd handle things compared to MIPv6. > > >>It may not look like a particularly interesting >>area with the basic-NEMO solution, but we need a >>basic security analysis before we can tackle RO. >> > > > I'd say that RO solutions may change the problem set; from RRH > experience, RRH removes some threats and creates new openings. So it may > well be difficult to separate RO and security. > > But sure, it's good to understand the limits of basic-Nemo I think that any RO solution will have to interwork with Basic NEMO. The presence of a strong security analysis (of basic, initially) will help with that. I can't see that investigating RO security is as worthwhile (except on a per RO method basis) until the WG decides to pursue the issue and is happy with the general form of Basic NEMO (This may be accomplished, although we need to address IPR fears) I'll try to read Souwhan's draft soon, and we can try to get some discussion going. Greg From exim@www1.ietf.org Mon Jun 30 21:26:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25461 for ; Mon, 30 Jun 2003 21:26:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h611QF028896 for nemo-archive@odin.ietf.org; Mon, 30 Jun 2003 21:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9uQ-0007Vz-TN for nemo-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 21:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25443 for ; Mon, 30 Jun 2003 21:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X9uO-0005uU-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 21:26:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X9uH-0005uR-00 for nemo-web-archive@ietf.org; Mon, 30 Jun 2003 21:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9uD-0007V9-37; Mon, 30 Jun 2003 21:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9tK-0007Uj-7v for nemo@optimus.ietf.org; Mon, 30 Jun 2003 21:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25434 for ; Mon, 30 Jun 2003 21:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X9tH-0005uK-00 for nemo@ietf.org; Mon, 30 Jun 2003 21:25:03 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 19X9t5-0005uC-00 for nemo@ietf.org; Mon, 30 Jun 2003 21:24:52 -0400 Received: from broink.its.monash.edu.au ([130.194.1.70]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXQQPL4KZI9B9GUU@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 1 Jul 2003 11:17:55 +1000 Received: from broink.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C5C438003; Tue, 01 Jul 2003 11:17:54 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 6E97A38002; Tue, 01 Jul 2003 11:17:54 +1000 (EST) Date: Tue, 01 Jul 2003 11:17:54 +1000 From: Greg Daley Subject: Re: [nemo] Security considerations for NEMO? To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F00E142.9090500@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT G'Day Pascal, Pascal Thubert (pthubert) wrote: > >>-----Original Message----- >>From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] >>Sent: lundi 30 juin 2003 09:01 >>To: nemo@ietf.org >>Subject: [nemo] Security considerations for NEMO? >> >>Hi All, >> > > > Hi Greg :) > > >>I've not heard any responses to Thierry's request for >>NEMO security analysis? >> >>Is anyone working on this now? > > > I wrote some thoughts here and there, including RRH draft, but not > really. > > One point that's not seen as an attack is related to anonymity. Could > the visitor and the visited entertain an 'anonymous' relationship. We > had that discussion with Alex (and you if I remember :) some time ago. I believe I remember it. I think I was talking about using AAA, so privacy from the NEMO wasn't my focus at the time. I think that Basic NEMO allows a limited knowledge environment to exist (for example, the visited network needn't know that a device is an MR), nor does a visitor know that it is on a NEMO (necessarily) but still guess that AAA or PKI will be used to authorize visitors. SEND seems to allow some security without necessarily divulging identities (if CGA is used). I'm not exactly sure how all this works with RO though. Did you have a separate draft on visitor anonymity? >>How about we look at issues in 3 areas: >> >>Attacks on the MR at the visiting network >>(similar to MIPv6 host issues, although >>there may be further consequences for a >>network). >> > > > Maybe the assumption that the egress can not be an ingress network as > well will not stand too long. If so, the visited link integrates the > mobile network, leading to new problems. But in basic-NEMO, I expect > that the MR behaves as a MIP MN so it inherits from the related threats. > > On top of that, the MR is still a router. When it autoconfigures a > CareOf, it also adds connected routes to its Routing table. Which can > lead to attacks. So you're right, we have to consider this... It may be relatively simple in basic NEMO, though. > >>Attacks on the NEMO's Resources, >>(i.e, Bidirectional tunnel bandwidth, >>routing attacks) > > > Man in the middle, leaks... > > Do we need to mandate ESP or is there a simplest way, what limitations? Obviously tunnel MTUs are an issue. If there's a problem with ICMP Too Big reception then DoS occurs... > >>Attacks on nodes within a NEMO (are there any >>special attacks?) >> > > > Big surprise, yes! And a lot of SeND / CGA related work should be > considered. I agree, Although I think that CGA is over-rated when the routing infrastructure is not able to be implicitly trusted (as in NEMO). > >>Are there any further areas to look at? >> > > > Attacks on the HA and the home. > > - Can we afford to tunnel everything from ingress of MR to HA? I think we have to determine what circumstances this will occur under... I think that we have to look at the Basic NEMO case as the main issue (at least initially). Nesting may exacerbate this though. Is there a way that MRs know that they are being nested? > - What policy on the HA for MR-HA tunneled packets? Are we talking Basic or RO? > - Where should the HA be placed, in DMZ or something? This is worth consideration. I think that if we're talking about Basic NEMO with bidirectional IKE/ESP tunnels, then we have no greater risk to the network from attacks occurring on the NEMO from the Internet. We're possibly providing carriage for untrusted hosts though, which significantly changes how we'd handle things compared to MIPv6. > > >>It may not look like a particularly interesting >>area with the basic-NEMO solution, but we need a >>basic security analysis before we can tackle RO. >> > > > I'd say that RO solutions may change the problem set; from RRH > experience, RRH removes some threats and creates new openings. So it may > well be difficult to separate RO and security. > > But sure, it's good to understand the limits of basic-Nemo I think that any RO solution will have to interwork with Basic NEMO. The presence of a strong security analysis (of basic, initially) will help with that. I can't see that investigating RO security is as worthwhile (except on a per RO method basis) until the WG decides to pursue the issue and is happy with the general form of Basic NEMO (This may be accomplished, although we need to address IPR fears) I'll try to read Souwhan's draft soon, and we can try to get some discussion going. Greg