From bpatil1@gmail.com Wed Apr 3 10:59:24 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B121F8BF2 for ; Wed, 3 Apr 2013 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUBLz25hnqjy for ; Wed, 3 Apr 2013 10:59:23 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70D4121F8BDD for ; Wed, 3 Apr 2013 10:59:23 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so1803068oag.4 for ; Wed, 03 Apr 2013 10:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=zYLxrIjYhoY8Ftxauf1xIhfhY6A4ZtGp8/92DDxkx0c=; b=zzQ97nizKJzO3/asnoPEqiMk0kLOWiii+f0S4TgtJefE6bxyc4sBxHSWFoFZ9stXcU QraeaGuFBvyHduqG8TO05N2UTbKnZc1qdn1UGcGQR8XCtrzBzSN4SiZl73PpTewVkr9F BlMFGcuWbY6mBf4dj5w7y/o1dor1wWfWd4hsZCKQoupzHInP26bGAcpFlR2F9lgERxbi YgE9NrQNlBOTFVIax0x/AKplNAZnHPi6yEWg9q5tOLpGXIYz57Y6EVk42vxXcj6YQoav eFZPtvrSMjA5koGmR56HSzZNFyBTpQoAdI3A8BLCjDYyCw3xWjHWiJ4HFIdE/mtn1Nv0 aKzQ== MIME-Version: 1.0 X-Received: by 10.60.28.37 with SMTP id y5mr1770434oeg.134.1365011963008; Wed, 03 Apr 2013 10:59:23 -0700 (PDT) Received: by 10.76.127.34 with HTTP; Wed, 3 Apr 2013 10:59:22 -0700 (PDT) Date: Wed, 3 Apr 2013 12:59:22 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=e89a8fb1f7f02b608904d9789d47 Cc: "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:59:24 -0000 --e89a8fb1f7f02b608904d9789d47 Content-Type: text/plain; charset=ISO-8859-1 Questions: 1. In the terminology section: "The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router and advertised in the mobile network." What is the mobile network being refered to in this statement? Is it the PMIP6 domain itself? Or is it the network that the mobile router is hosting? 2. In Sec 4.3.1: "It is possible that the delegated prefix(es) may have been assigned to the MAG by the LMA during this procedure of PMIPv6 tunnel establishment. That is the MAG may include one (or more) Delegated Mobile Network Prefix (DMNP) mobility options which MUST be set to the unspecified IPv6 address "::" in the PBU to request the delegated prefix(es). The LMA assigns a new set of DMNP(s) in PBA message." Not sure what your assumptions are here. Why does the LMA assign delegated prefix(es) during normal RFC5213 PMIP6 tunnel establishment procedures? What would cause the MAG to include the DMNP option in the PBU at this stage (Step 2) of the session? 3. In Sec 4.3.1: " The mobile router, acting as a "Requesting Router" as described in [RFC3633], sends a DHCPv6 SOLICIT message including one or more IA_PD option(s) to the mobile access gateway (which has a "DHCPv6 Server" function) to acquire the delegated prefix(es)." Is there an assumption that the MAG is also the DHCPv6 server? The MAG could be a DHCP relay as well, right? 4. In Sec 4.3.1, step 5: "The LMA must set up forwarding for the delegated prefixes as reachable through the PMIPv6 tunnel." The LMA may or may not assign these delegated prefixes. The MAG could be the one assigning the delegated prefixes as per the description. Are those prefixes routable by the LMA? 5. In Sec 4.4.1, step 4: "If the mobile access gateway does not know the delegated prefix(es), then the delegated mobile network prefix in the DMNP option(s) MUST be set to the unspecified IPv6 address "::", " How would the MAG know the delegated prefix(es)? Unless it is just renewing the assigned prefix(es)? 6. Is the assumption that the DHCP server functionality resides either at the MAG or the LMA in this I-D? 7. In Sec 6.2 you state: "In order to receive these packets, the local mobility anchor MUST be the topological anchor of the MR's delegated mobile network prefix(es)." This should be made clear up front in order to avoid confusion about how forwarding is accomplished. Editorial: s/Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host./ Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling. Mobility elements in the network are responsible for managing IP mobility on behalf of the host. s/However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility./However, Proxy Mobile IPv6 lacks the ability to assign a prefix to a router and manage its IP mobility. s/and be able to obtain IP mobility support for those IP addresses./ and enable IP mobility support for the assigned IP address or prefixes. s/However, this network-based mobility management support is specific to an IP host and currently there is no such network-based mobility management support for a mobile router with a cluster of IP hosts behind it./However, the Proxy Mobile IPv6 based solution for network-based mobility management is specific to IP hosts and does not provide similar functionality for a mobile router with a cluster of IP hosts behind it. -Raj --e89a8fb1f7f02b608904d9789d47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Questions:
1. In the terminology section:
=A0 =A0"The DMNP= is an IPv4 or an IPv6 prefix delegated to a mobile router
=A0 = =A0 =A0 and advertised in the mobile network."

