From rajeev.koodli@gmail.com Tue Sep 15 13:09:41 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936DF3A682E for ; Tue, 15 Sep 2009 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oomHJYLdGdQ for ; Tue, 15 Sep 2009 13:09:40 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id BFE833A62C1 for ; Tue, 15 Sep 2009 13:09:40 -0700 (PDT) Received: by iwn27 with SMTP id 27so1772016iwn.7 for ; Tue, 15 Sep 2009 13:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=tycsNPgDAPMxXE7sRAl/FKbMHU16wC8tzaXge8SvYAY=; b=OBVQ4bu6T2B+EXZGbgBULdoFr5hD+tyhA2DUbLuZBRIFoaqTGiB+6UPkYBDjhnqQo6 8iHjAS4Qlv6Z2BI5Mqdy6aIyTHnHXCHvyeQU8X0B/rLmdS9tfTx/bNS9Kpa4nhxzZaBG wlOuP0VQOmvu4vUXN24LJJ6f66mAHqyfxDK0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=gj7rFAmP/1fEiBkFnx8VBhcNzfEX5XvFODQ1zdfcYFbs9oD6KUwvkZ+t05hOPHiGms Hv69Pq36Cxf9FPQoVnd0q1Goe2yuZB+xQ8ZCcDe8IlqcQh2C0YMoDc0IaAN6ngZsq9wj pJdpy3pK7coRu+HbUMnRAlJEQXb7AaYnqhTIw= MIME-Version: 1.0 Received: by 10.231.126.69 with SMTP id b5mr6027703ibs.54.1253045425699; Tue, 15 Sep 2009 13:10:25 -0700 (PDT) Date: Tue, 15 Sep 2009 13:10:25 -0700 Message-ID: <3d57679a0909151310j1849c35ao48fd72dec5df27cf@mail.gmail.com> From: Rajeev Koodli To: falk@bbn.com Content-Type: text/plain; charset=ISO-8859-1 Cc: irsg@isi.edu, mobopts@irtf.org Subject: [Mobopts] Request to publish draft-irtf-mobopts-mmcastv6-ps-08.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 20:09:41 -0000 Hi Aaron, I am following up on a previous request (for version 07). We received two more Ready to Publish with some comments. The authors have addressed the comments in version 08. Please see the formal request below. Thanks, -Rajeev This is a request to publish the Mobopts RG document draft-irtf-mobopts-mmcastv6-ps-08 as an Informational RFC. The draft has undergone several revisions within the RG. The latest version of the draft (rev 08) includes the changes and edits that were suggested as part of the the IRSG Reviews by Craig Partridge, Andrei Gurtov and Andrew Lachlan. The original IRSG Review was done on Rev 06 of the I-D. There are three votes for "Ready to Publish" and one vote for "No Objection". During the development of this document in the mobopts RG, several people have thoroughly reviewed the document and the changes have been incorporated. The draft revisions, reviews etc. are captured at: http://trac.tools.ietf.org/group/irtf/trac/ticket/26 On Tue, Jul 14, 2009 at 10:39 AM, Rajeev Koodli wrote: > > > Hi Aaron, > > This is a request to publish the Mobopts RG document > draft-irtf-mobopts-mmcastv6-ps-07 as an Informational > RFC. > > The draft has undergone several revisions within the RG. > The latest version of the draft (rev 07) includes the changes > and edits that were suggested as part of the the IRSG Review by Craig > Partridge. > The IRSG Review was done on Rev 06 of the I-D. > > There was one vote for "Ready to Publish" and one vote for "No Objection" > during the IRSG Poll. (I sought additional votes multiple times, but now it > is time to progress the document) > > During the development of this document in the mobopts RG, several > people have thoroughly reviewed the document and the changes have been > incorporated. > > The draft revisions, reviews etc are captured at: > > http://trac.tools.ietf.org/group/irtf/trac/ticket/26 > > Thanks, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts > > From falk@bbn.com Tue Sep 15 14:08:28 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9198C3A6B6F for ; Tue, 15 Sep 2009 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgxy9knlvkTJ for ; Tue, 15 Sep 2009 14:08:27 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8567E3A6868 for ; Tue, 15 Sep 2009 14:08:27 -0700 (PDT) Received: from dhcp89-081-193.bbn.com ([128.89.81.193]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MneKu-00024I-E4; Tue, 15 Sep 2009 16:09:12 -0400 Message-ID: <4AB00279.3040708@bbn.com> Date: Tue, 15 Sep 2009 17:09:13 -0400 From: Aaron Falk User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Rajeev Koodli References: <3d57679a0909151310j1849c35ao48fd72dec5df27cf@mail.gmail.com> In-Reply-To: <3d57679a0909151310j1849c35ao48fd72dec5df27cf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: irsg@isi.edu, mobopts@irtf.org Subject: Re: [Mobopts] Request to publish draft-irtf-mobopts-mmcastv6-ps-08.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 21:08:28 -0000 Rajeev- I observe that the current revision is -16, not -08. See http://tools.ietf.org/html/draft-irtf-mobopts-location-privacy-solutions. Do you want to publish -16? --aaron Rajeev Koodli wrote: > Hi Aaron, > > I am following up on a previous request (for version 07). > We received two more Ready to Publish with some comments. > The authors have addressed the comments in version 08. Please see the > formal request below. > > Thanks, > > -Rajeev > > > This is a request to publish the Mobopts RG document > draft-irtf-mobopts-mmcastv6-ps-08 as an Informational > RFC. > > The draft has undergone several revisions within the RG. > The latest version of the draft (rev 08) includes the changes > and edits that were suggested as part of the the IRSG Reviews by Craig > Partridge, > Andrei Gurtov and Andrew Lachlan. > > The original IRSG Review was done on Rev 06 of the I-D. > > There are three votes for "Ready to Publish" and one vote for "No Objection". > > During the development of this document in the mobopts RG, several > people have thoroughly reviewed the document and the changes have been > incorporated. > > The draft revisions, reviews etc. are captured at: > > http://trac.tools.ietf.org/group/irtf/trac/ticket/26 > > > > On Tue, Jul 14, 2009 at 10:39 AM, Rajeev Koodli wrote: > >> Hi Aaron, >> >> This is a request to publish the Mobopts RG document >> draft-irtf-mobopts-mmcastv6-ps-07 as an Informational >> RFC. >> >> The draft has undergone several revisions within the RG. >> The latest version of the draft (rev 07) includes the changes >> and edits that were suggested as part of the the IRSG Review by Craig >> Partridge. >> The IRSG Review was done on Rev 06 of the I-D. >> >> There was one vote for "Ready to Publish" and one vote for "No Objection" >> during the IRSG Poll. (I sought additional votes multiple times, but now it >> is time to progress the document) >> >> During the development of this document in the mobopts RG, several >> people have thoroughly reviewed the document and the changes have been >> incorporated. >> >> The draft revisions, reviews etc are captured at: >> >> http://trac.tools.ietf.org/group/irtf/trac/ticket/26 >> >> Thanks, >> >> -Rajeev >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> http://www.irtf.org/mailman/listinfo/mobopts >> >> >> > > From rkoodli@starentnetworks.com Tue Sep 15 14:22:11 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4751028C124 for ; Tue, 15 Sep 2009 14:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9YDe-SCXS+H for ; Tue, 15 Sep 2009 14:22:10 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 493753A68EE for ; Tue, 15 Sep 2009 14:22:10 -0700 (PDT) X-ASG-Debug-ID: 1253049777-38ea00310002-hAkvSY X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id BB07FEFC07B for ; Tue, 15 Sep 2009 17:22:57 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id gy8D2AMNLgr2jbUI for ; Tue, 15 Sep 2009 17:22:57 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Sep 2009 17:18:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [Mobopts] Request to publishdraft-irtf-mobopts-mmcastv6-ps-08.txt Date: Tue, 15 Sep 2009 17:18:25 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BDFEECF@exchtewks3.starentnetworks.com> In-Reply-To: <4AB00279.3040708@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Request to publishdraft-irtf-mobopts-mmcastv6-ps-08.txt Thread-Index: Aco2SJd6pwhJigq+RUaHgHMz5PL3YgAAoOSQ References: <3d57679a0909151310j1849c35ao48fd72dec5df27cf@mail.gmail.com> <4AB00279.3040708@bbn.com> From: "Koodli, Rajeev" To: "Aaron Falk" X-OriginalArrivalTime: 15 Sep 2009 21:18:30.0430 (UTC) FILETIME=[12CBB3E0:01CA364A] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253049777 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Cc: irsg@isi.edu, mobopts@irtf.org Subject: Re: [Mobopts] Request to publishdraft-irtf-mobopts-mmcastv6-ps-08.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 21:22:11 -0000 Hi Aaron, You are looking at a different ID - version 16 is for the location privacy draft (which has finished IESG review, but is waiting for an AD write-up!) Thanks, -Rajeev =20 > -----Original Message----- > From: mobopts-bounces@irtf.org=20 > [mailto:mobopts-bounces@irtf.org] On Behalf Of Aaron Falk > Sent: Tuesday, September 15, 2009 2:09 PM > To: Rajeev Koodli > Cc: irsg@isi.edu; mobopts@irtf.org > Subject: Re: [Mobopts] Request to=20 > publishdraft-irtf-mobopts-mmcastv6-ps-08.txt >=20 > Rajeev- >=20 > I observe that the current revision is -16, not -08. See=20 > http://tools.ietf.org/html/draft-irtf-mobopts-location-privacy > -solutions.=20 > Do you want to publish -16? >=20 > --aaron >=20 > Rajeev Koodli wrote: > > Hi Aaron, > > > > I am following up on a previous request (for version 07). > > We received two more Ready to Publish with some comments. > > The authors have addressed the comments in version 08.=20 > Please see the=20 > > formal request below. > > > > Thanks, > > > > -Rajeev > > > > > > This is a request to publish the Mobopts RG document > > draft-irtf-mobopts-mmcastv6-ps-08 as an Informational RFC. > > > > The draft has undergone several revisions within the RG. > > The latest version of the draft (rev 08) includes the changes and=20 > > edits that were suggested as part of the the IRSG Reviews by Craig=20 > > Partridge, Andrei Gurtov and Andrew Lachlan. > > > > The original IRSG Review was done on Rev 06 of the I-D. > > > > There are three votes for "Ready to Publish" and one vote=20 > for "No Objection". > > > > During the development of this document in the mobopts RG, several=20 > > people have thoroughly reviewed the document and the=20 > changes have been=20 > > incorporated. > > > > The draft revisions, reviews etc. are captured at: > > > > http://trac.tools.ietf.org/group/irtf/trac/ticket/26 > > > > > > > > On Tue, Jul 14, 2009 at 10:39 AM, Rajeev=20 > Koodli wrote: > > =20 > >> Hi Aaron, > >> > >> This is a request to publish the Mobopts RG document > >> draft-irtf-mobopts-mmcastv6-ps-07 as an Informational RFC. > >> > >> The draft has undergone several revisions within the RG. > >> The latest version of the draft (rev 07) includes the changes and=20 > >> edits that were suggested as part of the the IRSG Review by Craig=20 > >> Partridge. > >> The IRSG Review was done on Rev 06 of the I-D. > >> > >> There was one vote for "Ready to Publish" and one vote for=20 > "No Objection" > >> during the IRSG Poll. (I sought additional votes multiple=20 > times, but=20 > >> now it is time to progress the document) > >> > >> During the development of this document in the mobopts RG, several=20 > >> people have thoroughly reviewed the document and the changes have=20 > >> been incorporated. > >> > >> The draft revisions, reviews etc are captured at: > >> > >> http://trac.tools.ietf.org/group/irtf/trac/ticket/26 > >> > >> Thanks, > >> > >> -Rajeev > >> > >> > >> > >> > >> _______________________________________________ > >> Mobopts mailing list > >> Mobopts@irtf.org > >> http://www.irtf.org/mailman/listinfo/mobopts > >> > >> > >> =20 > > > > =20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts >=20 From falk@bbn.com Wed Sep 16 14:47:40 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533903A6A88 for ; Wed, 16 Sep 2009 14:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaDLw23sTzD1 for ; Wed, 16 Sep 2009 14:47:39 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 59CF33A6833 for ; Wed, 16 Sep 2009 14:47:39 -0700 (PDT) Received: from dhcp89-081-193.bbn.com ([128.89.81.193]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mo1QS-0001i0-E5; Wed, 16 Sep 2009 16:48:28 -0400 Message-ID: <4AB15D2D.3070506@bbn.com> Date: Wed, 16 Sep 2009 17:48:29 -0400 From: Aaron Falk User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <3d57679a0909151310j1849c35ao48fd72dec5df27cf@mail.gmail.com> <4AB00279.3040708@bbn.com> <4D35478224365146822AE9E3AD4A26660BDFEECF@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660BDFEECF@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: irsg@isi.edu, mobopts@irtf.org Subject: Re: [Mobopts] Request to publishdraft-irtf-mobopts-mmcastv6-ps-08.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 21:47:40 -0000 Whoops! I see. Sorry. --aaron Koodli, Rajeev wrote: > Hi Aaron, > > You are looking at a different ID - version 16 is for the location > privacy draft (which has finished IESG review, but is waiting for an AD > write-up!) > > Thanks, > > -Rajeev > > > >> -----Original Message----- >> From: mobopts-bounces@irtf.org >> [mailto:mobopts-bounces@irtf.org] On Behalf Of Aaron Falk >> Sent: Tuesday, September 15, 2009 2:09 PM >> To: Rajeev Koodli >> Cc: irsg@isi.edu; mobopts@irtf.org >> Subject: Re: [Mobopts] Request to >> publishdraft-irtf-mobopts-mmcastv6-ps-08.txt >> >> Rajeev- >> >> I observe that the current revision is -16, not -08. See >> http://tools.ietf.org/html/draft-irtf-mobopts-location-privacy >> -solutions. >> Do you want to publish -16? >> >> --aaron >> >> Rajeev Koodli wrote: >> >>> Hi Aaron, >>> >>> I am following up on a previous request (for version 07). >>> We received two more Ready to Publish with some comments. >>> The authors have addressed the comments in version 08. >>> >> Please see the >> >>> formal request below. >>> >>> Thanks, >>> >>> -Rajeev >>> >>> >>> This is a request to publish the Mobopts RG document >>> draft-irtf-mobopts-mmcastv6-ps-08 as an Informational RFC. >>> >>> The draft has undergone several revisions within the RG. >>> The latest version of the draft (rev 08) includes the changes and >>> edits that were suggested as part of the the IRSG Reviews by Craig >>> Partridge, Andrei Gurtov and Andrew Lachlan. >>> >>> The original IRSG Review was done on Rev 06 of the I-D. >>> >>> There are three votes for "Ready to Publish" and one vote >>> >> for "No Objection". >> >>> During the development of this document in the mobopts RG, several >>> people have thoroughly reviewed the document and the >>> >> changes have been >> >>> incorporated. >>> >>> The draft revisions, reviews etc. are captured at: >>> >>> http://trac.tools.ietf.org/group/irtf/trac/ticket/26 >>> >>> >>> >>> On Tue, Jul 14, 2009 at 10:39 AM, Rajeev >>> >> Koodli wrote: >> >>> >>> >>>> Hi Aaron, >>>> >>>> This is a request to publish the Mobopts RG document >>>> draft-irtf-mobopts-mmcastv6-ps-07 as an Informational RFC. >>>> >>>> The draft has undergone several revisions within the RG. >>>> The latest version of the draft (rev 07) includes the changes and >>>> edits that were suggested as part of the the IRSG Review by Craig >>>> Partridge. >>>> The IRSG Review was done on Rev 06 of the I-D. >>>> >>>> There was one vote for "Ready to Publish" and one vote for >>>> >> "No Objection" >> >>>> during the IRSG Poll. (I sought additional votes multiple >>>> >> times, but >> >>>> now it is time to progress the document) >>>> >>>> During the development of this document in the mobopts RG, several >>>> people have thoroughly reviewed the document and the changes have >>>> been incorporated. >>>> >>>> The draft revisions, reviews etc are captured at: >>>> >>>> http://trac.tools.ietf.org/group/irtf/trac/ticket/26 >>>> >>>> Thanks, >>>> >>>> -Rajeev >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mobopts mailing list >>>> Mobopts@irtf.org >>>> http://www.irtf.org/mailman/listinfo/mobopts >>>> >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> http://www.irtf.org/mailman/listinfo/mobopts >> >> > > > This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. > > From jari.arkko@piuha.net Thu Sep 24 02:19:28 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084333A6824 for ; Thu, 24 Sep 2009 02:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBhd1r7IbbWV for ; Thu, 24 Sep 2009 02:19:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by core3.amsl.com (Postfix) with ESMTP id 5D5AF3A67EC for ; Thu, 24 Sep 2009 02:19:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DB325D4943; Thu, 24 Sep 2009 12:20:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw-BnWXu90-a; Thu, 24 Sep 2009 12:20:32 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9AB03D4903; Thu, 24 Sep 2009 12:20:32 +0300 (EEST) Message-ID: <4ABB39DF.10609@piuha.net> Date: Thu, 24 Sep 2009 12:20:31 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: draft-irtf-mobopts-mmcastv6-ps@tools.ietf.org, IESG , ml-mobopts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipdvb-chairs@tools.ietf.org, multimob-chairs@tools.ietf.org, "16ng-chairs@tools.ietf.org" <16ng-chairs@tools.ietf.org> Subject: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:19:28 -0000 Hi all, I have reviewed this document today. The purpose of my review and the following IESG review is to perform a so called RFC 3932 check, i.e., make sure that documents outside the IETF stream do not allocate IANA values reserved for standards track protocols or otherwise collide with IETF working group efforts. I have not found any collision with this work and IETF work, though obviously, this work has been one of the inputs for the formation of the MOBOPTS working group, and also talks about IP over a number of link layers. I have recommended the standard RFC 3932 boilerplate IESG note about non-IETF work. Once the 3932bis work is concluded we will be able to make use of the new style of headers and boilerplates which do not require IESG notes. I have written to the tracker that if this happens before this document comes out of the RFC Editor queue then no note is needed. The document will be under the entire IESG's review in two weeks to confirm my recommendation. Please remember that neither my review or the IESG review is a technical review. In other words, the RG is fully responsible for the correctness of the document. As a personal note I wanted to say nevertheless that I was reasonably happy with the document. Thank you for writing this. In any case, I have included a few personal review comments below. Also, as the document contains quite a bit of material relating to IP over 802.16 and IP over DVB, I have Cced the relevant working group chairs in case they have further comments. Jari Arkko > obility management may issue > traffic directives that lead to suboptimal routing, i.e., erroneous > subscriptions following predictive handover operations, or slow > effective leaves caused by MLD querying, or by departure of the MN > from a previous network without leaving the subscribed groups. > I had a hard time parsing this. Maybe say instead: "Mobility management may impact routing by, e.g., erroneous ... or by MNs leaving networks without unsubscribing form the groups they were receiving.". What's a "slow effective leave"? > IP multicast deployment in general has been hesitant over the past 15 > years s/hesitant/slow/? > a strong business case for IP > portables ... portable IP-based devices. > Current packet filtering practice causes inter-working problems between Mobile IPv6 nodes connected via GPRS [46 ]. > This is incorrect AFAIK. There are filtering procedures in IMS that cause problems for Mobile IPv6 and other things. However, those filtering mechanisms are not a part of the link layer nor are they applied for regular Internet access. I would suggest this statement be deleted from the draft, along with the reference. > PTM uses an > unidirectional common channel, operating in unacknowledged without > adjustment of power levels and no reporting on lost packets. > ... unacknowledged mode? > Mobility services transport for MIH naturally reside > on the network layer and are currently in the process of > specification [55 ]. > > draft-ietf-mipshop-mstp-solution is an approved specification (though not yet out of the RFC Ed queue). Also, I believe 802.21 specifies both network and link layer transport, so its not clear why you say "naturally" above. In general Section 4 wanders off a little bit to topics outside multicast. I understand that some amount of explanation is needed about what each L2 technology does, but I'd consider tightening the text in AUTH48 in some places. > MLD > router querying will allow the multicast forwarding state to be > restored in case of an erroneous prediction (i.e., an anticipated > move to a network that is not fulfilled). fulfilled? > Mobility protocols need to consider the implications and requirements > for AAA. AAA binding records may change between attachments, or may > be individually chosen prior to network (re-)association. The most > appropriate network path may be one that satisfies user preferences, > e.g., to use/avoid a specific network, minimize monetary cost, etc, > rather than one that only minimizes the routing cost. Consequently, > AAA bindings cannot be treated at a pure level of context transfer. > It was not clear to me why AAA is relevant. And what's an "AAA binding record"? I must say that I don't understand the rest of the paragraph either. The term AAA was not defined or expanded. Please check the other terms too. > Due to lack of feedback, the admission [83 ] and binding > updates [84 ] of mobile multicast sources require autonomously > verifiable authentication as can be achieved by Cryptographically > Generated Addresses (CGAs). > And presumably with other means as well. I would suggest saying "... be achieved by, for instance, ...". It would have been interesting if Section 8 listed some of the multicast specific issues around security. For instance, I would presume that a HA operating tunneled multicast service by n-casting is more vulnerable to a DoS attack than some other more native multicast solution. Jari From schmidt@informatik.haw-hamburg.de Thu Sep 24 02:49:02 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563563A687F; Thu, 24 Sep 2009 02:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYIpAlss3T8I; Thu, 24 Sep 2009 02:49:01 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 1436C3A689C; Thu, 24 Sep 2009 02:49:00 -0700 (PDT) Envelope-to: iesg@ietf.org, mobopts@irtf.org Received: from [91.113.129.90] (helo=[192.168.1.216]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Mqkxi-0005fO-Mm; Thu, 24 Sep 2009 11:50:06 +0200 Message-ID: <4ABB40C9.4050909@informatik.haw-hamburg.de> Date: Thu, 24 Sep 2009 11:50:01 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <4ABB39DF.10609@piuha.net> In-Reply-To: <4ABB39DF.10609@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipdvb-chairs@tools.ietf.org, draft-irtf-mobopts-mmcastv6-ps@tools.ietf.org, multimob-chairs@tools.ietf.org, IESG , "16ng-chairs@tools.ietf.org" <16ng-chairs@tools.ietf.org>, ml-mobopts Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:49:02 -0000 Hi Jari, many thanks for your review and in particular for the detailed comments: Most of them will obviously improve the document, some of them we have to consider in detail. We will be back with an exhaustive response once we have re-worked all details. Thanks again! Thomas Jari Arkko wrote: > Hi all, > > I have reviewed this document today. The purpose of my review and the > following IESG review is to perform a so called RFC 3932 check, i.e., > make sure that documents outside the IETF stream do not allocate IANA > values reserved for standards track protocols or otherwise collide with > IETF working group efforts. > > I have not found any collision with this work and IETF work, though > obviously, this work has been one of the inputs for the formation of the > MOBOPTS working group, and also talks about IP over a number of link > layers. > > I have recommended the standard RFC 3932 boilerplate IESG note about > non-IETF work. Once the 3932bis work is concluded we will be able to > make use of the new style of headers and boilerplates which do not > require IESG notes. I have written to the tracker that if this happens > before this document comes out of the RFC Editor queue then no note is > needed. > > The document will be under the entire IESG's review in two weeks to > confirm my recommendation. Please remember that neither my review or the > IESG review is a technical review. In other words, the RG is fully > responsible for the correctness of the document. As a personal note I > wanted to say nevertheless that I was reasonably happy with the > document. Thank you for writing this. > > In any case, I have included a few personal review comments below. Also, > as the document contains quite a bit of material relating to IP over > 802.16 and IP over DVB, I have Cced the relevant working group chairs in > case they have further comments. > > Jari Arkko > >> obility management may issue >> traffic directives that lead to suboptimal routing, i.e., erroneous >> subscriptions following predictive handover operations, or slow >> effective leaves caused by MLD querying, or by departure of the MN >> from a previous network without leaving the subscribed groups. >> > > I had a hard time parsing this. Maybe say instead: "Mobility management > may impact routing by, e.g., erroneous ... or by MNs leaving networks > without unsubscribing form the groups they were receiving.". What's a > "slow effective leave"? > >> IP multicast deployment in general has been hesitant over the past 15 >> years > > s/hesitant/slow/? > >> a strong business case for IP >> portables > ... portable IP-based devices. > >> Current packet filtering practice causes inter-working problems >> between Mobile IPv6 nodes connected via GPRS [46 >> ]. >> > This is incorrect AFAIK. There are filtering procedures in IMS that > cause problems for Mobile IPv6 and other things. However, those > filtering mechanisms are not a part of the link layer nor are they > applied for regular Internet access. I would suggest this statement be > deleted from the draft, along with the reference. > >> PTM uses an >> unidirectional common channel, operating in unacknowledged without >> adjustment of power levels and no reporting on lost packets. >> > > ... unacknowledged mode? > >> Mobility services transport for MIH naturally reside >> on the network layer and are currently in the process of >> specification [55 >> ]. >> >> > draft-ietf-mipshop-mstp-solution is an approved specification (though > not yet out of the RFC Ed queue). > > Also, I believe 802.21 specifies both network and link layer transport, > so its not clear why you say "naturally" above. > > In general Section 4 wanders off a little bit to topics outside > multicast. I understand that some amount of explanation is needed about > what each L2 technology does, but I'd consider tightening the text in > AUTH48 in some places. > >> MLD >> router querying will allow the multicast forwarding state to be >> restored in case of an erroneous prediction (i.e., an anticipated >> move to a network that is not fulfilled). > fulfilled? > >> Mobility protocols need to consider the implications and requirements >> for AAA. AAA binding records may change between attachments, or may >> be individually chosen prior to network (re-)association. The most >> appropriate network path may be one that satisfies user preferences, >> e.g., to use/avoid a specific network, minimize monetary cost, etc, >> rather than one that only minimizes the routing cost. Consequently, >> AAA bindings cannot be treated at a pure level of context transfer. >> > It was not clear to me why AAA is relevant. And what's an "AAA binding > record"? I must say that I don't understand the rest of the paragraph > either. > > The term AAA was not defined or expanded. Please check the other terms too. > >> Due to lack of feedback, the admission [83 >> ] >> and binding >> updates [84 >> ] >> of mobile multicast sources require autonomously >> verifiable authentication as can be achieved by Cryptographically >> Generated Addresses (CGAs). >> > And presumably with other means as well. I would suggest saying "... be > achieved by, for instance, ...". > > It would have been interesting if Section 8 listed some of the multicast > specific issues around security. For instance, I would presume that a HA > operating tunneled multicast service by n-casting is more vulnerable to > a DoS attack than some other more native multicast solution. > > Jari > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From rkoodli@starentnetworks.com Thu Sep 24 10:09:14 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5D628C121 for ; Thu, 24 Sep 2009 10:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqPkuzfotdLo for ; Thu, 24 Sep 2009 10:09:13 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 756403A6877 for ; Thu, 24 Sep 2009 10:09:13 -0700 (PDT) X-ASG-Debug-ID: 1253811410-23e600520002-hAkvSY X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id E547DEFC64A; Thu, 24 Sep 2009 12:56:50 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id JleC79yI93fgZKCC; Thu, 24 Sep 2009 12:56:50 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Sep 2009 12:55:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps Date: Thu, 24 Sep 2009 12:44:57 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660C21B8C3@exchtewks3.starentnetworks.com> In-Reply-To: <4ABB39DF.10609@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps Thread-Index: Aco8+BFUzu5Wu8KWTvGo+fZXGlGmmAAP0CXg References: <4ABB39DF.10609@piuha.net> From: "Koodli, Rajeev" To: , "IESG" , "ml-mobopts" X-OriginalArrivalTime: 24 Sep 2009 16:55:10.0960 (UTC) FILETIME=[C74BA700:01CA3D37] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253811410 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Cc: 16ng-chairs@tools.ietf.org, multimob-chairs@tools.ietf.org, ipdvb-chairs@tools.ietf.org Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 17:09:14 -0000 =20 Hi Jari, Thanks for your review. The authors will find your input useful and will address them. > I have not found any collision with this work and IETF work,=20 > though obviously, this work has been one of the inputs for=20 > the formation of the MOBOPTS working group, and also talks=20 > about IP over a number of link layers. Perhaps you meant MULTIMOB above. Regards, -Rajeev >=20 > I have recommended the standard RFC 3932 boilerplate IESG=20 > note about non-IETF work. Once the 3932bis work is concluded=20 > we will be able to make use of the new style of headers and=20 > boilerplates which do not require IESG notes. I have written=20 > to the tracker that if this happens before this document=20 > comes out of the RFC Editor queue then no note is needed. >=20 > The document will be under the entire IESG's review in two=20 > weeks to confirm my recommendation. Please remember that=20 > neither my review or the IESG review is a technical review.=20 > In other words, the RG is fully responsible for the=20 > correctness of the document. As a personal note I wanted to=20 > say nevertheless that I was reasonably happy with the=20 > document. Thank you for writing this. >=20 > In any case, I have included a few personal review comments=20 > below. Also, as the document contains quite a bit of material=20 > relating to IP over > 802.16 and IP over DVB, I have Cced the relevant working=20 > group chairs in case they have further comments. >=20 > Jari Arkko >=20 > > obility management may issue > > traffic directives that lead to suboptimal routing,=20 > i.e., erroneous > > subscriptions following predictive handover operations, or slow > > effective leaves caused by MLD querying, or by departure=20 > of the MN > > from a previous network without leaving the subscribed groups. > > =20 >=20 > I had a hard time parsing this. Maybe say instead: "Mobility=20 > management may impact routing by, e.g., erroneous ... or by=20 > MNs leaving networks without unsubscribing form the groups=20 > they were receiving.". What's a "slow effective leave"? >=20 > > IP multicast deployment in general has been hesitant over=20 > the past 15 > > years >=20 > s/hesitant/slow/? >=20 > > a strong business case for IP > > portables > ... portable IP-based devices. >=20 > > Current packet filtering practice causes inter-working=20 > problems between Mobile IPv6 nodes connected via GPRS [46=20 > ref-46>]. > > =20 > This is incorrect AFAIK. There are filtering procedures in=20 > IMS that cause problems for Mobile IPv6 and other things.=20 > However, those filtering mechanisms are not a part of the=20 > link layer nor are they applied for regular Internet access.=20 > I would suggest this statement be deleted from the draft,=20 > along with the reference. >=20 > > PTM uses an > > unidirectional common channel, operating in=20 > unacknowledged without > > adjustment of power levels and no reporting on lost packets. > > =20 >=20 > ... unacknowledged mode? >=20 > > Mobility services transport for MIH naturally reside > > on the network layer and are currently in the process of > > specification [55=20 > ref-55>]. > > > > =20 > draft-ietf-mipshop-mstp-solution is an approved specification=20 > (though not yet out of the RFC Ed queue). >=20 > Also, I believe 802.21 specifies both network and link layer=20 > transport, so its not clear why you say "naturally" above. >=20 > In general Section 4 wanders off a little bit to topics=20 > outside multicast. I understand that some amount of=20 > explanation is needed about what each L2 technology does, but=20 > I'd consider tightening the text in > AUTH48 in some places. >=20 > > MLD > > router querying will allow the multicast forwarding state to be > > restored in case of an erroneous prediction (i.e., an anticipated > > move to a network that is not fulfilled). > fulfilled? >=20 > > Mobility protocols need to consider the implications and=20 > requirements > > for AAA. AAA binding records may change between=20 > attachments, or may > > be individually chosen prior to network=20 > (re-)association. The most > > appropriate network path may be one that satisfies user=20 > preferences, > > e.g., to use/avoid a specific network, minimize monetary=20 > cost, etc, > > rather than one that only minimizes the routing cost.=20 > Consequently, > > AAA bindings cannot be treated at a pure level of=20 > context transfer. > > =20 > It was not clear to me why AAA is relevant. And what's an=20 > "AAA binding record"? I must say that I don't understand the=20 > rest of the paragraph either. >=20 > The term AAA was not defined or expanded. Please check the=20 > other terms too. >=20 > > Due to lack of feedback, the admission [83=20 > ref-83>] and binding > > updates [84=20 > ref-84>] of mobile multicast sources require autonomously > > verifiable authentication as can be achieved by Cryptographically > > Generated Addresses (CGAs). > > =20 > And presumably with other means as well. I would suggest=20 > saying "... be achieved by, for instance, ...". >=20 > It would have been interesting if Section 8 listed some of=20 > the multicast specific issues around security. For instance,=20 > I would presume that a HA operating tunneled multicast=20 > service by n-casting is more vulnerable to a DoS attack than=20 > some other more native multicast solution. >=20 > Jari >=20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts >=20 From jari.arkko@piuha.net Thu Sep 24 11:13:49 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2102D3A6816 for ; Thu, 24 Sep 2009 11:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHRk1KyuHttL for ; Thu, 24 Sep 2009 11:13:48 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5A5F23A6845 for ; Thu, 24 Sep 2009 11:13:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5B762D4943; Thu, 24 Sep 2009 21:14:56 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuKtLFUPHX2I; Thu, 24 Sep 2009 21:14:54 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A5F4DD4922; Thu, 24 Sep 2009 21:14:54 +0300 (EEST) Message-ID: <4ABBB71D.2040207@piuha.net> Date: Thu, 24 Sep 2009 21:14:53 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4ABB39DF.10609@piuha.net> <4D35478224365146822AE9E3AD4A26660C21B8C3@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660C21B8C3@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipdvb-chairs@tools.ietf.org, draft-irtf-mobopts-mmcastv6-ps@tools.ietf.org, multimob-chairs@tools.ietf.org, IESG , 16ng-chairs@tools.ietf.org, ml-mobopts Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:13:49 -0000 Rajeev, >> I have not found any collision with this work and IETF work, >> though obviously, this work has been one of the inputs for >> the formation of the MOBOPTS working group, and also talks >> about IP over a number of link layers. >> > > Perhaps you meant MULTIMOB above. > Of course, sorry for the confusion. Jari