From mip4-bounces@ietf.org Mon May 02 17:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSigg-0001aY-7E; Mon, 02 May 2005 17:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSige-0001aO-4a for mip4@megatron.ietf.org; Mon, 02 May 2005 17:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18590 for ; Mon, 2 May 2005 17:42:41 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSiuP-0003FH-02 for mip4@ietf.org; Mon, 02 May 2005 17:56:57 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j42LgWmg014720; Mon, 2 May 2005 16:42:32 -0500 (CDT) Message-ID: <42769EC8.8CB45517@alcatel.com> Date: Mon, 02 May 2005 16:42:32 -0500 From: Tim Ozugur X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds952.usa.alcatel.com id j42LgWmg014720 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Call For Participation: BWAN 2005 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Apologies if you are receiving this message more than once) ------------------------------------------------------------------ CALL FOR PARTICIPATION International Workshop on=20 Broadband Wireless Access Network on fixed network (BWAN 2005) (http://www.bwan.org/) ORLANDO, FL - JUNE 15, 2005 co-located with International Conference on Multimedia Services=20 Access Networks (MSAN '05: http://www.msan.org) CO_SPONSORED BY IEEE ------------------------------------------------------------------- Scope: Workshop: Broadband Wireless Access based on fixed Network=20 (xDSL, FTTx, etc ).=20 This Workshop will deal about complementary wireless broadband access network based on wired network (xDSL, FTTx, etc), 3G/4G and also about different techniques that can solved the tremendous challenges making the sharing of each phone line accessible through wireless access with a minimum guarantee of service for any connected user. In this workshop, the challenges to develop a new low cost mobile or semi-mobile access network with low powering unit will be explored and that may complement UMTS.=20 The workshop is intended to present new architectures of fixed network supporting mobility and/or nomadic features for wireless access (802.11, WiMax,=85802.20=85.), the sharing of the network access, bandwidth sharin= g on radio access. (Single Hop, mesh,=85) and discuss about the perspective= s of shared access network enhanced with wireless extension based on technologies such as WiFi,.. 802.16,.. 802.20, etc to maximize the performance of the overall link and reduce the costs. Within the framework of BWAN 2005, a new research field to prepare the next generation of network access.=20 Topics of interest to this workshop include (but are not limited to) performance studies and solutions (algorithms, protocols, architectures) that tend to improve experience of users of services and applications based on Internet.=20 Workshop Topics: - New Architectures and technologies for broadband wireless=20 access on fixed network(xDSL/FTTx,etc) with mobility features=20 - AAA (Authentification, Authorization, Accounting)=20 - Micro and macro mobility=20 - Medium access control (QoS, bandwidth sharing, fairness)=20 - End to end security and privacy issues on Mobile and/or nomadic=20 Access Network=20 - Low cost and low power integrated xDSL/FTTx+WiFi modem with=20 mobility enhancement=20 - Network cost performance and Business Models SLA-based services=20 - Radio extension such as 802.xy (WiFi, WiMax, etc) =20 Relating Topics:=20 - Modulation, coding and antennas (MIMO)=20 - Interference mitigation for multiple access=20 - Complementary solutions to UMTS=20 - Location-Based Services Applications=20 - Scalability issues to large number of sites=20 - Standard and regulations=20 - IPv6 impact=20 - Mesh extensions -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 03 13:53:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1a5-0002N6-6A; Tue, 03 May 2005 13:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1a4-0002N1-3n for mip4@megatron.ietf.org; Tue, 03 May 2005 13:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14972 for ; Tue, 3 May 2005 13:53:10 -0400 (EDT) Received: from amsterdam.ucdavis.edu ([169.237.104.160]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT1nz-0008Dv-C2 for mip4@ietf.org; Tue, 03 May 2005 14:07:36 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by amsterdam.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j43Hr7UU023865 for ; Tue, 3 May 2005 10:53:07 -0700 (PDT) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j43Hr7dS007156 for ; Tue, 3 May 2005 10:53:07 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j43Hr7pW007155; Tue, 3 May 2005 10:53:07 -0700 (PDT) Date: Tue, 3 May 2005 10:53:07 -0700 (PDT) Message-Id: <200505031753.j43Hr7pW007155@tremex.ucdavis.edu> To: mip4@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mip4] Call for Paper: JSAC-MRNM X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 06 17:24:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUAIq-00040d-98; Fri, 06 May 2005 17:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUAIo-00040U-QH for mip4@megatron.ietf.org; Fri, 06 May 2005 17:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12248 for ; Fri, 6 May 2005 17:24:03 -0400 (EDT) Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUAXK-0004I2-Mp for mip4@ietf.org; Fri, 06 May 2005 17:39:10 -0400 Received: from shiraz.levkowetz.com (213.64.173.70) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) id 41E321670124610C for mip4@ietf.org; Fri, 6 May 2005 23:23:50 +0200 Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DUAIY-00073j-13 for mip4@ietf.org; Fri, 06 May 2005 23:23:50 +0200 Message-ID: <427BE065.5000900@levkowetz.com> Date: Fri, 06 May 2005 23:23:49 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv4 Mailing List X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Mip4] Follow-up on several items. X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org First of all, my excuses for being very late with the follow-up on both the FMIP document, and on the action items from the IETF-62 meeting. By chance, both Pete and myself has run into some personal stuff at the same time. I now have my situation reasonably under control, but still regret that I haven't been able to give the attention to MIP4 which it deserves. Anyway, here goes: I have started putting together a new charter proposal, and expects to send that to the ADs during the coming week. Adoption of FMIPv4: I've initiated discussion with Gabriel, CC: the ADs, regarding where this should be taken up. Assuming we agree on it being appropriate for MIP4, I will add this to the Charter revision proposal I've started to put together. Generic strings: I'm incorporating this as a work item in the charter proposal. Radius attributes: I've initiated discussion with the RADEXT chairs about where this should be a work item. If MIP4 is appropriate, I will add this to the charter as a work item. RFC3519bis: I'm adding this to the charter proposal. I'll follow up with more information as soon as it becomes available. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 11 09:01:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqqF-0003me-FG; Wed, 11 May 2005 09:01:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqqD-0003m1-Hb for mip4@megatron.ietf.org; Wed, 11 May 2005 09:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01073 for ; Wed, 11 May 2005 09:01:31 -0400 (EDT) Received: from amber.ccs.neu.edu ([129.10.116.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVr5k-0005eK-2U for mip4@ietf.org; Wed, 11 May 2005 09:17:36 -0400 Received: from denali.ccs.neu.edu ([129.10.116.200]) by amber.ccs.neu.edu with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.50) id 1DVqq9-0007Gc-Hk; Wed, 11 May 2005 09:01:30 -0400 Date: Wed, 11 May 2005 09:01:31 -0400 (EDT) From: Guevara Noubir To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Mip4] ACM Workshop on Wireless Security (WiSe 2005) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Our apologies if you receive multiple copies of this CFP) ============================================= ACM Workshop on Wireless Security (WiSe 2005) ============================================= (in conjunction with ACM MobiCom 2005) Location: Cologne, Germany Sponsored by ACM SIGMOBILE (PENDING) http://www.ee.washington.edu/research/nsl/wise2005 The workshop on Wireless Security will be held in conjunction with ACM MobiCom 2005. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, applied cryptography, and dependability; with the goal of fostering interaction. With the proliferation of wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: - Key management in wireless/mobile environments - Trust establishment - Computationally efficient primitives - Intrusion detection, detection of malicious behavior - Revocation of malicious parties - Secure PHY/MAC/routing protocols - Secure location determination - Denial of service - User privacy, location privacy - Anonymity, prevention of traffic analysis - Dependable wireless networking - Identity theft and phishing in mobile networks - Charging in wireless networks - Cooperation in wireless networks - Vulnerability modeling - Incentive-aware secure protocol design - Jamming - Monitoring and surveillance Paper submission instructions: ------------------------------ Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 10 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Awards: ------- We gratefully acknowledge funding from the Center of Applied Cybersecurity Research to sponsor two awards of $500 each: one for best paper and one for best student paper. Important dates ================ Paper submission deadline: June 10, 2005 Notification of acceptance: July 10, 2005 Camera-ready papers due: July 15, 2005 Workshop date: Aug 28 - Sept 2, 2005 (in conjunction with Mobicom 2005) Workshop Co-Chairs: ------------------- Markus Jakobsson, Indiana University at Bloomington (markus@indiana.edu) Radha Poovendran, University of Washington (radha@ee.washington.edu) Program committee: ------------------ Yair Amir, Johns Hopkins University Farooq Anjum, Stevens Institute of Technology Srdjan Capkun, Swiss Federal Institute of Technology (EPFL) Yih-Chun, UC Berkeley Brian DeCleene, Alphatech Wenliang (Kevin) Du, Syracuse University Rick Han, University of Colorado Jean-Pierre Hubaux, Swiss Federal Institute of Technology (EPFL) Jiejun Kong, UCLA Wenke Lee, Georgia Institute of Technology Mingyan Li, University of Washington Catherine Meadows, Naval Research Laboratory Peng Ning, North Carolina State University Kaisa Nyberg, Nokia Research Center Adrian Perrig, Carnegie Mellon University Cliff Wang, Army Research Office XiaoFeng Wang, Indiana University at Bloomington Susanne Wetzel, Stevens Institute of Technology Haitao Zheng, Microsoft Research Ben Zhao, UCSB Publicity Co-Chairs: -------------------- Rick Han, University of Colarado Guevara Noubir, Northeastern University Ulrike Meyer Darmstadt University of Technology Publication Chair: ------------------ Saad Biaz, Auburn University Treasurer: ---------- Yongguang Zhang, HRL Labs and University of Texas-Austin WiSe Steering Committee: ------------------------ Adrian Perrig, Carnegie Mellon University Douglas Maughan, DHS / HSARPA Nitin Vaidya, University of Illinois -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 12 15:21:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJF0-00019M-BI; Thu, 12 May 2005 15:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbtZ-0007E8-G2; Tue, 10 May 2005 17:04:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20442; Tue, 10 May 2005 17:03:58 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVc8w-0007rU-Mq; Tue, 10 May 2005 17:19:55 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j4AL2ITs010373; Tue, 10 May 2005 16:02:19 -0500 (CDT) Received: from harlem (harlem.dnrc.bell-labs.com [135.180.161.4]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j4AL2GS09674; Tue, 10 May 2005 17:02:16 -0400 (EDT) Date: Tue, 10 May 2005 17:02:17 -0400 (EDT) From: Thyaga Nandagopal X-X-Sender: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Thu, 12 May 2005 15:21:01 -0400 Subject: [Mip4] COMSWARE 2006: Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on Communication Systems Software and Middleware COMSWARE 2006 http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor: IEEE Communications Society, Indian Institute of Technology, Delhi In Co-operation with: ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA), IBM, Microsoft Research, NOKIA, Lucent Technologies, Sasken The convergence of the communications, information technologies and the Int= ernet has ushered in a revolution in the way people communicate with each other. = The key enabler for this convergence has been the advancement of software technolog= y in various communication sectors, as evident by the high levels of activity in= the industry, academia, and standards bodies, coupled with the increasing depen= dence of this convergence to sustain and improve growth rates in many countries arou= nd the world. This new international conference will provide a forum to exchange ideas, t= echniques, and applications, discuss best practices and challenging issues, raise awar= eness and share experiences among researchers, practitioners, standard developers and= policy makers in the field of software techniques in communications. The conferenc= e will bring leading researchers and practitioners in areas ranging from communica= tions software and software engineering aspects of communications software, to mi= ddleware and networking protocols. The objective of the conference is to provide a h= igh degree of collaboration, participation and discussions of the various topic= s among multi-national participants from the industrial, governmental and academic = sectors. COMSWARE will include a regular paper track and an industry track. The pape= r track will include a highly selective technical program. The conference solicits = original, previously unpublished research work, experimental efforts, and practical e= xperiences for the technical program. COMSWARE will also feature panel discussions fro= m experts in academia and industry, workshops and tutorials featuring the state-of-th= e-art in various communications software and related areas. There will be demos and = exhibits that will expose the delegates to exciting products and software solutions = from industry and academia. Accepted papers will be published by IEEE Computer S= ociety. The top papers accepted to the conference will be published in a reputed jo= urnal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 4, 2005 (Instructions at http://www.comsware.org) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs:=09=09Victor Bahl, Microsoft Research, USA =09=09=09Bijendra Nath Jain, IIT, Delhi, India =09=09=09Henning Schulzrinne, Columbia University, USA =09=09=09Alfred Spector, IBM Research, USA Steering Committee:=09Imrich Chlamtac, University of Trento, Italy =09=09=09Rajeev Shorey, IBM Research, India =09=09=09Prasant Mohapatra, University of California, Davis, USA Program Chairs:=09=09Sanjoy Paul, Lucent Technologies, USA =09=09=09G. Venkatesh, SASKEN Technologies, India =09=09=09Jim Woodcock, University of York, UK Tutorial Chair:=09=09Archan Misra, IBM Research, USA Workshop Chairs:=09Ashwin Gumaste, Fujitsu Research, USA =09=09=09Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Co-Chairs: Sudipta Maitra, IBM, Delhi Laurent Mignet, IBM Research, Delhi Finance Chair: Karen Decker, USA -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 12 16:40:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWKTz-0005vB-Hw; Thu, 12 May 2005 16:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWKTr-0005v5-T7 for mip4@megatron.ietf.org; Thu, 12 May 2005 16:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07865 for ; Thu, 12 May 2005 16:40:25 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWKje-0005ao-04 for mip4@ietf.org; Thu, 12 May 2005 16:56:46 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4CKlxrT012483 for ; Thu, 12 May 2005 13:47:59 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j4CKhuff027192 for ; Thu, 12 May 2005 15:43:56 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 May 2005 15:40:24 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , Kent Leung , Avi Lior , "'Chowdhury, Kuntal'" Date: Thu, 12 May 2005 15:40:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.9 (+) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: Mobile IPv4 Mailing List Subject: [Mip4] resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1047177188==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1047177188== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55732.D2494D8C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55732.D2494D8C Content-Type: text/plain Sorry for the long delay on this. I looked at all the email and tried to see the convergence. Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. Madjid Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? CcoA case: there is no FA, HA acts as NAS a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the AAA server NAS ID: FQDN for HA, if available c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) NAS ID: FQDN for FA, if available b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the AAA server NAS ID: FQDN for FA, if available c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? ------_=_NextPart_001_01C55732.D2494D8C Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5U PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIChmaWx0ZXJlZCkiPg0KDQo8c3R5bGU+DQo8IS0t DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e2ZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47 fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KDQo8L2hl YWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBj bGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPlNv cnJ5IGZvciB0aGUgbG9uZyBkZWxheSBvbiB0aGlzLiBJIGxvb2tlZCBhdCBhbGwgdGhlIGVtYWls DQphbmQgdHJpZWQgdG8gc2VlIHRoZSBjb252ZXJnZW5jZS48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPk1vc3Qgb2YgdGhlIGNhc2VzIHNl ZW0gdG8gYmUgc3RyYWlnaHRmb3J3YXJkOiBwdXQgTkFJIGluDQp1c2VyIG5hbWUgYW5kIElQIGFk ZHJlc3MgaW4gSG9BLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseTpBcmlhbCc+SXQgc2VlbXMgdGhhdCB0aGUgbWFpbiBpc3N1ZSBpcyB3aGVuIEhvQSBp cyBhdmFpbGFibGUgYnV0DQpOQUkgaXMgbm90IGFuZCB0aGUgQUFBIGluZnJhc3RydWN0dXJlICht YWlubHkgTkFTKSBtYXkgbm90IHRydXN0IEhvQQ0Kcm91dGFiaWxpdHkgZW5vdWdoIHRvIHB1dCBp dCBpbiB1c2VyIG5hbWUgd2hlbiBOQUkgaXMgbm90IHRoZXJlLiBBdmkgc3VnZ2VzdGVkDQp3ZSBj b21lIHVwIHdpdGggc29tZSBndWlkYW5jZSBmb3IgaW1wbGVtZW50ZXJzLCBJIGFtIG5vdCBxdWl0 ZSBzdXJlIGlmIEkgY2FtZQ0KdXAgd2l0aCBhbnl0aGluZy4gS3VudGFsIHN1Z2dlc3RlZCBhIERO UyBsb29rdXAuIE1heWJlIHdlIGNhbiBpbmNsdWRlIHRoYXQgaW4NClJBRElVUyByb3V0aW5nIHJl cXVpcmVtZW50IHNlY3Rpb24sIHNvIHRoYXQgd2UgY2FuIGRlYWwgd2l0aCBpdCB3aGVuIHRoaXMg ZHJhZnQNCmdldHMgdG8gUkFERVhULjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5Bbnl3YXksIGJlZm9yZSB5b3UgZmlyZSBh d2F5IGF0IG15IHN0YXRlbWVudHMgYWJvdmUsIHBsZWFzZQ0KbG9vayBhdCB0aGUgZm9sbG93aW5n IHN1bW1hcnkgYW5kIGlmIHlvdSBkZWVtIGl0IHRvIGJlIGFkZXF1YXRlLiBJIHdpbGwgbWFrZQ0K dGhlIGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGFjY29yZGluZ2x5IGFuZCBmaXJlIGF3YXkgYSBuZXcg dmVyc2lvbi48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpBcmlhbCc+TWFkamlkPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QXR0cmlidXRlcyB3ZSBk aXNjdXNzZWQ6PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OkFyaWFsJz5NTiBIb0EsIE1OIE5BSSwgSEEgSVAsIE5BUyBJRCwgdXNlciBuYW1lPC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5Ob3Qg c3VyZSB3aHkgQXZpIGJyb3VnaHQgdXAgdGhlIE1OIENvQSBhdHRyaWJ1dGU/IFdlIGRpZCBub3QN CmhhdmUgdGhhdCBvcmlnaW5hbGx5Pzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTpBcmlhbCc+VGhlIGhvbWUgQUFBIG9yIEhBIGRvbid0IGtub3cgQ29B IGFueXdheSwgc28gbm90IHN1cmUNCndoYXQgaXMgdXNlZCBmb3I/PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkNjb0EgY2Fz ZTogdGhlcmUgaXMgbm8gRkEsIEhBIGFjdHMgYXMgTkFTPC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+YSkgSWYg Ym90aCBOQUkgYW5kIEhvQSBhdmFpbGFibGUgZm9yIE1OICh3ZSBjYW4gYXNzdW1lIEhBIElQDQpp cyBhbHNvIGF2YWlsYWJsZSBpbiBSUlEpOjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVzZXINCm5hbWUgYXR0cmlidXRl OiBNTiBOQUk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTIgZmFjZT1Bcmlh bD48c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs Jz5NTg0KSG9BIGF0dHJpYnV0ZTogTU4gSG9BIElQIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1JVCBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPkhBIElQDQphdHRyaWJ1dGU6IEhBIElQIGZyb20gUlJR IChpbnRlcmZhY2UgdG93YXJkcyB0aGUgTU4sIG5vdCB0b3dhcmRzIEFBQSk8L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO QVMNCklQIGF0dHJpYnV0ZTogSVAgYWRkcmVzcyBvZiBIQSBpbnRlcmZhY2UgdG93YXJkcyB0aGUg QUFBIHNlcnZlciAodGhpcyBzaG91bGQgYmUNCmEgcm91dGFibGUgSVAgYWRkcmVzcyk8L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBOQVMNCklEOiBGUUROIGZvciBIQSwgaWYgYXZhaWxhYmxlPC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4oSXNzdWU6IFJGQyAzMzQ0 IGRvZXMgbm90IGFzc3VtZSB0aGF0IGJvdGggSG9BIGFuZCBOQUkgYXJlDQphdmFpbGFibGUgYXQg dGhlIHNhbWUgdGltZS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6QXJpYWwnPlNlZSBzZWN0aW9uIDMuNjogd2hlbiBOQUkgaXMgdXNlZCBIb0EgaXMg c2V0IHRvIDAuMC4wLjApLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5iKSBJZiBvbmx5IE5BSSBpcyBhdmFpbGFibGUgYW5k IG5vIEhvQSBpcyBwcmVzZW50IChIQSBJUCBtYXkNCm9yIG1heSBub3QgYmUgcHJlc2VudCkuPC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVXNlcg0KbmFtZTogTU4gTkFJPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm8NCk1OIEhvQSBhdHRyaWJ1 dGUgPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy aWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSEENCklQIGF0dHJpYnV0ZSAoaWYgcHJlc2VudCk8L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO QVMNCklQIGF0dHJpYnV0ZTogSVAgYWRkcmVzcyBmb3IgSEEgaW50ZXJmYWNlIHRvd2FyZHMgdGhl IEFBQSBzZXJ2ZXI8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOQVMNCklEOiBGUUROIGZvciBIQSwgaWYgYXZhaWxhYmxl PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPmMpIElmIG9ubHkgSG9BIGlzIHByZXNlbnQgKEhBIElQIHNob3VsZCBiZSBwcmVz ZW50IGFzIHdlbGwpDQpidXQgbm8gTkFJPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUFBLXJvdXRhYmlsaXR5DQpmb3Ig bXVsdGktZG9tYWluIHJvYW1pbmcgaXMgbm90IHBvc3NpYmxlPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXNlcg0KbmFt ZTogTU4gRlFETiBpZiBhdmFpbGFibGU/Py8gTU4gSG9BIGlmIGRlZW1lZCByb3V0YWJsZSAoKioq KTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlh bCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE1ODQpIb0E6IE1OIEhvQTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PGZv bnQNCnNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9SVQgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWwnPkhBDQpJUCBhdHRyaWJ1dGUgKGZyb20gUlJRKTwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+ PHNwYW4gbGFuZz1JVCBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPk5BUyBJUA0KYXR0cmli dXRlOiBIQSBJUCBhZGRyZXNzIHRvd2FyZHMgdGhlIEFBQSBzZXJ2ZXIpLjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5B Uw0KSUQ6IEZRRE4gZm9yIEhBLCBpZiBhdmFpbGFibGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPioqKiBBdmkgc3VnZ2VzdGVkIHRvIHBy b3ZpZGUgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBoZXJlPw0KV2hhdCBzaG91bGQgd2UgcmVj b21tZW5kPzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkZvciBGQS1CYXNlZCBjYXNlOjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+YSkgd2hlbiBib3Ro IE1OIE5BSSBhbmQgTU4gSG9BIGFyZSBhdmFpbGFibGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVc2VyDQpuYW1lIGF0 dHJpYnV0ZTogTU4gTkFJPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTU4NCkhvQSBhdHRyaWJ1dGU6IE1OIEhvQSBJUCA8 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBIQQ0KSVAgYXR0cmlidXRlOiBIQSBJUCBmcm9tIFJSUSAoaW50ZXJmYWNlIHRv d2FyZHMgdGhlIE1OLCBub3QgdG93YXJkcyBBQUEpPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkFTDQpJUCBhdHRyaWJ1 dGU6IEZBIElQIGFkZHJlc3MgdG93YXJkcyB0aGUgQUFBIHNlcnZlciAodGhpcyBzaG91bGQgYmUg YSByb3V0YWJsZQ0KSVAgYWRkcmVzcyk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDouNWluJz48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPk5BUyBJRDog RlFETiBmb3IgRkEsIGlmIGF2YWlsYWJsZTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmIpIElmIG9ubHkgTkFJ IGlzIGF2YWlsYWJsZSBhbmQgbm8gSG9BIGlzIHByZXNlbnQgKEhBIElQIG1heQ0Kb3IgbWF5IG5v dCBiZSBwcmVzZW50KS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVc2VyDQpuYW1lOiBNTiBOQUk8L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO bw0KTU4gSG9BIGF0dHJpYnV0ZSA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIQQ0KSVAgYXR0cmlidXRlIChpZiBwcmVz ZW50IGluIFJSUSk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOQVMNCklQIGF0dHJpYnV0ZTogSVAgYWRkcmVzcyBmb3Ig RkEgaW50ZXJmYWNlIHRvd2FyZHMgdGhlIEFBQSBzZXJ2ZXI8L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDouNWluJz48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwnPk5BUyBJRDogRlFETiBmb3IgRkEsIGlmIGF2YWlsYWJsZTwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmMp IElmIG9ubHkgSG9BIGlzIHByZXNlbnQgKEhBIElQIHNob3VsZCBiZSBwcmVzZW50IGFzIHdlbGwp DQpidXQgbm8gTkFJPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUFBLXJvdXRhYmlsaXR5DQpmb3IgbXVsdGktZG9tYWlu IHJvYW1pbmcgaXMgbm90IHBvc3NpYmxlPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXNlcg0KbmFtZTogTU4gRlFETiBp ZiBhdmFpbGFibGU/Py8gTU4gSG9BIGlmIGRlZW1lZCByb3V0YWJsZSAoKioqKTwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE1ODQpIb0E6IE1OIEhvQTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9MiBm YWNlPUFyaWFsPjxzcGFuIGxhbmc9SVQgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWwnPkhBDQpJUCBhdHRyaWJ1dGUgKGZyb20gUlJRKTwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1J VCBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPk5BUyBJUA0KYXR0cmlidXRlOiBGQSBJUCBh ZGRyZXNzIHRvd2FyZHMgdGhlIEFBQSBzZXJ2ZXIpLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50Oi41aW4nPjxmb250IHNpemU9MiBmYWNl PUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+ TkFTIElEOiBGUUROIGZvciBGQSwgaWYgYXZhaWxhYmxlPC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPioqKiBBdmkgc3VnZ2Vz dGVkIHRvIHByb3ZpZGUgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBoZXJlPw0KV2hhdCBzaG91 bGQgd2UgcmVjb21tZW5kPzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0K DQo8L2h0bWw+DQo= ------_=_NextPart_001_01C55732.D2494D8C-- --===============1047177188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1047177188==-- From mip4-bounces@ietf.org Fri May 13 01:53:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWT6o-0001VK-4B; Fri, 13 May 2005 01:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWT6l-0001VF-Nn for mip4@megatron.ietf.org; Fri, 13 May 2005 01:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19716 for ; Fri, 13 May 2005 01:53:10 -0400 (EDT) Received: from ames.starentnetworks.com ([12.33.235.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWTMc-00072v-9o for mip4@ietf.org; Fri, 13 May 2005 02:09:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 01:52:59 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F03411D39@ames.starentnetworks.com> Thread-Topic: resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVXMtf6W8ANZhPaTeiVmhPSwh+JjgATSyYv From: "Chowdhury, Kuntal" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org Subject: [Mip4] Re: resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Madjid,=20 Good sunnary. I am still not clear about the case when the MN sends a = RRQ with a non routable HoA but does not include NAI extension. What = should be in the username attribute in that case? We can't assume that = the MN FQDN can be drived. So, there won't be anything to identify the = user. Why can't we assume that the HA rejects such RRQs (poorly formed = RRQ)? It does not make sense to go through hoops to accomodate nasty MN = implementations, IMHO. Regarding the need for the inclusion of CoA in the Access-Request, I = think it is optional for the FA and the HA to include it, but it is good = to have.=20 -Kuntal -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 ; Kent Leung = ; Avi Lior ; Chowdhury, = Kuntal CC: Mobile IPv4 Mailing List Sent: Thu May 12 15:40:23 2005 Subject: resolution of RADIUS-MIP identifier issues?? Sorry for the long delay on this. I looked at all the email and tried to = see the convergence. Most of the cases seem to be straightforward: put NAI in user name and = IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and = the AAA infrastructure (mainly NAS) may not trust HoA routability enough = to put it in user name when NAI is not there. Avi suggested we come up = with some guidance for implementers, I am not quite sure if I came up = with anything. Kuntal suggested a DNS lookup. Maybe we can include that = in RADIUS routing requirement section, so that we can deal with it when = this draft gets to RADEXT. =20 Anyway, before you fire away at my statements above, please look at the = following summary and if you deem it to be adequate. I will make the = changes to the draft accordingly and fire away a new version. =20 Madjid =20 =20 Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that = originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? =20 CcoA case: there is no FA, HA acts as NAS =20 =20 a) If both NAI and HoA available for MN (we can assume HA IP is also = available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP=20 HA IP attribute: HA IP from RRQ (interface towards the MN, = not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA = server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at = the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). =20 b) If only NAI is available and no HoA is present (HA IP may or may not = be present). User name: MN NAI No MN HoA attribute=20 HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the = AAA server NAS ID: FQDN for HA, if available =20 c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable = (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available *** Avi suggested to provide guidance for implementers here? What should = we recommend? =20 =20 For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP=20 HA IP attribute: HA IP from RRQ (interface towards the MN, = not towards AAA) NAS IP attribute: FA IP address towards the AAA server (this = should be a routable IP address) NAS ID: FQDN for FA, if available =20 =20 b) If only NAI is available and no HoA is present (HA IP may or may not = be present). User name: MN NAI No MN HoA attribute=20 HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the = AAA server NAS ID: FQDN for FA, if available =20 =20 c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable = (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available =20 *** Avi suggested to provide guidance for implementers here? What should = we recommend? -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 04:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWVLi-000080-E3; Fri, 13 May 2005 04:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWVLf-00007s-W5 for mip4@megatron.ietf.org; Fri, 13 May 2005 04:16:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19440 for ; Fri, 13 May 2005 04:16:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWVbY-0003tO-EW for mip4@ietf.org; Fri, 13 May 2005 04:33:09 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 May 2005 01:16:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4D8GJO9009114; Fri, 13 May 2005 01:16:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 01:16:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 01:16:13 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52285617@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVXM2bmyc4VAeu8TWW6FWa2pzQWjwABfz0w From: "Kent Leung \(kleung\)" To: "Nakhjiri Madjid-MNAKHJI1" , "Avi Lior" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 13 May 2005 08:16:23.0105 (UTC) FILETIME=[0CC6AB10:01C55794] X-Spam-Score: 0.3 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1193851707==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1193851707== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55794.0BD7645B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55794.0BD7645B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Madjid. My comment below in "KL>". ________________________________ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Thursday, May 12, 2005 1:40 PM To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury, Kuntal' Cc: Mobile IPv4 Mailing List Subject: [Mip4] resolution of RADIUS-MIP identifier issues?? =09 =09 Sorry for the long delay on this. I looked at all the email and tried to see the convergence. Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. =20 Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. =20 Madjid =20 =20 Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? =20 CcoA case: there is no FA, HA acts as NAS =20 =20 a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP=20 HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). =20 KL> I think RRQ fields should be mapped directly to RADIUS AVPs. So NAI -> username and HoA IP -> MN HoA AVP. Don't set HoA to 0.0.0.0 if it's not. This bit of info might be useful for the RADIUS server. =20 =20 b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute=20 HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the AAA server NAS ID: FQDN for HA, if available =20 KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to me. Pls explain? =20 =20 c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? =20 KL> The User-Name AVP MUST be in the Access-Request. The length of String field must be >=3D 3. What happens when there is no DNS entry for the MN with private HoA IP address? How is the User-Name AVP populated? =20 For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP=20 HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) =20 KL> HA IP address in RRQ may be any interface address on the router/HA. This may be a logical interface or happens to be the same interface towards AAA. We should not prohibit any interface as stated in parenthesis. =20 =20 NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) NAS ID: FQDN for FA, if available =20 KL> For FA case, are we talking about FA-AAA or HA-AAA interaction? I think we need to cover both scenarios. The NAS IP AVP is set to the HA/FA IP address towards the AAA server. =20 =20 b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute=20 HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the AAA server NAS ID: FQDN for FA, if available =20 KL> Same as above, meaning of "no HoA"? =20 c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available =20 *** Avi suggested to provide guidance for implementers here? What should we recommend? =09 Kent=20 ------_=_NextPart_001_01C55794.0BD7645B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Madjid.  My comment below in=20 "KL>".

From: mip4-bounces@ietf.org=20 [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri=20 Madjid-MNAKHJI1
Sent: Thursday, May 12, 2005 1:40 = PM
To:=20 Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury,=20 Kuntal'
Cc: Mobile IPv4 Mailing List
Subject: = [Mip4]=20 resolution of RADIUS-MIP identifier issues??

Sorry for the long delay = on this.=20 I looked at all the email and tried to see the = convergence.

Most of the cases seem = to be=20 straightforward: put NAI in user name and IP address in = HoA.

It seems that the main = issue is=20 when HoA is available but NAI is not and the AAA infrastructure = (mainly NAS)=20 may not trust HoA routability enough to put it in user name when NAI = is not=20 there. Avi suggested we come up with some guidance for implementers, I = am not=20 quite sure if I came up with anything. Kuntal suggested a DNS lookup. = Maybe we=20 can include that in RADIUS routing requirement section, so that we can = deal=20 with it when this draft gets to RADEXT.

 

Anyway, before you fire = away at my=20 statements above, please look at the following summary and if you deem = it to=20 be adequate. I will make the changes to the draft accordingly and fire = away a=20 new version.

 

Madjid

 

 

Attributes we=20 discussed:

MN HoA, MN NAI, HA IP, = NAS ID,=20 user name

Not sure why Avi brought = up the MN=20 CoA attribute? We did not have that originally?

The home AAA or HA don't = know CoA=20 anyway, so not sure what is used for?

 

CcoA case: there is no = FA, HA acts=20 as NAS

 

 

a) If both NAI and HoA = available=20 for MN (we can assume HA IP is also available in = RRQ):

           = =20 User name attribute: MN NAI

           = =20 MN HoA attribute: MN HoA = IP=20

           = =20 HA IP attribute: HA IP = from RRQ=20 (interface towards the MN, not towards AAA)

           = =20 NAS IP attribute: IP address of HA interface towards the AAA server = (this=20 should be a routable IP address)

           = =20 NAS ID: FQDN for HA, if available

(Issue: RFC 3344 does = not assume=20 that both HoA and NAI are available at the same = time.

See section 3.6: when = NAI is used=20 HoA is set to 0.0.0.0).

 

KL> I think RRQ fields should be mapped = directly=20 to RADIUS AVPs.  So NAI -> username

       and = HoA IP ->=20 MN HoA AVP.  Don't set HoA to 0.0.0.0 if it's not.  This bit = of=20 info

       might = be useful=20 for the RADIUS server.

 

 

b) If only NAI is = available and no=20 HoA is present (HA IP may or may not be present).

           = =20 User name: MN NAI

           = =20 No MN HoA attribute

           = =20 HA IP attribute (if present)

           = =20 NAS IP attribute: IP address for HA interface towards the AAA=20 server

           = =20 NAS ID: FQDN for HA, if available

 