=A0 =A0 =A0 What is the mobile network being refered to= in this statement?
=A0 =A0 =A0 Is it the PMIP6 domain itself? Or= is it the network that the
=A0 =A0 =A0 mobile router is hosting?=

2. In Sec 4.3.1:
=A0 =A0"It is possible that the = delegated prefix(es) may
=A0 =A0 =A0 =A0have been assigned to the= MAG by the LMA during this procedure of
=A0 =A0 =A0 =A0PMIPv6 tu= nnel establishment. =A0That is the MAG may include one (or
=A0 =A0 =A0 =A0more) Delegated Mobile Network Prefix (DMNP) mobility o= ptions
=A0 =A0 =A0 =A0which MUST be set to the unspecified IPv6 a= ddress "::" in the PBU
=A0 =A0 =A0 =A0to request the de= legated prefix(es). =A0The LMA assigns a new set
=A0 =A0 =A0 =A0of DMNP(s) in PBA message."

=A0 =A0 =A0 =A0Not sure what your assumptions are here. Why does the LMA=
=A0 =A0 =A0 =A0assign delegated prefix(es) during normal RFC5213= PMIP6 tunnel
=A0 =A0 =A0 =A0establishment procedures?
=A0 =A0 =A0 =A0What woul= d cause the MAG to include the DMNP option in the PBU
=A0 =A0 =A0= =A0at this stage (Step 2) of the session?

3. In S= ec 4.3.1:
=A0 =A0" The mobile router, acting as a "Requesting Router" = as described
=A0 =A0 =A0 =A0in [RFC3633], sends a DHCPv6 SOLICIT = message including one or
=A0 =A0 =A0 =A0more IA_PD option(s) to t= he mobile access gateway (which has a
=A0 =A0 =A0 =A0"DHCPv6 Server" function) to acquire the dele= gated prefix(es)."

=A0 =A0 =A0 =A0Is there an= assumption that the MAG is also the DHCPv6 server?
=A0 =A0 =A0 = =A0The MAG could be a DHCP relay as well, right?

4. In Sec 4.3.1, step 5:
=A0 =A0"The LMA= must set
=A0 =A0 =A0 =A0up forwarding for the delegated prefixes= as reachable through the
=A0 =A0 =A0 =A0PMIPv6 tunnel."

=A0 =A0 =A0 =A0The LMA may or may not assign these delegated prefixes.= The MAG
=A0 =A0 =A0 =A0could be the one assigning the delegated = prefixes as per the
=A0 =A0 =A0 =A0description. Are those prefixe= s routable by the LMA?

5. In Sec 4.4.1, step 4:
=A0 =A0"If the = mobile access
=A0 =A0 =A0 =A0 gateway does not know the delegated= prefix(es), then the
=A0 =A0 =A0 =A0 delegated mobile network pr= efix in the DMNP option(s) MUST be
=A0 =A0 =A0 =A0 set to the unspecified IPv6 address "::", &q= uot;

<= /span>How would the MAG know the delegated prefix(es)? Unless it is
just renewing the ass= igned prefix(es)?

6. Is the assumption that the DHCP server functionality= resides either
=A0 =A0at the MAG or the LMA in this I-D?

7. In Sec 6.2 you state:
=A0 =A0"In order = to receive these packets, the
=A0 =A0 =A0 local mobility anchor MUST be the topological anchor of th= e MR's
=A0 =A0 =A0 delegated mobile network prefix(es)."=

=A0 =A0 =A0 This should be made clear up front in= order to avoid confusion
=A0 =A0 =A0 about how forwarding is accomplished.

=


Editorial:

s/Pr= oxy Mobile IPv6 enables IP mobility for a host without requiring
= =A0 =A0its participation in any mobility signaling, being the network
=A0 =A0responsible for managing IP mobility on behalf of the host./ Pr= oxy
=A0 =A0Mobile IPv6 enables IP mobility for a host without req= uiring=A0
=A0 =A0its participation in any mobility signaling. Mob= ility elements in
=A0 =A0the network are responsible for managing IP mobility on behalf = of
=A0 =A0the host.=A0