KL> HoA field is always in RRQ, so "no = HoA is=20 present" doesn't make sense to me.  Pls

      =20 explain?

 

 

c) If only HoA is = present (HA IP=20 should be present as well) but no NAI

           = =20 AAA-routability for multi-domain roaming is not = possible

           = =20 User name: MN FQDN if available??/ MN HoA if deemed routable=20 (***)

           = =20 MN HoA: MN HoA

           = =20 HA IP attribute (from=20 RRQ)

           = =20 NAS IP attribute: HA IP = address=20 towards the AAA server).

           = =20 NAS ID: FQDN for HA, if available

*** Avi suggested to = provide=20 guidance for implementers here? What should we = recommend?

 

KL> The User-Name AVP MUST be in the=20 Access-Request.  The length of String field must be >=3D = 3.  What=20 happens when there is no DNS entry for the MN with private HoA IP=20 address?  How is the User-Name AVP = populated?

 

For FA-Based=20 case:

a) when both MN NAI and = MN HoA are=20 available

           = =20 User name attribute: MN NAI

           = =20 MN HoA attribute: MN HoA IP

           = =20 HA IP attribute: HA IP from RRQ (interface towards the MN, not towards = AAA)

 

KL> HA IP = address in RRQ=20 may be any interface address on the router/HA.  This may be a = logical=20 interface or happens to be the same interface towards AAA.  We = should not=20 prohibit any interface as stated in = parenthesis.

 

 

           = =20 NAS IP attribute: FA IP address towards the AAA server (this should be = a=20 routable IP address)

NAS ID: FQDN for FA, if=20 available

 

KL> For FA case, are we talking about = FA-AAA or=20 HA-AAA interaction?  I think we need to cover both = scenarios.  The=20 NAS IP AVP is set to the HA/FA IP address towards the AAA=20 server.

 

 

b) If only NAI is = available and no=20 HoA is present (HA IP may or may not be present).

           = =20 User name: MN NAI

           = =20 No MN HoA attribute

           = =20 HA IP attribute (if present in RRQ)

           = =20 NAS IP attribute: IP address for FA interface towards the AAA=20 server

NAS ID: FQDN for FA, if=20 available

 

KL> Same as above, meaning of "no=20 HoA"?

 

c) If only HoA is = present (HA IP=20 should be present as well) but no NAI

           = =20 AAA-routability for multi-domain roaming is not = possible

           = =20 User name: MN FQDN if available??/ MN HoA if deemed routable=20 (***)

           = =20 MN HoA: MN HoA

           = =20 HA IP attribute (from=20 RRQ)

           = =20 NAS IP attribute: FA IP = address=20 towards the AAA server).

NAS ID: FQDN for FA, if=20 available

 

*** Avi=20 suggested to provide guidance for implementers here? What should we=20 recommend?

Kent 

------_=_NextPart_001_01C55794.0BD7645B-- --===============1193851707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1193851707==-- From mip4-bounces@ietf.org Fri May 13 10:40:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbKn-00071Q-8o; Fri, 13 May 2005 10:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbKl-00071L-Iw for mip4@megatron.ietf.org; Fri, 13 May 2005 10:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21753 for ; Fri, 13 May 2005 10:40:09 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWbag-0001qM-PJ for mip4@ietf.org; Fri, 13 May 2005 10:56:40 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j4DEjq2t006882 for ; Fri, 13 May 2005 07:45:52 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j4DEgKEQ029901 for ; Fri, 13 May 2005 09:42:20 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 09:40:04 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Chowdhury, Kuntal'" , kleung@cisco.com, avi@bridgewatersystems.com Date: Fri, 13 May 2005 09:40:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: mip4@ietf.org Subject: [Mip4] RE: resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Kuntal, It seems that we have to have the User-name attribute populated before sending an Access Request on behalf of the MN. Avi seemed to have issues with putting an non-routable HoA in User-name. The reasoning is understandable, however, as you said we cannot fix MN implementation problems here, unless somebody on this list tells me there is a legitimate reason for the MN using a non-routable HoA (NAT-traversal?). I think we should simply not support NAT traversal at this point. For case C) where no NAI is available, we should accept User-Name=HOA MN-HoA=HoA The HA simply creates the Access Request and sends it to AAA server. I don't think we can modify the RFC 3344 behavior of HA here. It is not within our scope. If NAT traversal drafts define a behavior for HA to change the non-routable HoA to routable one, then the HA may insert the routable address inside the MN-HoA or something. I don't think we should deal with that now. We can provide some recommendation. The AAA server examining these two fields will recognize that MN did not have an NAI and if HoA is unrecognizable it will reject the request. If you guys are ok with this, I will add some text in that effect. Madjid ----- Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] Sent: Friday, May 13, 2005 12:53 AM To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com; avi@bridgewatersystems.com Cc: mip4@ietf.org Subject: Re: resolution of RADIUS-MIP identifier issues?? Madjid, Good sunnary. I am still not clear about the case when the MN sends a RRQ with a non routable HoA but does not include NAI extension. What should be in the username attribute in that case? We can't assume that the MN FQDN can be drived. So, there won't be anything to identify the user. Why can't we assume that the HA rejects such RRQs (poorly formed RRQ)? It does not make sense to go through hoops to accomodate nasty MN implementations, IMHO. Regarding the need for the inclusion of CoA in the Access-Request, I think it is optional for the FA and the HA to include it, but it is good to have. -Kuntal -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 ; Kent Leung ; Avi Lior ; Chowdhury, Kuntal CC: Mobile IPv4 Mailing List Sent: Thu May 12 15:40:23 2005 Subject: resolution of RADIUS-MIP identifier issues?? Sorry for the long delay on this. I looked at all the email and tried to see the convergence. Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. Madjid Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? CcoA case: there is no FA, HA acts as NAS a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the AAA server NAS ID: FQDN for HA, if available c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) NAS ID: FQDN for FA, if available b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the AAA server NAS ID: FQDN for FA, if available c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 10:50:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbV3-0000IX-8D; Fri, 13 May 2005 10:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbUy-0000Hp-TI for mip4@megatron.ietf.org; Fri, 13 May 2005 10:50:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22318 for ; Fri, 13 May 2005 10:50:41 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWbkt-0002C0-SG for mip4@ietf.org; Fri, 13 May 2005 11:07:12 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j4DF0daJ008831 for ; Fri, 13 May 2005 08:00:39 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4DEqemo011990 for ; Fri, 13 May 2005 09:52:41 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 09:50:37 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kent Leung \\(kleung\\)'" , Avi Lior , "Chowdhury, Kuntal" , Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 09:50:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.1 (++) X-Scan-Signature: b4c10eaa27436d806c79842272125a2a Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087836601==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2087836601== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C557CB.1F5F831C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C557CB.1F5F831C Content-Type: text/plain Hi Kent, See inlines. Madjid -----Original Message----- From: Kent Leung \(kleung\) [mailto:kleung@cisco.com] Sent: Friday, May 13, 2005 3:16 AM To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Hi Madjid. My comment below in "KL>". _____ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Thursday, May 12, 2005 1:40 PM To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury, Kuntal' Cc: Mobile IPv4 Mailing List Subject: [Mip4] resolution of RADIUS-MIP identifier issues?? Sorry for the long delay on this. I looked at all the email and tried to see the convergence. Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. Madjid Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? CcoA case: there is no FA, HA acts as NAS a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). KL> I think RRQ fields should be mapped directly to RADIUS AVPs. So NAI -> username and HoA IP -> MN HoA AVP. Don't set HoA to 0.0.0.0 if it's not. This bit of info might be useful for the RADIUS server. Madjid>>Not sure if I said we make HoA to 0.0.0.0 anywhere? I was just quoting the RFC 3344 behavior as a potential issue for this scenario. But that may not be our problem. We are simply providing support for different scenario. b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the AAA server NAS ID: FQDN for HA, if available KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to me. Pls explain? Madjid>> Ok, I guess what I meant here was the RFC 3344 behavior, when NAI is present, the MN according to 3344 sets the HoA to 0.0.0.0. You are right, we better include HoA as it is in MN HOA always. I guess this simplifies our life, since cases a and b are now one. c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? KL> The User-Name AVP MUST be in the Access-Request. The length of String field must be >= 3. What happens when there is no DNS entry for the MN with private HoA IP address? How is the User-Name AVP populated? Madjid>> I agree. Two options in this case: 1) include HoA in User-Name (as I said in my previous email). If HoA is routable fine, if not either HA must fix it, or the AAA server rejects it. 2) Not sure if we can put zeros in User-Name attribute? For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) KL> HA IP address in RRQ may be any interface address on the router/HA. This may be a logical interface or happens to be the same interface towards AAA. We should not prohibit any interface as stated in parenthesis. Madjid>> Agree, need to clarify the sentence in the write up. How about, the following in the Mobile IP requirements section? In case the HA is using different interfaces towards the MN and AAA server, care must be taken so that HA IP includes the IP address used in RRQ and NAS IP includes the address used in AAA signaling. NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) NAS ID: FQDN for FA, if available KL> For FA case, are we talking about FA-AAA or HA-AAA interaction? I think we need to cover both scenarios. The NAS IP AVP is set to the HA/FA IP address towards the AAA server. Madjid>> this part is about FA-AAA. b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the AAA server NAS ID: FQDN for FA, if available KL> Same as above, meaning of "no HoA"? c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? Kent ------_=_NextPart_001_01C557CB.1F5F831C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCg0KDQo8bWV0YSBuYW1lPUdl bmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCAoZmlsdGVyZWQpIj4NCg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZW1haWxzdHlsZTE3DQoJe2ZvbnQtZmFtaWx5 OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7Zm9udC1m YW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuU2VjdGlv bjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwvaGVhZD4NCg0KPGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24x Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPkhpIEtlbnQsPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSc+U2VlIGlubGluZXMuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+TWFkamlkPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhv bWEnPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQt d2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvYj4gS2VudCBMZXVuZyBcKGtsZXVuZ1wpDQpbbWFp bHRvOmtsZXVuZ0BjaXNjby5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpi b2xkJz5TZW50Ojwvc3Bhbj48L2I+IEZyaWRheSwgTWF5IDEzLCAyMDA1IDM6MTYgQU08YnI+DQo8 Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gTmFraGppcmkg TWFkamlkLU1OQUtISkkxOyBBdmkNCkxpb3I7IENob3dkaHVyeSwgS3VudGFsPGJyPg0KPGI+PHNw YW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNjOjwvc3Bhbj48L2I+IE1vYmlsZSBJUHY0IE1h aWxpbmcgTGlzdDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0 Ojwvc3Bhbj48L2I+IFJFOiBbTWlwNF0gcmVzb2x1dGlvbiBvZg0KUkFESVVTLU1JUCBpZGVudGlm aWVyIGlzc3Vlcz8/PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5IaSBNYWRqaWQuJm5ic3A7IE15 IGNvbW1lbnQgYmVsb3cgaW4NCiZxdW90O0tMJmd0OyZxdW90Oy48L3NwYW4+PC9mb250PjwvcD4N Cg0KPGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCc+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0K PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRl cic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPg0K DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5G cm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250DQpzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4NCm1pcDQtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1pcDQtYm91bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9J2Zv bnQtd2VpZ2h0Og0KYm9sZCc+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+TmFraGppcmkgTWFkamlk LU1OQUtISkkxPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9z cGFuPjwvYj4gVGh1cnNkYXksIE1heSAxMiwgMjAwNSAxOjQwDQpQTTxicj4NCjxiPjxzcGFuIHN0 eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBOYWtoamlyaSBNYWRqaWQtTU5B S0hKSTE7IEtlbnQNCkxldW5nIChrbGV1bmcpOyBBdmkgTGlvcjsgJ0Nob3dkaHVyeSwgS3VudGFs Jzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5DYzo8L3NwYW4+PC9iPiBN b2JpbGUgSVB2NCBNYWlsaW5nIExpc3Q8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6 Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBbTWlwNF0gcmVzb2x1dGlvbiBvZg0KUkFESVVTLU1J UCBpZGVudGlmaWVyIGlzc3Vlcz8/PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5Tb3JyeSBmb3IgdGhlIGxvbmcgZGVsYXkgb24gdGhpcy4g SSBsb29rZWQgYXQgYWxsIHRoZSBlbWFpbA0KYW5kIHRyaWVkIHRvIHNlZSB0aGUgY29udmVyZ2Vu Y2UuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy aWFsJz5Nb3N0IG9mIHRoZSBjYXNlcyBzZWVtIHRvIGJlIHN0cmFpZ2h0Zm9yd2FyZDogcHV0IE5B SSBpbg0KdXNlciBuYW1lIGFuZCBJUCBhZGRyZXNzIGluIEhvQS48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkl0IHNlZW1zIHRoYXQgdGhl IG1haW4gaXNzdWUgaXMgd2hlbiBIb0EgaXMgYXZhaWxhYmxlIGJ1dA0KTkFJIGlzIG5vdCBhbmQg dGhlIEFBQSBpbmZyYXN0cnVjdHVyZSAobWFpbmx5IE5BUykgbWF5IG5vdCB0cnVzdCBIb0ENCnJv dXRhYmlsaXR5IGVub3VnaCB0byBwdXQgaXQgaW4gdXNlciBuYW1lIHdoZW4gTkFJIGlzIG5vdCB0 aGVyZS4gQXZpIHN1Z2dlc3RlZA0Kd2UgY29tZSB1cCB3aXRoIHNvbWUgZ3VpZGFuY2UgZm9yIGlt cGxlbWVudGVycywgSSBhbSBub3QgcXVpdGUgc3VyZSBpZiBJIGNhbWUNCnVwIHdpdGggYW55dGhp bmcuIEt1bnRhbCBzdWdnZXN0ZWQgYSBETlMgbG9va3VwLiBNYXliZSB3ZSBjYW4gaW5jbHVkZSB0 aGF0IGluDQpSQURJVVMgcm91dGluZyByZXF1aXJlbWVudCBzZWN0aW9uLCBzbyB0aGF0IHdlIGNh biBkZWFsIHdpdGggaXQgd2hlbiB0aGlzIGRyYWZ0DQpnZXRzIHRvIFJBREVYVC48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QW55d2F5 LCBiZWZvcmUgeW91IGZpcmUgYXdheSBhdCBteSBzdGF0ZW1lbnRzIGFib3ZlLCBwbGVhc2UNCmxv b2sgYXQgdGhlIGZvbGxvd2luZyBzdW1tYXJ5IGFuZCBpZiB5b3UgZGVlbSBpdCB0byBiZSBhZGVx dWF0ZS4gSSB3aWxsIG1ha2UNCnRoZSBjaGFuZ2VzIHRvIHRoZSBkcmFmdCBhY2NvcmRpbmdseSBh bmQgZmlyZSBhd2F5IGEgbmV3IHZlcnNpb24uPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPk1hZGppZDwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkF0dHJpYnV0ZXMgd2Ug ZGlzY3Vzc2VkOjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseTpBcmlhbCc+TU4gSG9BLCBNTiBOQUksIEhBIElQLCBOQVMgSUQsIHVzZXIgbmFtZTwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Tm90 IHN1cmUgd2h5IEF2aSBicm91Z2h0IHVwIHRoZSBNTiBDb0EgYXR0cmlidXRlPyBXZSBkaWQgbm90 DQpoYXZlIHRoYXQgb3JpZ2luYWxseT88L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPlRoZSBob21lIEFBQSBvciBIQSBkb24ndCBrbm93IENv QSBhbnl3YXksIHNvIG5vdCBzdXJlIHdoYXQNCmlzIHVzZWQgZm9yPzwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5DY29BIGNhc2U6IHRo ZXJlIGlzIG5vIEZBLCBIQSBhY3RzIGFzIE5BUzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmEpIElmIGJvdGggTkFJIGFuZCBIb0Eg YXZhaWxhYmxlIGZvciBNTiAod2UgY2FuIGFzc3VtZSBIQSBJUA0KaXMgYWxzbyBhdmFpbGFibGUg aW4gUlJRKTo8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KVXNlciBuYW1lIGF0dHJpYnV0ZTogTU4gTkFJPC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1JVCBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5NTiBIb0EgYXR0cmli dXRlOiBNTiBIb0EgSVAgPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToNCkFyaWFsJz5IQSBJUCBhdHRyaWJ1dGU6IEhBIElQIGZyb20gUlJRIChpbnRlcmZhY2UgdG93 YXJkcyB0aGUgTU4sIG5vdCB0b3dhcmRzDQpBQUEpPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCk5BUyBJUCBhdHRyaWJ1 dGU6IElQIGFkZHJlc3Mgb2YgSEEgaW50ZXJmYWNlIHRvd2FyZHMgdGhlIEFBQSBzZXJ2ZXIgKHRo aXMNCnNob3VsZCBiZSBhIHJvdXRhYmxlIElQIGFkZHJlc3MpPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCk5BUyBJRDog RlFETiBmb3IgSEEsIGlmIGF2YWlsYWJsZTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+KElzc3VlOiBSRkMgMzM0NCBkb2VzIG5vdCBhc3N1 bWUgdGhhdCBib3RoIEhvQSBhbmQgTkFJIGFyZQ0KYXZhaWxhYmxlIGF0IHRoZSBzYW1lIHRpbWUu PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz5TZWUgc2VjdGlvbiAzLjY6IHdoZW4gTkFJIGlzIHVzZWQgSG9BIGlzIHNldCB0byAwLjAuMC4w KS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpB cmlhbCc+S0wmZ3Q7IEkgdGhpbmsgUlJRIGZpZWxkcyBzaG91bGQgYmUgbWFwcGVkIGRpcmVjdGx5 IHRvDQpSQURJVVMgQVZQcy4mbmJzcDsgU28gTkFJIC0mZ3Q7IHVzZXJuYW1lPC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIEhvQSBJUCAtJmd0OyBNTiBIb0ENCkFWUC4m bmJzcDsgRG9uJ3Qgc2V0IEhvQSB0byAwLjAuMC4wIGlmIGl0J3Mgbm90LiZuYnNwOyBUaGlzIGJp dCBvZiBpbmZvPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWlnaHQgYmUg dXNlZnVsIGZvciB0aGUNClJBRElVUyBzZXJ2ZXIuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxmb250IGNvbG9yPW5hdnk+PHNwYW4g c3R5bGU9J2NvbG9yOm5hdnknPk1hZGppZCZndDsmZ3Q7Tm90IHN1cmUNCmlmIEkgc2FpZCB3ZSBt YWtlIEhvQSB0byAwLjAuMC4wIGFueXdoZXJlPyBJIHdhcyBqdXN0IHF1b3RpbmcgdGhlIFJGQyAz MzQ0IGJlaGF2aW9yDQphcyBhIHBvdGVudGlhbCBpc3N1ZSBmb3IgdGhpcyBzY2VuYXJpby4gQnV0 IHRoYXQgbWF5IG5vdCBiZSBvdXIgcHJvYmxlbS4gV2UgYXJlDQpzaW1wbHkgcHJvdmlkaW5nIHN1 cHBvcnQgZm9yIGRpZmZlcmVudCBzY2VuYXJpby4gPC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmIpIElmIG9u bHkgTkFJIGlzIGF2YWlsYWJsZSBhbmQgbm8gSG9BIGlzIHByZXNlbnQgKEhBIElQIG1heQ0Kb3Ig bWF5IG5vdCBiZSBwcmVzZW50KS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVXNlciBuYW1lOiBNTiBOQUk8L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KTm8gTU4gSG9BIGF0dHJpYnV0ZSA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KSEEgSVAgYXR0cmlidXRlIChp ZiBwcmVzZW50KTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpOQVMgSVAgYXR0cmlidXRlOiBJUCBhZGRyZXNzIGZvciBI QSBpbnRlcmZhY2UgdG93YXJkcyB0aGUgQUFBIHNlcnZlcjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpOQVMgSUQ6IEZR RE4gZm9yIEhBLCBpZiBhdmFpbGFibGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+S0wmZ3Q7IEhvQSBmaWVsZCBpcyBhbHdheXMgaW4g UlJRLCBzbyAmcXVvdDtubyBIb0EgaXMNCnByZXNlbnQmcXVvdDsgZG9lc24ndCBtYWtlIHNlbnNl IHRvIG1lLiZuYnNwOyBQbHM8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl eHBsYWluPzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0zIGNvbG9yPW5hdnkgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6bmF2eSc+TWFkamlkJmd0OyZndDsgT2ssIEkgZ3Vlc3Mgd2hhdCBJ IG1lYW50DQpoZXJlIHdhcyB0aGUgUkZDIDMzNDQgYmVoYXZpb3IsIHdoZW4gTkFJIGlzIHByZXNl bnQsIHRoZSBNTiBhY2NvcmRpbmcgdG8gMzM0NA0Kc2V0cyB0aGUgSG9BIHRvIDAuMC4wLjAuIFlv dSBhcmUgcmlnaHQsIHdlIGJldHRlciBpbmNsdWRlIEhvQSBhcyBpdCBpcyBpbiBNTg0KSE9BIGFs d2F5cy4gSSBndWVzcyB0aGlzIHNpbXBsaWZpZXMgb3VyIGxpZmUsIHNpbmNlIGNhc2VzIGEgYW5k IGIgYXJlIG5vdyBvbmUuIDwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5jKSBJZiBvbmx5IEhvQSBpcyBwcmVzZW50IChIQSBJ UCBzaG91bGQgYmUgcHJlc2VudCBhcyB3ZWxsKQ0KYnV0IG5vIE5BSTwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpBQUEt cm91dGFiaWxpdHkgZm9yIG11bHRpLWRvbWFpbiByb2FtaW5nIGlzIG5vdCBwb3NzaWJsZTwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQpVc2VyIG5hbWU6IE1OIEZRRE4gaWYgYXZhaWxhYmxlPz8vIE1OIEhvQSBpZiBkZWVt ZWQgcm91dGFibGUgKCoqKik8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KTU4gSG9BOiBNTiBIb0E8L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUlUIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkhBIElQIGF0dHJpYnV0ZSAo ZnJvbSBSUlEpPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCkFy aWFsJz5OQVMgSVAgYXR0cmlidXRlOiBIQSBJUCBhZGRyZXNzIHRvd2FyZHMgdGhlIEFBQSBzZXJ2 ZXIpLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpB cmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQpOQVMgSUQ6IEZRRE4gZm9yIEhBLCBpZiBhdmFpbGFibGU8L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPioqKiBB dmkgc3VnZ2VzdGVkIHRvIHByb3ZpZGUgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBoZXJlPw0K V2hhdCBzaG91bGQgd2UgcmVjb21tZW5kPzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5LTCZndDsgVGhlIFVzZXItTmFtZSBBVlAgTVVT VCBiZSBpbiB0aGUNCkFjY2Vzcy1SZXF1ZXN0LiZuYnNwOyBUaGUgbGVuZ3RoIG9mIFN0cmluZyBm aWVsZCBtdXN0IGJlICZndDs9IDMuJm5ic3A7IFdoYXQNCmhhcHBlbnMgd2hlbiB0aGVyZSBpcyBu byBETlMgZW50cnkgZm9yIHRoZSBNTiB3aXRoIHByaXZhdGUgSG9BIElQDQphZGRyZXNzPyZuYnNw OyBIb3cgaXMgdGhlIFVzZXItTmFtZSBBVlAgcG9wdWxhdGVkPzwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPW5hdnkgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6bmF2eSc+Jm5i c3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+TWFkamlkJmd0OyZndDsgSSBhZ3JlZS4gVHdvIG9w dGlvbnMgaW4NCnRoaXMgY2FzZTogPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+MSkgaW5jbHVkZSBI b0EgaW4gVXNlci1OYW1lIChhcyBJIHNhaWQgaW4NCm15IHByZXZpb3VzIGVtYWlsKS4gSWYgSG9B IGlzIHJvdXRhYmxlIGZpbmUsIGlmIG5vdCBlaXRoZXIgSEEgbXVzdCBmaXggaXQsIG9yDQp0aGUg QUFBIHNlcnZlciByZWplY3RzIGl0Ljwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjIpIE5vdCBzdXJl IGlmIHdlIGNhbiBwdXQgemVyb3MgaW4NClVzZXItTmFtZSBhdHRyaWJ1dGU/PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkZvciBG QS1CYXNlZCBjYXNlOjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseTpBcmlhbCc+YSkgd2hlbiBib3RoIE1OIE5BSSBhbmQgTU4gSG9BIGFyZSBhdmFpbGFi bGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp YWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KVXNlciBuYW1lIGF0dHJpYnV0ZTogTU4gTkFJPC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCk1O IEhvQSBhdHRyaWJ1dGU6IE1OIEhvQSBJUCA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KSEEgSVAgYXR0cmlidXRlOiBI QSBJUCBmcm9tIFJSUSAoaW50ZXJmYWNlIHRvd2FyZHMgdGhlIE1OLCBub3QgdG93YXJkcyBBQUEp PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5LTCZndDsmbmJzcDtIQSBJUCBhZGRyZXNzIGluIFJS USBtYXkgYmUNCmFueSBpbnRlcmZhY2UgYWRkcmVzcyBvbiB0aGUgcm91dGVyL0hBLiZuYnNwOyBU aGlzIG1heSBiZSBhIGxvZ2ljYWwgaW50ZXJmYWNlDQpvciBoYXBwZW5zIHRvIGJlIHRoZSBzYW1l IGludGVyZmFjZSB0b3dhcmRzIEFBQS4mbmJzcDsgV2Ugc2hvdWxkIG5vdCBwcm9oaWJpdA0KYW55 IGludGVyZmFjZSBhcyBzdGF0ZWQgaW4gcGFyZW50aGVzaXMuPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpu YXZ5Jz5NYWRqaWQmZ3Q7Jmd0OyBBZ3JlZSwgbmVlZCB0byBjbGFyaWZ5IHRoZQ0Kc2VudGVuY2Ug aW4gdGhlIHdyaXRlIHVwLiBIb3cgYWJvdXQsIHRoZSBmb2xsb3dpbmcgaW4gdGhlIE1vYmlsZSBJ UA0KcmVxdWlyZW1lbnRzIHNlY3Rpb24/PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SW4gY2FzZSB0 aGUgSEEgaXMgdXNpbmcgZGlmZmVyZW50DQppbnRlcmZhY2VzIHRvd2FyZHMgdGhlIE1OIGFuZCBB QUEgc2VydmVyLCBjYXJlIG11c3QgYmUgdGFrZW4gc28gdGhhdCBIQSBJUA0KaW5jbHVkZXMgdGhl IElQIGFkZHJlc3MgdXNlZCBpbiBSUlEgYW5kIE5BUyBJUCBpbmNsdWRlcyB0aGUgYWRkcmVzcyB1 c2VkIGluIEFBQQ0Kc2lnbmFsaW5nLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5i c3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy aWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCk5BUyBJUCBhdHRyaWJ1dGU6IEZBIElQIGFkZHJlc3MgdG93YXJkcyB0 aGUgQUFBIHNlcnZlciAodGhpcyBzaG91bGQgYmUgYQ0Kcm91dGFibGUgSVAgYWRkcmVzcyk8L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDou NWluJz48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWwnPk5BUyBJRDogRlFETiBmb3IgRkEsIGlmIGF2YWlsYWJsZTwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz5LTCZndDsgRm9yIEZBIGNhc2UsIGFyZSB3ZSB0YWxraW5nIGFib3V0IEZBLUFBQSBvciBIQS1B QUENCmludGVyYWN0aW9uPyZuYnNwOyBJIHRoaW5rIHdlIG5lZWQgdG8gY292ZXIgYm90aCBzY2Vu YXJpb3MuJm5ic3A7IFRoZSBOQVMgSVANCkFWUCBpcyBzZXQgdG8gdGhlIEhBL0ZBIElQIGFkZHJl c3MgdG93YXJkcyB0aGUgQUFBIHNlcnZlci48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPk1hZGpp ZCZndDsmZ3Q7IHRoaXMgcGFydCBpcyBhYm91dCBGQS1BQUEuPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmIpIElmIG9ubHkgTkFJIGlz IGF2YWlsYWJsZSBhbmQgbm8gSG9BIGlzIHByZXNlbnQgKEhBIElQIG1heQ0Kb3IgbWF5IG5vdCBi ZSBwcmVzZW50KS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVXNlciBuYW1lOiBNTiBOQUk8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KTm8g TU4gSG9BIGF0dHJpYnV0ZSA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KSEEgSVAgYXR0cmlidXRlIChpZiBwcmVzZW50 IGluIFJSUSk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KTkFTIElQIGF0dHJpYnV0ZTogSVAgYWRkcmVzcyBmb3IgRkEg aW50ZXJmYWNlIHRvd2FyZHMgdGhlIEFBQSBzZXJ2ZXI8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDouNWluJz48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwn Pk5BUyBJRDogRlFETiBmb3IgRkEsIGlmIGF2YWlsYWJsZTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5LTCZndDsgU2FtZSBhcyBhYm92 ZSwgbWVhbmluZyBvZiAmcXVvdDtubyBIb0EmcXVvdDs/PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPmMpIElmIG9ubHkgSG9BIGlzIHBy ZXNlbnQgKEhBIElQIHNob3VsZCBiZSBwcmVzZW50IGFzIHdlbGwpDQpidXQgbm8gTkFJPC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCkFBQS1yb3V0YWJpbGl0eSBmb3IgbXVsdGktZG9tYWluIHJvYW1pbmcgaXMgbm90IHBv c3NpYmxlPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OkFyaWFsJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClVzZXIgbmFtZTogTU4gRlFETiBpZiBhdmFpbGFibGU/Py8gTU4g SG9BIGlmIGRlZW1lZCByb3V0YWJsZSAoKioqKTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpNTiBIb0E6IE1OIEhvQTwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIGxh bmc9SVQgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+SEEgSVAg YXR0cmlidXRlIChmcm9tIFJSUSk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9SVQgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxm b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Og0KQXJpYWwnPk5BUyBJUCBhdHRyaWJ1dGU6IEZBIElQIGFkZHJlc3MgdG93YXJkcyB0 aGUgQUFBIHNlcnZlcikuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0ndGV4dC1pbmRlbnQ6LjVpbic+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5OQVMgSUQ6IEZRRE4gZm9y IEZBLCBpZiBhdmFpbGFibGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseTpBcmlhbCc+KioqIEF2aSBzdWdnZXN0ZWQgdG8gcHJvdmlkZSBndWlkYW5j ZSBmb3IgaW1wbGVtZW50ZXJzIGhlcmU/DQpXaGF0IHNob3VsZCB3ZSByZWNvbW1lbmQ/PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+S2VudDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8L2Rpdj4NCg0KPC9ib2R5 Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C557CB.1F5F831C-- --===============2087836601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2087836601==-- From mip4-bounces@ietf.org Fri May 13 11:17:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbul-0004fq-RU; Fri, 13 May 2005 11:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbuk-0004fl-9V for mip4@megatron.ietf.org; Fri, 13 May 2005 11:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23946 for ; Fri, 13 May 2005 11:17:19 -0400 (EDT) Received: from wsip-68-101-41-112.dc.dc.cox.net ([68.101.41.112] helo=email-filesrv) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWcAh-0003Di-3d for mip4@ietf.org; Fri, 13 May 2005 11:33:51 -0400 Received: from [198.57.19.100] by email-filesrv (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.7)); Fri, 13 May 2005 10:48:33 -0400 Message-ID: <001901c557ce$e4bb0b30$2101a8c0@us.nextel.com> From: "Qiang Zhang/Aber" To: "Nakhjiri Madjid-MNAKHJI1" , "'Chowdhury, Kuntal'" , , References: Subject: Re: [Mip4] RE: resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 11:17:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.9 (++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, Madjid, a couple comments.. thanks NAT Traversal is a fairly common practice and MN usually doesn't have a routable HoA. In addition, I have impression by reading below that User-Name AVP is being restricted to use HoA or FQDN for MIP, (ignore this if I got it wrong), in many cases that the user-name should not be limited to HoA or FQDN , for example, it can be a MSISDN or any sort of identifier that is compliant with RADIUS user-name AVP. Qiang > > It seems that we have to have the User-name attribute populated before sending an Access Request on behalf of the MN. Avi seemed to have issues with putting an non-routable HoA in User-name. The reasoning is understandable, however, as you said we cannot fix MN implementation problems here, unless somebody on this list tells me there is a legitimate reason for the MN using a non-routable HoA (NAT-traversal?). > I think we should simply not support NAT traversal at this point. > > For case C) where no NAI is available, we should accept > User-Name=HOA > MN-HoA=HoA > The HA simply creates the Access Request and sends it to AAA server. I don't think we can modify the RFC 3344 behavior of HA here. It is not within our scope. If NAT traversal drafts define a behavior for HA to change the non-routable HoA to routable one, then the HA may insert the routable address inside the MN-HoA or something. I don't think we should deal with that now. We can provide some recommendation. The AAA server examining these two fields will recognize that MN did not have an NAI and if HoA is unrecognizable it will reject the request. > > If you guys are ok with this, I will add some text in that effect. > > Madjid > ----- > Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Friday, May 13, 2005 12:53 AM > To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com; avi@bridgewatersystems.com > Cc: mip4@ietf.org > Subject: Re: resolution of RADIUS-MIP identifier issues?? > > Madjid, > > Good sunnary. I am still not clear about the case when the MN sends a RRQ with a non routable HoA but does not include NAI extension. What should be in the username attribute in that case? We can't assume that the MN FQDN can be drived. So, there won't be anything to identify the user. Why can't we assume that the HA rejects such RRQs (poorly formed RRQ)? It does not make sense to go through hoops to accomodate nasty MN implementations, IMHO. > > Regarding the need for the inclusion of CoA in the Access-Request, I think it is optional for the FA and the HA to include it, but it is good to have. > > -Kuntal > > > -------------------------- > Sent from my BlackBerry Wireless Handheld > > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 > To: Nakhjiri Madjid-MNAKHJI1 ; Kent Leung ; Avi Lior ; Chowdhury, Kuntal > CC: Mobile IPv4 Mailing List > Sent: Thu May 12 15:40:23 2005 > Subject: resolution of RADIUS-MIP identifier issues?? > > Sorry for the long delay on this. I looked at all the email and tried to see the convergence. > > Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. > > It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. > > > > Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. > > > > Madjid > > > > > > Attributes we discussed: > > MN HoA, MN NAI, HA IP, NAS ID, user name > > Not sure why Avi brought up the MN CoA attribute? We did not have that originally? > > The home AAA or HA don't know CoA anyway, so not sure what is used for? > > > > CcoA case: there is no FA, HA acts as NAS > > > > > > a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): > > User name attribute: MN NAI > > MN HoA attribute: MN HoA IP > > HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) > > NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) > > NAS ID: FQDN for HA, if available > > (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. > > See section 3.6: when NAI is used HoA is set to 0.0.0.0). > > > > b) If only NAI is available and no HoA is present (HA IP may or may not be present). > > User name: MN NAI > > No MN HoA attribute > > HA IP attribute (if present) > > NAS IP attribute: IP address for HA interface towards the AAA server > > NAS ID: FQDN for HA, if available > > > > c) If only HoA is present (HA IP should be present as well) but no NAI > > AAA-routability for multi-domain roaming is not possible > > User name: MN FQDN if available??/ MN HoA if deemed routable (***) > > MN HoA: MN HoA > > HA IP attribute (from RRQ) > > NAS IP attribute: HA IP address towards the AAA server). > > NAS ID: FQDN for HA, if available > > *** Avi suggested to provide guidance for implementers here? What should we recommend? > > > > > > For FA-Based case: > > a) when both MN NAI and MN HoA are available > > User name attribute: MN NAI > > MN HoA attribute: MN HoA IP > > HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) > > NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) > > NAS ID: FQDN for FA, if available > > > > > > b) If only NAI is available and no HoA is present (HA IP may or may not be present). > > User name: MN NAI > > No MN HoA attribute > > HA IP attribute (if present in RRQ) > > NAS IP attribute: IP address for FA interface towards the AAA server > > NAS ID: FQDN for FA, if available > > > > > > c) If only HoA is present (HA IP should be present as well) but no NAI > > AAA-routability for multi-domain roaming is not possible > > User name: MN FQDN if available??/ MN HoA if deemed routable (***) > > MN HoA: MN HoA > > HA IP attribute (from RRQ) > > NAS IP attribute: FA IP address towards the AAA server). > > NAS ID: FQDN for FA, if available > > > > *** Avi suggested to provide guidance for implementers here? What should we recommend? > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 11:34:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcAq-0007N8-SD; Fri, 13 May 2005 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcAp-0007N3-49 for mip4@megatron.ietf.org; Fri, 13 May 2005 11:33:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24811 for ; Fri, 13 May 2005 11:33:55 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWcQg-0003rx-2r for mip4@ietf.org; Fri, 13 May 2005 11:50:28 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j4DFhQ7P021660 for ; Fri, 13 May 2005 08:43:26 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j4DFb0cE028269 for ; Fri, 13 May 2005 10:37:00 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 10:33:50 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Qiang Zhang/Aber'" , "'Chowdhury, Kuntal'" , kleung@cisco.com, avi@bridgewatersystems.com Subject: RE: [Mip4] RE: resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 10:33:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Qiang, Thanks for the email. We are not limiting the usage of user-name to anything. Our main concern is that User-Name is really something that must be understood by the AAA infrastructure. The point is whether we have to provide a solution for every case here or not. I don't think we should. If AAA server does not recognize the User-Name, it will simply reject the request. Madjid -----Original Message----- From: Qiang Zhang/Aber [mailto:qzhang@aber-networks.net] Sent: Friday, May 13, 2005 10:18 AM To: Nakhjiri Madjid-MNAKHJI1; 'Chowdhury, Kuntal'; kleung@cisco.com; avi@bridgewatersystems.com Cc: mip4@ietf.org Subject: Re: [Mip4] RE: resolution of RADIUS-MIP identifier issues?? Hi, Madjid, a couple comments.. thanks NAT Traversal is a fairly common practice and MN usually doesn't have a routable HoA. In addition, I have impression by reading below that User-Name AVP is being restricted to use HoA or FQDN for MIP, (ignore this if I got it wrong), in many cases that the user-name should not be limited to HoA or FQDN , for example, it can be a MSISDN or any sort of identifier that is compliant with RADIUS user-name AVP. Qiang > > It seems that we have to have the User-name attribute populated before sending an Access Request on behalf of the MN. Avi seemed to have issues with putting an non-routable HoA in User-name. The reasoning is understandable, however, as you said we cannot fix MN implementation problems here, unless somebody on this list tells me there is a legitimate reason for the MN using a non-routable HoA (NAT-traversal?). > I think we should simply not support NAT traversal at this point. > > For case C) where no NAI is available, we should accept > User-Name=HOA > MN-HoA=HoA > The HA simply creates the Access Request and sends it to AAA server. I don't think we can modify the RFC 3344 behavior of HA here. It is not within our scope. If NAT traversal drafts define a behavior for HA to change the non-routable HoA to routable one, then the HA may insert the routable address inside the MN-HoA or something. I don't think we should deal with that now. We can provide some recommendation. The AAA server examining these two fields will recognize that MN did not have an NAI and if HoA is unrecognizable it will reject the request. > > If you guys are ok with this, I will add some text in that effect. > > Madjid > ----- > Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Friday, May 13, 2005 12:53 AM > To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com; avi@bridgewatersystems.com > Cc: mip4@ietf.org > Subject: Re: resolution of RADIUS-MIP identifier issues?? > > Madjid, > > Good sunnary. I am still not clear about the case when the MN sends a RRQ with a non routable HoA but does not include NAI extension. What should be in the username attribute in that case? We can't assume that the MN FQDN can be drived. So, there won't be anything to identify the user. Why can't we assume that the HA rejects such RRQs (poorly formed RRQ)? It does not make sense to go through hoops to accomodate nasty MN implementations, IMHO. > > Regarding the need for the inclusion of CoA in the Access-Request, I think it is optional for the FA and the HA to include it, but it is good to have. > > -Kuntal > > > -------------------------- > Sent from my BlackBerry Wireless Handheld > > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 > To: Nakhjiri Madjid-MNAKHJI1 ; Kent Leung ; Avi Lior ; Chowdhury, Kuntal > CC: Mobile IPv4 Mailing List > Sent: Thu May 12 15:40:23 2005 > Subject: resolution of RADIUS-MIP identifier issues?? > > Sorry for the long delay on this. I looked at all the email and tried to see the convergence. > > Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. > > It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. > > > > Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. > > > > Madjid > > > > > > Attributes we discussed: > > MN HoA, MN NAI, HA IP, NAS ID, user name > > Not sure why Avi brought up the MN CoA attribute? We did not have that originally? > > The home AAA or HA don't know CoA anyway, so not sure what is used for? > > > > CcoA case: there is no FA, HA acts as NAS > > > > > > a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): > > User name attribute: MN NAI > > MN HoA attribute: MN HoA IP > > HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) > > NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) > > NAS ID: FQDN for HA, if available > > (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. > > See section 3.6: when NAI is used HoA is set to 0.0.0.0). > > > > b) If only NAI is available and no HoA is present (HA IP may or may not be present). > > User name: MN NAI > > No MN HoA attribute > > HA IP attribute (if present) > > NAS IP attribute: IP address for HA interface towards the AAA server > > NAS ID: FQDN for HA, if available > > > > c) If only HoA is present (HA IP should be present as well) but no NAI > > AAA-routability for multi-domain roaming is not possible > > User name: MN FQDN if available??/ MN HoA if deemed routable (***) > > MN HoA: MN HoA > > HA IP attribute (from RRQ) > > NAS IP attribute: HA IP address towards the AAA server). > > NAS ID: FQDN for HA, if available > > *** Avi suggested to provide guidance for implementers here? What should we recommend? > > > > > > For FA-Based case: > > a) when both MN NAI and MN HoA are available > > User name attribute: MN NAI > > MN HoA attribute: MN HoA IP > > HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) > > NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) > > NAS ID: FQDN for FA, if available > > > > > > b) If only NAI is available and no HoA is present (HA IP may or may not be present). > > User name: MN NAI > > No MN HoA attribute > > HA IP attribute (if present in RRQ) > > NAS IP attribute: IP address for FA interface towards the AAA server > > NAS ID: FQDN for FA, if available > > > > > > c) If only HoA is present (HA IP should be present as well) but no NAI > > AAA-routability for multi-domain roaming is not possible > > User name: MN FQDN if available??/ MN HoA if deemed routable (***) > > MN HoA: MN HoA > > HA IP attribute (from RRQ) > > NAS IP attribute: FA IP address towards the AAA server). > > NAS ID: FQDN for FA, if available > > > > *** Avi suggested to provide guidance for implementers here? What should we recommend? > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 11:43:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcJf-0000C0-5n; Fri, 13 May 2005 11:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWcJd-0000Bo-2Z for mip4@megatron.ietf.org; Fri, 13 May 2005 11:43:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25325 for ; Fri, 13 May 2005 11:43:02 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWcZZ-0004Bd-HS for mip4@ietf.org; Fri, 13 May 2005 11:59:34 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 11:42:54 -0400 Message-ID: From: Avi Lior To: "'Kent Leung (kleung)'" , Nakhjiri Madjid-MNAKHJI1 , Avi Lior , "Chowdhury, Kuntal" Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 11:42:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 12866e56e287fcb9ed724727fee710b4 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0633493018==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0633493018== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C557D2.6D02DCE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C557D2.6D02DCE0 Content-Type: text/plain We need to clear this up first: 2865 Does not mandate the user-name is required in Access-Request. Here are the appropriate snippets..... Section 4.1 Access-Request ..... An Access-Request SHOULD contain a User-Name attribute. Section 5.1 User-Name User-Name Description This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. Here is the entry in the table. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name And here is what 2865 says about routing: The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm"). So here is the table of attributes. (This hopefully simplifies the summary) RADIUS MIP ------------ ----- User-Name <--- MN-NAI-Extension (see note below) MN_HOA <--- HOA (if available) HA_IP <---- HA_IP (if available) NAS_IP <----- as per RADIUS. NAS_ID <----- as per RADIUS. The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP. If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. [NOTE we need to check the NAI bible] see more inline -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Friday, May 13, 2005 4:16 AM To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Hi Madjid. My comment below in "KL>". _____ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Thursday, May 12, 2005 1:40 PM To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury, Kuntal' Cc: Mobile IPv4 Mailing List Subject: [Mip4] resolution of RADIUS-MIP identifier issues?? Sorry for the long delay on this. I looked at all the email and tried to see the convergence. Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA. It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT. Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version. Madjid Attributes we discussed: MN HoA, MN NAI, HA IP, NAS ID, user name Not sure why Avi brought up the MN CoA attribute? We did not have that originally? The home AAA or HA don't know CoA anyway, so not sure what is used for? CcoA case: there is no FA, HA acts as NAS a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ): User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address) NAS ID: FQDN for HA, if available (Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time. See section 3.6: when NAI is used HoA is set to 0.0.0.0). KL> I think RRQ fields should be mapped directly to RADIUS AVPs. So NAI -> username and HoA IP -> MN HoA AVP. Don't set HoA to 0.0.0.0 if it's not. This bit of info might be useful for the RADIUS server. b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present) NAS IP attribute: IP address for HA interface towards the AAA server NAS ID: FQDN for HA, if available KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to me. Pls explain? c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: HA IP address towards the AAA server). NAS ID: FQDN for HA, if available [Avi] We shouldnt specify what is in NAS ID other then what is already recommended by RADIUS. You can say it should be the FQDN but you must not mandate it. So I belive that standard RADIUS definition is sufficient. *** Avi suggested to provide guidance for implementers here? What should we recommend? KL> The User-Name AVP MUST be in the Access-Request. The length of String field must be >= 3. What happens when there is no DNS entry for the MN with private HoA IP address? How is the User-Name AVP populated? [Avi] No. That is wrong as shown above. For FA-Based case: a) when both MN NAI and MN HoA are available User name attribute: MN NAI MN HoA attribute: MN HoA IP HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA) KL> HA IP address in RRQ may be any interface address on the router/HA. This may be a logical interface or happens to be the same interface towards AAA. We should not prohibit any interface as stated in parenthesis. NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address) NAS ID: FQDN for FA, if available KL> For FA case, are we talking about FA-AAA or HA-AAA interaction? I think we need to cover both scenarios. The NAS IP AVP is set to the HA/FA IP address towards the AAA server. b) If only NAI is available and no HoA is present (HA IP may or may not be present). User name: MN NAI No MN HoA attribute HA IP attribute (if present in RRQ) NAS IP attribute: IP address for FA interface towards the AAA server NAS ID: FQDN for FA, if available KL> Same as above, meaning of "no HoA"? c) If only HoA is present (HA IP should be present as well) but no NAI AAA-routability for multi-domain roaming is not possible User name: MN FQDN if available??/ MN HoA if deemed routable (***) MN HoA: MN HoA HA IP attribute (from RRQ) NAS IP attribute: FA IP address towards the AAA server). NAS ID: FQDN for FA, if available *** Avi suggested to provide guidance for implementers here? What should we recommend? Kent ------_=_NextPart_001_01C557D2.6D02DCE0 Content-Type: text/html Message
We need to clear this up first:
 
2865 Does not mandate the user-name is required in Access-Request.
 
Here are the appropriate snippets.....
 
Section 4.1 Access-Request
..... An Access-Request SHOULD contain a User-Name attribute.
 
Section 5.1 User-Name
 
User-Name
 
   Description
 
      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.
 
Here is the entry in the table.
 Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name
 
And here is what 2865 says about routing:
The User-Name
   attribute MAY contain a Network Access Identifier [8] for RADIUS
   Proxy operations.  The choice of which server receives the forwarded
   request SHOULD be based on the authentication "realm". The
   authentication realm MAY be the realm part of a Network Access
   Identifier (a "named realm").  Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").
 
 
So here is the table of attributes.  (This hopefully simplifies the summary)
 
RADIUS     MIP
------------     -----
User-Name <--- MN-NAI-Extension (see note below)
MN_HOA   <--- HOA (if available)
HA_IP       <---- HA_IP (if available)
NAS_IP    <----- as per RADIUS.
NAS_ID    <----- as per RADIUS.
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank.  If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP.  [NOTE we need to check the NAI bible]
 
 
see more inline
-----Original Message-----
From: Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Friday, May 13, 2005 4:16 AM
To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

Hi Madjid.  My comment below in "KL>".

From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri Madjid-MNAKHJI1
Sent: Thursday, May 12, 2005 1:40 PM
To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury, Kuntal'
Cc: Mobile IPv4 Mailing List
Subject: [Mip4] resolution of RADIUS-MIP identifier issues??

Sorry for the long delay on this. I looked at all the email and tried to see the convergence.

Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA.

It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT.

 

Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version.

 

Madjid

 

 

Attributes we discussed:

MN HoA, MN NAI, HA IP, NAS ID, user name

Not sure why Avi brought up the MN CoA attribute? We did not have that originally?

The home AAA or HA don't know CoA anyway, so not sure what is used for?

 

CcoA case: there is no FA, HA acts as NAS

 

 

a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ):

            User name attribute: MN NAI

            MN HoA attribute: MN HoA IP

            HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA)

            NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address)

            NAS ID: FQDN for HA, if available

(Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time.

See section 3.6: when NAI is used HoA is set to 0.0.0.0).

 

KL> I think RRQ fields should be mapped directly to RADIUS AVPs.  So NAI -> username

       and HoA IP -> MN HoA AVP.  Don't set HoA to 0.0.0.0 if it's not.  This bit of info

       might be useful for the RADIUS server.

 

 

b) If only NAI is available and no HoA is present (HA IP may or may not be present).

            User name: MN NAI

            No MN HoA attribute

            HA IP attribute (if present)

            NAS IP attribute: IP address for HA interface towards the AAA server

            NAS ID: FQDN for HA, if available

 

KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to me.  Pls

       explain?

 

 

c) If only HoA is present (HA IP should be present as well) but no NAI

            AAA-routability for multi-domain roaming is not possible

            User name: MN FQDN if available??/ MN HoA if deemed routable (***)

            MN HoA: MN HoA

            HA IP attribute (from RRQ)

            NAS IP attribute: HA IP address towards the AAA server).

            NAS ID: FQDN for HA, if available
[Avi] We shouldnt specify what is in NAS ID other then what is already recommended by RADIUS. You can say it should be the FQDN but you must not mandate it.  So I belive that standard RADIUS definition is sufficient.

 

*** Avi suggested to provide guidance for implementers here? What should we recommend?

 

KL> The User-Name AVP MUST be in the Access-Request.  The length of String field must be >= 3.  What happens when there is no DNS entry for the MN with private HoA IP address?  How is the User-Name AVP populated?
[Avi] No.  That is wrong as shown above. 

 

For FA-Based case:

a) when both MN NAI and MN HoA are available

            User name attribute: MN NAI

            MN HoA attribute: MN HoA IP

            HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA)

 

KL> HA IP address in RRQ may be any interface address on the router/HA.  This may be a logical interface or happens to be the same interface towards AAA.  We should not prohibit any interface as stated in parenthesis.

 

 

            NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address)

NAS ID: FQDN for FA, if available

 

KL> For FA case, are we talking about FA-AAA or HA-AAA interaction?  I think we need to cover both scenarios.  The NAS IP AVP is set to the HA/FA IP address towards the AAA server.

 

 

b) If only NAI is available and no HoA is present (HA IP may or may not be present).

            User name: MN NAI

            No MN HoA attribute

            HA IP attribute (if present in RRQ)

            NAS IP attribute: IP address for FA interface towards the AAA server

NAS ID: FQDN for FA, if available

 

KL> Same as above, meaning of "no HoA"?

 

c) If only HoA is present (HA IP should be present as well) but no NAI

            AAA-routability for multi-domain roaming is not possible

            User name: MN FQDN if available??/ MN HoA if deemed routable (***)

            MN HoA: MN HoA

            HA IP attribute (from RRQ)

            NAS IP attribute: FA IP address towards the AAA server).

NAS ID: FQDN for FA, if available

 

*** Avi suggested to provide guidance for implementers here? What should we recommend?

Kent 

------_=_NextPart_001_01C557D2.6D02DCE0-- --===============0633493018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0633493018==-- From mip4-bounces@ietf.org Fri May 13 13:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdZE-0008B3-Ep; Fri, 13 May 2005 13:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWdZC-00088C-BW for mip4@megatron.ietf.org; Fri, 13 May 2005 13:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05224 for ; Fri, 13 May 2005 13:03:11 -0400 (EDT) Received: from ames.starentnetworks.com ([12.33.235.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWdp9-0007vx-W8 for mip4@ietf.org; Fri, 13 May 2005 13:19:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 13:02:58 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D8FD5@ames.starentnetworks.com> Thread-Topic: resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVXyasnRQ1NwnTpTJGTpew0ruM0RAAETqmg From: "Chowdhury, Kuntal" To: "Nakhjiri Madjid-MNAKHJI1" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org Subject: [Mip4] RE: resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Madjid, Rejecting a poorly formed RRQ is not a protocol violation. If the user = uses a private IP address as HoA and does not include NAI extension, it = is entirely upto the HA provider's policy to accept or reject the = registration request. If the provider's network is setup with = non-overlapping private IP addresses and these private addresses can be = mapped to unique usernames, then the HA MAY process the request by = setting username=3DHoA. Otherwise, the HA SHOULD reject the request as = the user cannot be uniquely identified. I think we need to clarify the = HA behavior on this line. BTW, support of private IP address (private HoA) at the HA does not = necessarily mean that the HA has NAT traversal support. HAs are deployed = with overlapping private IP address pools for different enterprises. = Such traffic are tunneled to/from the enterprise via the HA. The NAT can = be somewhere in the enterprise. -Kuntal > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, May 13, 2005 9:40 AM > To: Chowdhury, Kuntal; kleung@cisco.com; avi@bridgewatersystems.com > Cc: mip4@ietf.org > Subject: RE: resolution of RADIUS-MIP identifier issues?? >=20 >=20 > Hi Kuntal, >=20 > It seems that we have to have the User-name attribute=20 > populated before sending an Access Request on behalf of the=20 > MN. Avi seemed to have issues with putting an non-routable=20 > HoA in User-name. The reasoning is understandable, however,=20 > as you said we cannot fix MN implementation problems here,=20 > unless somebody on this list tells me there is a legitimate=20 > reason for the MN using a non-routable HoA (NAT-traversal?). > I think we should simply not support NAT traversal at this point. >=20 > For case C) where no NAI is available, we should accept=20 > User-Name=3DHOA > MN-HoA=3DHoA > The HA simply creates the Access Request and sends it to AAA=20 > server. I don't think we can modify the RFC 3344 behavior of=20 > HA here. It is not within our scope. If NAT traversal drafts=20 > define a behavior for HA to change the non-routable HoA to=20 > routable one, then the HA may insert the routable address=20 > inside the MN-HoA or something. I don't think we should deal=20 > with that now. We can provide some recommendation. The AAA=20 > server examining these two fields will recognize that MN did=20 > not have an NAI and if HoA is unrecognizable it will reject=20 > the request. >=20 > If you guys are ok with this, I will add some text in that effect. >=20 > Madjid > ----- > Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Friday, May 13, 2005 12:53 AM > To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com;=20 > avi@bridgewatersystems.com > Cc: mip4@ietf.org > Subject: Re: resolution of RADIUS-MIP identifier issues?? >=20 > Madjid,=20 >=20 > Good sunnary. I am still not clear about the case when the MN=20 > sends a RRQ with a non routable HoA but does not include NAI=20 > extension. What should be in the username attribute in that=20 > case? We can't assume that the MN FQDN can be drived. So,=20 > there won't be anything to identify the user. Why can't we=20 > assume that the HA rejects such RRQs (poorly formed RRQ)? It=20 > does not make sense to go through hoops to accomodate nasty=20 > MN implementations, IMHO. >=20 > Regarding the need for the inclusion of CoA in the=20 > Access-Request, I think it is optional for the FA and the HA=20 > to include it, but it is good to have.=20 >=20 > -Kuntal >=20 >=20 > -------------------------- > Sent from my BlackBerry Wireless Handheld >=20 >=20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 > To: Nakhjiri Madjid-MNAKHJI1 ;=20 > Kent Leung ; Avi Lior=20 > ; Chowdhury, Kuntal=20 > > CC: Mobile IPv4 Mailing List > Sent: Thu May 12 15:40:23 2005 > Subject: resolution of RADIUS-MIP identifier issues?? >=20 > Sorry for the long delay on this. I looked at all the email=20 > and tried to see the convergence. >=20 > Most of the cases seem to be straightforward: put NAI in user=20 > name and IP address in HoA. >=20 > It seems that the main issue is when HoA is available but NAI=20 > is not and the AAA infrastructure (mainly NAS) may not trust=20 > HoA routability enough to put it in user name when NAI is not=20 > there. Avi suggested we come up with some guidance for=20 > implementers, I am not quite sure if I came up with anything.=20 > Kuntal suggested a DNS lookup. Maybe we can include that in=20 > RADIUS routing requirement section, so that we can deal with=20 > it when this draft gets to RADEXT. >=20 > =20 >=20 > Anyway, before you fire away at my statements above, please=20 > look at the following summary and if you deem it to be=20 > adequate. I will make the changes to the draft accordingly=20 > and fire away a new version. >=20 > =20 >=20 > Madjid >=20 > =20 >=20 > =20 >=20 > Attributes we discussed: >=20 > MN HoA, MN NAI, HA IP, NAS ID, user name >=20 > Not sure why Avi brought up the MN CoA attribute? We did not=20 > have that originally? >=20 > The home AAA or HA don't know CoA anyway, so not sure what is=20 > used for? >=20 > =20 >=20 > CcoA case: there is no FA, HA acts as NAS >=20 > =20 >=20 > =20 >=20 > a) If both NAI and HoA available for MN (we can assume HA IP=20 > is also available in RRQ): >=20 > User name attribute: MN NAI >=20 > MN HoA attribute: MN HoA IP=20 >=20 > HA IP attribute: HA IP from RRQ (interface=20 > towards the MN, not towards AAA) >=20 > NAS IP attribute: IP address of HA interface=20 > towards the AAA server (this should be a routable IP address) >=20 > NAS ID: FQDN for HA, if available >=20 > (Issue: RFC 3344 does not assume that both HoA and NAI are=20 > available at the same time. >=20 > See section 3.6: when NAI is used HoA is set to 0.0.0.0). >=20 > =20 >=20 > b) If only NAI is available and no HoA is present (HA IP may=20 > or may not be present). >=20 > User name: MN NAI >=20 > No MN HoA attribute=20 >=20 > HA IP attribute (if present) >=20 > NAS IP attribute: IP address for HA interface=20 > towards the AAA server >=20 > NAS ID: FQDN for HA, if available >=20 > =20 >=20 > c) If only HoA is present (HA IP should be present as well) but no NAI >=20 > AAA-routability for multi-domain roaming is not possible >=20 > User name: MN FQDN if available??/ MN HoA if=20 > deemed routable (***) >=20 > MN HoA: MN HoA >=20 > HA IP attribute (from RRQ) >=20 > NAS IP attribute: HA IP address towards the AAA server). >=20 > NAS ID: FQDN for HA, if available >=20 > *** Avi suggested to provide guidance for implementers here?=20 > What should we recommend? >=20 > =20 >=20 > =20 >=20 > For FA-Based case: >=20 > a) when both MN NAI and MN HoA are available >=20 > User name attribute: MN NAI >=20 > MN HoA attribute: MN HoA IP=20 >=20 > HA IP attribute: HA IP from RRQ (interface=20 > towards the MN, not towards AAA) >=20 > NAS IP attribute: FA IP address towards the AAA=20 > server (this should be a routable IP address) >=20 > NAS ID: FQDN for FA, if available >=20 > =20 >=20 > =20 >=20 > b) If only NAI is available and no HoA is present (HA IP may=20 > or may not be present). >=20 > User name: MN NAI >=20 > No MN HoA attribute=20 >=20 > HA IP attribute (if present in RRQ) >=20 > NAS IP attribute: IP address for FA interface=20 > towards the AAA server >=20 > NAS ID: FQDN for FA, if available >=20 > =20 >=20 > =20 >=20 > c) If only HoA is present (HA IP should be present as well) but no NAI >=20 > AAA-routability for multi-domain roaming is not possible >=20 > User name: MN FQDN if available??/ MN HoA if=20 > deemed routable (***) >=20 > MN HoA: MN HoA >=20 > HA IP attribute (from RRQ) >=20 > NAS IP attribute: FA IP address towards the AAA server). >=20 > NAS ID: FQDN for FA, if available >=20 > =20 >=20 > *** Avi suggested to provide guidance for implementers here?=20 > What should we recommend? >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 16:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgRj-0002vb-0q; Fri, 13 May 2005 16:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgRi-0002vR-0R for mip4@megatron.ietf.org; Fri, 13 May 2005 16:07:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29114 for ; Fri, 13 May 2005 16:07:39 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWghf-0000ig-9e for mip4@ietf.org; Fri, 13 May 2005 16:24:13 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 May 2005 13:07:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4DK7ArO011669; Fri, 13 May 2005 13:07:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 13:07:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 13:07:24 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52285705@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVX0oMsWaNZfWg8SSWbrGl+Gkce7wADhg3g From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Nakhjiri Madjid-MNAKHJI1" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 13 May 2005 20:07:25.0532 (UTC) FILETIME=[619069C0:01C557F7] X-Spam-Score: 0.3 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331633261==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0331633261== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C557F7.58134EEA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C557F7.58134EEA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avi. Comments below in "KL>". ________________________________ From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Friday, May 13, 2005 8:43 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? =09 =09 =09 We need to clear this up first: =20 2865 Does not mandate the user-name is required in Access-Request. =20 KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC. =20 =20 =20 =20 Here are the appropriate snippets..... =20 Section 4.1 Access-Request ..... An Access-Request SHOULD contain a User-Name attribute. =20 Section 5.1 User-Name =20 User-Name =20 Description =20 This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. =20 Here is the entry in the table. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name =20 KL> OK, User-Name AVP may be not in the messages. =20 =20 And here is what 2865 says about routing: The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm"). =20 KL> OK =20 So here is the table of attributes. (This hopefully simplifies the summary) =20 RADIUS MIP ------------ ----- User-Name <--- MN-NAI-Extension (see note below) MN_HOA <--- HOA (if available) HA_IP <---- HA_IP (if available) NAS_IP <----- as per RADIUS. NAS_ID <----- as per RADIUS. =20 The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank.=20 =20 KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >=3D 3 octets. =20 =20 If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP. If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. [NOTE we need to check the NAI bible] =20 =20 see more inline =20 =20 Kent ------_=_NextPart_001_01C557F7.58134EEA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Avi.  Comments below in=20 "KL>".

From: Avi Lior=20 [mailto:avi@bridgewatersystems.com]
Sent: Friday, May 13, = 2005 8:43=20 AM
To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi = Lior;=20 Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing = List
Subject:=20 RE: [Mip4] resolution of RADIUS-MIP identifier = issues??

We=20 need to clear this up first:
 
2865=20 Does not mandate the user-name is required in=20 Access-Request.
 
KL> I = was looking=20 at RFC 2138 (my usual reference :), which is obsoleted by this=20 RFC.
 
 
 
 
Here=20 are the appropriate snippets.....
 
Section 4.1 = Access-Request
..... An Access-Request SHOULD contain a = User-Name=20 attribute.
 
Section 5.1 User-Name
 
User-Name
 
   = Description
 
      This = Attribute=20 indicates the name of the user to be=20 authenticated.
      It MUST be sent in=20 Access-Request packets if available.
 
Here=20 is the entry in the table.
 Request   = Accept  =20 Reject   Challenge   #   =20 Attribute
   0-1      =20 0-1      = 0       =20 0           =20 1   User-Name
 
KL> OK, = User-Name=20 AVP may be not in the messages.
 
 
And=20 here is what 2865 says about routing:
The=20 User-Name
   attribute MAY contain a Network Access = Identifier=20 [8] for RADIUS
   Proxy operations.  The choice of = which=20 server receives the forwarded
   request SHOULD be based = on the=20 authentication "realm". The
   authentication realm MAY = be the=20 realm part of a Network Access
   Identifier (a "named=20 realm").  Alternatively, the choice of which
   = server=20 receives the forwarded request MAY be based on whatever = other
  =20 criteria the forwarding server is configured to use, such as=20 Called-
   Station-Id (a "numbered = realm").
 
KL>=20 OK
 
So here is the table of attributes.  = (This=20 hopefully simplifies the summary)
 
RADIUS    =20 MIP
------------    =20 -----
User-Name <--- = MN-NAI-Extension (see note=20 below)
MN_HOA   <--- HOA (if=20 available)
HA_IP       = <----=20 HA_IP (if available)
NAS_IP    <----- as per=20 RADIUS.
NAS_ID    <----- as per=20 RADIUS.
 
The=20 User-Name MUST be populated with the MN-NAI-Extension if = avialable.  If=20 MN-NAI-Extension is not available the User-Name MAY be left=20 blank. 
 
KL> If the = MN-NAI-Extension is=20 absent, then the User-Name AVP MAY be left out of the RADIUS messages, = right?  The User-Name string field has to be >=3D 3=20 octets.
 
 
  If routing of = the=20 Access-Request is required it may be performed based on whatever other = criteria criteria the forwarding server is configured to use such as = HoA or=20 HA-IP.  If the NAI is not available, the RADIUS = client MAY=20 populate the user name with a value of annonymous@realm where=20 realm is the result of doing a DNS lookup using HoA or HA-IP.  = [NOTE we=20 need to check the NAI bible]
 
 
see more inline
 <snip> 
 
Kent
------_=_NextPart_001_01C557F7.58134EEA-- --===============0331633261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0331633261==-- From mip4-bounces@ietf.org Fri May 13 17:41:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhuY-0000TY-K2; Fri, 13 May 2005 17:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhuW-0000TQ-Gx for mip4@megatron.ietf.org; Fri, 13 May 2005 17:41:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14352 for ; Fri, 13 May 2005 17:41:29 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWiAW-0006p0-92 for mip4@ietf.org; Fri, 13 May 2005 17:58:05 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j4DLpUr0015575 for ; Fri, 13 May 2005 14:51:30 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4DLi0sh010461 for ; Fri, 13 May 2005 16:44:01 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 16:41:27 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , "'Avi Lior'" , "'Kent Leung (kleung)'" , "'Chowdhury, Kuntal'" Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 16:41:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: 'Mobile IPv4 Mailing List' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1854228460==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1854228460== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55804.60B34DB6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55804.60B34DB6 Content-Type: text/plain Ok, this email got blocked because it was too long. So I am sending it again, without all the previous emails... Madjid -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 Sent: Friday, May 13, 2005 2:36 PM To: 'Avi Lior'; 'Kent Leung (kleung)'; Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1 Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Thanks Avi for the clarification and the suggestion. I guess now we are not obligated to add a User-Name if we don't have an NAI. We also know at this point that every RRQ MUST have an HoA field, it may have been populated by a routable HoA, non-routable HoA or just 0.0.0.0. Regardless of the case, there IS an HoA field and if the NAS creates an Access Request it will include that in the MN HoA attribute. If the HA decides to reject an RRQ, there is nothing we will do here. Question: Is HA IP address a mandated field in MIP RRQ? What will the MN insert there if it does not know the HA? Ok, another attempt at the summary: For CcoA case: The HA acts as a NAS. The HA may or may not use two different interfaces towards the MN and AAA server. If the HA decides to create a RADIUS Access Request, the attributes are populated as following User-Name: MN-NAI from MN-NAI extension of MIP RRQ MN-HoA: HoA from MIP RRQ (including cases where HoA=0.0.0.0) HA IP: HA IP address from MIP RRQ NAS IP: As instructed per RADIUS for Access Request (maybe different from HA IP) NAS ID: as instructed per RADIUS Note that creating a RADIUS Access Request based on a RRQ is within the discretion of HA. If the MIP HA deems the RRQ or its contents (such as the HoA or HA-IP included in the RRQ) or lack thereof (such as NAI) inappropriate for processing, it MAY reject the RRQ without creating a RADIUS Access Request. If HA acting as a RADIUS client decides to create a RADIUS Access Request and the MN-NAI-Extension is not available in the RRQ, the HA can populate the User-Name attribute according the network policies and is outside the scope of this specification. For instance User-Name MAY be left blank or be populated with anonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. For FA-based CoA, similar to above, except FA acts as a RADIUS client. ------_=_NextPart_001_01C55804.60B34DB6 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCg0KDQo8bWV0YSBuYW1lPUdl bmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCAoZmlsdGVyZWQpIj4NCjx0aXRsZT5N ZXNzYWdlPC90aXRsZT4NCg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZW1h aWxzdHlsZTE3DQoJe2ZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5lbWFpbHN0eWxlMTgNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXtmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdl IFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4w aW4gMS4yNWluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHls ZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+T2ssIHRoaXMgZW1haWwgZ290IGJsb2NrZWQg YmVjYXVzZSBpdCB3YXMNCnRvbyBsb25nLiBTbyBJIGFtIHNlbmRpbmcgaXQgYWdhaW4sIHdpdGhv dXQgYWxsIHRoZSBwcmV2aW91cyBlbWFpbHMuLi48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5NYWRqaWQ8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4m bmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OlRhaG9tYSc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj48c3BhbiBzdHlsZT0n Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9iPiBOYWtoamlyaSBNYWRqaWQtTU5BS0hK STEgPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwv Yj4gPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz5GcmlkYXksIE1heSAxMywNCiAyMDA1 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhvbWEnPiA8L3NwYW4+PC9mb250Pjxmb250IHNp emU9MiBmYWNlPVRhaG9tYT48c3Bhbg0KIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlRhaG9tYSc+MjozNiBQTTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9t YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPjxicj4N CjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiAnQXZpIExp b3InOyAnS2VudCBMZXVuZw0KKGtsZXVuZyknOyBDaG93ZGh1cnksIEt1bnRhbDsgTmFraGppcmkg TWFkamlkLU1OQUtISkkxPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNj Ojwvc3Bhbj48L2I+IDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yDQogZmFjZT1UYWhvbWE+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz5Nb2JpbGU8L3Nw YW4+PC9mb250Pjxmb250DQpzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gSVB2NA0KTWFpbGluZyBMaXN0PGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtN aXA0XSByZXNvbHV0aW9uIG9mDQpSQURJVVMtTUlQIGlkZW50aWZpZXIgaXNzdWVzPz88L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOm5hdnknPlRoYW5rcyBBdmkgZm9yIHRoZSBjbGFyaWZpY2F0aW9uIGFuZCB0 aGUNCnN1Z2dlc3Rpb24uIEkgZ3Vlc3Mgbm93IHdlIGFyZSBub3Qgb2JsaWdhdGVkIHRvIGFkZCBh IFVzZXItTmFtZSBpZiB3ZQ0KZG9uJ3QgaGF2ZSBhbiBOQUkuPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eSc+V2UgYWxzbyBrbm93IGF0IHRoaXMgcG9pbnQgdGhhdCBldmVyeSBSUlENCk1VU1QgaGF2ZSBh biBIb0EgZmllbGQsIGl0IG1heSBoYXZlIGJlZW4gcG9wdWxhdGVkIGJ5IGEgcm91dGFibGUgSG9B LA0Kbm9uLXJvdXRhYmxlIEhvQSBvciBqdXN0IDAuMC4wLjAuIFJlZ2FyZGxlc3Mgb2YgdGhlIGNh c2UsIHRoZXJlIElTIGFuIEhvQSBmaWVsZA0KYW5kIGlmIHRoZSBOQVMgY3JlYXRlcyBhbiBBY2Nl c3MgUmVxdWVzdCBpdCB3aWxsIGluY2x1ZGUgdGhhdCBpbiB0aGUgTU4gSG9BDQphdHRyaWJ1dGUu IElmIHRoZSBIQSBkZWNpZGVzIHRvIHJlamVjdCBhbiBSUlEsIHRoZXJlIGlzIG5vdGhpbmcgd2Ug d2lsbCBkbw0KaGVyZS48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Jz5RdWVzdGlvbjogSXMgSEEgSVAgYWRkcmVzcyBhIG1hbmRhdGVkDQpmaWVsZCBp biBNSVAgUlJRPyBXaGF0IHdpbGwgdGhlIE1OIGluc2VydCB0aGVyZSBpZiBpdCBkb2VzIG5vdCBr bm93IHRoZSBIQT88L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEw LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpuYXZ5Jz5PaywgYW5vdGhlciBhdHRlbXB0IGF0IHRoZSBzdW1tYXJ5Ojwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkZvciBDY29BIGNhc2U6IDwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnknPlRoZSBIQSBhY3RzIGFzIGEgTkFTLiBUaGUgSEEgbWF5IG9y IG1heSBub3QNCnVzZSB0d28gZGlmZmVyZW50IGludGVyZmFjZXMgdG93YXJkcyB0aGUgTU4gYW5k IEFBQSBzZXJ2ZXIuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SWYgdGhlIEhBIGRlY2lkZXMgdG8g Y3JlYXRlIGEgUkFESVVTDQpBY2Nlc3MgUmVxdWVzdCwgdGhlIGF0dHJpYnV0ZXMgYXJlIHBvcHVs YXRlZCBhcyBmb2xsb3dpbmc8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5Vc2VyLU5hbWU6IE1OLU5B SSBmcm9tIE1OLU5BSSBleHRlbnNpb24gb2YNCk1JUCBSUlE8L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 Jz5NTi1Ib0E6IEhvQSBmcm9tIE1JUCBSUlEgKGluY2x1ZGluZyBjYXNlcw0Kd2hlcmUgSG9BPTAu MC4wLjApPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SEEgSVA6IEhBIElQIGFkZHJlc3MgZnJvbSBN SVAgUlJRPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+TkFTIElQOiBBcyBpbnN0cnVjdGVkIHBlciBS QURJVVMgZm9yDQpBY2Nlc3MgUmVxdWVzdCAobWF5YmUgZGlmZmVyZW50IGZyb20gSEEgSVApPC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+TkFTIElEOiBhcyBpbnN0cnVjdGVkIHBlciBSQURJVVM8L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpuYXZ5Jz5Ob3RlIHRoYXQgY3JlYXRpbmcgYSBSQURJVVMgQWNjZXNzIFJl cXVlc3QNCmJhc2VkIG9uIGEgUlJRIGlzIHdpdGhpbiB0aGUgZGlzY3JldGlvbiBvZiBIQS4gSWYg dGhlIE1JUCBIQSBkZWVtcyB0aGUgUlJRIG9yDQppdHMgY29udGVudHMgKHN1Y2ggYXMgdGhlIEhv QSBvciBIQS1JUCBpbmNsdWRlZCBpbiB0aGUgUlJRKSBvciBsYWNrIHRoZXJlb2YNCihzdWNoIGFz IE5BSSkgaW5hcHByb3ByaWF0ZSBmb3IgcHJvY2Vzc2luZywgaXQgTUFZIHJlamVjdCB0aGUgUlJR IHdpdGhvdXQNCmNyZWF0aW5nIGEgUkFESVVTIEFjY2VzcyBSZXF1ZXN0LiBJZiBIQSBhY3Rpbmcg YXMgYSBSQURJVVMgY2xpZW50IGRlY2lkZXMgdG8gY3JlYXRlDQphIFJBRElVUyBBY2Nlc3MgUmVx dWVzdCBhbmQgdGhlIE1OLU5BSS1FeHRlbnNpb24gaXMgbm90IGF2YWlsYWJsZSBpbiB0aGUgUlJR LA0KdGhlIEhBIGNhbiBwb3B1bGF0ZSB0aGUgVXNlci1OYW1lIGF0dHJpYnV0ZSBhY2NvcmRpbmcg dGhlIG5ldHdvcmsgcG9saWNpZXMgYW5kDQppcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24uIEZvciBpbnN0YW5jZSBVc2VyLU5hbWUgTUFZIGJlIGxlZnQNCmJsYW5rIG9y IGJlIHBvcHVsYXRlZCB3aXRoIDxhIGhyZWY9Im1haWx0bzphbm5vbnltb3VzQHJlYWxtIj48Zm9u dCBjb2xvcj1uYXZ5PjxzcGFuDQpzdHlsZT0nY29sb3I6bmF2eSc+YW5vbnltb3VzQHJlYWxtPC9z cGFuPjwvZm9udD48L2E+IHdoZXJlIHJlYWxtIGlzIHRoZSByZXN1bHQNCm9mIGRvaW5nIGEgRE5T IGxvb2t1cCB1c2luZyBIb0Egb3IgSEEtSVAuIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkZvciBGQS1iYXNlZCBDb0EsIHNpbWlsYXIgdG8gYWJv dmUsIGV4Y2VwdA0KRkEgYWN0cyBhcyBhIFJBRElVUyBjbGllbnQuPC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eSc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwv aHRtbD4NCg== ------_=_NextPart_001_01C55804.60B34DB6-- --===============1854228460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1854228460==-- From mip4-bounces@ietf.org Fri May 13 17:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiBW-000546-ON; Fri, 13 May 2005 17:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiBT-00053y-M4 for mip4@megatron.ietf.org; Fri, 13 May 2005 17:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15454 for ; Fri, 13 May 2005 17:59:00 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWiRT-0007RO-ON for mip4@ietf.org; Fri, 13 May 2005 18:15:36 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 17:58:40 -0400 Message-ID: From: Avi Lior To: "'Chowdhury, Kuntal'" , "Kent Leung (kleung)" Date: Fri, 13 May 2005 17:58:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: Nakhjiri Madjid-MNAKHJI1 , "'mip4@ietf.org'" Subject: [Mip4] RE: OFFLIST resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org In view Kuntal's email we need to capture the following: If a NAS does not have enough information to route the packet it shall reject. If a RADIUS forwarding server does not have enough information to route the packet it shall respond with an Access-Reject. If a RADIUS Server, does not have enugh information to identifiy the user for authentication purposes, the RADIUS server MUST respond with an access-reject packet. > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Friday, May 13, 2005 5:43 PM > To: Kent Leung (kleung) > Cc: Nakhjiri Madjid-MNAKHJI1; Avi Lior > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? > > > Routing the AAA message is one thing, but actually able to > authenticate the user is another thing. You cannot > authenticate the user if the RRQ does not contain ANY > information that can be used to identify the user and the > HoA=private IP and the network supports overlapping private address. > > I had a discussion with Avi, BTW. We agreed that in such > situation the NAS would still send Access-Request with HoA, > HA address etc. and the RADIUS server was free to send > Access-Reject since there would be NOTHING in the > Access-Request that could be used to identify and > authenticate the user. > > -Kuntal > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Friday, May 13, 2005 3:12 PM > > To: Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1; Avi Lior > > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? > > > > > > I think this case is up to implementation. There are other ways to > > route the message w/o username AVP. This is a generic RADIUS issue > > which don't need to be solved in this draft, IMHO. Just > map and stop > > at that... > > > > Kent > > > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Friday, May 13, 2005 11:23 AM > > > To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior > > > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? > > > > > > What exactly you mean by mapping? What you plan to do when MN > > > uses a private HoA and does not include it's NAI? > > > > > > -Kuntal > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Friday, May 13, 2005 1:19 PM > > > > To: 'Kent Leung \(kleung\)'; Avi Lior; Chowdhury, Kuntal > > > > Subject: RE: OFFLIST resolution of RADIUS-MIP > identifier issues?? > > > > > > > > > > > > I think I stated this as well. Anyway, I agree. > > > > I like Avi's suggestion. I will get back to you with > > > another summary > > > > to clean everything up. Unfortunately I am in the middle of > > > something > > > > right now. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Kent Leung \(kleung\) [mailto:kleung@cisco.com] > > > > Sent: Friday, May 13, 2005 1:09 PM > > > > To: Avi Lior; Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1 > > > > Subject: RE: OFFLIST resolution of RADIUS-MIP > identifier issues?? > > > > > > > > I'm in agreement. We should only do mapping... > > > > > > > > Kent > > > > > > > > > -----Original Message----- > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > Sent: Friday, May 13, 2005 10:25 AM > > > > > To: 'Chowdhury, Kuntal'; Nakhjiri Madjid-MNAKHJI1; Kent Leung > > > > > (kleung); Avi Lior > > > > > Subject: RE:OFFLIST resolution of RADIUS-MIP > identifier issues?? > > > > > > > > > > "OFFLIST" > > > > > > > > > > It seems to me that we are trying to enhance or tighten > > MIP with > > > > > this document. > > > > > > > > > > IMO In doing this work we should as much possible avoid > > > introducing > > > > > any new rules or tightening the MIP scope. We should > > just figure > > > > > out how to do the mapping and keep it as simple as possible. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Chowdhury, Kuntal > > [mailto:kchowdhury@starentnetworks.com] > > > > > > Sent: Friday, May 13, 2005 1:03 PM > > > > > > To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com; > > > > > > avi@bridgewatersystems.com > > > > > > Cc: mip4@ietf.org > > > > > > Subject: RE: resolution of RADIUS-MIP identifier issues?? > > > > > > > > > > > > > > > > > > Madjid, > > > > > > > > > > > > Rejecting a poorly formed RRQ is not a protocol violation. > > > > > If the user > > > > > > uses a private IP address as HoA and does not include NAI > > > > > extension, > > > > > > it is entirely upto the HA provider's policy to accept or > > > > > reject the > > > > > > registration request. If the provider's network is > setup with > > > > > > non-overlapping private IP addresses and these private > > > > > addresses can > > > > > > be mapped to unique usernames, then the HA MAY process the > > > > > request by > > > > > > setting username=HoA. Otherwise, the HA SHOULD reject the > > > > > request as > > > > > > the user cannot be uniquely identified. I think we need to > > > > > clarify the > > > > > > HA behavior on this line. > > > > > > > > > > > > BTW, support of private IP address (private HoA) at the > > > > HA does not > > > > > > necessarily mean that the HA has NAT traversal > > support. HAs are > > > > > > deployed with overlapping private IP address pools for > > > different > > > > > > enterprises. Such traffic are tunneled to/from the > > > > > enterprise via the > > > > > > HA. The NAT can be somewhere in the enterprise. > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > > Sent: Friday, May 13, 2005 9:40 AM > > > > > > > To: Chowdhury, Kuntal; kleung@cisco.com; > > > > > avi@bridgewatersystems.com > > > > > > > Cc: mip4@ietf.org > > > > > > > Subject: RE: resolution of RADIUS-MIP identifier issues?? > > > > > > > > > > > > > > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > It seems that we have to have the User-name attribute > > > populated > > > > > > > before sending an Access Request on behalf of the MN. Avi > > > > > seemed to > > > > > > > have issues with putting an non-routable HoA in > > > User-name. The > > > > > > > reasoning is understandable, however, as you said we > > > > > cannot fix MN > > > > > > > implementation problems here, unless somebody on this > > > > > list tells me > > > > > > > there is a legitimate reason for the MN using a > > > > non-routable HoA > > > > > > > (NAT-traversal?). > > > > > > > I think we should simply not support NAT traversal at > > > > this point. > > > > > > > > > > > > > > For case C) where no NAI is available, we should accept > > > > > > > User-Name=HOA MN-HoA=HoA The HA simply creates the > > > > Access Request > > > > > > > and sends it to AAA server. I don't think we can modify > > > > > the RFC 3344 > > > > > > > behavior of HA here. It is not within our scope. If NAT > > > > traversal > > > > > > > drafts define a behavior for HA to change the > > > > non-routable HoA to > > > > > > > routable one, then the HA may insert the routable address > > > > > inside the > > > > > > > MN-HoA or something. I don't think we should deal with > > > > > that now. We > > > > > > > can provide some recommendation. The AAA server examining > > > > > these two > > > > > > > fields will recognize that MN did not have an NAI and > > > if HoA is > > > > > > > unrecognizable it will reject the request. > > > > > > > > > > > > > > If you guys are ok with this, I will add some text in > > > > that effect. > > > > > > > > > > > > > > Madjid > > > > > > > ----- > > > > > > > Original Message----- > > > > > > > From: Chowdhury, Kuntal > > > [mailto:kchowdhury@starentnetworks.com] > > > > > > > Sent: Friday, May 13, 2005 12:53 AM > > > > > > > To: Nakhjiri Madjid-MNAKHJI1; kleung@cisco.com; > > > > > > > avi@bridgewatersystems.com > > > > > > > Cc: mip4@ietf.org > > > > > > > Subject: Re: resolution of RADIUS-MIP identifier issues?? > > > > > > > > > > > > > > Madjid, > > > > > > > > > > > > > > Good sunnary. I am still not clear about the case when > > > > > the MN sends > > > > > > > a RRQ with a non routable HoA but does not include NAI > > > > extension. > > > > > > > What should be in the username attribute in that > > > case? We can't > > > > > > > assume that the MN FQDN can be drived. So, there won't be > > > > > anything > > > > > > > to identify the user. Why can't we assume that the HA > > > > > rejects such > > > > > > > RRQs (poorly formed RRQ)? It does not make sense to go > > > > > through hoops > > > > > > > to accomodate nasty MN implementations, IMHO. > > > > > > > > > > > > > > Regarding the need for the inclusion of CoA in the > > > > > Access-Request, I > > > > > > > think it is optional for the FA and the HA to include it, > > > > > but it is > > > > > > > good to have. > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > -------------------------- > > > > > > > Sent from my BlackBerry Wireless Handheld > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > > > > > > To: Nakhjiri Madjid-MNAKHJI1 > > > > ; Kent > > > > > > > Leung ; Avi Lior > > > > ; > > > > > > > Chowdhury, Kuntal > > > > > > > CC: Mobile IPv4 Mailing List > > > > > > > Sent: Thu May 12 15:40:23 2005 > > > > > > > Subject: resolution of RADIUS-MIP identifier issues?? > > > > > > > > > > > > > > Sorry for the long delay on this. I looked at all the > > > email and > > > > > > > tried to see the convergence. > > > > > > > > > > > > > > Most of the cases seem to be straightforward: put NAI in > > > > > user name > > > > > > > and IP address in HoA. > > > > > > > > > > > > > > It seems that the main issue is when HoA is available but > > > > > NAI is not > > > > > > > and the AAA infrastructure (mainly NAS) may not trust HoA > > > > > > > routability enough to put it in user name when NAI is not > > > > > there. Avi > > > > > > > suggested we come up with some guidance for implementers, > > > > > I am not > > > > > > > quite sure if I came up with anything. > > > > > > > Kuntal suggested a DNS lookup. Maybe we can include that > > > > > in RADIUS > > > > > > > routing requirement section, so that we can deal with it > > > > > when this > > > > > > > draft gets to RADEXT. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyway, before you fire away at my statements above, > > > > > please look at > > > > > > > the following summary and if you deem it to be adequate. > > > > > I will make > > > > > > > the changes to the draft accordingly and fire away a > > > > new version. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Attributes we discussed: > > > > > > > > > > > > > > MN HoA, MN NAI, HA IP, NAS ID, user name > > > > > > > > > > > > > > Not sure why Avi brought up the MN CoA attribute? We > > > > did not have > > > > > > > that originally? > > > > > > > > > > > > > > The home AAA or HA don't know CoA anyway, so not sure > > > > > what is used > > > > > > > for? > > > > > > > > > > > > > > > > > > > > > > > > > > > > CcoA case: there is no FA, HA acts as NAS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > a) If both NAI and HoA available for MN (we can assume HA > > > > > IP is also > > > > > > > available in RRQ): > > > > > > > > > > > > > > User name attribute: MN NAI > > > > > > > > > > > > > > MN HoA attribute: MN HoA IP > > > > > > > > > > > > > > HA IP attribute: HA IP from RRQ (interface > > > > > towards the > > > > > > > MN, not towards AAA) > > > > > > > > > > > > > > NAS IP attribute: IP address of HA interface > > > > > towards the > > > > > > > AAA server (this should be a routable IP address) > > > > > > > > > > > > > > NAS ID: FQDN for HA, if available > > > > > > > > > > > > > > (Issue: RFC 3344 does not assume that both HoA and NAI > > > > > are available > > > > > > > at the same time. > > > > > > > > > > > > > > See section 3.6: when NAI is used HoA is set to 0.0.0.0). > > > > > > > > > > > > > > > > > > > > > > > > > > > > b) If only NAI is available and no HoA is present (HA IP > > > > > may or may > > > > > > > not be present). > > > > > > > > > > > > > > User name: MN NAI > > > > > > > > > > > > > > No MN HoA attribute > > > > > > > > > > > > > > HA IP attribute (if present) > > > > > > > > > > > > > > NAS IP attribute: IP address for HA > > > > interface towards > > > > > > > the AAA server > > > > > > > > > > > > > > NAS ID: FQDN for HA, if available > > > > > > > > > > > > > > > > > > > > > > > > > > > > c) If only HoA is present (HA IP should be > present as well) > > > > > > but no NAI > > > > > > > > > > > > > > AAA-routability for multi-domain roaming is > > > > > not possible > > > > > > > > > > > > > > User name: MN FQDN if available??/ MN HoA > > > if deemed > > > > > > > routable (***) > > > > > > > > > > > > > > MN HoA: MN HoA > > > > > > > > > > > > > > HA IP attribute (from RRQ) > > > > > > > > > > > > > > NAS IP attribute: HA IP address towards the > > > > > AAA server). > > > > > > > > > > > > > > NAS ID: FQDN for HA, if available > > > > > > > > > > > > > > *** Avi suggested to provide guidance for > implementers here? > > > > > > > What should we recommend? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For FA-Based case: > > > > > > > > > > > > > > a) when both MN NAI and MN HoA are available > > > > > > > > > > > > > > User name attribute: MN NAI > > > > > > > > > > > > > > MN HoA attribute: MN HoA IP > > > > > > > > > > > > > > HA IP attribute: HA IP from RRQ (interface > > > > > towards the > > > > > > > MN, not towards AAA) > > > > > > > > > > > > > > NAS IP attribute: FA IP address towards the > > > > > AAA server > > > > > > > (this should be a routable IP address) > > > > > > > > > > > > > > NAS ID: FQDN for FA, if available > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > b) If only NAI is available and no HoA is present (HA IP > > > > > may or may > > > > > > > not be present). > > > > > > > > > > > > > > User name: MN NAI > > > > > > > > > > > > > > No MN HoA attribute > > > > > > > > > > > > > > HA IP attribute (if present in RRQ) > > > > > > > > > > > > > > NAS IP attribute: IP address for FA > > > > interface towards > > > > > > > the AAA server > > > > > > > > > > > > > > NAS ID: FQDN for FA, if available > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > c) If only HoA is present (HA IP should be > present as well) > > > > > > but no NAI > > > > > > > > > > > > > > AAA-routability for multi-domain roaming is > > > > > not possible > > > > > > > > > > > > > > User name: MN FQDN if available??/ MN HoA > > > if deemed > > > > > > > routable (***) > > > > > > > > > > > > > > MN HoA: MN HoA > > > > > > > > > > > > > > HA IP attribute (from RRQ) > > > > > > > > > > > > > > NAS IP attribute: FA IP address towards the > > > > > AAA server). > > > > > > > > > > > > > > NAS ID: FQDN for FA, if available > > > > > > > > > > > > > > > > > > > > > > > > > > > > *** Avi suggested to provide guidance for > implementers here? > > > > > > > What should we recommend? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 18:03:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiFn-0005yh-0B; Fri, 13 May 2005 18:03:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiFk-0005xp-0v for mip4@megatron.ietf.org; Fri, 13 May 2005 18:03:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15725 for ; Fri, 13 May 2005 18:03:24 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWiVk-0007bT-8F for mip4@ietf.org; Fri, 13 May 2005 18:20:00 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 May 2005 18:03:18 -0400 Message-ID: From: Avi Lior To: "'Kent Leung (kleung)'" , Avi Lior , Nakhjiri Madjid-MNAKHJI1 , "Chowdhury, Kuntal" Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Fri, 13 May 2005 18:03:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032990244==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0032990244== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55807.9127FEE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55807.9127FEE0 Content-Type: text/plain Kent, The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. You are correct. YOu cant send a blank. It must be ommitted. -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Friday, May 13, 2005 4:07 PM To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Hi Avi. Comments below in "KL>". _____ From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Friday, May 13, 2005 8:43 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? We need to clear this up first: 2865 Does not mandate the user-name is required in Access-Request. KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC. Here are the appropriate snippets..... Section 4.1 Access-Request ..... An Access-Request SHOULD contain a User-Name attribute. Section 5.1 User-Name User-Name Description This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. Here is the entry in the table. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name KL> OK, User-Name AVP may be not in the messages. And here is what 2865 says about routing: The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm"). KL> OK So here is the table of attributes. (This hopefully simplifies the summary) RADIUS MIP ------------ ----- User-Name <--- MN-NAI-Extension (see note below) MN_HOA <--- HOA (if available) HA_IP <---- HA_IP (if available) NAS_IP <----- as per RADIUS. NAS_ID <----- as per RADIUS. The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP. If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. [NOTE we need to check the NAI bible] see more inline Kent ------_=_NextPart_001_01C55807.9127FEE0 Content-Type: text/html Message
Kent,
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 
 
KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.
 
You are correct. YOu cant send a blank.  It must be ommitted.
 
-----Original Message-----
From: Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Friday, May 13, 2005 4:07 PM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

Hi Avi.  Comments below in "KL>".

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Friday, May 13, 2005 8:43 AM
To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

We need to clear this up first:
 
2865 Does not mandate the user-name is required in Access-Request.
 
KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC.
 
 
 
 
Here are the appropriate snippets.....
 
Section 4.1 Access-Request
..... An Access-Request SHOULD contain a User-Name attribute.
 
Section 5.1 User-Name
 
User-Name
 
   Description
 
      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.
 
Here is the entry in the table.
 Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name
 
KL> OK, User-Name AVP may be not in the messages.
 
 
And here is what 2865 says about routing:
The User-Name
   attribute MAY contain a Network Access Identifier [8] for RADIUS
   Proxy operations.  The choice of which server receives the forwarded
   request SHOULD be based on the authentication "realm". The
   authentication realm MAY be the realm part of a Network Access
   Identifier (a "named realm").  Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").
 
KL> OK
 
So here is the table of attributes.  (This hopefully simplifies the summary)
 
RADIUS     MIP
------------     -----
User-Name <--- MN-NAI-Extension (see note below)
MN_HOA   <--- HOA (if available)
HA_IP       <---- HA_IP (if available)
NAS_IP    <----- as per RADIUS.
NAS_ID    <----- as per RADIUS.
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 
 
KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.
 
 
  If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP.  [NOTE we need to check the NAI bible]
 
 
see more inline
 <snip> 
 
Kent
------_=_NextPart_001_01C55807.9127FEE0-- --===============0032990244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0032990244==-- From mip4-bounces@ietf.org Fri May 13 18:12:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiNM-0008Eo-G1; Fri, 13 May 2005 18:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWiNK-0008Ee-5W for mip4@megatron.ietf.org; Fri, 13 May 2005 18:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16848 for ; Fri, 13 May 2005 18:11:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWidJ-0007rV-Pk for mip4@ietf.org; Fri, 13 May 2005 18:27:51 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 May 2005 15:10:50 -0700 X-IronPort-AV: i="3.93,108,1115017200"; d="scan'208"; a="265006275:sNHT2470663902" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4DMAHOP027198; Fri, 13 May 2005 15:10:43 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 15:10:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 15:10:36 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52285749@xmb-sjc-235.amer.cisco.com> Thread-Topic: OFFLIST resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVYBxkm+Qn83nbmRFGyyBwzXeUZ6QAAKCKQ From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 13 May 2005 22:10:39.0761 (UTC) FILETIME=[98DE3810:01C55808] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , mip4@ietf.org Subject: [Mip4] RE: OFFLIST resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Getting close ... > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Friday, May 13, 2005 2:59 PM > To: 'Chowdhury, Kuntal'; Kent Leung (kleung) > Cc: Nakhjiri Madjid-MNAKHJI1; 'mip4@ietf.org' > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? >=20 > In view Kuntal's email we need to capture the following: >=20 > If a NAS does not have enough information to route the packet=20 > it shall reject. If a RADIUS forwarding server does not have=20 > enough information to route the packet it shall respond with=20 > an Access-Reject. >=20 Isn't this just normal RADIUS operation for the NAS and RADIUS forwarding server? I don't have a problem with explicit language in the text. But this seems common sense though. > If a RADIUS Server, does not have enugh information to=20 > identifiy the user for authentication purposes, the RADIUS=20 > server MUST respond with an access-reject packet. >=20 I would expect this to be in the normal operation of RADIUS server. Shouldn't all this be defined in the RFC 2865? If so, reference that. If not, agree that such clarification should be in the draft. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 18:43:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWisF-0007mJ-A9; Fri, 13 May 2005 18:43:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWisE-0007mE-KI for mip4@megatron.ietf.org; Fri, 13 May 2005 18:43:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19380 for ; Fri, 13 May 2005 18:43:11 -0400 (EDT) Received: from ames.starentnetworks.com ([12.33.235.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWj8E-0000ap-Kx for mip4@ietf.org; Fri, 13 May 2005 18:59:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 18:43:03 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D8FD9@ames.starentnetworks.com> Thread-Topic: OFFLIST resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVYBxkm+Qn83nbmRFGyyBwzXeUZ6QAAKCKQAAB9hdA= From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , mip4@ietf.org, Avi Lior Subject: [Mip4] RE: OFFLIST resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org How does a NAS create an Access-Request based on information in MIPv4 = RRQ and what is the authentication style (note that auth style at the FA = is FAC as defined in RFC 3012, but at the HA is not defined for RADIUS) = is being defined in this ID. So, to answer your question, NO, such = behavior is not necessarily defined and universally understood. I did a quick glance through RFC 2865, I could not find the RADIUS = Server behavior w.r.t. the case we are talking about. -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, May 13, 2005 5:11 PM > To: Avi Lior; Chowdhury, Kuntal > Cc: Nakhjiri Madjid-MNAKHJI1; mip4@ietf.org > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? >=20 >=20 > Getting close ... >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > > Sent: Friday, May 13, 2005 2:59 PM > > To: 'Chowdhury, Kuntal'; Kent Leung (kleung) > > Cc: Nakhjiri Madjid-MNAKHJI1; 'mip4@ietf.org' > > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? > >=20 > > In view Kuntal's email we need to capture the following: > >=20 > > If a NAS does not have enough information to route the packet=20 > > it shall reject. If a RADIUS forwarding server does not have=20 > > enough information to route the packet it shall respond with=20 > > an Access-Reject. > >=20 >=20 > Isn't this just normal RADIUS operation for the NAS and RADIUS > forwarding server? I don't have a problem with explicit=20 > language in the > text. But this seems common sense though. >=20 >=20 >=20 > > If a RADIUS Server, does not have enugh information to=20 > > identifiy the user for authentication purposes, the RADIUS=20 > > server MUST respond with an access-reject packet. > >=20 >=20 > I would expect this to be in the normal operation of RADIUS server. >=20 > Shouldn't all this be defined in the RFC 2865? If so, reference that. > If not, agree that such clarification should be in the draft. >=20 > Kent >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 18:52:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWj11-0001ao-Lm; Fri, 13 May 2005 18:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWj10-0001aj-S8 for mip4@megatron.ietf.org; Fri, 13 May 2005 18:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20046 for ; Fri, 13 May 2005 18:52:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWjH0-0000vb-Ul for mip4@ietf.org; Fri, 13 May 2005 19:08:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 May 2005 15:52:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4DMpjrS028509; Fri, 13 May 2005 15:52:06 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 15:52:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2005 15:51:56 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5228577F@xmb-sjc-235.amer.cisco.com> Thread-Topic: OFFLIST resolution of RADIUS-MIP identifier issues?? Thread-Index: AcVYBxkm+Qn83nbmRFGyyBwzXeUZ6QAAKCKQAAB9hdAAAPZcUA== From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" X-OriginalArrivalTime: 13 May 2005 22:52:04.0886 (UTC) FILETIME=[621E3360:01C5580E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , mip4@ietf.org, Avi Lior Subject: [Mip4] RE: OFFLIST resolution of RADIUS-MIP identifier issues?? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org =20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Friday, May 13, 2005 3:43 PM > To: Kent Leung (kleung) > Cc: Nakhjiri Madjid-MNAKHJI1; mip4@ietf.org; Avi Lior > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues?? >=20 > How does a NAS create an Access-Request based on information=20 > in MIPv4 RRQ and what is the authentication style (note that=20 > auth style at the FA is FAC as defined in RFC 3012, but at=20 > the HA is not defined for RADIUS)=20 3012bis defines HA case since CCoA is a supported scenario. > is being defined in this=20 > ID. So, to answer your question, NO, such behavior is not=20 > necessarily defined and universally understood. >=20 > I did a quick glance through RFC 2865, I could not find the=20 > RADIUS Server behavior w.r.t. the case we are talking about. >=20 I'm not trying to give you a hard time. :) I just expected the generic RADIUS issues to be covered already. If not, there's no harm to add that in the Mobile IP based draft. As I had say, "If not, agree that such clarification should be in the draft." Avi, why didn't they cover these common issues in RADIUS draft? Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 13 21:29:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWlSr-0003Th-Q8; Fri, 13 May 2005 21:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWlSq-0003TV-Qs; Fri, 13 May 2005 21:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29496; Fri, 13 May 2005 21:29:10 -0400 (EDT) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWlit-0006SL-AR; Fri, 13 May 2005 21:45:47 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 8FAF2C327; Fri, 13 May 2005 21:29:03 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j4E1T3K9006899; Fri, 13 May 2005 21:29:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4E1T2OG029141; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 09960-29; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4E1T2r l029136;Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 09B8F33800F; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [6 8.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid 7612A33800D; F ri, 13 May 2005 21:29:00 -0400 (EDT) Message-ID: <42855467.8090606@grc.nasa.gov> Date: Fri, 13 May 2005 21:29:11 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo , mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] Space-based deployment of NEMO (IPv4 version) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Sorry I have not been to active on the lists. Hopefully, that will change. At the last IETF meeting I had many requests for information on deployment of mobile networking onboard a satellite. I have finally completed the full detailed report and some executive summaries. The full report describes the deployment including how the network is set up, how the satellite network operates and even includes router configurations for the home agent, foreign agent and mobile router. An interesting note is that triangular routing or route optimization is definitely preferred over bidirectional tunneling due to rate mismatches - see the powerpoint presentation. The final report and executive summaries are available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html A presentation that has animation of the data flow is available at the same URL - pick or move down to the "Presentations" section. "Secure, Network-Centric Operations of a Space-Based Asset: Cisco Router in Low-Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)" Net-Centric Operations 2005, May 10-11, 2005 Washington, DC ( Powerpoint) file size 5,871,616 bytes Sorry I have not been to active on the lists. Hopefully, that will change soon. Will -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 16 11:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhyq-0004wU-JY; Mon, 16 May 2005 11:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhyp-0004wO-8k for mip4@megatron.ietf.org; Mon, 16 May 2005 11:58:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28979 for ; Mon, 16 May 2005 11:58:04 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXiFM-0007t7-H7 for mip4@ietf.org; Mon, 16 May 2005 12:15:14 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j4GFvsEN005810 for ; Mon, 16 May 2005 08:57:54 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j4GG1RSq027395 for ; Mon, 16 May 2005 11:01:28 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 May 2005 10:57:52 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , "'Kent Leung (kleung)'" , "Chowdhury, Kuntal" Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Mon, 16 May 2005 10:57:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1977146486==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1977146486== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55A2F.EA5CB878" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55A2F.EA5CB878 Content-Type: text/plain I guess I missed the resolution. Do we or do we not send a blank User-Name attribute if NAI is missing? -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Friday, May 13, 2005 5:03 PM To: 'Kent Leung (kleung)'; Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Kent, The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. You are correct. YOu cant send a blank. It must be ommitted. -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Friday, May 13, 2005 4:07 PM To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Hi Avi. Comments below in "KL>". _____ From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Friday, May 13, 2005 8:43 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? We need to clear this up first: 2865 Does not mandate the user-name is required in Access-Request. KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC. Here are the appropriate snippets..... Section 4.1 Access-Request ..... An Access-Request SHOULD contain a User-Name attribute. Section 5.1 User-Name User-Name Description This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. Here is the entry in the table. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name KL> OK, User-Name AVP may be not in the messages. And here is what 2865 says about routing: The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm"). KL> OK So here is the table of attributes. (This hopefully simplifies the summary) RADIUS MIP ------------ ----- User-Name <--- MN-NAI-Extension (see note below) MN_HOA <--- HOA (if available) HA_IP <---- HA_IP (if available) NAS_IP <----- as per RADIUS. NAS_ID <----- as per RADIUS. The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP. If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. [NOTE we need to check the NAI bible] see more inline Kent ------_=_NextPart_001_01C55A2F.EA5CB878 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCg0KDQo8bWV0YSBuYW1lPUdl bmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCAoZmlsdGVyZWQpIj4NCjx0aXRsZT5N ZXNzYWdlPC90aXRsZT4NCg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZW1h aWxzdHlsZTE3DQoJe2ZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFn ZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEu MGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5 bGU+DQoNCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxl Pg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkkgZ3Vlc3MgSSBtaXNzZWQgdGhlIHJlc29s dXRpb24uIERvIHdlIG9yDQpkbyB3ZSBub3Qgc2VuZCBhIGJsYW5rIFVzZXItTmFtZSBhdHRyaWJ1 dGUgaWYgTkFJIGlzIG1pc3Npbmc/PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1UYWhv bWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhvbWEnPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0 OmJvbGQnPkZyb206PC9zcGFuPjwvYj4gQXZpIExpb3INClttYWlsdG86YXZpQGJyaWRnZXdhdGVy c3lzdGVtcy5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50 Ojwvc3Bhbj48L2I+IEZyaWRheSwgTWF5IDEzLCAyMDA1IDU6MDMgUE08YnI+DQo8Yj48c3BhbiBz dHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gJ0tlbnQgTGV1bmcgKGtsZXVu ZyknOyBBdmkNCkxpb3I7IE5ha2hqaXJpIE1hZGppZC1NTkFLSEpJMTsgQ2hvd2RodXJ5LCBLdW50 YWw8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4g TW9iaWxlIElQdjQgTWFpbGluZyBMaXN0PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0 OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtNaXA0XSByZXNvbHV0aW9uIG9mDQpSQURJ VVMtTUlQIGlkZW50aWZpZXIgaXNzdWVzPz88L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJs dWUnPktlbnQsPC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPlRoZSBVc2VyLU5hbWUgTVVTVCBiZSBwb3B1bGF0ZWQg d2l0aCB0aGUNCk1OLU5BSS1FeHRlbnNpb24gaWYgYXZpYWxhYmxlLiZuYnNwOyBJZiBNTi1OQUkt RXh0ZW5zaW9uIGlzIG5vdCBhdmFpbGFibGUgdGhlDQpVc2VyLU5hbWUgTUFZIGJlIGxlZnQgYmxh bmsuJm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPktMJmd0OyBJZiB0aGUgTU4tTkFJLUV4dGVuc2lvbiBpcyBhYnNlbnQs DQp0aGVuIHRoZSBVc2VyLU5hbWUgQVZQIE1BWSBiZSBsZWZ0IG91dCBvZiB0aGUgUkFESVVTIG1l c3NhZ2VzLCByaWdodD8mbmJzcDsgVGhlDQpVc2VyLU5hbWUgc3RyaW5nIGZpZWxkIGhhcyB0byBi ZSAmZ3Q7PSAzIG9jdGV0cy48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+WW91IGFyZSBjb3JyZWN0LiBZT3UgY2FudCBzZW5kIGEN CmJsYW5rLiZuYnNwOyBJdCBtdXN0IGJlIG9tbWl0dGVkLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0 Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxibG9ja3F1b3RlIHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQ7DQptYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+RnJv bTo8L3NwYW4+PC9iPiBLZW50IExldW5nIChrbGV1bmcpDQpbbWFpbHRvOmtsZXVuZ0BjaXNjby5j b21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwvc3Bhbj48 L2I+IEZyaWRheSwgTWF5IDEzLCAyMDA1IDQ6MDcgUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gQXZpIExpb3I7IE5ha2hqaXJpDQpNYWRqaWQt TU5BS0hKSTE7IENob3dkaHVyeSwgS3VudGFsPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2Vp Z2h0OmJvbGQnPkNjOjwvc3Bhbj48L2I+IE1vYmlsZSBJUHY0IE1haWxpbmcgTGlzdDxicj4NCjxi PjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBb TWlwNF0gcmVzb2x1dGlvbiBvZg0KUkFESVVTLU1JUCBpZGVudGlmaWVyIGlzc3Vlcz8/PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+SGkgQXZpLiZuYnNwOyBDb21tZW50cyBiZWxvdyBpbg0KJnF1b3Q7 S0wmZ3Q7JnF1b3Q7Ljwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ow0KbWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGln bj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6 ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxmb250 IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZv bnQNCnNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpUYWhvbWEnPiBBdmkgTGlvcg0KW21haWx0bzphdmlAYnJpZGdld2F0ZXJzeXN0ZW1z LmNvbV0gPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFu PjwvYj4gRnJpZGF5LCBNYXkgMTMsIDIwMDUgODo0MyBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBLZW50IExldW5nIChrbGV1bmcpOyBOYWto amlyaQ0KTWFkamlkLU1OQUtISkkxOyBBdmkgTGlvcjsgQ2hvd2RodXJ5LCBLdW50YWw8YnI+DQo8 Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gTW9iaWxlIElQ djQgTWFpbGluZyBMaXN0PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1 YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtNaXA0XSByZXNvbHV0aW9uIG9mDQpSQURJVVMtTUlQIGlk ZW50aWZpZXIgaXNzdWVzPz88L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVl Jz5XZSBuZWVkIHRvIGNsZWFyIHRoaXMgdXAgZmlyc3Q6PC9zcGFuPjwvZm9udD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPjI4NjUgRG9lcyBub3QgbWFu ZGF0ZSB0aGUgdXNlci1uYW1lIGlzDQpyZXF1aXJlZCBpbiBBY2Nlc3MtUmVxdWVzdC48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+ S0wmZ3Q7IEkgd2FzIGxvb2tpbmcgYXQgUkZDIDIxMzggKG15IHVzdWFsDQpyZWZlcmVuY2UgOiks IHdoaWNoIGlzIG9ic29sZXRlZCBieSB0aGlzIFJGQy48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3Nw YW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SGVyZSBhcmUgdGhl IGFwcHJvcHJpYXRlIHNuaXBwZXRzLi4uLi48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9m b250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+U2VjdGlvbiA0LjEgQWNjZXNzLVJlcXVl c3Q8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+Li4uLi4gQW4gQWNj ZXNzLVJlcXVlc3QgU0hPVUxEIGNvbnRhaW4gYQ0KVXNlci1OYW1lIGF0dHJpYnV0ZS48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+ U2VjdGlvbiA1LjEgVXNlci1OYW1lPC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPlVzZXItTmFtZTwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz4mbmJzcDsmbmJzcDsg RGVzY3JpcHRpb248L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMNCkF0 dHJpYnV0ZSBpbmRpY2F0ZXMgdGhlIG5hbWUgb2YgdGhlIHVzZXIgdG8gYmUgYXV0aGVudGljYXRl ZC48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgTVVTVCBiZSBzZW50IGlu IEFjY2Vzcy1SZXF1ZXN0IHBhY2tldHMgaWYNCmF2YWlsYWJsZS48L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SGVyZSBpcyB0aGUg ZW50cnkgaW4gdGhlIHRhYmxlLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpi bHVlJz4mbmJzcDtSZXF1ZXN0Jm5ic3A7Jm5ic3A7DQpBY2NlcHQmbmJzcDsmbmJzcDsgUmVqZWN0 Jm5ic3A7Jm5ic3A7IENoYWxsZW5nZSZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7DQpB dHRyaWJ1dGU8YnI+DQombmJzcDsmbmJzcDsgMC0xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQowLTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMSZuYnNwOyZuYnNw OyBVc2VyLU5hbWU8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+S0wmZ3Q7IE9LLCBVc2VyLU5hbWUgQVZQIG1heSBiZSBub3QgaW4g dGhlDQptZXNzYWdlcy48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+QW5kIGhlcmUgaXMgd2hh dCAyODY1IHNheXMgYWJvdXQgcm91dGluZzo8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6Ymx1ZSc+VGhlIFVzZXItTmFtZTxicj4NCiZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgTUFZ IGNvbnRhaW4gYSBOZXR3b3JrIEFjY2VzcyBJZGVudGlmaWVyIFs4XSBmb3IgUkFESVVTPGJyPg0K Jm5ic3A7Jm5ic3A7IFByb3h5IG9wZXJhdGlvbnMuJm5ic3A7IFRoZSBjaG9pY2Ugb2Ygd2hpY2gg c2VydmVyIHJlY2VpdmVzIHRoZQ0KZm9yd2FyZGVkPGJyPg0KJm5ic3A7Jm5ic3A7IHJlcXVlc3Qg U0hPVUxEIGJlIGJhc2VkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiAmcXVvdDtyZWFsbSZxdW90Oy4N ClRoZTxicj4NCiZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGlvbiByZWFsbSBNQVkgYmUgdGhlIHJl YWxtIHBhcnQgb2YgYSBOZXR3b3JrIEFjY2Vzczxicj4NCiZuYnNwOyZuYnNwOyBJZGVudGlmaWVy IChhICZxdW90O25hbWVkIHJlYWxtJnF1b3Q7KS4mbmJzcDsgQWx0ZXJuYXRpdmVseSwgdGhlDQpj aG9pY2Ugb2Ygd2hpY2g8YnI+DQombmJzcDsmbmJzcDsgc2VydmVyIHJlY2VpdmVzIHRoZSBmb3J3 YXJkZWQgcmVxdWVzdCBNQVkgYmUgYmFzZWQgb24gd2hhdGV2ZXINCm90aGVyPGJyPg0KJm5ic3A7 Jm5ic3A7IGNyaXRlcmlhIHRoZSBmb3J3YXJkaW5nIHNlcnZlciBpcyBjb25maWd1cmVkIHRvIHVz ZSwgc3VjaCBhcw0KQ2FsbGVkLTxicj4NCiZuYnNwOyZuYnNwOyBTdGF0aW9uLUlkIChhICZxdW90 O251bWJlcmVkIHJlYWxtJnF1b3Q7KS48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250 PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+S0wmZ3Q7IE9LPC9zcGFuPjwvZm9udD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5i c3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPlNvIGhlcmUgaXMg dGhlIHRhYmxlIG9mIGF0dHJpYnV0ZXMuJm5ic3A7DQooVGhpcyBob3BlZnVsbHkgc2ltcGxpZmll cyB0aGUgc3VtbWFyeSk8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPlJBRElVUyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBNSVA8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+LS0tLS0t LS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tPC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOmJsdWUnPlVzZXItTmFtZSAmbHQ7LS0tDQpNTi1OQUktRXh0ZW5zaW9u Jm5ic3A7KHNlZSBub3RlIGJlbG93KTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpibHVlJz5NTl9IT0EmbmJzcDsmbmJzcDsgJmx0Oy0tLSBIT0EgKGlmDQphdmFpbGFibGUpPC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkhBX0lQJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombHQ7LS0tLSBIQV9JUCAoaWYgYXZhaWxhYmxlKTwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5OQVNfSVAmbmJzcDsmbmJz cDsmbmJzcDsgJmx0Oy0tLS0tIGFzIHBlcg0KUkFESVVTLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpibHVlJz5OQVNfSUQmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0tLS0tIGFz IHBlcg0KUkFESVVTLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpibHVlJz5UaGUgVXNlci1OYW1lIE1VU1QgYmUgcG9wdWxhdGVkIHdpdGgg dGhlDQpNTi1OQUktRXh0ZW5zaW9uIGlmIGF2aWFsYWJsZS4mbmJzcDsgSWYgTU4tTkFJLUV4dGVu c2lvbiBpcyBub3QgYXZhaWxhYmxlIHRoZQ0KVXNlci1OYW1lIE1BWSBiZSBsZWZ0IGJsYW5rLiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5LTCZndDsgSWYgdGhlIE1OLU5BSS1FeHRlbnNpb24gaXMgYWJzZW50LA0KdGhl biB0aGUgVXNlci1OYW1lIEFWUCBNQVkgYmUgbGVmdCBvdXQgb2YgdGhlIFJBRElVUyBtZXNzYWdl cywgcmlnaHQ/Jm5ic3A7IFRoZQ0KVXNlci1OYW1lIHN0cmluZyBmaWVsZCBoYXMgdG8gYmUgJmd0 Oz0gMyBvY3RldHMuPC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPiZuYnNwOyBJZiByb3V0aW5n IG9mIHRoZSBBY2Nlc3MtUmVxdWVzdCBpcw0KcmVxdWlyZWQgaXQgbWF5IGJlIHBlcmZvcm1lZCBi YXNlZCBvbiB3aGF0ZXZlciBvdGhlciBjcml0ZXJpYSBjcml0ZXJpYSB0aGUNCmZvcndhcmRpbmcg c2VydmVyIGlzIGNvbmZpZ3VyZWQgdG8gdXNlIHN1Y2ggYXMgSG9BIG9yIEhBLUlQLiZuYnNwOyBJ ZiB0aGUgTkFJDQppcyBub3QgYXZhaWxhYmxlLCZuYnNwO3RoZSZuYnNwO1JBRElVUyBjbGllbnQm bmJzcDtNQVkgcG9wdWxhdGUgdGhlIHVzZXIgbmFtZQ0Kd2l0aCBhIHZhbHVlIG9mIDwvc3Bhbj48 L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmFubm9ueW1vdXNAcmVhbG0iPjxmb250IHNpemU9Mg0KZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+ YW5ub255bW91c0ByZWFsbTwvc3Bhbj48L2ZvbnQ+PC9hPjxmb250DQpzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsOw0KY29sb3I6Ymx1ZSc+IHdoZXJlIHJlYWxtIGlzIHRoZSByZXN1bHQgb2YgZG9pbmcgYSBE TlMgbG9va3VwIHVzaW5nIEhvQSBvcg0KSEEtSVAuJm5ic3A7IFtOT1RFIHdlIG5lZWQgdG8gY2hl Y2sgdGhlIE5BSSBiaWJsZV08L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+c2VlIG1vcmUgaW5s aW5lPGJyPg0KJm5ic3A7Jmx0O3NuaXAmZ3Q7Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPktlbnQ8L3NwYW4+PC9mb250 PjwvcD4NCg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8L2Rp dj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C55A2F.EA5CB878-- --===============1977146486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1977146486==-- From mip4-bounces@ietf.org Mon May 16 14:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXk0F-0003to-JL; Mon, 16 May 2005 14:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXk0D-0003tj-EJ for mip4@megatron.ietf.org; Mon, 16 May 2005 14:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18735 for ; Mon, 16 May 2005 14:07:39 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkGm-0006Xd-WE for mip4@ietf.org; Mon, 16 May 2005 14:24:50 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 May 2005 14:07:26 -0400 Message-ID: From: Avi Lior To: Nakhjiri Madjid-MNAKHJI1 , "'Avi Lior'" , "'Kent Leung (kleung)'" , "Chowdhury, Kuntal" Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Date: Mon, 16 May 2005 14:07:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.4 (/) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0950907057==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0950907057== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55A42.17A1ACA0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55A42.17A1ACA0 Content-Type: text/plain You cant send a blank attribute. We can force it to nul. But there is no point in doing that. This is the statement that we need to make: MN-NAI-Extension, if available, SHOULD be placed in the User-Name attribute. Reason behind it: 1) Why SHOULD. Some application may want to put something else in the User-Name attribute. There maybe a better NAI and we dont want them to be forced to always use MN-NAI-Extenison 2) We dont want to say "If NAI is not avialable User-Name SHALL|SHOULD be ignored" because some deployments may have something else they can put in that attribute. So in the sprit of just doing mapping, then that is the only requirement that we should impose. However, we are still free to make some recommendations. -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, May 16, 2005 11:58 AM To: 'Avi Lior'; 'Kent Leung (kleung)'; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? I guess I missed the resolution. Do we or do we not send a blank User-Name attribute if NAI is missing? -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Friday, May 13, 2005 5:03 PM To: 'Kent Leung (kleung)'; Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Kent, The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. You are correct. YOu cant send a blank. It must be ommitted. -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Friday, May 13, 2005 4:07 PM To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? Hi Avi. Comments below in "KL>". _____ From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Friday, May 13, 2005 8:43 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues?? We need to clear this up first: 2865 Does not mandate the user-name is required in Access-Request. KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC. Here are the appropriate snippets..... Section 4.1 Access-Request ..... An Access-Request SHOULD contain a User-Name attribute. Section 5.1 User-Name User-Name Description This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. Here is the entry in the table. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name KL> OK, User-Name AVP may be not in the messages. And here is what 2865 says about routing: The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm"). KL> OK So here is the table of attributes. (This hopefully simplifies the summary) RADIUS MIP ------------ ----- User-Name <--- MN-NAI-Extension (see note below) MN_HOA <--- HOA (if available) HA_IP <---- HA_IP (if available) NAS_IP <----- as per RADIUS. NAS_ID <----- as per RADIUS. The User-Name MUST be populated with the MN-NAI-Extension if avialable. If MN-NAI-Extension is not available the User-Name MAY be left blank. KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right? The User-Name string field has to be >= 3 octets. If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP. If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. [NOTE we need to check the NAI bible] see more inline Kent ------_=_NextPart_001_01C55A42.17A1ACA0 Content-Type: text/html Message
You cant send a blank attribute.  We can force it to nul.  But there is no point in doing that. 
 
This is the statement that we need to make:
 
MN-NAI-Extension, if available, SHOULD be placed in the User-Name attribute.
 
Reason behind it:
 
1) Why SHOULD. Some application may want to put something else in the User-Name attribute.  There maybe a better NAI and we dont want them to be forced to always use MN-NAI-Extenison
 
2) We dont want to say "If NAI is not avialable User-Name SHALL|SHOULD be ignored" because some deployments may have something else they can put in that attribute.
 
So in the sprit of just doing mapping, then that is the only requirement that we should impose.  However, we are still free to make some recommendations.
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Monday, May 16, 2005 11:58 AM
To: 'Avi Lior'; 'Kent Leung (kleung)'; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

I guess I missed the resolution. Do we or do we not send a blank User-Name attribute if NAI is missing?

 

-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Friday, May 13, 2005 5:03 PM
To: 'Kent Leung (kleung)'; Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

 

Kent,

 

The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 

 

KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.

 

You are correct. YOu cant send a blank.  It must be ommitted.

 

-----Original Message-----
From: Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Friday, May 13, 2005 4:07 PM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

Hi Avi.  Comments below in "KL>".

 

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Friday, May 13, 2005 8:43 AM
To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

We need to clear this up first:

 

2865 Does not mandate the user-name is required in Access-Request.

 

KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC.

 

 

 

 

Here are the appropriate snippets.....

 

Section 4.1 Access-Request

..... An Access-Request SHOULD contain a User-Name attribute.

 

Section 5.1 User-Name

 

User-Name

 

   Description

 

      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.

 

Here is the entry in the table.

 Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name

 

KL> OK, User-Name AVP may be not in the messages.

 

 

And here is what 2865 says about routing:

The User-Name
   attribute MAY contain a Network Access Identifier [8] for RADIUS
   Proxy operations.  The choice of which server receives the forwarded
   request SHOULD be based on the authentication "realm". The
   authentication realm MAY be the realm part of a Network Access
   Identifier (a "named realm").  Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").

 

KL> OK

 

So here is the table of attributes.  (This hopefully simplifies the summary)

 

RADIUS     MIP

------------     -----

User-Name <--- MN-NAI-Extension (see note below)

MN_HOA   <--- HOA (if available)

HA_IP       <---- HA_IP (if available)

NAS_IP    <----- as per RADIUS.

NAS_ID    <----- as per RADIUS.

 

The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 

 

KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.

 

 

  If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY populate the user name with a value of annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP.  [NOTE we need to check the NAI bible]

 

 

see more inline
 <snip> 

 

Kent

------_=_NextPart_001_01C55A42.17A1ACA0-- --===============0950907057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0950907057==-- From mip4-bounces@ietf.org Thu May 19 15:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqyS-0006Pv-38; Thu, 19 May 2005 15:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqyO-0006Oy-GR; Thu, 19 May 2005 15:46:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14981; Thu, 19 May 2005 15:46:22 -0400 (EDT) Message-Id: <200505191946.PAA14981@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 19 May 2005 15:46:21 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dynamic-assignment-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Dynamic Home Agent Assignment Author(s) : M. Kulkarni, et al. Filename : draft-ietf-mip4-dynamic-assignment-04.txt Pages : 23 Date : 2005-5-19 Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). This draft proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-dynamic-assignment-04.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-mip4-dynamic-assignment-04.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: <2005-5-19153551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dynamic-assignment-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-19153551.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sun May 22 16:12:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwnt-0003hO-DL; Sun, 22 May 2005 16:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwns-0003hI-EJ for mip4@megatron.ietf.org; Sun, 22 May 2005 16:12:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21862 for ; Sun, 22 May 2005 16:12:02 -0400 (EDT) Received: from berlin.ucdavis.edu ([169.237.104.158]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZx5h-0001o9-AB for mip4@ietf.org; Sun, 22 May 2005 16:30:30 -0400 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by berlin.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j4MKBuAf027038 for ; Sun, 22 May 2005 13:11:56 -0700 (PDT) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j4MKBuVV010194 for ; Sun, 22 May 2005 13:11:56 -0700 (PDT) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id j4MKBuQd010193; Sun, 22 May 2005 13:11:56 -0700 (PDT) Date: Sun, 22 May 2005 13:11:56 -0700 (PDT) Message-Id: <200505222011.j4MKBuQd010193@lymeon.ucdavis.edu> To: mip4@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mip4] Call for Paper: JSAC-MRNM (The deadline is approaching.) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 23 17:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKH0-0003Kz-Ba; Mon, 23 May 2005 17:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKGy-0003Km-In; Mon, 23 May 2005 17:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21741; Mon, 23 May 2005 17:15:38 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKYz-0001H1-Mc; Mon, 23 May 2005 17:34:20 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4NLDx305503; Mon, 23 May 2005 14:13:59 -0700 (PDT) Message-Id: <200505232113.j4NLDx305503@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 23 May 2005 14:13:59 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mip4@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip4] RFC 4064 on Experimental Message, Extensions, and Error Codes for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4064 Title: Experimental Message, Extensions, and Error Codes for Mobile IPv4 Author(s): A. Patel, K. Leung Status: Standards Track Date: May 2005 Mailbox: alpesh@cisco.com, kleung@cisco.com Pages: 11 Characters: 20748 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip4-experimental-messages-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4064.txt Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. This document is a product of the Mobility for IPv4 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050523141233.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4064 --OtherAccess Content-Type: Message/External-body; name="rfc4064.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050523141233.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon May 23 18:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTc-0007Yt-9O; Mon, 23 May 2005 18:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTQ-0007Vw-Pv; Mon, 23 May 2005 18:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05735; Mon, 23 May 2005 18:32:34 -0400 (EDT) From: rfc-editor@rfc-editor.org Received: from mail.ci.sugar-land.tx.us ([66.150.129.211]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLlU-0006Po-IO; Mon, 23 May 2005 18:51:17 -0400 Received: from svrpd14 ([192.168.2.137]) by mail.ci.sugar-land.tx.us; Mon, 23 May 2005 17:31:44 -0500 MIME-Version: 1.0 Date: Mon, 23 May 2005 17:31:43 -0500 X-Priority: 3 (Normal) To: ietf-announce@ietf.org, mip4@ietf.org, rfc-editor@rfc-editor.org X-Mailer: GWAVA Archive Mailer Content-Type: multipart/mixed; boundary="----=_NextPart_290_9db8_a90946b6.8350a70a_.MIX" Message-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Subject: [Mip4] RFC 4064 on Experimental Message, Extensions, and Error Codes for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new Request for Comments is now available in online RFC libraries. RFC 4064 Title: Experimental Message, Extensions, and Error Codes for Mobile IPv4 Author(s): A. Patel, K. Leung Status: Standards Track Date: May 2005 Mailbox: alpesh@cisco.com, kleung@cisco.com Pages: 11 Characters: 20748 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip4-experimental-messages-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4064.txt Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. This document is a product of the Mobility for IPv4 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute =2E.. Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: application/octet-stream; name="2#Part.001" Content-Disposition: attachment; filename="2#Part.001" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMjMzLlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDY0DQo= ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: text/plain; name="3#rfc4064.txt" Content-Disposition: attachment; filename="3#rfc4064.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <050523141233.RFC@RFC-EDITOR.ORG> ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: application/octet-stream; name="4#Part.003" Content-Disposition: attachment; filename="4#Part.003" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo= ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: application/octet-stream; name="5#Mime.822" Content-Disposition: attachment; filename="5#Mime.822" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWVnYXRyb24uaWV0Zi5vcmcgWzEzMi4xNTEuNi43MV0NCglieSBt YWlsLmNpLnN1Z2FyLWxhbmQudHgudXM7IE1vbiwgMjMgTWF5IDIwMDUgMTY6Mjc6NDAgLTA1 MDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAoWzEyNy4wLjAuMV0g aGVsbz1tZWdhdHJvbi5pZXRmLm9yZykNCglieSBtZWdhdHJvbi5pZXRmLm9yZyB3aXRoIGVz bXRwIChFeGltIDQuMzIpDQoJaWQgMURhS0gzLTAwMDNMTy1IZzsgTW9uLCAyMyBNYXkgMjAw NSAxNzoxNTo0NSAtMDQwMA0KUmVjZWl2ZWQ6IGZyb20gb2Rpbi5pZXRmLm9yZyAoWzEzMi4x NTEuMS4xNzZdIGhlbG89aWV0Zi5vcmcpDQoJYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBl c210cCAoRXhpbSA0LjMyKQ0KCWlkIDFEYUtHeS0wMDAzS20tSW47IE1vbiwgMjMgTWF5IDIw MDUgMTc6MTU6NDAgLTA0MDANClJlY2VpdmVkOiBmcm9tIGlldGYtbXguaWV0Zi5vcmcgKGll dGYtbXguaWV0Zi5vcmcgWzEzMi4xNTEuNi4xXSkNCglieSBpZXRmLm9yZyAoOC45LjFhLzgu OS4xYSkgd2l0aCBFU01UUCBpZCBSQUEyMTc0MTsNCglNb24sIDIzIE1heSAyMDA1IDE3OjE1 OjM4IC0wNDAwIChFRFQpDQpSZWNlaXZlZDogZnJvbSBib3JlYXMuaXNpLmVkdSAoWzEyOC45 LjE2MC4xNjFdKQ0KCWJ5IGlldGYtbXguaWV0Zi5vcmcgd2l0aCBlc210cCAoRXhpbSA0LjMz KQ0KCWlkIDFEYUtZei0wMDAxSDEtTWM7IE1vbiwgMjMgTWF5IDIwMDUgMTc6MzQ6MjAgLTA0 MDANClJlY2VpdmVkOiBmcm9tIElTSS5FRFUgKGFkbWEuaXNpLmVkdSBbMTI4LjkuMTYwLjIz OV0pDQoJYnkgYm9yZWFzLmlzaS5lZHUgKDguMTEuNnAyKzA5MTcvOC4xMS4yKSB3aXRoIEVT TVRQIGlkIGo0TkxEeDMwNTUwMzsNCglNb24sIDIzIE1heSAyMDA1IDE0OjEzOjU5IC0wNzAw IChQRFQpDQpNZXNzYWdlLUlkOiA8MjAwNTA1MjMyMTEzLmo0TkxEeDMwNTUwM0Bib3JlYXMu aXNpLmVkdT4NClRvOiBpZXRmLWFubm91bmNlQGlldGYub3JnDQpGcm9tOiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnDQpNaW1lLVZlcnNpb246IDEuMA0KQ29udGVudC1UeXBlOiBNdWx0 aXBhcnQvTWl4ZWQ7IEJvdW5kYXJ5PU5leHRQYXJ0DQpEYXRlOiBNb24sIDIzIE1heSAyMDA1 IDE0OjEzOjU5IC0wNzAwDQpYLUlTSS00LTM5LTYtTWFpbFNjYW5uZXI6IEZvdW5kIHRvIGJl IGNsZWFuDQpYLU1haWxTY2FubmVyLUZyb206IHJmYy1lZEBpc2kuZWR1DQpYLVNwYW0tU2Nv cmU6IC0xNC42ICgtLS0tLS0tLS0tLS0tLSkNClgtU2Nhbi1TaWduYXR1cmU6IDZlOTIyNzky MDI0NzMyZmIxYmI2ZjM0NmU2MzUxN2U0DQpDYzogbWlwNEBpZXRmLm9yZywgcmZjLWVkaXRv ckByZmMtZWRpdG9yLm9yZw0KU3ViamVjdDogUkZDIDQwNjQgb24gIEV4cGVyaW1lbnRhbCBN ZXNzYWdlLCBFeHRlbnNpb25zLA0KCWFuZCBFcnJvciBDb2RlcyBmb3IgTW9iaWxlIElQdjQN ClgtQmVlblRoZXJlOiBpZXRmLWFubm91bmNlQGlldGYub3JnDQpYLU1haWxtYW4tVmVyc2lv bjogMi4xLjUNClByZWNlZGVuY2U6IGxpc3QNCkxpc3QtSWQ6IGlldGYtYW5ub3VuY2UuaWV0 Zi5vcmcNCkxpc3QtVW5zdWJzY3JpYmU6IDxodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZXRmLWFubm91bmNlPiwNCgk8bWFpbHRvOmlldGYtYW5ub3VuY2UtcmVx dWVzdEBpZXRmLm9yZz9zdWJqZWN0PXVuc3Vic2NyaWJlPg0KTGlzdC1Qb3N0OiA8bWFpbHRv OmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQpMaXN0LUhlbHA6IDxtYWlsdG86aWV0Zi1hbm5v dW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4NCkxpc3QtU3Vic2NyaWJlOiA8 aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZT4s DQoJPG1haWx0bzppZXRmLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJz Y3JpYmU+DQpTZW5kZXI6IGlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZw0KRXJyb3Jz LVRvOiBpZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCg0KDQotLU5leHRQYXJ0DQoN Cg0KQSBuZXcgUmVxdWVzdCBmb3IgQ29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxp bmUgUkZDIGxpYnJhcmllcy4NCg0KDQogICAgICAgIFJGQyA0MDY0DQoNCiAgICAgICAgVGl0 bGU6ICAgICAgRXhwZXJpbWVudGFsIE1lc3NhZ2UsIEV4dGVuc2lvbnMsIGFuZCBFcnJvciBD b2Rlcw0KICAgICAgICAgICAgICAgICAgICBmb3IgTW9iaWxlIElQdjQNCiAgICAgICAgQXV0 aG9yKHMpOiAgQS4gUGF0ZWwsIEsuIExldW5nDQogICAgICAgIFN0YXR1czogICAgIFN0YW5k YXJkcyBUcmFjaw0KICAgICAgICBEYXRlOiAgICAgICBNYXkgMjAwNQ0KICAgICAgICBNYWls Ym94OiAgICBhbHBlc2hAY2lzY28uY29tLCBrbGV1bmdAY2lzY28uY29tDQogICAgICAgIFBh Z2VzOiAgICAgIDExDQogICAgICAgIENoYXJhY3RlcnM6IDIwNzQ4DQogICAgICAgIFVwZGF0 ZXMvT2Jzb2xldGVzL1NlZUFsc286ICAgIE5vbmUNCg0KICAgICAgICBJLUQgVGFnOiAgICBk cmFmdC1pZXRmLW1pcDQtZXhwZXJpbWVudGFsLW1lc3NhZ2VzLTAyLnR4dA0KDQogICAgICAg IFVSTDogICAgICAgIGZ0cDovL2Z0cC5yZmMtZWRpdG9yLm9yZy9pbi1ub3Rlcy9yZmM0MDY0 LnR4dA0KDQoNCk1vYmlsZSBJUHY0IG1lc3NhZ2UgdHlwZXMgcmFuZ2UgZnJvbSAwIHRvIDI1 NS4gIFRoaXMgZG9jdW1lbnQNCnJlc2VydmVzIGEgbWVzc2FnZSB0eXBlIGZvciB1c2UgYnkg YW4gaW5kaXZpZHVhbCwgY29tcGFueSwgb3INCm9yZ2FuaXphdGlvbiBmb3IgZXhwZXJpbWVu dGFsIHB1cnBvc2VzLCB0byBldmFsdWF0ZSBlbmhhbmNlbWVudHMNCnRvIE1vYmlsZSBJUHY0 IG1lc3NhZ2VzIGJlZm9yZSBhIGZvcm1hbCBzdGFuZGFyZHMgcHJvcG9zYWwgaXMgaXNzdWVk Lg0KDQpUaGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgTW9iaWxpdHkgZm9yIElQ djQgV29ya2luZyBHcm91cCBvZg0KdGhlIElFVEYuDQoNClRoaXMgaXMgbm93IGEgUHJvcG9z ZWQgU3RhbmRhcmQgUHJvdG9jb2wuDQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIElu dGVybmV0IHN0YW5kYXJkcyB0cmFjayBwcm90b2NvbCBmb3INCnRoZSBJbnRlcm5ldCBjb21t dW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9ucw0KZm9yIGlt cHJvdmVtZW50cy4gIFBsZWFzZSByZWZlciB0byB0aGUgY3VycmVudCBlZGl0aW9uIG9mIHRo ZQ0KIkludGVybmV0IE9mZmljaWFsIFByb3RvY29sIFN0YW5kYXJkcyIgKFNURCAxKSBmb3Ig dGhlDQpzdGFuZGFyZGl6YXRpb24gc3RhdGUgYW5kIHN0YXR1cyBvZiB0aGlzIHByb3RvY29s LiAgRGlzdHJpYnV0aW9uDQpvZiB0aGlzIG1lbW8gaXMgdW5saW1pdGVkLg0KDQpUaGlzIGFu bm91bmNlbWVudCBpcyBzZW50IHRvIHRoZSBJRVRGIGxpc3QgYW5kIHRoZSBSRkMtRElTVCBs aXN0Lg0KUmVxdWVzdHMgdG8gYmUgYWRkZWQgdG8gb3IgZGVsZXRlZCBmcm9tIHRoZSBJRVRG IGRpc3RyaWJ1dGlvbiBsaXN0DQpzaG91bGQgYmUgc2VudCB0byBJRVRGLVJFUVVFU1RASUVU Ri5PUkcuICBSZXF1ZXN0cyB0byBiZQ0KYWRkZWQgdG8gb3IgZGVsZXRlZCBmcm9tIHRoZSBS RkMtRElTVCBkaXN0cmlidXRpb24gbGlzdCBzaG91bGQNCmJlIHNlbnQgdG8gUkZDLURJU1Qt UkVRVUVTVEBSRkMtRURJVE9SLk9SRy4NCg0KRGV0YWlscyBvbiBvYnRhaW5pbmcgUkZDcyB2 aWEgRlRQIG9yIEVNQUlMIG1heSBiZSBvYnRhaW5lZCBieSBzZW5kaW5nDQphbiBFTUFJTCBt ZXNzYWdlIHRvIHJmYy1pbmZvQFJGQy1FRElUT1IuT1JHIHdpdGggdGhlIG1lc3NhZ2UgYm9k eSANCmhlbHA6IHdheXNfdG9fZ2V0X3JmY3MuICBGb3IgZXhhbXBsZToNCg0KICAgICAgICBU bzogcmZjLWluZm9AUkZDLUVESVRPUi5PUkcNCiAgICAgICAgU3ViamVjdDogZ2V0dGluZyBy ZmNzDQoNCiAgICAgICAgaGVscDogd2F5c190b19nZXRfcmZjcw0KDQpSZXF1ZXN0cyBmb3Ig c3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJlIGFkZHJlc3NlZCB0byBlaXRoZXIgdGhl DQphdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVzdGlvbiwgb3IgdG8gUkZDLU1hbmFnZXJAUkZD LUVESVRPUi5PUkcuICBVbmxlc3MNCnNwZWNpZmljYWxseSBub3RlZCBvdGhlcndpc2Ugb24g dGhlIFJGQyBpdHNlbGYsIGFsbCBSRkNzIGFyZSBmb3INCnVubGltaXRlZCBkaXN0cmlidXRp b24uDQoNClN1Ym1pc3Npb25zIGZvciBSZXF1ZXN0cyBmb3IgQ29tbWVudHMgc2hvdWxkIGJl IHNlbnQgdG8NClJGQy1FRElUT1JAUkZDLUVESVRPUi5PUkcuICBQbGVhc2UgY29uc3VsdCBS RkMgMjIyMywgSW5zdHJ1Y3Rpb25zIHRvIFJGQw0KQXV0aG9ycywgZm9yIGZ1cnRoZXIgaW5m b3JtYXRpb24uDQoNCg0KSm95Y2UgSy4gUmV5bm9sZHMgYW5kIFNhbmR5IEdpbm96YQ0KVVND L0luZm9ybWF0aW9uIFNjaWVuY2VzIEluc3RpdHV0ZQ0KDQouLi4NCg0KQmVsb3cgaXMgdGhl IGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBNYWlsIFJlYWRlciAN CmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZl cnNpb24NCm9mIHRoZSBSRkNzLg0KDQotLU5leHRQYXJ0DQpDb250ZW50LVR5cGU6IE11bHRp cGFydC9BbHRlcm5hdGl2ZTsgQm91bmRhcnk9Ik90aGVyQWNjZXNzIg0KDQotLU90aGVyQWNj ZXNzDQpDb250ZW50LVR5cGU6IE1lc3NhZ2UvRXh0ZXJuYWwtYm9keTsgYWNjZXNzLXR5cGU9 Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9IlJGQy1JTkZPQFJGQy1FRElUT1IuT1JHIg0KDQpD b250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtSUQ6IDwwNTA1MjMxNDEyMzMuUkZD QFJGQy1FRElUT1IuT1JHPg0KDQpSRVRSSUVWRTogcmZjDQpET0MtSUQ6IHJmYzQwNjQNCg0K LS1PdGhlckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IG5h bWU9InJmYzQwNjQudHh0Ijsgc2l0ZT0iZnRwLmlzaS5lZHUiOw0KCWFjY2Vzcy10eXBlPSJh bm9uLWZ0cCI7IGRpcmVjdG9yeT0iaW4tbm90ZXMiDQoNCkNvbnRlbnQtVHlwZTogdGV4dC9w bGFpbg0KQ29udGVudC1JRDogPDA1MDUyMzE0MTIzMy5SRkNAUkZDLUVESVRPUi5PUkc+DQoN Cg0KLS1PdGhlckFjY2Vzcy0tDQotLU5leHRQYXJ0DQpDb250ZW50LVR5cGU6IHRleHQvcGxh aW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KTUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHJh bnNmZXItRW5jb2Rpbmc6IDdiaXQNCkNvbnRlbnQtRGlzcG9zaXRpb246IGlubGluZQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSUVURi1B bm5vdW5jZSBtYWlsaW5nIGxpc3QNCklFVEYtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg0KLS1OZXh0 UGFydC0tDQoNCg== ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: text/plain; name="GWAVADAT.TXT" Content-Disposition: attachment; filename="GWAVADAT.TXT" Content-Transfer-Encoding: quoted-printable AdmID:4DDD0A62EBA77CBE10F8B8E606004A84 ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------=_NextPart_290_9db8_a90946b6.8350a70a_.MIX-- From mip4-bounces@ietf.org Mon May 23 18:33:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLU4-0007cR-7o; Mon, 23 May 2005 18:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLU3-0007cM-1D for mip4@megatron.ietf.org; Mon, 23 May 2005 18:33:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05779 for ; Mon, 23 May 2005 18:33:12 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLm6-0006Qo-0r for mip4@ietf.org; Mon, 23 May 2005 18:51:55 -0400 Received: from usdaln07347 (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4NMX2CR011986; Mon, 23 May 2005 17:33:03 -0500 (CDT) Message-Id: <200505232233.j4NMX2CR011986@auds953.usa.alcatel.com> From: "Tim Ozugur" To: Date: Mon, 23 May 2005 17:33:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcVPYqCdGhRw/vEsTTy5gWxhKF55nwQgYPcAAADJnJA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [Mip4] Call For Participation: BWAN 2005 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Apologies if you are receiving this message more than once) ----------------------------------------------------------- CALL FOR PARTICIPATION International Workshop on Broadband Wireless Access Network on fixed network (BWAN 2005) (http://www.bwan.org/) ORLANDO, FL - JUNE 15, 2005 co-located with International Conference on Multimedia Services Access Networks (MSAN'05) CO_SPONSORED BY IEEE ----------------------------------------------------------- International Workshop on Broadband Wireless Access Network on fixed network (BWAN 2005) will host a panel entitled "Future of Telecom Industry". PANEL: Today, Telecom Industry is moving in a new era where broadband wireless access is progressing quickly towards multi-access even though there are still technical challenges to tackle and new interesting business models are appearing in parallel for the benefit of customers. So, what will be the Telecom Industry and communication orientations for the future? A panel, including leaders like Global operators and industrials, such as - Alcatel - Alvarion - Flarion Technologies - Telenor will discuss some key challenges, including "Trends and Strategies on the Broadband mobile Wireless access network in 2010" during the BWAN workshop. --------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 31 03:27:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd19q-0003jR-0n; Tue, 31 May 2005 03:27:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbIGp-0002A8-KU; Thu, 26 May 2005 09:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27594; Thu, 26 May 2005 09:19:29 -0400 (EDT) Received: from nt-ftw.ftw.tuwien.ac.at ([128.130.90.21] helo=publications.ftw.tuwien.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbIZN-0000pE-Ro; Thu, 26 May 2005 09:38:44 -0400 Received: from mail.ftw.at by publications.ftw.tuwien.ac.at via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 26 May 2005 15:36:09 +0100 Received: from ftw.at ([192.168.0.36] RDNS failed) by mail.ftw.at with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 15:22:15 +0200 Message-ID: <4295CD7F.9070908@ftw.at> Date: Thu, 26 May 2005 15:22:07 +0200 From: Stavros Toumpis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Toumpis, Stavros" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2005 13:22:15.0448 (UTC) FILETIME=[EEFEB980:01C561F5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 May 2005 03:27:25 -0400 Cc: Subject: [Mip4] Wiopt 2006, Boston: Prelimininary Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Wiopt 2006 Preliminary Call for Papers The 4th International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt'06) April 3 - 7, 2006 Boston, Massachusetts http://www.wiopt.org SCOPE OF THE SYMPOSIUM ---------------------- The complexity of mobile, ad hoc, and wireless networks requires thoroughly founded models capturing their essential characteristics and new optimization techniques building upon such models. Insights into both the theoretical aspects of these problems as well as practical methods and tools are necessary. This symposium intends to bring together researchers and practitioners working on optimization issues from different perspectives, including performance analysis, mobile networking, wireless communication, and optimization theory. Contributions to this conference should show new modeling and optimization techniques suitable for mobile/wireless networks or innovative applications of these techniques to improve network operation. Topics of interest include, but are not limited to: * Modeling techniques and tools for wireless networks * Performance characterization & optimization of wireless networks * Wireless network optimization: Applications, algorithms, and tools * Protocol design for optimal wireless network utilization * Models and optimization approaches for energy efficiency, QoS, bandwidth economy and other aspects of wireless networks * Models and optimization techniques for non-standard network paradigms like sensor, vehicular, body area networks * Security and co-operation models for mobile and ad hoc networks * Pricing and incentives in wireless networks * Game theoretic techniques for mobile/wireless networks SUBMISSION INSTRUCTIONS ----------------------- Papers should be submitted as extended abstracts of up to 8 pages, single column format; and contain sufficient information to allow for a detailed review. The final manuscript will be 10 pages in double column format. Selected papers from WiOpt 2006 will appear in a special issue of ACM/Kluwer Monet. IMPORTANT DATES --------------- Submission deadline: Oct. 5, 2005 (5pm EST) Notification of acceptance: Dec. 5, 2005 Camera-ready copy: Jan. 5, 2006 Papers should be submitted in pdf or ps format through the EDAS system (http://edas.info). For more details, please visit http://www.wiopt.org General Chair ------------- I. Matta, Boston University, USA Vice General Chair ------------------ Christos Douligeris, University of Piraeus, Greece Program Co-Chairs ----------------- E. Modiano, MIT, USA Leandros Tassiulas, University of Thessaly, Greece Steering Committee ------------------ Eitan Altman, INRIA, France Tamer Basar, UIUC, USA Imrich Chlamtac, Create-Net, Italy (Chair) Marco Conti, IIT-CNR, Italy Jon Crowcroft, Cambridge University, UK Tony Ephremides, University of Maryland, USA Holger Karl, University of Paderborn, Germany Daniele Miorandi, CREATE-NET, Italy Roger Whitaker, Cardiff University, UK Workshops Steering Subcommittee ------------------------------- Chadi Barakat, INRIA, France Dina Papagiannaki, Intel Research Cambridge, UK Workshops Chair --------------- Mingyan Liu, University of Michigan, USA Local Arrangements Chair ------------------------ David Starobinski, Boston University, USA Publicity Chair --------------- Stavros Toumpis, ftw, Vienna Publications Chair ------------------ Guevara Noubir, Northeastern University, USA ADJUNCT WORKSHOPS ----------------- Several one-day workshops will accompany the main WiOpt Symposium: * WINMEE 2006: Measurement in Wireless Networks Chairs: K. Almeroth (UCSB) Kave Salamatian (LIP6-CNRS, Univ. Pierre et Marie Curie) * RAWNET 2006: Resource Allocation in Wireless Networks Chairs: S. Borst (Bell Labs.-CWI) A. Proutiere (France Telecom R&D) * SPASWIN 2006: Stochastic Geometry for Wireless Networks Chairs: M. Fransescheti (USCD) P. Thiran (EPFL) * NETCOD 2006: Network Coding and Information Theory Chairs: R. Kotter (UIUC) M. Medard (MIT) SPONSORSHIP ----------- Wiopt'06 is co-sponsored by Create-net, ICST, Boston University, INRIA, the ACM (approval for cooperation pending), and the IEEE Information Theory, Control and Communications Societies (approval pending). -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 02 12:21:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsRR-0004qW-Hc; Thu, 02 Jun 2005 12:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdBJ6-0001aC-OB for mip4@megatron.ietf.org; Tue, 31 May 2005 14:17:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03524 for ; Tue, 31 May 2005 14:17:38 -0400 (EDT) Received: from pantheon-po06.its.yale.edu ([130.132.50.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdBUe-0000eN-Rr for mip4@ietf.org; Tue, 31 May 2005 14:29:39 -0400 Received: from websrv3b.its.yale.edu (websrv3b.its.yale.edu [130.132.41.26]) by pantheon-po06.its.yale.edu (8.12.11/8.12.11) with ESMTP id j4VI9GN2027898 for ; Tue, 31 May 2005 14:09:16 -0400 Received: from mail pickup service by websrv3b.its.yale.edu with Microsoft SMTPSVC; Tue, 31 May 2005 14:07:24 -0400 X-Mailer: Microsoft CDO for Windows 2000 List-Software: Yale ITS Message II System (9926) From: "Mobiquitous Organizers" To: "Mobiquitous Organizing Committee" Date: Tue, 31 May 2005 14:07:24 -0400 Message-ID: <002b01c5660b$98c1d380$1a298482@yu.yale.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcVmC5i6qm4MRp9YRkKtSjxQ1n1Vyg== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 31 May 2005 18:07:24.0782 (UTC) FILETIME=[9904A8E0:01C5660B] X-YaleITSMailFilter: Version 1.2b (attachment(s) not renamed) X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 02 Jun 2005 12:21:08 -0400 Cc: Subject: [Mip4] MobiQ 2005 - Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Dear Colleague, Enclosed below please find the Call for Participation for the Second = Annual International Conference on Mobile and Ubiquitous Systems: = Networking and Services (MobiQuitous 2005) to be held July 17-21, 2005, = San Diego, California on the UCSD, La Jolla campus. The conference program consists of keynote talks, technical papers, = panels, challenges session, posters and demos. For complete information = about the conference, please visit: http://www.mobiquitous.org Important Deadlines: Discounted Registration Deadline: June 17, 2005 We apologize if you received multiple copies of this Call for = Participation. Please feel free to distribute it to those who might be = interested. Very truly yours, Mobiquitous 2005 Organizing Committee *********************************************************************** MobiQuitous 2005 CALL FOR PARTICIPATION The Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services http://www.mobiquitous.org July 17-21, 2005, San Diego, California Early registration ends: June 17, 2005 DEMO Submissions still accepted! Sponsored by: CreateNet (www.create-net.it) and ICST CalIT2 (www.calit2.net) In Cooperation with AAAI Technically Co-Sponsored by ACM SIGMOBILE Technically Co-Sponsored by IEEE Computer Society Proceedings to be published by IEEE Computer Society Press and to be = made available on IEEE Xplore *********************************************************************** The combination of mobile and ubiquitous computing is emerging as a = promising new paradigm with the goal to provide computing and = communication services all the time, everywhere, transparently and = invisibly to the user, using devices embedded in the surrounding = physical environment. In this context, the communication devices, the = objects with which they interact, or both may be mobile. The = implementation of such a paradigm requires advances in wireless network = technologies and devices, development of infrastructures supporting = cognitive environments, and discovery and identification of ubiquitous = computing applications and services. The second Annual International Conference on Mobile and Ubiquitous = Systems: networking and services (Mobiquitous-05) will cover all these = aspects, representing a forum where practitioners and researchers coming = from the many areas involved in ubiquitous solutions design and = deployment will be able to interact exchanging the cross-layer = experiences needed to build the overall ubiquitous systems. Areas = addressed by the conference include: applications, service-oriented = computing, middleware, networking, agents, knowledge management and = databases. DEMOS: Proposals for research and industrial demos are solicited. A = maximum of 2 pages should be submitted which include a description of = the demo and needed resources from the conference organizers. Proposals = should be submitted to Dr. Ramiro Liscano (Demo Chair) rliscano@ieee.org = by June 10, 2005. -------------- TENTATIVE TECHNICAL PROGRAM -------------- *************************************************************** Sunday, July 17, 2005 Workshops *************************************************************** Monday, July 18, 2005 8.30AM - 9.00 AM: Welcome, Introduction 9.00AM - 10.00AM: Robert Hecht-Nielsen, Univ of California, San Diego = Calit2 Title: The Fundamental Mechanism of Cognition 10.00AM - 10.30AM: Break 10.00 AM - 12.30 PM: Poster Session 1 Dynamically Re-Configurable Communication Protocols using Key = Identifiers Kaushalya Premadasa, Bjorn Landfeldt An Analysis of Strategies for Mitigating the Sensor Network Hot Spot = Problem Zhao Cheng, Mark Perillo, Wendi Heinzelman JiTS: Just-in-Time Scheduling for Real-Time Sensor Data Dissemination Ke Liu, Nael Abu-Ghazaleh Channel Characteristics for On-Body Mica2Dot Wireless Sensor Networks David Jea, Mani Srivastava CustoMed: A Power Optimized Customizable and Mobile Medical Monitoring = and Analysis System Roozbeh Jafari, Foad Dabiri, Majid Sarrafzadeh Agent Negotiation in Ad-Hoc Networks Cosmin Carabelea, Michael Berger Building a Ubiquitous Platform for Remote Sensing Using Smartphones Dirk Trossen, Dana Pavel Orion: P2P-based Inter-space Context Discovery Platform Chung-Yau Chin, Daqing Zhang, Mohan Gurusamy MAIPAN -- Middleware for Application Interconnection in Personal Area = Networks Miklos Aurel Ronai, Kristof Fodor, Gergely Biczok, Zoltan Turanyi, Andras Valko 10.30AM - 12.00 Noon: Session 1: Security and Resource Management A Reputation-based Mechanism for Isolating Selfish Nodes in Ad Hoc = Networks Secure Reporting of Traffic Forwarding Activity in Mobile Ad Hoc = Networks Defend Against Cache Consistency Attacks in Wireless Ad Hoc Networks A Policy-based Resource Management Framework for Active Spaces 12.00PM - 1.30PM: Lunch 1.30PM - 3.00PM: Panel on "Security, cooperation and safety in mobile = ubiquitous networks" Panel Chair: Ahmed Helmy, Univ of Southern California 3.00PM - 3.30PM: Break 3.30PM - 5.00PM: Session 2: Routing in Ad Hoc Networks Content-Based Routing in Mobile Ad Hoc Networks Multi-Constraint Dynamic Access Selection in Always Best Connected = Networks Extended ZRP:Performance Evaluation of a Routing Layer Based Service = Discovery Protocol for Mobile Ad Hoc Networks Market Models and Pricing Mechanisms in a Multihop Wireless Hotspot *************************************************************** Tuesday, July 19, 2005 9.00AM - 10.00AM: Martin Cooper, Title: TBA 10.00AM - 10.30AM: Break 10.30AM - 12.00 Noon: Session 3: Security in Sensor Networks SWAT: Small World-based Attacker Traceback in Ad-hoc Networks Correlation analysis for alleviating effects of inserted data in = wireless sensor networks Efficient Aggregation of encrypted data in Wireless Sensor Practical Broadcast Authentication in Sensor Networks 10.00 AM - 12.30 PM: Poster Session 2 Reader Collision Avoidance in RFID Systems Murali Krishna Ramanathan, Bogdan Carbunar, Ananth Grama, Suresh Jagannathan KTR: an Efficient Key Management Scheme For Air Access Control Qijun Gu, Peng Liu, Wang-Chien LEE, Chao-Hsien Chu Temporal Transcoding for Mobile Video Communication Francesca Martelli, Maurizio A. Bonuccelli, Francesca Lonetti Smart Components in a Pervasive Messaging Service Wolfgang Narzt, Gustav Pomberger, Alois Ferscha, Dieter Kolb, Reiner Muller, Jan Wieghardt, Horst Hortner, Roland Haring, Christopher Lindinger Embedded SW Design Issues for Distributed Applications on Mobile = Terminals Giovanni Perbellini, Stefano Martini, Franco Fummi, Fabio Ricciato, Maura Turolla An Efficient Peer-to-Peer Lookup Protocol for Location-Aware Mobile Ad = Hoc Networks Daewoong Kim, Chanik Park Design and Implementation of a Software Infrastructure for Integrating = Sentient Artefacts Fahim Kawsar , Kaori Fujinami, Tatsuo Nakajima Geographically Bound Mobile Agent in MANET Kenji Tei, Nobukazu Yoshioka, Yoshiaki Fukazawa, Shinichi Honiden Secure Address Auto-configuration for Mobile Ad Hoc Networks Pan Wang, Douglas Reeves, Peng Ning 12.00PM - 1.30PM: Lunch 1.30PM - 3.30PM: Challenges Session 3.30PM - 4.00PM: Break 4.00PM - 5.30PM: Session 4: Handoff and MAC protocols PPP Migration: A Technique for Low-Latency Handoff in CDMA2000 Networks A Relay Based Multi-rate MAC Protocol for Ad-hoc Networks MPA assisted Optimized Proactive Handoff Scheme An Enhanced Dynamic Framed Slotted ALOHA Algorithm for RFID Tag = Identification Session 5: Middleware Loosely Coupling Ontological Reasoning with an Efficient Middleware for = Context-awareness Contextualizing Applications via Semantic Middleware Plethora: A Framework for Converting Generic Applications to Run in a = Ubiquitous Environment Exploiting co-location history for efficient service selection in = ubiquitous computing systems 6.30PM - 9.00PM: Banquet *************************************************************** Wednesday, July 20, 2005 8.30AM - 10.00AM: Session 6: Routing in Ad Hoc networks A Generalization of the Face Routing Algorithm to Some Non-Planar = Networks Routing in MANETs with Address Conflicts Transparent Heterogeneous Mobile Ad Hoc Networks SRDP: Securing Route Discovery in DSR Session 7: Querying On Incremental Processing of Continual Range Queries for Location-Aware = Services and Applications Decentralizing Query Processing in Sensor Networks Energy Efficient Processing of K Nearest Neighbor Queries in = Location-aware Sensor Networks A location aware mobile tourist guide selecting and interpreting sights = and services by context matching 10.00AM - 10.30AM: Break 10.30AM - 12.30 Noon: Session 8: Network Architectures Decentralized Optimization of Dynamic Bluetooth Scatternets Improving Connectivity of Wireless Ad-Hoc Networks Efficient Continuous Mapping in Sensor Networks Using Isolines A Peer-to-Peer Architecture for Context Lookup Community-Based Asynchronous Wakeup Protocol for Wireless Peer-to-Peer = File Sharing Networks Session 9: Locationing and Mobility Multivariate Analysis for Probabilistic WLAN Location Determination = Systems Proxy-based Hand-Off of Web Sessions for User Mobility Web Profiles: A Negotiation Model for User Awareness in Personal Area = Networks A SIP-based Architecture model for Contextual Coalition Access Control = for Ubiquitous Computing A Cooperative Learning Framework for Mobility-Aware Resource Management = in Multi-Inhabitant Smart Homes 12.30PM - 1.30PM: Lunch 1.30PM - 3.00PM: Session 10: Ad Hoc Networks Multi-path Admission Control for Mobile Ad hoc Networks Personal Access Point for IEEE 802.11 Systems On Upper Bound and Heuristics for Multicast Lifetime Maximization Using = Dynamic Routing in Energy-Limited Wireless Ad Hoc Networks A Feedback Control Scheme for Resource Allocation in Wireless Multi-hop = Ad Hoc Networks Session 11: Applications StateSnap: A Snapshot-based Interface for State-Reproductable Operation = of Networked Appliances Bluetooth Base Station Minimal Deployment for High Definition = Positioning An assessment of the audio codec performance in Voice over WLAN (VoWLAN) = systems *************************************************************** Thursday, July 21, 2005 Workshops *************************************************************** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/