s/However,
<= div>=A0 =A0Proxy Mobile IPv6 does not support assigning a prefix to a route= r and
=A0 =A0managing its IP mobility./However, Proxy Mobile IPv6 lacks the<= /div>
=A0 =A0ability to assign a prefix to a router and =A0manage its I= P
=A0 =A0mobility.=A0

s/and be able to o= btain IP mobility support for those IP addresses./
=A0 =A0and enable IP mobility support for the assigned IP address or
=A0 =A0prefixes.=A0

s/However,
= =A0 =A0this network-based mobility management support is specific to an IP<= /div>
=A0 =A0host and currently there is no such network-based mobility managemen= t
=A0 =A0support for a mobile router with a cluster of IP hosts b= ehind it./However,
=A0 =A0the Proxy Mobile IPv6 based solution fo= r =A0network-based mobility
=A0 =A0management is specific to IP hosts and does not provide similar=
=A0 =A0functionality for a mobile router with a cluster of IP ho= sts behind
=A0 =A0it.=A0

-Raj

--e89a8fb1f7f02b608904d9789d47-- From internet-drafts@ietf.org Wed Apr 24 00:19:58 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7D21F8E9E; Wed, 24 Apr 2013 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSrkMtXOQDbH; Wed, 24 Apr 2013 00:19:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63C321F8FA4; Wed, 24 Apr 2013 00:19:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424071957.17351.10122.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 00:19:57 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-07.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 07:19:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Author(s) : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-07.txt Pages : 19 Date : 2013-04-24 Abstract: A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-logical-interface-supp= ort-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnsonhammond1@hushmail.com Sat Apr 27 17:29:30 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9821F9973 for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrcfYii1RuCt for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 1F26C21F9984 for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 994821B5330 for ; Sat, 27 Apr 2013 17:34:29 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:34:29 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 387B2E6739; Sat, 27 Apr 2013 17:34:29 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:34:29 -0400 To: netext@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173429.387B2E6739@smtp.hushmail.com> Subject: [netext] Biggest Fake Conference in Computer Science X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:29:30 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Sat Apr 27 18:50:38 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EFD21F93B7; Sat, 27 Apr 2013 18:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.411 X-Spam-Level: X-Spam-Status: No, score=-98.411 tagged_above=-999 required=5 tests=[AWL=-2.094, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJMYGyQW+lwb; Sat, 27 Apr 2013 18:50:37 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id 6195521F9367; Sat, 27 Apr 2013 18:50:35 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm27517c8fab; Sun, 28 Apr 2013 09:56:24 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm1d5177ddf5; Wed, 24 Apr 2013 15:55:10 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Wed, 24 Apr 2013 15:55:10 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 043FB21F8EAC; Wed, 24 Apr 2013 00:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366788001; bh=EcGysMTbsDy0eHrBqQAqWEdKXCd8uLz0DWFXvZC+nzA=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fE+wam/IIwA/v06EnBMTZHv2fwmO863/ZPjISpJDuYn35CSepJBu8e/ZWNbcV9iWf p5nR4Ay7nzKaMbfOjx1s5dI6t6fFYR4iTmnIejKWUvfica9yGErwksXA6QAZCmfs6D +LxlSw+8K1O7Iqj561QxavBdIjitICTg0bSDgrm8= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7D21F8E9E; Wed, 24 Apr 2013 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSrkMtXOQDbH; Wed, 24 Apr 2013 00:19:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63C321F8FA4; Wed, 24 Apr 2013 00:19:57 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424071957.17351.10122.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 00:19:57 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: 1Rm7u44B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-07.txt X-BeenThere: netext@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 01:50:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Author(s) : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-07.txt Pages : 19 Date : 2013-04-24 Abstract: A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-logical-interface-support-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wwwrun@rfc-editor.org Mon Apr 29 11:49:52 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E421F9AD6; Mon, 29 Apr 2013 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+zCSq5H7Wtd; Mon, 29 Apr 2013 11:49:51 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D842E21F9AC5; Mon, 29 Apr 2013 11:49:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4A143B1E004; Mon, 29 Apr 2013 11:49:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429184926.4A143B1E004@rfc-editor.org> Date: Mon, 29 Apr 2013 11:49:26 -0700 (PDT) Cc: netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 6909 on IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:49:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6909 Title: IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 Author: S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli Status: Standards Track Stream: IETF Date: April 2013 Mailbox: sgundave@cisco.com, zhou.xingyue@zte.com.cn, jouni.nospam@gmail.com, gfeige@cisco.com, rkoodli@cisco.com Pages: 14 Characters: 34575 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-pmipv6-sipto-option-12.txt URL: http://www.rfc-editor.org/rfc/rfc6909.txt This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network. This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC