From nobody Tue Jul 1 17:38:07 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428231A0AA9 for ; Tue, 1 Jul 2014 17:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxDQsWZ-4myc for ; Tue, 1 Jul 2014 17:38:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60AF1A0A8E for ; Tue, 1 Jul 2014 17:38:01 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 109BBD2328B; Wed, 2 Jul 2014 02:38:00 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id DC531CC5EB6; Wed, 2 Jul 2014 02:37:59 +0200 (CEST) Message-ID: <1404261479.5086.15.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hidetoshi Yokota Date: Wed, 02 Jul 2014 02:37:59 +0200 In-Reply-To: <53B0155E.2050002@gmail.com> References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20792.003 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ioi8eejsLZK8lqKrJajkp2kwRTc Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 02 Jul 2014 00:38:06 -0000 Hi Hidetoshi, Thanks again for your comments. Please see inline below some comments/replies from my side: On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote: > Hi Carlos, > > I briefly reviewed the updated draft and have a couple of comments. > > o The messages named as FMI/FMA in this document are actually UPN/UPA, > so the description is confusing since it looks as if new messages were > defined. I would propose a new flag or notification reason/status code > to indicate that UPN/UPA are used for flow mobility. The use of FMI/FMA is simply to make clearer that these UPN/UPA messages are for flow mobility purposes. New notification reason codes are actually defined in the document for this purpose. > > o In the previous version, FMI could convey the Flow ID mobility option, > but the latest version can convey only HNPs. This looks like a > degradation and I'm not sure how both LMA and MAG can share the same > flow mobility cache. With the UPN/UPA signaling option, the document has never supported conveying the Flow ID mobility option. Ensuring that both the LMA and MAG keep the same flow mobility cache was out of the scope of the document. If the WG agrees, we could add the possibility of supporting UPN/UPA (FMI/FMA) optionally conveying the Flow ID mobility option. What do other people think? > > o The flow mobility operation such as "add" or "remove" should be able > to specify the targeted flow. To this end, the Flow ID mobility option > in RFC6089 should be used. The flow binding action sub-option defined in > RFC7109 can be used for the flow mobility operation. In the current version "add" and "remove" are performed with prefix granularity (as I mentioned in a previous e-mail, this was the consensus reached some time ago, but we can revisit this if the WG wants to do so). Thanks! Carlos > > Please take these points into consideration. > > Regards, > -- > Hidetoshi > > (2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote: > > Hi, > > > > I've just posted -10, now including only one single signaling > > mechanisms, as discussed on the ML. > > > > I think this version is ready for WGLC. > > > > Carlos > > > > On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote: > >> Hi Carlos/All, > >> > >> > >> Can we plan to close this work in the next few days. AFAIK, this > >> FMI/FMA issue is now resolved. If you still doubt the consensus on > >> this issue, we can wait for 2 days for any comments and post the next > >> rev. > >> > >> > >> I'm hoping we will close this work this week and go LC on Monday (if > >> chairs agree). Waiting for Toronto meeting can delay the work by > >> another few months. > >> > >> > >> > >> > >> Regards > >> Sri > >> > >> > >> From: Sri Gundavelli > >> Date: Thursday, June 19, 2014 6:46 AM > >> To: "pierrick.seite@orange.com" , Hidetoshi > >> Yokota , "netext@ietf.org" > >> Subject: Re: [netext] [Fwd: I-D Action: > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> > >> > >> > >> Hi Pierrick, > >> > >> > >> After the NETEXT meeting in London, we had some offline discussions > >> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN) > >> messaging format for FMI/FMA. So, the Flow Mobility spec may refer to > >> this message as FMI/FMA, but the underneath messaging format will > >> confirm to RFC-7077 format and will have references to RFC-7077. We > >> are not going to define a new MH message. This closes the key issue of > >> using two notification approaches in the same spec. AFAIK, no one has > >> any objection to this. If any does, its now time to speak up :) > >> > >> > >> Regards > >> Sri > >> > >> > >> > >> > >> From: "pierrick.seite@orange.com" > >> Date: Thursday, June 19, 2014 1:32 AM > >> To: Hidetoshi Yokota , "netext@ietf.org" > >> > >> Subject: Re: [netext] [Fwd: I-D Action: > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> > >> > >> > >> Hi Hidetoshi/all, > >> > >> > >> > >> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in > >> London, we have decided (group consensus) to reintroduce FMI/FMA to > >> avoid dependency between RFC. Now, it’s true that introducing 2 > >> options for message format makes the solution more complex for little > >> added-value (no major differences between messages)… So, maybe the > >> question is “is it good or bad to have RFC dependency?” then update > >> the draft according the answer... > >> > >> > >> > >> Pierrick > >> > >> > >> > >> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi > >> Yokota > >> Envoyé : jeudi 19 juin 2014 06:41 > >> À : netext@ietf.org > >> Objet : Re: [netext] [Fwd: I-D Action: > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> > >> > >> > >> > >> Hello Carlos, > >> > >> Thanks for updating the draft. > >> I have a couple of questions and comments: > >> > >> o In Section 3.2.1, which is the shared prefix case, there is no > >> message exchange between the LMA and MAG, so there is no flow > >> information on the MAG side. It should work in the sense of routing, > >> but if, for example, each flow has a specific QoS, the MAG should also > >> need to know which flow should go on which QoS path especially for > >> upstream traffic towards the LMA. Or, the MAG may want to send a > >> trigger for flow mobility to the MN (the exact mechanism is out of > >> scope). Some mobility signaling should be there, too. > >> > >> o In Section 3.3, FMI/FMA are revived considering the case where UPN > >> is not supported, but they convey very little information. There is no > >> special information that cannot be conveyed by the existing messages. > >> Since RFC7077 is now a proposed standard, I cannot think of a > >> situation where the UPN/UPA are not supported, nevertheless FMI/FMA > >> are supported. It rather seems more natural to mandate the support of > >> RFC7077 or to mandate FMI/FMA for all flow mobility operations. > >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to > >> convey different set of parameters in Figure 7. Could you clarify it a > >> little bit more please? > >> > >> o In Section 3.3, just above Figure 7, there is a description: "..., > >> and the type of flow mobility operation (add flow)", but does RFC6089 > >> define such an operation code? This kind of operation should also be > >> defined in the draft. > >> > >> Regards, > >> > >> > >> > >> -- > >> Hidetoshi Yokota > >> > >> KDDI R&D Laboratories, Inc. > >> e-mail:yokota@kddilabs.jp > >> > >> > >> > >> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote: > >> > >> > >> Hi, > >> > >> As agreed in London, I've updated the flow mobility draft to include > >> also the FMI/FMA signaling option (in addition to the use of Update > >> Notifications). The draft also includes a mechanism to allow selecting > >> which one of the two signaling mechanisms to use. > >> > >> In my personal opinion, it'd be much cleaner and simpler to just specify > >> one signaling mechanism, but this is up to the WG to decide. > >> > >> Comments, reviews and discussion on this new revision would be welcome. > >> Hopefully we could get at least a new revision before Toronto. > >> > >> Thanks, > >> > >> Carlos > >> > >> > >> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > >> > >> > >> > >> _________________________________________________________________________________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or privileged information that may be protected by law; > >> they should not be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > >> Thank you. > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > From nobody Wed Jul 2 00:08:51 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA71A0AD6; Wed, 2 Jul 2014 00:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niZSlKpbAX0n; Wed, 2 Jul 2014 00:08:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DBF1A0A98; Wed, 2 Jul 2014 00:08:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702070845.15575.52045.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 00:08:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/NBLdRrpUVmY20gWDJAeciLfwNSw Cc: iesg-secretary@ietf.org Subject: [netext] Last Call Expired: X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 07:08:47 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Wed Jul 2 06:37:27 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C491A00E2 for ; Wed, 2 Jul 2014 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEjQTBPo_35y for ; Wed, 2 Jul 2014 06:37:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5161A00C2 for ; Wed, 2 Jul 2014 06:37:20 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1243D2AC518; Wed, 2 Jul 2014 15:37:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E8A8BC807B; Wed, 2 Jul 2014 15:37:18 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 2 Jul 2014 15:37:18 +0200 From: To: "cjbc@it.uc3m.es" , Hidetoshi Yokota Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] Thread-Index: AQHPlY3htvAJ1IWl0EOaJJ8WiqPoZpuMyPvw Date: Wed, 2 Jul 2014 13:37:18 +0000 Message-ID: <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> In-Reply-To: <1404261479.5086.15.camel@acorde.it.uc3m.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.1.72719 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/3svQ8wPQLQnmIzMncvl8YNPmpUg Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 13:37:24 -0000 SGksDQoNCkp1c3QgYSBtaW5vciBjb21tZW50Og0KDQpUaGUgYWNrbm93bGVkZ2VtZW50IHNlY3Rp b24gc3RhdGVzIHRoYXQgdGhpcyB3b3JrIGhhcyBiZWVuIHBhcnRpYWxseSBmdW5kZWQgYnkgdGhl IEV1cm9wZWFuIENvbW11bml0eSB2aWEgYSByZXNlYXJjaCBwcm9qZWN0LiBJcyBzdWNoIHN0YXRl bWVudCBhY2NlcHRhYmxlIGZvciBhbiBJRVRGIGRvY3VtZW50PyBTaG91ZG4ndCB3ZSByZW1vdmUg dGhpcyBhY2s/DQoNClBpZXJyaWNrDQoNCj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj5E ZcKgOiBDYXJsb3MgSmVzw7pzIEJlcm5hcmRvcyBDYW5vIFttYWlsdG86Y2piY0BpdC51YzNtLmVz XQ0KPkVudm95w6nCoDogbWVyY3JlZGkgMiBqdWlsbGV0IDIwMTQgMDI6MzgNCj7DgMKgOiBIaWRl dG9zaGkgWW9rb3RhDQo+Q2PCoDogU3JpIEd1bmRhdmVsbGk7IFNFSVRFIFBpZXJyaWNrIElNVC9P TE47IG5ldGV4dEBpZXRmLm9yZw0KPk9iamV0wqA6IFJlOiBbbmV0ZXh0XSBbRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW5ldGV4dC1wbWlwdjYtZmxvd21vYi0NCj4wOS50eHRdDQo+DQo+SGkg SGlkZXRvc2hpLA0KPg0KPlRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNl ZSBpbmxpbmUgYmVsb3cgc29tZQ0KPmNvbW1lbnRzL3JlcGxpZXMgZnJvbSBteSBzaWRlOg0KPg0K Pk9uIFN1biwgMjAxNC0wNi0yOSBhdCAyMjozMiArMDkwMCwgSGlkZXRvc2hpIFlva290YSB3cm90 ZToNCj4+IEhpIENhcmxvcywNCj4+DQo+PiBJIGJyaWVmbHkgcmV2aWV3ZWQgdGhlIHVwZGF0ZWQg ZHJhZnQgYW5kIGhhdmUgYSBjb3VwbGUgb2YgY29tbWVudHMuDQo+Pg0KPj4gbyBUaGUgbWVzc2Fn ZXMgbmFtZWQgYXMgRk1JL0ZNQSBpbiB0aGlzIGRvY3VtZW50IGFyZSBhY3R1YWxseQ0KPlVQTi9V UEEsDQo+PiBzbyB0aGUgZGVzY3JpcHRpb24gaXMgY29uZnVzaW5nIHNpbmNlIGl0IGxvb2tzIGFz IGlmIG5ldyBtZXNzYWdlcyB3ZXJlDQo+PiBkZWZpbmVkLiBJIHdvdWxkIHByb3Bvc2UgYSBuZXcg ZmxhZyBvciBub3RpZmljYXRpb24gcmVhc29uL3N0YXR1cyBjb2RlDQo+PiB0byBpbmRpY2F0ZSB0 aGF0IFVQTi9VUEEgYXJlIHVzZWQgZm9yIGZsb3cgbW9iaWxpdHkuDQo+DQo+VGhlIHVzZSBvZiBG TUkvRk1BIGlzIHNpbXBseSB0byBtYWtlIGNsZWFyZXIgdGhhdCB0aGVzZSBVUE4vVVBBIG1lc3Nh Z2VzDQo+YXJlIGZvciBmbG93IG1vYmlsaXR5IHB1cnBvc2VzLiBOZXcgbm90aWZpY2F0aW9uIHJl YXNvbiBjb2RlcyBhcmUgYWN0dWFsbHkNCj5kZWZpbmVkIGluIHRoZSBkb2N1bWVudCBmb3IgdGhp cyBwdXJwb3NlLg0KPg0KPj4NCj4+IG8gSW4gdGhlIHByZXZpb3VzIHZlcnNpb24sIEZNSSBjb3Vs ZCBjb252ZXkgdGhlIEZsb3cgSUQgbW9iaWxpdHkNCj4+IG9wdGlvbiwgYnV0IHRoZSBsYXRlc3Qg dmVyc2lvbiBjYW4gY29udmV5IG9ubHkgSE5Qcy4gVGhpcyBsb29rcyBsaWtlIGENCj4+IGRlZ3Jh ZGF0aW9uIGFuZCBJJ20gbm90IHN1cmUgaG93IGJvdGggTE1BIGFuZCBNQUcgY2FuIHNoYXJlIHRo ZSBzYW1lDQo+PiBmbG93IG1vYmlsaXR5IGNhY2hlLg0KPg0KPldpdGggdGhlIFVQTi9VUEEgc2ln bmFsaW5nIG9wdGlvbiwgdGhlIGRvY3VtZW50IGhhcyBuZXZlciBzdXBwb3J0ZWQNCj5jb252ZXlp bmcgdGhlIEZsb3cgSUQgbW9iaWxpdHkgb3B0aW9uLiBFbnN1cmluZyB0aGF0IGJvdGggdGhlIExN QSBhbmQgTUFHDQo+a2VlcCB0aGUgc2FtZSBmbG93IG1vYmlsaXR5IGNhY2hlIHdhcyBvdXQgb2Yg dGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4gSWYNCj50aGUgV0cgYWdyZWVzLCB3ZSBjb3VsZCBh ZGQgdGhlIHBvc3NpYmlsaXR5IG9mIHN1cHBvcnRpbmcgVVBOL1VQQQ0KPihGTUkvRk1BKSBvcHRp b25hbGx5IGNvbnZleWluZyB0aGUgRmxvdyBJRCBtb2JpbGl0eSBvcHRpb24uIFdoYXQgZG8gb3Ro ZXINCj5wZW9wbGUgdGhpbms/DQo+DQo+Pg0KPj4gbyBUaGUgZmxvdyBtb2JpbGl0eSBvcGVyYXRp b24gc3VjaCBhcyAiYWRkIiBvciAicmVtb3ZlIiBzaG91bGQgYmUgYWJsZQ0KPj4gdG8gc3BlY2lm eSB0aGUgdGFyZ2V0ZWQgZmxvdy4gVG8gdGhpcyBlbmQsIHRoZSBGbG93IElEIG1vYmlsaXR5IG9w dGlvbg0KPj4gaW4gUkZDNjA4OSBzaG91bGQgYmUgdXNlZC4gVGhlIGZsb3cgYmluZGluZyBhY3Rp b24gc3ViLW9wdGlvbiBkZWZpbmVkDQo+PiBpbg0KPj4gUkZDNzEwOSBjYW4gYmUgdXNlZCBmb3Ig dGhlIGZsb3cgbW9iaWxpdHkgb3BlcmF0aW9uLg0KPg0KPkluIHRoZSBjdXJyZW50IHZlcnNpb24g ImFkZCIgYW5kICJyZW1vdmUiIGFyZSBwZXJmb3JtZWQgd2l0aCBwcmVmaXgNCj5ncmFudWxhcml0 eSAoYXMgSSBtZW50aW9uZWQgaW4gYSBwcmV2aW91cyBlLW1haWwsIHRoaXMgd2FzIHRoZSBjb25z ZW5zdXMNCj5yZWFjaGVkIHNvbWUgdGltZSBhZ28sIGJ1dCB3ZSBjYW4gcmV2aXNpdCB0aGlzIGlm IHRoZSBXRyB3YW50cyB0byBkbyBzbykuDQo+DQo+VGhhbmtzIQ0KPg0KPkNhcmxvcw0KPg0KPj4N Cj4+IFBsZWFzZSB0YWtlIHRoZXNlIHBvaW50cyBpbnRvIGNvbnNpZGVyYXRpb24uDQo+Pg0KPj4g UmVnYXJkcywNCj4+IC0tDQo+PiBIaWRldG9zaGkNCj4+DQo+PiAoMjAxNC8wNi8yNiA3OjA1KSwg Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyB3cm90ZToNCj4+ID4gSGksDQo+PiA+DQo+PiA+ IEkndmUganVzdCBwb3N0ZWQgLTEwLCBub3cgaW5jbHVkaW5nIG9ubHkgb25lIHNpbmdsZSBzaWdu YWxpbmcNCj4+ID4gbWVjaGFuaXNtcywgYXMgZGlzY3Vzc2VkIG9uIHRoZSBNTC4NCj4+ID4NCj4+ ID4gSSB0aGluayB0aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yIFdHTEMuDQo+PiA+DQo+PiA+IENh cmxvcw0KPj4gPg0KPj4gPiBPbiBUaHUsIDIwMTQtMDYtMTkgYXQgMTg6MDkgKzAwMDAsIFNyaSBH dW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQo+PiA+PiBIaSBDYXJsb3MvQWxsLA0KPj4gPj4N Cj4+ID4+DQo+PiA+PiBDYW4gd2UgcGxhbiB0byBjbG9zZSB0aGlzIHdvcmsgaW4gdGhlIG5leHQg ZmV3IGRheXMuIEFGQUlLLCB0aGlzDQo+PiA+PiBGTUkvRk1BIGlzc3VlIGlzIG5vdyByZXNvbHZl ZC4gSWYgeW91IHN0aWxsIGRvdWJ0IHRoZSBjb25zZW5zdXMgb24NCj4+ID4+IHRoaXMgaXNzdWUs IHdlIGNhbiB3YWl0IGZvciAyIGRheXMgZm9yIGFueSBjb21tZW50cyBhbmQgcG9zdCB0aGUNCj4+ ID4+IG5leHQgcmV2Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBJJ20gaG9waW5nIHdlIHdpbGwgY2xv c2UgdGhpcyB3b3JrIHRoaXMgd2VlayBhbmQgZ28gTEMgb24gTW9uZGF5DQo+PiA+PiAoaWYgY2hh aXJzIGFncmVlKS4gV2FpdGluZyBmb3IgVG9yb250byBtZWV0aW5nIGNhbiBkZWxheSB0aGUgd29y aw0KPj4gPj4gYnkgYW5vdGhlciBmZXcgbW9udGhzLg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4g Pj4NCj4+ID4+IFJlZ2FyZHMNCj4+ID4+IFNyaQ0KPj4gPj4NCj4+ID4+DQo+PiA+PiBGcm9tOiBT cmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPg0KPj4gPj4gRGF0ZTogVGh1cnNkYXks IEp1bmUgMTksIDIwMTQgNjo0NiBBTQ0KPj4gPj4gVG86ICJwaWVycmljay5zZWl0ZUBvcmFuZ2Uu Y29tIiA8cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT4sDQo+PiA+PiBIaWRldG9zaGkgWW9rb3Rh IDx5b2tvdGFAa2RkaWxhYnMuanA+LCAibmV0ZXh0QGlldGYub3JnIg0KPj4gPj4gPG5ldGV4dEBp ZXRmLm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBbRndkOiBJLUQgQWN0aW9uOg0K Pj4gPj4gZHJhZnQtaWV0Zi1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDkudHh0XQ0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gSGkgUGllcnJpY2ssDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEFmdGVy IHRoZSBORVRFWFQgbWVldGluZyBpbiBMb25kb24sIHdlIGhhZCBzb21lIG9mZmxpbmUgZGlzY3Vz c2lvbnMNCj4+ID4+IHdpdGggUmFqaXYgYW5kIGZvbGtzLiBUaGVyZSBpcyBhZ3JlZW1lbnQgdG8g dXNlIHRoZSBSRkMtNzA3NyAoVVBOKQ0KPj4gPj4gbWVzc2FnaW5nIGZvcm1hdCBmb3IgRk1JL0ZN QS4gU28sIHRoZSBGbG93IE1vYmlsaXR5IHNwZWMgbWF5IHJlZmVyDQo+PiA+PiB0byB0aGlzIG1l c3NhZ2UgYXMgRk1JL0ZNQSwgYnV0IHRoZSB1bmRlcm5lYXRoIG1lc3NhZ2luZyBmb3JtYXQNCj4+ ID4+IHdpbGwgY29uZmlybSB0byBSRkMtNzA3NyBmb3JtYXQgYW5kIHdpbGwgaGF2ZSByZWZlcmVu Y2VzIHRvDQo+PiA+PiBSRkMtNzA3Ny4gV2UgYXJlIG5vdCBnb2luZyB0byBkZWZpbmUgYSBuZXcg TUggbWVzc2FnZS4gVGhpcyBjbG9zZXMNCj4+ID4+IHRoZSBrZXkgaXNzdWUgb2YgdXNpbmcgdHdv IG5vdGlmaWNhdGlvbiBhcHByb2FjaGVzIGluIHRoZSBzYW1lDQo+PiA+PiBzcGVjLiBBRkFJSywg bm8gb25lIGhhcyBhbnkgb2JqZWN0aW9uIHRvIHRoaXMuIElmIGFueSBkb2VzLCBpdHMgbm93DQo+ PiA+PiB0aW1lIHRvIHNwZWFrIHVwIDopDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IFJlZ2FyZHMNCj4+ ID4+IFNyaQ0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEZyb206ICJwaWVycmlj ay5zZWl0ZUBvcmFuZ2UuY29tIiA8cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT4NCj4+ID4+IERh dGU6IFRodXJzZGF5LCBKdW5lIDE5LCAyMDE0IDE6MzIgQU0NCj4+ID4+IFRvOiBIaWRldG9zaGkg WW9rb3RhIDx5b2tvdGFAa2RkaWxhYnMuanA+LCAibmV0ZXh0QGlldGYub3JnIg0KPj4gPj4gPG5l dGV4dEBpZXRmLm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBbRndkOiBJLUQgQWN0 aW9uOg0KPj4gPj4gZHJhZnQtaWV0Zi1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDkudHh0XQ0KPj4g Pj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gSGkgSGlkZXRvc2hpL2FsbCwNCj4+ID4+DQo+PiA+Pg0K Pj4gPj4NCj4+ID4+IFJlbGVhc2UgLTA4IG1hbmRhdGVzIFJGQzcwNzcgYW5kIHRoZSBkb2Mgd2Fz IGdvb2QsIElNSE8uIEJ1dCwgaW4NCj4+ID4+IExvbmRvbiwgd2UgaGF2ZSBkZWNpZGVkIChncm91 cCBjb25zZW5zdXMpIHRvIHJlaW50cm9kdWNlIEZNSS9GTUEgdG8NCj4+ID4+IGF2b2lkIGRlcGVu ZGVuY3kgYmV0d2VlbiBSRkMuIE5vdywgaXTigJlzIHRydWUgdGhhdCBpbnRyb2R1Y2luZyAyDQo+ PiA+PiBvcHRpb25zIGZvciBtZXNzYWdlIGZvcm1hdCBtYWtlcyB0aGUgc29sdXRpb24gbW9yZSBj b21wbGV4IGZvcg0KPj4gPj4gbGl0dGxlIGFkZGVkLXZhbHVlIChubyBtYWpvciBkaWZmZXJlbmNl cyBiZXR3ZWVuIG1lc3NhZ2VzKeKApiBTbywNCj4+ID4+IG1heWJlIHRoZSBxdWVzdGlvbiBpcyDi gJxpcyBpdCBnb29kIG9yIGJhZCB0byBoYXZlIFJGQyBkZXBlbmRlbmN5P+KAnQ0KPj4gPj4gdGhl biB1cGRhdGUgdGhlIGRyYWZ0IGFjY29yZGluZyB0aGUgYW5zd2VyLi4uDQo+PiA+Pg0KPj4gPj4N Cj4+ID4+DQo+PiA+PiBQaWVycmljaw0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gRGUgOiBu ZXRleHQgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPj4g Pj4gSGlkZXRvc2hpIFlva290YSBFbnZvecOpIDogamV1ZGkgMTkganVpbiAyMDE0IDA2OjQxIMOA IDoNCj4+ID4+IG5ldGV4dEBpZXRmLm9yZyBPYmpldCA6IFJlOiBbbmV0ZXh0XSBbRndkOiBJLUQg QWN0aW9uOg0KPj4gPj4gZHJhZnQtaWV0Zi1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDkudHh0XQ0K Pj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEhlbGxvIENhcmxvcywNCj4+ID4+DQo+ PiA+PiBUaGFua3MgZm9yIHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4+ID4+IEkgaGF2ZSBhIGNvdXBs ZSBvZiBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOg0KPj4gPj4NCj4+ID4+IG8gSW4gU2VjdGlvbiAz LjIuMSwgd2hpY2ggaXMgdGhlIHNoYXJlZCBwcmVmaXggY2FzZSwgdGhlcmUgaXMgbm8NCj4+ID4+ IG1lc3NhZ2UgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgTE1BIGFuZCBNQUcsIHNvIHRoZXJlIGlzIG5v IGZsb3cNCj4+ID4+IGluZm9ybWF0aW9uIG9uIHRoZSBNQUcgc2lkZS4gSXQgc2hvdWxkIHdvcmsg aW4gdGhlIHNlbnNlIG9mDQo+PiA+PiByb3V0aW5nLCBidXQgaWYsIGZvciBleGFtcGxlLCBlYWNo IGZsb3cgaGFzIGEgc3BlY2lmaWMgUW9TLCB0aGUgTUFHDQo+PiA+PiBzaG91bGQgYWxzbyBuZWVk IHRvIGtub3cgd2hpY2ggZmxvdyBzaG91bGQgZ28gb24gd2hpY2ggUW9TIHBhdGgNCj4+ID4+IGVz cGVjaWFsbHkgZm9yIHVwc3RyZWFtIHRyYWZmaWMgdG93YXJkcyB0aGUgTE1BLiBPciwgdGhlIE1B RyBtYXkNCj4+ID4+IHdhbnQgdG8gc2VuZCBhIHRyaWdnZXIgZm9yIGZsb3cgbW9iaWxpdHkgdG8g dGhlIE1OICh0aGUgZXhhY3QNCj4+ID4+IG1lY2hhbmlzbSBpcyBvdXQgb2Ygc2NvcGUpLiAgU29t ZSBtb2JpbGl0eSBzaWduYWxpbmcgc2hvdWxkIGJlIHRoZXJlLA0KPnRvby4NCj4+ID4+DQo+PiA+ PiBvIEluIFNlY3Rpb24gMy4zLCBGTUkvRk1BIGFyZSByZXZpdmVkIGNvbnNpZGVyaW5nIHRoZSBj YXNlIHdoZXJlDQo+PiA+PiBVUE4gaXMgbm90IHN1cHBvcnRlZCwgYnV0IHRoZXkgY29udmV5IHZl cnkgbGl0dGxlIGluZm9ybWF0aW9uLg0KPj4gPj4gVGhlcmUgaXMgbm8gc3BlY2lhbCBpbmZvcm1h dGlvbiB0aGF0IGNhbm5vdCBiZSBjb252ZXllZCBieSB0aGUgZXhpc3RpbmcNCj5tZXNzYWdlcy4N Cj4+ID4+IFNpbmNlIFJGQzcwNzcgaXMgbm93IGEgcHJvcG9zZWQgc3RhbmRhcmQsIEkgY2Fubm90 IHRoaW5rIG9mIGENCj4+ID4+IHNpdHVhdGlvbiB3aGVyZSB0aGUgVVBOL1VQQSBhcmUgbm90IHN1 cHBvcnRlZCwgbmV2ZXJ0aGVsZXNzDQo+Rk1JL0ZNQQ0KPj4gPj4gYXJlIHN1cHBvcnRlZC4gSXQg cmF0aGVyIHNlZW1zIG1vcmUgbmF0dXJhbCB0byBtYW5kYXRlIHRoZSBzdXBwb3J0DQo+PiA+PiBv Zg0KPj4gPj4gUkZDNzA3NyBvciB0byBtYW5kYXRlIEZNSS9GTUEgZm9yIGFsbCBmbG93IG1vYmls aXR5IG9wZXJhdGlvbnMuDQo+PiA+PiBBbHNvLCB3aGVuIGNvbXBhcmVkIHdpdGggVVBOL1VQQSBj YXNlIGluIEZpZ3VyZSA0LCBGTUkvRk1BIHNlZW0gdG8NCj4+ID4+IGNvbnZleSBkaWZmZXJlbnQg c2V0IG9mIHBhcmFtZXRlcnMgaW4gRmlndXJlIDcuIENvdWxkIHlvdSBjbGFyaWZ5DQo+PiA+PiBp dCBhIGxpdHRsZSBiaXQgbW9yZSBwbGVhc2U/DQo+PiA+Pg0KPj4gPj4gbyBJbiBTZWN0aW9uIDMu MywganVzdCBhYm92ZSBGaWd1cmUgNywgdGhlcmUgaXMgYSBkZXNjcmlwdGlvbjoNCj4+ID4+ICIu Li4sIGFuZCB0aGUgdHlwZSBvZiBmbG93IG1vYmlsaXR5IG9wZXJhdGlvbiAoYWRkIGZsb3cpIiwg YnV0IGRvZXMNCj4+ID4+IFJGQzYwODkgZGVmaW5lIHN1Y2ggYW4gb3BlcmF0aW9uIGNvZGU/IFRo aXMga2luZCBvZiBvcGVyYXRpb24NCj4+ID4+IHNob3VsZCBhbHNvIGJlIGRlZmluZWQgaW4gdGhl IGRyYWZ0Lg0KPj4gPj4NCj4+ID4+IFJlZ2FyZHMsDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+ PiAtLQ0KPj4gPj4gSGlkZXRvc2hpIFlva290YQ0KPj4gPj4NCj4+ID4+IEtEREkgUiZEIExhYm9y YXRvcmllcywgSW5jLg0KPj4gPj4gZS1tYWlsOnlva290YUBrZGRpbGFicy5qcA0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gKDIwMTQvMDYvMTQgMjoxNiksIENhcmxvcyBKZXPDunMgQmVybmFy ZG9zIENhbm8gd3JvdGU6DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ICAgICAgICAgIEhpLA0KPj4gPj4N Cj4+ID4+ICAgICAgICAgIEFzIGFncmVlZCBpbiBMb25kb24sIEkndmUgdXBkYXRlZCB0aGUgZmxv dyBtb2JpbGl0eSBkcmFmdCB0byBpbmNsdWRlDQo+PiA+PiAgICAgICAgICBhbHNvIHRoZSBGTUkv Rk1BIHNpZ25hbGluZyBvcHRpb24gKGluIGFkZGl0aW9uIHRvIHRoZSB1c2Ugb2YgVXBkYXRlDQo+ PiA+PiAgICAgICAgICBOb3RpZmljYXRpb25zKS4gVGhlIGRyYWZ0IGFsc28gaW5jbHVkZXMgYSBt ZWNoYW5pc20gdG8gYWxsb3cgc2VsZWN0aW5nDQo+PiA+PiAgICAgICAgICB3aGljaCBvbmUgb2Yg dGhlIHR3byBzaWduYWxpbmcgbWVjaGFuaXNtcyB0byB1c2UuDQo+PiA+Pg0KPj4gPj4gICAgICAg ICAgSW4gbXkgcGVyc29uYWwgb3BpbmlvbiwgaXQnZCBiZSBtdWNoIGNsZWFuZXIgYW5kIHNpbXBs ZXIgdG8ganVzdA0KPnNwZWNpZnkNCj4+ID4+ICAgICAgICAgIG9uZSBzaWduYWxpbmcgbWVjaGFu aXNtLCBidXQgdGhpcyBpcyB1cCB0byB0aGUgV0cgdG8gZGVjaWRlLg0KPj4gPj4NCj4+ID4+ICAg ICAgICAgIENvbW1lbnRzLCByZXZpZXdzIGFuZCBkaXNjdXNzaW9uIG9uIHRoaXMgbmV3IHJldmlz aW9uIHdvdWxkIGJlDQo+d2VsY29tZS4NCj4+ID4+ICAgICAgICAgIEhvcGVmdWxseSB3ZSBjb3Vs ZCBnZXQgYXQgbGVhc3QgYSBuZXcgcmV2aXNpb24gYmVmb3JlIFRvcm9udG8uDQo+PiA+Pg0KPj4g Pj4gICAgICAgICAgVGhhbmtzLA0KPj4gPj4NCj4+ID4+ICAgICAgICAgIENhcmxvcw0KPj4gPj4N Cj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiAgICAgICAgICBuZXRleHQgbWFpbGlu ZyBsaXN0DQo+PiA+PiAgICAgICAgICBuZXRleHRAaWV0Zi5vcmcNCj4+ID4+ICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+PiA+Pg0KPj4gPj4N Cj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPl9fX19fX19fDQo+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+DQo+PiA+PiBD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMNCj4+ID4+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jIHBhcyBldHJlDQo+PiA+PiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UNCj4+ID4+IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUNCj5haW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMNCj5kJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLA0KPmRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4gPj4NCj4+ID4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPj4gPj4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3Qg YmUNCj5kaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K Pj4gPj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZA0KPmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCj4+ID4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPj4gPj4gVGhhbmsgeW91Lg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4+ID4+ IG5ldGV4dEBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRleHQNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+DQo+DQoNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From nobody Wed Jul 2 06:52:03 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6969E1A0117 for ; Wed, 2 Jul 2014 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRck_aKJ1z4q for ; Wed, 2 Jul 2014 06:51:57 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB281A0102 for ; Wed, 2 Jul 2014 06:51:56 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8EBD71239CFB; Wed, 2 Jul 2014 15:51:55 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 7720B1204E29; Wed, 2 Jul 2014 15:51:55 +0200 (CEST) Message-ID: <1404309115.8479.24.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: pierrick.seite@orange.com Date: Wed, 02 Jul 2014 15:51:55 +0200 In-Reply-To: <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20792.007 X-TM-AS-Result: No--28.806-7.0-31-1 X-imss-scan-details: No--28.806-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/o21iKWx2HffxquW49j0SOlm1WLI Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 02 Jul 2014 13:52:01 -0000 Hi Pierrick, This should be fine. I've put similar statements in previous documents and I haven't had any problems so far. The statement just refers to my work (e.g., supporting travels, etc). Carlos On Wed, 2014-07-02 at 13:37 +0000, pierrick.seite@orange.com wrote: > Hi, > > Just a minor comment: > > The acknowledgement section states that this work has been partially funded by the European Community via a research project. Is such statement acceptable for an IETF document? Shoudn't we remove this ack? > > Pierrick > > >-----Message d'origine----- > >De : Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > >Envoyé : mercredi 2 juillet 2014 02:38 > >À : Hidetoshi Yokota > >Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; netext@ietf.org > >Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob- > >09.txt] > > > >Hi Hidetoshi, > > > >Thanks again for your comments. Please see inline below some > >comments/replies from my side: > > > >On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote: > >> Hi Carlos, > >> > >> I briefly reviewed the updated draft and have a couple of comments. > >> > >> o The messages named as FMI/FMA in this document are actually > >UPN/UPA, > >> so the description is confusing since it looks as if new messages were > >> defined. I would propose a new flag or notification reason/status code > >> to indicate that UPN/UPA are used for flow mobility. > > > >The use of FMI/FMA is simply to make clearer that these UPN/UPA messages > >are for flow mobility purposes. New notification reason codes are actually > >defined in the document for this purpose. > > > >> > >> o In the previous version, FMI could convey the Flow ID mobility > >> option, but the latest version can convey only HNPs. This looks like a > >> degradation and I'm not sure how both LMA and MAG can share the same > >> flow mobility cache. > > > >With the UPN/UPA signaling option, the document has never supported > >conveying the Flow ID mobility option. Ensuring that both the LMA and MAG > >keep the same flow mobility cache was out of the scope of the document. If > >the WG agrees, we could add the possibility of supporting UPN/UPA > >(FMI/FMA) optionally conveying the Flow ID mobility option. What do other > >people think? > > > >> > >> o The flow mobility operation such as "add" or "remove" should be able > >> to specify the targeted flow. To this end, the Flow ID mobility option > >> in RFC6089 should be used. The flow binding action sub-option defined > >> in > >> RFC7109 can be used for the flow mobility operation. > > > >In the current version "add" and "remove" are performed with prefix > >granularity (as I mentioned in a previous e-mail, this was the consensus > >reached some time ago, but we can revisit this if the WG wants to do so). > > > >Thanks! > > > >Carlos > > > >> > >> Please take these points into consideration. > >> > >> Regards, > >> -- > >> Hidetoshi > >> > >> (2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote: > >> > Hi, > >> > > >> > I've just posted -10, now including only one single signaling > >> > mechanisms, as discussed on the ML. > >> > > >> > I think this version is ready for WGLC. > >> > > >> > Carlos > >> > > >> > On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote: > >> >> Hi Carlos/All, > >> >> > >> >> > >> >> Can we plan to close this work in the next few days. AFAIK, this > >> >> FMI/FMA issue is now resolved. If you still doubt the consensus on > >> >> this issue, we can wait for 2 days for any comments and post the > >> >> next rev. > >> >> > >> >> > >> >> I'm hoping we will close this work this week and go LC on Monday > >> >> (if chairs agree). Waiting for Toronto meeting can delay the work > >> >> by another few months. > >> >> > >> >> > >> >> > >> >> > >> >> Regards > >> >> Sri > >> >> > >> >> > >> >> From: Sri Gundavelli > >> >> Date: Thursday, June 19, 2014 6:46 AM > >> >> To: "pierrick.seite@orange.com" , > >> >> Hidetoshi Yokota , "netext@ietf.org" > >> >> > >> >> Subject: Re: [netext] [Fwd: I-D Action: > >> >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> >> > >> >> > >> >> > >> >> Hi Pierrick, > >> >> > >> >> > >> >> After the NETEXT meeting in London, we had some offline discussions > >> >> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN) > >> >> messaging format for FMI/FMA. So, the Flow Mobility spec may refer > >> >> to this message as FMI/FMA, but the underneath messaging format > >> >> will confirm to RFC-7077 format and will have references to > >> >> RFC-7077. We are not going to define a new MH message. This closes > >> >> the key issue of using two notification approaches in the same > >> >> spec. AFAIK, no one has any objection to this. If any does, its now > >> >> time to speak up :) > >> >> > >> >> > >> >> Regards > >> >> Sri > >> >> > >> >> > >> >> > >> >> > >> >> From: "pierrick.seite@orange.com" > >> >> Date: Thursday, June 19, 2014 1:32 AM > >> >> To: Hidetoshi Yokota , "netext@ietf.org" > >> >> > >> >> Subject: Re: [netext] [Fwd: I-D Action: > >> >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> >> > >> >> > >> >> > >> >> Hi Hidetoshi/all, > >> >> > >> >> > >> >> > >> >> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in > >> >> London, we have decided (group consensus) to reintroduce FMI/FMA to > >> >> avoid dependency between RFC. Now, it’s true that introducing 2 > >> >> options for message format makes the solution more complex for > >> >> little added-value (no major differences between messages)… So, > >> >> maybe the question is “is it good or bad to have RFC dependency?” > >> >> then update the draft according the answer... > >> >> > >> >> > >> >> > >> >> Pierrick > >> >> > >> >> > >> >> > >> >> De : netext [mailto:netext-bounces@ietf.org] De la part de > >> >> Hidetoshi Yokota Envoyé : jeudi 19 juin 2014 06:41 À : > >> >> netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: > >> >> draft-ietf-netext-pmipv6-flowmob-09.txt] > >> >> > >> >> > >> >> > >> >> > >> >> Hello Carlos, > >> >> > >> >> Thanks for updating the draft. > >> >> I have a couple of questions and comments: > >> >> > >> >> o In Section 3.2.1, which is the shared prefix case, there is no > >> >> message exchange between the LMA and MAG, so there is no flow > >> >> information on the MAG side. It should work in the sense of > >> >> routing, but if, for example, each flow has a specific QoS, the MAG > >> >> should also need to know which flow should go on which QoS path > >> >> especially for upstream traffic towards the LMA. Or, the MAG may > >> >> want to send a trigger for flow mobility to the MN (the exact > >> >> mechanism is out of scope). Some mobility signaling should be there, > >too. > >> >> > >> >> o In Section 3.3, FMI/FMA are revived considering the case where > >> >> UPN is not supported, but they convey very little information. > >> >> There is no special information that cannot be conveyed by the existing > >messages. > >> >> Since RFC7077 is now a proposed standard, I cannot think of a > >> >> situation where the UPN/UPA are not supported, nevertheless > >FMI/FMA > >> >> are supported. It rather seems more natural to mandate the support > >> >> of > >> >> RFC7077 or to mandate FMI/FMA for all flow mobility operations. > >> >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to > >> >> convey different set of parameters in Figure 7. Could you clarify > >> >> it a little bit more please? > >> >> > >> >> o In Section 3.3, just above Figure 7, there is a description: > >> >> "..., and the type of flow mobility operation (add flow)", but does > >> >> RFC6089 define such an operation code? This kind of operation > >> >> should also be defined in the draft. > >> >> > >> >> Regards, > >> >> > >> >> > >> >> > >> >> -- > >> >> Hidetoshi Yokota > >> >> > >> >> KDDI R&D Laboratories, Inc. > >> >> e-mail:yokota@kddilabs.jp > >> >> > >> >> > >> >> > >> >> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote: > >> >> > >> >> > >> >> Hi, > >> >> > >> >> As agreed in London, I've updated the flow mobility draft to include > >> >> also the FMI/FMA signaling option (in addition to the use of Update > >> >> Notifications). The draft also includes a mechanism to allow selecting > >> >> which one of the two signaling mechanisms to use. > >> >> > >> >> In my personal opinion, it'd be much cleaner and simpler to just > >specify > >> >> one signaling mechanism, but this is up to the WG to decide. > >> >> > >> >> Comments, reviews and discussion on this new revision would be > >welcome. > >> >> Hopefully we could get at least a new revision before Toronto. > >> >> > >> >> Thanks, > >> >> > >> >> Carlos > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> netext mailing list > >> >> netext@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netext > >> >> > >> >> > >> >> > >> >> > >> >> > >___________________________________________________________ > >________ > >> >> ______________________________________________________ > >> >> > >> >> Ce message et ses pieces jointes peuvent contenir des informations > >> >> confidentielles ou privilegiees et ne doivent donc pas etre > >> >> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >> >> ce message par erreur, veuillez le signaler a l'expediteur et le detruire > >ainsi que les pieces jointes. Les messages electroniques etant susceptibles > >d'alteration, Orange decline toute responsabilite si ce message a ete altere, > >deforme ou falsifie. Merci. > >> >> > >> >> This message and its attachments may contain confidential or > >> >> privileged information that may be protected by law; they should not be > >distributed, used or copied without authorisation. > >> >> If you have received this email in error, please notify the sender and > >delete this message and its attachments. > >> >> As emails may be altered, Orange is not liable for messages that have > >been modified, changed or falsified. > >> >> Thank you. > >> >> _______________________________________________ > >> >> netext mailing list > >> >> netext@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netext > >> > > >> > > >> > > >> > > >> > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Wed Jul 2 07:00:00 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5791A00F8 for ; Wed, 2 Jul 2014 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdvbtqU_Swng for ; Wed, 2 Jul 2014 06:59:53 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310531A00E8 for ; Wed, 2 Jul 2014 06:59:53 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 16C0188124 for ; Wed, 2 Jul 2014 06:59:53 -0700 (PDT) Received: from 10252102127.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A48F571B0001 for ; Wed, 2 Jul 2014 06:59:52 -0700 (PDT) Message-ID: <53B41059.7080505@innovationslab.net> Date: Wed, 02 Jul 2014 09:59:53 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netext@ietf.org References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1404309115.8479.24.camel@acorde.it.uc3m.es> In-Reply-To: <1404309115.8479.24.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fTRtbIqbQv54vM03r5ifFjfmeRHA4i3np" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/y_rXJbJNvIUZH2J_muiv-u2bu-w Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 13:59:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fTRtbIqbQv54vM03r5ifFjfmeRHA4i3np Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Carlos is correct, these type of acknowledgements are acceptable. They have been in several RFCs published with similar statements. Brian On 7/2/14 9:51 AM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Pierrick, >=20 > This should be fine. I've put similar statements in previous documents > and I haven't had any problems so far. The statement just refers to my > work (e.g., supporting travels, etc). >=20 > Carlos >=20 > On Wed, 2014-07-02 at 13:37 +0000, pierrick.seite@orange.com wrote: >> Hi, >> >> Just a minor comment: >> >> The acknowledgement section states that this work has been partially f= unded by the European Community via a research project. Is such statement= acceptable for an IETF document? Shoudn't we remove this ack? >> >> Pierrick >> >>> -----Message d'origine----- >>> De : Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] >>> Envoy=E9 : mercredi 2 juillet 2014 02:38 >>> =C0 : Hidetoshi Yokota >>> Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; netext@ietf.org >>> Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowm= ob- >>> 09.txt] >>> >>> Hi Hidetoshi, >>> >>> Thanks again for your comments. Please see inline below some >>> comments/replies from my side: >>> >>> On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote: >>>> Hi Carlos, >>>> >>>> I briefly reviewed the updated draft and have a couple of comments. >>>> >>>> o The messages named as FMI/FMA in this document are actually >>> UPN/UPA, >>>> so the description is confusing since it looks as if new messages we= re >>>> defined. I would propose a new flag or notification reason/status co= de >>>> to indicate that UPN/UPA are used for flow mobility. >>> >>> The use of FMI/FMA is simply to make clearer that these UPN/UPA messa= ges >>> are for flow mobility purposes. New notification reason codes are act= ually >>> defined in the document for this purpose. >>> >>>> >>>> o In the previous version, FMI could convey the Flow ID mobility >>>> option, but the latest version can convey only HNPs. This looks like= a >>>> degradation and I'm not sure how both LMA and MAG can share the same= >>>> flow mobility cache. >>> >>> With the UPN/UPA signaling option, the document has never supported >>> conveying the Flow ID mobility option. Ensuring that both the LMA and= MAG >>> keep the same flow mobility cache was out of the scope of the documen= t. If >>> the WG agrees, we could add the possibility of supporting UPN/UPA >>> (FMI/FMA) optionally conveying the Flow ID mobility option. What do o= ther >>> people think? >>> >>>> >>>> o The flow mobility operation such as "add" or "remove" should be ab= le >>>> to specify the targeted flow. To this end, the Flow ID mobility opti= on >>>> in RFC6089 should be used. The flow binding action sub-option define= d >>>> in >>>> RFC7109 can be used for the flow mobility operation. >>> >>> In the current version "add" and "remove" are performed with prefix >>> granularity (as I mentioned in a previous e-mail, this was the consen= sus >>> reached some time ago, but we can revisit this if the WG wants to do = so). >>> >>> Thanks! >>> >>> Carlos >>> >>>> >>>> Please take these points into consideration. >>>> >>>> Regards, >>>> -- >>>> Hidetoshi >>>> >>>> (2014/06/26 7:05), Carlos Jes=FAs Bernardos Cano wrote: >>>>> Hi, >>>>> >>>>> I've just posted -10, now including only one single signaling >>>>> mechanisms, as discussed on the ML. >>>>> >>>>> I think this version is ready for WGLC. >>>>> >>>>> Carlos >>>>> >>>>> On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:= >>>>>> Hi Carlos/All, >>>>>> >>>>>> >>>>>> Can we plan to close this work in the next few days. AFAIK, this >>>>>> FMI/FMA issue is now resolved. If you still doubt the consensus on= >>>>>> this issue, we can wait for 2 days for any comments and post the >>>>>> next rev. >>>>>> >>>>>> >>>>>> I'm hoping we will close this work this week and go LC on Monday >>>>>> (if chairs agree). Waiting for Toronto meeting can delay the work >>>>>> by another few months. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> Sri >>>>>> >>>>>> >>>>>> From: Sri Gundavelli >>>>>> Date: Thursday, June 19, 2014 6:46 AM >>>>>> To: "pierrick.seite@orange.com" , >>>>>> Hidetoshi Yokota , "netext@ietf.org" >>>>>> >>>>>> Subject: Re: [netext] [Fwd: I-D Action: >>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt] >>>>>> >>>>>> >>>>>> >>>>>> Hi Pierrick, >>>>>> >>>>>> >>>>>> After the NETEXT meeting in London, we had some offline discussion= s >>>>>> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)= >>>>>> messaging format for FMI/FMA. So, the Flow Mobility spec may refer= >>>>>> to this message as FMI/FMA, but the underneath messaging format >>>>>> will confirm to RFC-7077 format and will have references to >>>>>> RFC-7077. We are not going to define a new MH message. This closes= >>>>>> the key issue of using two notification approaches in the same >>>>>> spec. AFAIK, no one has any objection to this. If any does, its no= w >>>>>> time to speak up :) >>>>>> >>>>>> >>>>>> Regards >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: "pierrick.seite@orange.com" >>>>>> Date: Thursday, June 19, 2014 1:32 AM >>>>>> To: Hidetoshi Yokota , "netext@ietf.org" >>>>>> >>>>>> Subject: Re: [netext] [Fwd: I-D Action: >>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt] >>>>>> >>>>>> >>>>>> >>>>>> Hi Hidetoshi/all, >>>>>> >>>>>> >>>>>> >>>>>> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in >>>>>> London, we have decided (group consensus) to reintroduce FMI/FMA t= o >>>>>> avoid dependency between RFC. Now, it=92s true that introducing 2 >>>>>> options for message format makes the solution more complex for >>>>>> little added-value (no major differences between messages)=85 So, >>>>>> maybe the question is =93is it good or bad to have RFC dependency?= =94 >>>>>> then update the draft according the answer... >>>>>> >>>>>> >>>>>> >>>>>> Pierrick >>>>>> >>>>>> >>>>>> >>>>>> De : netext [mailto:netext-bounces@ietf.org] De la part de >>>>>> Hidetoshi Yokota Envoy=E9 : jeudi 19 juin 2014 06:41 =C0 : >>>>>> netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: >>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hello Carlos, >>>>>> >>>>>> Thanks for updating the draft. >>>>>> I have a couple of questions and comments: >>>>>> >>>>>> o In Section 3.2.1, which is the shared prefix case, there is no >>>>>> message exchange between the LMA and MAG, so there is no flow >>>>>> information on the MAG side. It should work in the sense of >>>>>> routing, but if, for example, each flow has a specific QoS, the MA= G >>>>>> should also need to know which flow should go on which QoS path >>>>>> especially for upstream traffic towards the LMA. Or, the MAG may >>>>>> want to send a trigger for flow mobility to the MN (the exact >>>>>> mechanism is out of scope). Some mobility signaling should be the= re, >>> too. >>>>>> >>>>>> o In Section 3.3, FMI/FMA are revived considering the case where >>>>>> UPN is not supported, but they convey very little information. >>>>>> There is no special information that cannot be conveyed by the exi= sting >>> messages. >>>>>> Since RFC7077 is now a proposed standard, I cannot think of a >>>>>> situation where the UPN/UPA are not supported, nevertheless >>> FMI/FMA >>>>>> are supported. It rather seems more natural to mandate the support= >>>>>> of >>>>>> RFC7077 or to mandate FMI/FMA for all flow mobility operations. >>>>>> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to= >>>>>> convey different set of parameters in Figure 7. Could you clarify >>>>>> it a little bit more please? >>>>>> >>>>>> o In Section 3.3, just above Figure 7, there is a description: >>>>>> "..., and the type of flow mobility operation (add flow)", but doe= s >>>>>> RFC6089 define such an operation code? This kind of operation >>>>>> should also be defined in the draft. >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Hidetoshi Yokota >>>>>> >>>>>> KDDI R&D Laboratories, Inc. >>>>>> e-mail:yokota@kddilabs.jp >>>>>> >>>>>> >>>>>> >>>>>> (2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> As agreed in London, I've updated the flow mobility draft= to include >>>>>> also the FMI/FMA signaling option (in addition to the use= of Update >>>>>> Notifications). The draft also includes a mechanism to al= low selecting >>>>>> which one of the two signaling mechanisms to use. >>>>>> >>>>>> In my personal opinion, it'd be much cleaner and simpler = to just >>> specify >>>>>> one signaling mechanism, but this is up to the WG to deci= de. >>>>>> >>>>>> Comments, reviews and discussion on this new revision wou= ld be >>> welcome. >>>>>> Hopefully we could get at least a new revision before Tor= onto. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Carlos >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> ___________________________________________________________ >>> ________ >>>>>> ______________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations= >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu= >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le d= etruire >>> ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles >>> d'alteration, Orange decline toute responsabilite si ce message a ete= altere, >>> deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should n= ot be >>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender= and >>> delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that h= ave >>> been modified, changed or falsified. >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and= delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 --fTRtbIqbQv54vM03r5ifFjfmeRHA4i3np Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTtBBZAAoJEBOZRqCi7goq5UMIAKLs7aIiD7MYLrxZpDtT1KFq vToHnUq2CSnnEFEZwmXtodYrRheT0XU6/mp0LzGR7dbT9FyMn+DIm2FeODe8BFiX jrsH+ev7fdraMx63Jh2vgKt4WUlFKPVf3FsnOT661R3izlc8pMVWJ0765dVm3n3+ wQplpnCz6+iCYzOGPZc22CXN2dyNpK2v8ebtaNYHTX9zdld4e7uRO3Y7RG0lDWNv HYw3y2e8TtmBmG3f8taoy9jlMtP7LN5ExlC/HyWf83+id4nogaMl0biezIF1SsmV 8izG0EzW3mtJONTf4O7eGR7FuQ905k7JhmvSa8lOqbqC3yq9YqE2c1ldw5uLy4Y= =dYko -----END PGP SIGNATURE----- --fTRtbIqbQv54vM03r5ifFjfmeRHA4i3np-- From nobody Wed Jul 2 19:48:31 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9051A8BAF; Wed, 2 Jul 2014 19:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ueRTpSlRz75; Wed, 2 Jul 2014 19:48:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4B1A0545; Wed, 2 Jul 2014 19:48:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703024825.30127.83117.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 19:48:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6UpCVzF21I4juRdTyUbYKJ3DUxc Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Jul 2014 02:48:27 -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 : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-05.txt Pages : 11 Date : 2014-07-02 Abstract: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 19:48:33 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613871A0AB2 for ; Wed, 2 Jul 2014 19:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQBasMSMxE_D; Wed, 2 Jul 2014 19:48:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981E1A0AED; Wed, 2 Jul 2014 19:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703024826.30127.45077.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 19:48:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/50MjLLcd2eIyRp7bLp4yUqJ1a54 Subject: [netext] New Version Notification - draft-ietf-netext-pmip-cp-up-separation-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Jul 2014 02:48:28 -0000 A new version (-05) has been submitted for draft-ietf-netext-pmip-cp-up-separation: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-cp-up-separation-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Jul 2 22:41:52 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E643A1A0A8A for ; Wed, 2 Jul 2014 22:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0fUZJ71w-80 for ; Wed, 2 Jul 2014 22:41:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109171A0336 for ; Wed, 2 Jul 2014 22:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2833; q=dns/txt; s=iport; t=1404366110; x=1405575710; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wyGB7Iz8RXbQ38vrTLKUUsRy/d+pYuH0Y7a0aEVpNo8=; b=gB3dfo32W/WGA68fDNPDLY1XGdj0VJJe8zVyzg/R4BIugmiUtLYYMW98 0Y/MPxjwCWNXewJ16kUTISS7zcZ8s0H1YBpKHGt8P5k1V5iboYJ9VmjKn K2EYOo22PnJC75DRaJr5n2449UQU9HV6tPmVTKfeJ+JKOu7tE9ndL6+/U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAHAFDstFOtJV2c/2dsb2JhbABagw1SWqs3DAECAQEBBQFuAZlmAYEIFnWEAwECBDo9FAEINkIbAQYDAgQTCQuILg2cEKseF4VwiEV0hEMFmm2BSJJCg0OCMA X-IronPort-AV: E=Sophos;i="5.01,593,1400025600"; d="scan'208";a="337411591" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2014 05:41:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s635fnJa017616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jul 2014 05:41:49 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 00:41:49 -0500 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: New Version Notification for draft-gundavelli-netext-rfc6757bis-00.txt Thread-Index: AQHPln22QR+RKNl34Umb7pAgGbXZ/JuNtHEA Date: Thu, 3 Jul 2014 05:41:48 +0000 Message-ID: In-Reply-To: <20140703051441.28953.7476.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <57B9C7FE9F94CB439FCCBD12F59588DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/T3xfsHlLpcEoQtxTSIkxunTzCZU Subject: [netext] FW: New Version Notification for draft-gundavelli-netext-rfc6757bis-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Jul 2014 05:41:52 -0000 WG: RFC-6757/Access Network Information option was published in Oct 2012. Over the last 2 year there were many architectural efforts around LTE-WLAN interworking, mobility in Community Wi-Fi architectures, Mobile Private Networks over LTE/SatRAN architectures and few other efforts. In all of these architectures, the ability to notify the access-network parameters from an access gateway to a mobile anchors (over any mobility protocol) proved to be much more valuable than we thought 4 years back when we first drafted the -00 version. Also, we did find few issues and gaps with the current RFC6757 sub-options. One example being, we missed the "Altitude" parameter in the Geo-Location sub-option. "Who cares about that Z-axis/Altitude, we are so down to earth and so Long/Lat is sufficient" .. so we though.. but we soon realized there are skyscrapers all around :) Not that we did not think about that, but we made an error in assuming it won't be needed. There were few other minor nits that few found in the spec. So, we wanted to revise the spec and fix the issues in the spec. This is FYI. We are not sure yet how this draft will be moved, on AD track or some other group, that needs to be decided. Regards Sri On 7/2/14 10:14 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-gundavelli-netext-rfc6757bis-00.txt >has been successfully submitted by Sri Gundavelli and posted to the >IETF repository. > >Name: draft-gundavelli-netext-rfc6757bis >Revision: 00 >Title: Access Network Identifier (ANI) Option for Proxy Mobile IPv6 >Document date: 2014-07-02 >Group: Individual Submission >Pages: 21 >URL: =20 >http://www.ietf.org/internet-drafts/draft-gundavelli-netext-rfc6757bis-00. >txt >Status: =20 >https://datatracker.ietf.org/doc/draft-gundavelli-netext-rfc6757bis/ >Htmlized: =20 >http://tools.ietf.org/html/draft-gundavelli-netext-rfc6757bis-00 > > >Abstract: > The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is > able to provide access-network- and access-operator-specific handling > or policing of the mobile node traffic using information about the > access network to which the mobile node is attached. This > specification defines a mechanism and a related mobility option for > carrying the access network identifier and the access operator > identification information from the mobile access gateway to the > local mobility anchor over Proxy Mobile IPv6. This document > obsoletes RFC 6757. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Thu Jul 3 09:29:37 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BA41A01F7; Thu, 3 Jul 2014 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q409ddd8vPxo; Thu, 3 Jul 2014 09:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5C1B27F9; Thu, 3 Jul 2014 09:29:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703162926.1015.49911.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 09:29:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/jeHclj84rI09AMiV9a0yBLoBVvo Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-qos-wifi-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Jul 2014 16:29:32 -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 : Mapping PMIPv6 QoS Procedures with WLAN QoS procedures Authors : John Kaippallimalil Rajesh Pazhyannur Parviz Yegani Filename : draft-ietf-netext-pmip-qos-wifi-01.txt Pages : 16 Date : 2014-07-03 Abstract: This document provides guidelines for achieving end to end QoS in a PMIPv6 domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a MAG and LMA in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11-2012, WMM-AC describes methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end to end QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 6 22:23:19 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9A51A0AF9 for ; Sun, 6 Jul 2014 22:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJaEByjKXjz6 for ; Sun, 6 Jul 2014 22:23:15 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 391531A0AF7 for ; Sun, 6 Jul 2014 22:23:14 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yanzhiwei@cnnic.cn Received: from unknown127.0.0.1 (HELO joyyan) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 07 Jul 2014 13:23:08 +0800 Date: Mon, 7 Jul 2014 13:23:09 +0800 From: "Zhiwei Yan" To: "netext" Message-ID: <201407071323083197199@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon188776547713_=====" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/r1KqR5sfPPE81OCjt446Aywe77k Cc: xl , Jong-Hyouk Lee Subject: [netext] New submission notification-draft-yan-netext-hnprenum-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 05:23:16 -0000 This is a multi-part message in MIME format. --=====003_Dragon188776547713_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, We submitted a draft about the HNP renumbering support in PMIPv6. http://tools.ietf.org/id/draft-yan-netext-hnprenum-01.txt As stated in this draft, the HNP renumbering was mentioned in PMIPv6 specification (RFC 5213), but the solution was not given. We adopt the RFC 7077 to slve this issue and then this drfat is an extension of RFC 7077 or as a similar operation of RFC 7077. Any comments and feedbacks are all welcome. Thank all of you. Regards, Zhiwei Yan 2014-07-07 --=====003_Dragon188776547713_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Hi,
We submitted a draft about the HNP renumbering support in PMIPv6.
http://tools.ietf.org/id/draft-yan-netext-hnprenum-01.txt
As stated in this draft, the HNP renumbering was mentioned in PMIPv6 specification (RFC 5213), but the solution was not given.
We adopt the RFC 7077 to slve this issue and then this drfat is an extension of RFC 7077 or as a similar operation of RFC 7077.
Any comments and feedbacks are all welcome.
Thank all of you.
Regards,
Zhiwei Yan
 
2014-07-07
 
 --=====003_Dragon188776547713_=====-- From nobody Tue Jul 8 09:46:25 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCF61B2BE0 for ; Tue, 8 Jul 2014 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deEc-1uJh_NT for ; Tue, 8 Jul 2014 09:46:18 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DD31B2BDE for ; Tue, 8 Jul 2014 09:46:06 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id hr17so4196432lab.18 for ; Tue, 08 Jul 2014 09:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=/92pxr2r6kvbd9bssF4nicSmmJJtV8Bj8pw3Cr+AxCg=; b=wv+LesZPUZhlZ/oYiBGf8aYkMRXATiNR7YxxONd37XK3veaEJlqLECK8rDjcPFFGkV AKTnBm+Tjmw9ginVf47EnjHwS0lsoZ3c9RaHvQ2+eEzxs7+vmpnJexLN0eS4lw0tVp+a p0RMAxYN7zncXlGiVXqG6P06cznCPnLoaGkXeFlwS25e/rdCjEpmr0H7pwiIrfZojiyS kTgwOVTt2035UUCFAW0I+pwRoOgFQc81Ki/iqdfxVN+41mUDwBu3hX8JXC5+v7OGUQKh 5Socqui9WuWMr5udtUbLXGZkotKg0AnXwaTVQ2ZDomlCWeXP0AZDNNjPC6IJ1Q3aTYlw 6ydA== MIME-Version: 1.0 X-Received: by 10.112.160.105 with SMTP id xj9mr26889878lbb.2.1404837964672; Tue, 08 Jul 2014 09:46:04 -0700 (PDT) Received: by 10.114.27.106 with HTTP; Tue, 8 Jul 2014 09:46:04 -0700 (PDT) Date: Tue, 8 Jul 2014 11:46:04 -0500 Message-ID: From: Behcet Sarikaya To: "netext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ipb-MdrraeKI-PfzDZNCukM4hq8 Subject: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Tue, 08 Jul 2014 16:46:20 -0000 Hi all, I have been commenting on draft-ietf-netext-pmipv6-flowmob for years. At some point the chairs set up the issue tracker and asked us to use it. I did put many comments on the issue tracker. In the meantime I have been involved in HA based flow binding entitled Flow Bindings Initiated by Home Agents for Mobile IPv6 work was published as RFC 7109. I have noticed that the editor has consistently ignored all these efforts. Now that we came to a point of final decision, I decided to put all my comments in writing. I made an xml file from Rev. 10 (BTW we had asked the editor to submit xml file for the draft but he did not listen as usual) and produced a complete revision which I called Rev. 11 and sent it in an email to the chairs. Here are the main points in this draft: This version is 5+ pages shorter than Rev. 10. This version removes the use cases section and replaces it with an overview of flow mobility actions describing the flow mobility protocol explicitly. This version removes FMI/FMA section. This version adds Local Mobility Anchor Considerations, Mobile Access Gateway considerations and much needed IPv4 flow mobility support sections. This section uses UPN/UPA messages to carry Flow Identification Mobility option and Flow Binding Action Sub-Option and Target Care-of Address Sub-Option defined in RFC7109. I propose this version to be used for further work and let Carlos further maintain the document in just a few steps that are left. Regards, Behcet From nobody Tue Jul 8 15:46:30 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDBA1A016C for ; Tue, 8 Jul 2014 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNZO9l-48LOb for ; Tue, 8 Jul 2014 15:46:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12701A015B for ; Tue, 8 Jul 2014 15:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1404859593; x=1406069193; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=YXwYHMMuc0LnnXbGEwYH5MinDELbtOpFyD2X3q5LmzM=; b=jFjv9BmGdSvDwIiE5teG1Xi4idGRxm8sFYUL7qTWnwEq6rE8xzTD62A6 1Hv4L7g4a6H/nSMsg2lI08cfAaEstZXhvXKnTMMHXzqkM/fcAgYsVjdBZ gkOIy/557iIzqutgTsQZt1Kd983EvlydBDvgomT4hMVf7acgTvO1pmZHq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIlzvFOtJA2H/2dsb2JhbABagw5SWr8mCIZuUwGBEhZ1hAUBBAEBATc0HQEINjEGCyUCBAESiC4DEQ3BAA2FXhMEjRiBSBEBV4RDBZh2ggCNeIYUg0OBdzk X-IronPort-AV: E=Sophos;i="5.01,628,1400025600"; d="scan'208";a="338633469" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2014 22:46:29 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s68MkNrt009583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 22:46:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 17:46:23 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" , "netext@ietf.org" Thread-Topic: [netext] Flow Mobility Draft Thread-Index: AQHPmv5wkFhO8op8cEugUOmfPd8FAQ== Date: Tue, 8 Jul 2014 22:46:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <813B82D7EDE9F341B3CB9B8E076BA9FD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6iB6HsH7VB8SuNLdQBXOztmM2Go Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Jul 2014 22:46:28 -0000 Behcet, Please post your proposed changes to the ML. There is an editor for the document, so its more appropriate you let the WG decide as what goes into the document. Document editor just follows the WG consensus. You know this all very well .. Regards Sri =20 On 7/8/14 9:46 AM, "Behcet Sarikaya" wrote: >Hi all, > >I have been commenting on draft-ietf-netext-pmipv6-flowmob for years. >At some point the chairs set up the issue tracker and asked us to use >it. I did put many comments on the issue tracker. > >In the meantime I have been involved in HA based flow binding entitled >Flow Bindings Initiated by Home Agents for Mobile IPv6 >work was published as RFC 7109. > >I have noticed that the editor has consistently ignored all these efforts. > >Now that we came to a point of final decision, I decided to put all my >comments in writing. I made an xml file from Rev. 10 >(BTW we had asked the editor to submit xml file for the draft but he >did not listen as usual) and produced a complete revision which I >called Rev. 11 and sent it in an email to the chairs. > >Here are the main points in this draft: >This version is 5+ pages shorter than Rev. 10. >This version removes the use cases section and replaces it with an >overview of flow mobility actions describing the flow mobility >protocol explicitly. >This version removes FMI/FMA section. >This version adds Local Mobility Anchor Considerations, Mobile Access >Gateway considerations >and much needed IPv4 flow mobility support sections. >This section uses UPN/UPA messages to carry Flow Identification >Mobility option and Flow Binding Action Sub-Option > and Target Care-of Address Sub-Option defined in RFC7109. > >I propose this version to be used for further work and let Carlos >further maintain the document in just a few steps that are left. > >Regards, > >Behcet > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Fri Jul 11 10:47:31 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48E1B2BF3 for ; Fri, 11 Jul 2014 10:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS89qlcpATQn for ; Fri, 11 Jul 2014 10:47:26 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADB91B2987 for ; Fri, 11 Jul 2014 10:47:26 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so69378wib.12 for ; Fri, 11 Jul 2014 10:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CYZrKDpKDJiMh6/TdJaHyWFpZhLrvGHdGPjqN47/LRA=; b=llAWwCmU4bQqEBUn4+MjTZ4U7RMnB19LnOSwZm1gX/Vaz+RRz8oq1y3/FJiRtjIIVG YlrsqnFG4dawSd/NYSEDRIqZyi8fjnCFXzOWsIn+fVCVUZP9PwIgG7verKkC+M0h8/+V Qoib0JD2fkQXh7ITXqTj7JfzrhzgnSq+pKeXeRoLdaIaieapQK9TjaTOxgEy5hBQ2lCE 9j614rVG4/Esr3FKEqyKFP9Sul0HFLHF+ctmgHMaX6ZDFPhFIrIuYkdRCzi5k5Yftcf+ 1o5mgclTaHDcOMAPhGlv8/FCcvcMZHNf5y6p57yzjHntn7m8f92ZamDMCHzu7R6JzC20 x39Q== MIME-Version: 1.0 X-Received: by 10.194.243.70 with SMTP id ww6mr519982wjc.76.1405100844577; Fri, 11 Jul 2014 10:47:24 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Fri, 11 Jul 2014 10:47:24 -0700 (PDT) Date: Fri, 11 Jul 2014 10:47:24 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e0141aaa0b6fa0904fdee8879 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Lq6px8r9wg5hif7g0wc5BcglQw0 Subject: [netext] IETF 90 Meeting X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Jul 2014 17:47:28 -0000 --089e0141aaa0b6fa0904fdee8879 Content-Type: text/plain; charset=UTF-8 Hello folks, we are scheduled to meet as follows: THURSDAY, July 24, 2014 1300-1500 Afternoon Session ISalon B INT netext Network-Based Mobility Extensions please let us know if you would like to present at the meeting. Provide a title, a pointer to the document and the time you would like. Thanks. Chairs --089e0141aaa0b6fa0904fdee8879 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello folks,

we are sche= duled to meet as follows:

THURSDAY, July 2=
4, 2014
1300-1=
500  Afternoon Session I
Salon B   INT   netext=C2=A0Network-Based Mobility Extensions
please let us know if you would like to present at the meeting. = Provide a title, a pointer to the document and the time you would like.

Thanks.

Chairs

--089e0141aaa0b6fa0904fdee8879-- From nobody Fri Jul 11 15:36:41 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763751B29F4 for ; Fri, 11 Jul 2014 15:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.739 X-Spam-Level: *** X-Spam-Status: No, score=3.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT8RlGwvRbsO for ; Fri, 11 Jul 2014 15:36:38 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 966091B29F2 for ; Fri, 11 Jul 2014 15:36:36 -0700 (PDT) Received: from 106.37.18.80 by mail.cnnic.cn with HTTP; Sat, 12 Jul 2014 06:36:32 +0800 X-WebMAIL-MUA: [106.37.18.80] X-eYou-Client: 106.37.18.80 From: "=?gb2312?B?0dPWvs6w?=" To: rajeev.koodli@gmail.com, netext@ietf.org Date: Sat, 12 Jul 2014 06:36:32 +0800 Message-ID: X-Priority: 3 X-Mailer: eYou MUA Subsystem 4.1.7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_208554_1405118192_6783.html" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/8Pt2r8p4Lz_oME-KHthRe--8zk4 Subject: Re: [netext] IETF 90 Meeting X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?gb2312?B?0dPWvs6w?= 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: Fri, 11 Jul 2014 22:36:39 -0000 ------=_208554_1405118192_6783.html Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBLb29kbGksDQpQbGVhc2UgYWxsb2NhdGUgMTAgbWludXRlcyBmb3IgdGhlIGludHJv ZHVjdGlvbiBvZiB0aGUgZm9sbG93aW5nIGRyYWZ0Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQteWFuLW5ldGV4dC1obnByZW51bS0wMS50eHQNCihITlAgcmVudW1iZXJp bmcgc3VwcG9ydCBpbiBQTUlQdjYpDQpUaGFuayB5b3Ugc28gbXVjaC4NClpoaXdlaQ0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLSDUrcq808q8/iAtLS0tLS0tLS0tLS0tLS0tLS0NCj5Gcm9t OiBSYWplZXYgS29vZGxpIDxyYWplZXYua29vZGxpQGdtYWlsLmNvbT4NCj5SZXBseS1Ubzog DQo+VG86ICJuZXRleHRAaWV0Zi5vcmciIDxuZXRleHRAaWV0Zi5vcmc+DQo+U3ViamVjdDog W25ldGV4dF0gSUVURiA5MCBNZWV0aW5nDQo+RGF0ZTogRnJpLCAxMSBKdWwgMjAxNCAxMDo0 NzoyNCAtMDcwMA0KPg0KSGVsbG8gZm9sa3MsDQp3ZSBhcmUgc2NoZWR1bGVkIHRvIG1lZXQg YXMgZm9sbG93czoNClRIVVJTREFZDQosIEp1bHkgMjQsIDIwMTQNCjEzMDAtMTUwMCAgQWZ0 ZXJub29uIFNlc3Npb24gSQ0KU2Fsb24gQg0KSU5UDQpuZXRleHQNCk5ldHdvcmstQmFzZWQg TW9iaWxpdHkgRXh0ZW5zaW9ucw0KcGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSB3b3VsZCBs aWtlIHRvIHByZXNlbnQgYXQgdGhlIG1lZXRpbmcuIFByb3ZpZGUgYSB0aXRsZSwgYSBwb2lu dGVyIHRvIHRoZSBkb2N1bWVudCBhbmQgdGhlIHRpbWUgeW91IHdvdWxkIGxpa2UuDQpUaGFu a3MuDQpDaGFpcnMNCg0KDQoK ------=_208554_1405118192_6783.html Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGJyPkRlYXIgS29vZGxpLDxkaXY+UGxlYXNlIGFsbG9jYXRlIDEwIG1pbnV0ZXMgZm9yIHRo ZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGZvbGxvd2luZyBkcmFmdDo8L2Rpdj48ZGl2Pjxicj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQteWFuLW5ldGV4dC1obnByZW51bS0wMS50 eHQ8L2Rpdj48ZGl2PihITlAgcmVudW1iZXJpbmcgc3VwcG9ydCBpbiBQTUlQdjYpPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3Ugc28gbXVjaC48L2Rpdj48ZGl2PlpoaXdl aTxicj48YnI+PGJyPi0tLS0tLS0tLS0tLS0tLS0tLSDUrcq808q8/iAtLS0tLS0tLS0tLS0t LS0tLS08YnI+Jmd0O0Zyb206Jm5ic3A7UmFqZWV2Jm5ic3A7S29vZGxpJm5ic3A7Jmx0O3Jh amVldi5rb29kbGlAZ21haWwuY29tJmd0Ozxicj4mZ3Q7UmVwbHktVG86Jm5ic3A7PGJyPiZn dDtUbzombmJzcDsibmV0ZXh0QGlldGYub3JnIiZuYnNwOyZsdDtuZXRleHRAaWV0Zi5vcmcm Z3Q7PGJyPiZndDtTdWJqZWN0OiZuYnNwO1tuZXRleHRdJm5ic3A7SUVURiZuYnNwOzkwJm5i c3A7TWVldGluZzxicj4mZ3Q7RGF0ZTombmJzcDtGcmksJm5ic3A7MTEmbmJzcDtKdWwmbmJz cDsyMDE0Jm5ic3A7MTA6NDc6MjQmbmJzcDstMDcwMDxicj4mZ3Q7PGJyPjxicj48ZGl2IGRp cj0ibHRyIj48YnI+PGRpdj5IZWxsbyBmb2xrcyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PndlIGFyZSBzY2hlZHVsZWQgdG8gbWVldCBhcyBmb2xsb3dzOjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+PHByZSBjbGFzcz0iIiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNp emU6MTVweCI+PGEgbmFtZT0iVEhVUlNEQVkiPlRIVVJTREFZPC9hPiwgSnVseSAyNCwgMjAx NDwvcHJlPg0KPC9kaXY+PGRpdj48cHJlIGNsYXNzPSIiIHN0eWxlPSJjb2xvcjpyZ2IoMCww LDApO2ZvbnQtc2l6ZToxNXB4Ij4xMzAwLTE1MDAgIEFmdGVybm9vbiBTZXNzaW9uIEkNCjxz cGFuIGlkPSI5MC10aHUtMTMwMC1uZXRleHQiIHN0eWxlPSJwYWRkaW5nOjJweCAwcHggMHB4 Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS85MC92ZW51ZS8/cm9v bT1zYWxvbi1iIiB0aXRsZT0iUm9vbSBtYXAiIHN0eWxlPSJjb2xvcjpyZ2IoNjgsMCwxMzYp O2JvcmRlci1ib3R0b20td2lkdGg6MHB4Ij5TYWxvbiBCPC9hPiAgIElOVCAgIDxhIG5hbWU9 Im5ldGV4dCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRleHQvIiBzdHls ZT0iY29sb3I6cmdiKDY4LDAsMTM2KTtib3JkZXItYm90dG9tLXdpZHRoOjBweCI+bmV0ZXh0 PC9hPjxzcGFuIHRpdGxlPSJOZXR3b3JrLUJhc2VkIE1vYmlsaXR5IEV4dGVuc2lvbnMiPk5l dHdvcmstQmFzZWQgTW9iaWxpdHkgRXh0ZW5zaW9uczwvc3Bhbj4gICA8L3NwYW4+PC9wcmU+ DQo8L2Rpdj48ZGl2PnBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3Ugd291bGQgbGlrZSB0byBw cmVzZW50IGF0IHRoZSBtZWV0aW5nLiBQcm92aWRlIGEgdGl0bGUsIGEgcG9pbnRlciB0byB0 aGUgZG9jdW1lbnQgYW5kIHRoZSB0aW1lIHlvdSB3b3VsZCBsaWtlLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhhbmtzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q2hhaXJzPC9k aXY+PGRpdj4NCjxicj48L2Rpdj48L2Rpdj4NCg0KPC9kaXY+ ------=_208554_1405118192_6783.html-- From nobody Mon Jul 14 09:21:05 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7566E1A0AEB for ; Mon, 14 Jul 2014 09:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBX11U8lNF7D for ; Mon, 14 Jul 2014 09:21:02 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6DA1A0AE0 for ; Mon, 14 Jul 2014 09:21:02 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so2861183wib.17 for ; Mon, 14 Jul 2014 09:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oE9gHbug2qb4vRyszh+TiPGXfpNB27MI4iE7LmiD+fA=; b=PtiKNfpUENHwgfeyO6TJL9aILYPdH1AXiBnGovIQMuyKTFilK/dqD+3hZ0aC74pStb f5P5oHgcC1JhVw5DeleuAwiHGqzgn0BuypISg2FSudQtAonFxMyLjKg0x1bV6t9RxCYO 92aVx1JIavWaJGV+IQUU4gznfwnMDuGe+xRWf7R6vUglsnBQdKsutx2CC0a+Wzvu0Q0M K7vpkvmS6EbN7K8rNUgQTE7ZNs//cSee+pRnbHCmKnxzHB4C096TJ5ys3upiFO1YaEbI 8F0ouQi1RUgspAdEkOiHFLSbgY+TFp5rCW75QD3gzCOwMJBLC8kuQoqOeD1B4W/ySjbZ FkQA== MIME-Version: 1.0 X-Received: by 10.180.210.239 with SMTP id mx15mr25348593wic.65.1405354860876; Mon, 14 Jul 2014 09:21:00 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Mon, 14 Jul 2014 09:21:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Jul 2014 09:21:00 -0700 Message-ID: From: Rajeev Koodli To: =?UTF-8?B?5bu25b+X5Lyf?= Content-Type: multipart/alternative; boundary=001a11c32db2441c9e04fe29ad1e Archived-At: http://mailarchive.ietf.org/arch/msg/netext/9Vn5gjRgkxcc91IjQyibMTLFuwU Cc: "netext@ietf.org" Subject: Re: [netext] IETF 90 Meeting X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 16:21:03 -0000 --001a11c32db2441c9e04fe29ad1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Sorry, I was not clear in my message. The NetExt WG is close to completing its work items and close down. So, we are only seeking slots for the remaining work items, for a quick status update and topics that need face-face discussions. Thanks. -Rajeev On Fri, Jul 11, 2014 at 3:36 PM, =E5=BB=B6=E5=BF=97=E4=BC=9F wrote: > > Dear Koodli, > Please allocate 10 minutes for the introduction of the following draft: > > http://tools.ietf.org/id/draft-yan-netext-hnprenum-01.txt > (HNP renumbering support in PMIPv6) > > Thank you so much. > Zhiwei > > > ------------------ =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 -----------------= - > >From: Rajeev Koodli > >Reply-To: > >To: "netext@ietf.org" > >Subject: [netext] IETF 90 Meeting > >Date: Fri, 11 Jul 2014 10:47:24 -0700 > > > > > Hello folks, > > we are scheduled to meet as follows: > > THURSDAY, July 24, 2014 > > 1300-1500 Afternoon Session ISalon B INT netext Net= work-Based Mobility Extensions > > please let us know if you would like to present at the meeting. Provide a > title, a pointer to the document and the time you would like. > > Thanks. > > Chairs > > --001a11c32db2441c9e04fe29ad1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Sorry, I was not cle= ar in my message. The NetExt WG is close to completing its work items and c= lose down.
So, we are only seeking slots for the remaining work i= tems, for a quick status update and topics that need face-face discussions.=

Thanks.

-Rajeev

=


O= n Fri, Jul 11, 2014 at 3:36 PM, =E5=BB=B6=E5=BF=97=E4=BC=9F <yanzhiwei@cn= nic.cn> wrote:

Dear Koodli,
Please allocate 10 minu= tes for the introduction of the following draft:
(HNP renumbering support in PMIPv6)

Thank you= so much.
Zhiwei


------------------ =E5=8E=9F=E5=A7=8B= =E9=82=AE=E4=BB=B6 ------------------
>From:=C2=A0Rajeev=C2=A0Koodli= =C2=A0<raje= ev.koodli@gmail.com>
>Reply-To:=C2=A0
>To:=C2=A0"netext@ietf.org"=C2=A0<netext@ietf.org>
>Subject:=C2= =A0[netext]=C2=A0IETF=C2=A090=C2=A0Meeting
>Date:=C2=A0Fri,=C2=A011=C2=A0Jul=C2=A02014=C2=A010:47:24=C2=A0-0700
= >


Hello folks,

we are scheduled to meet as follows:

<= div>
THURSDAY, July 24, 2014
1300-1500  =
Afternoon Session I
Salon B   INT   netextNetwork-Based Mobility =
Extensions




--001a11c32db2441c9e04fe29ad1e-- From nobody Mon Jul 14 09:24:26 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256E1A0AC4 for ; Mon, 14 Jul 2014 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX0GIutRC4DB for ; Mon, 14 Jul 2014 09:24:21 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7F71A0ABD for ; Mon, 14 Jul 2014 09:24:21 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so4398725wgg.7 for ; Mon, 14 Jul 2014 09:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iAeHkPAyrizhjaBQLRjRP/CDTfG3dWgMW6YO5gHQ1tI=; b=IP63iL4rZH7oTN8Y8424Flud7pcTZwdmsBUcKznobJ5STKC0UgVWopDHtVdgEkYxlP JWTv0bdMkAoPeb7D33L79mnqSMM5q3FYyoOWevhas/ES3RYHHeqhf6HUV/LR9nd/gyKE oiEjGGum7C4HjapFoJeH6xGljiOgxvSoGDtlLNeJwjGh1H9xJ52FaNclw18+G3HldaV1 5TQzIiWbZvWuJyJ07yxYBHxv8ZS9OzUjTcN775Qo+XlCBOXOY5khJ9+SBfjY0WNGvzUL eMyvucNYvdYwNdcB5OUL8qpljqu9o0DtdKrNHsFLoic6qQZQSdkoWsb9RWDLgq6O8Ha2 ZKOA== MIME-Version: 1.0 X-Received: by 10.194.88.199 with SMTP id bi7mr20821433wjb.79.1405355059777; Mon, 14 Jul 2014 09:24:19 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Mon, 14 Jul 2014 09:24:19 -0700 (PDT) In-Reply-To: <1404261479.5086.15.camel@acorde.it.uc3m.es> References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> Date: Mon, 14 Jul 2014 09:24:19 -0700 Message-ID: From: Rajeev Koodli To: "Carlos J. Bernardos" Content-Type: multipart/alternative; boundary=047d7bf10b121f1c0204fe29b930 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/94n_lK9reaOezaG_yu_UOr19uR4 Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 16:24:25 -0000 --047d7bf10b121f1c0204fe29b930 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Yokota-san, sorry for the delay in my response. I would like to clarify something: The FMI/FMA messages make use of the UPN/UPA format with specific New Reason/Status Codes. In other words, the _only_ requirement is to support the UPN/UPA messages for these specific FMI/FMA purposes, and that there is no requirement to support RFC 7077 in its entirety. So, I suggest adding the following text, perhaps in the Message Format section. "This specification requires implementation of UPN [RFC7077] and UPA [RFC7077] messages with the specific Notification Reason and Status Code as defined by this document. This document does not require implementation of any other aspects of RFC 7077." I am supportive of adding the Flow ID mobility option. Regards, -Rajeev On Tue, Jul 1, 2014 at 5:37 PM, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Hidetoshi, > > Thanks again for your comments. Please see inline below some > comments/replies from my side: > > On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote: > > Hi Carlos, > > > > I briefly reviewed the updated draft and have a couple of comments. > > > > o The messages named as FMI/FMA in this document are actually UPN/UPA, > > so the description is confusing since it looks as if new messages were > > defined. I would propose a new flag or notification reason/status code > > to indicate that UPN/UPA are used for flow mobility. > > The use of FMI/FMA is simply to make clearer that these UPN/UPA messages > are for flow mobility purposes. New notification reason codes are > actually defined in the document for this purpose. > > > > > o In the previous version, FMI could convey the Flow ID mobility option= , > > but the latest version can convey only HNPs. This looks like a > > degradation and I'm not sure how both LMA and MAG can share the same > > flow mobility cache. > > With the UPN/UPA signaling option, the document has never supported > conveying the Flow ID mobility option. Ensuring that both the LMA and > MAG keep the same flow mobility cache was out of the scope of the > document. If the WG agrees, we could add the possibility of supporting > UPN/UPA (FMI/FMA) optionally conveying the Flow ID mobility option. What > do other people think? > > > > > o The flow mobility operation such as "add" or "remove" should be able > > to specify the targeted flow. To this end, the Flow ID mobility option > > in RFC6089 should be used. The flow binding action sub-option defined i= n > > RFC7109 can be used for the flow mobility operation. > > In the current version "add" and "remove" are performed with prefix > granularity (as I mentioned in a previous e-mail, this was the consensus > reached some time ago, but we can revisit this if the WG wants to do > so). > > Thanks! > > Carlos > > > > > Please take these points into consideration. > > > > Regards, > > -- > > Hidetoshi > > > > (2014/06/26 7:05), Carlos Jes=C3=BAs Bernardos Cano wrote: > > > Hi, > > > > > > I've just posted -10, now including only one single signaling > > > mechanisms, as discussed on the ML. > > > > > > I think this version is ready for WGLC. > > > > > > Carlos > > > > > > On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote: > > >> Hi Carlos/All, > > >> > > >> > > >> Can we plan to close this work in the next few days. AFAIK, this > > >> FMI/FMA issue is now resolved. If you still doubt the consensus on > > >> this issue, we can wait for 2 days for any comments and post the nex= t > > >> rev. > > >> > > >> > > >> I'm hoping we will close this work this week and go LC on Monday (if > > >> chairs agree). Waiting for Toronto meeting can delay the work by > > >> another few months. > > >> > > >> > > >> > > >> > > >> Regards > > >> Sri > > >> > > >> > > >> From: Sri Gundavelli > > >> Date: Thursday, June 19, 2014 6:46 AM > > >> To: "pierrick.seite@orange.com" , > Hidetoshi > > >> Yokota , "netext@ietf.org" > > >> Subject: Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> Hi Pierrick, > > >> > > >> > > >> After the NETEXT meeting in London, we had some offline discussions > > >> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN) > > >> messaging format for FMI/FMA. So, the Flow Mobility spec may refer t= o > > >> this message as FMI/FMA, but the underneath messaging format will > > >> confirm to RFC-7077 format and will have references to RFC-7077. We > > >> are not going to define a new MH message. This closes the key issue = of > > >> using two notification approaches in the same spec. AFAIK, no one ha= s > > >> any objection to this. If any does, its now time to speak up :) > > >> > > >> > > >> Regards > > >> Sri > > >> > > >> > > >> > > >> > > >> From: "pierrick.seite@orange.com" > > >> Date: Thursday, June 19, 2014 1:32 AM > > >> To: Hidetoshi Yokota , "netext@ietf.org" > > >> > > >> Subject: Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> Hi Hidetoshi/all, > > >> > > >> > > >> > > >> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in > > >> London, we have decided (group consensus) to reintroduce FMI/FMA to > > >> avoid dependency between RFC. Now, it=E2=80=99s true that introducin= g 2 > > >> options for message format makes the solution more complex for littl= e > > >> added-value (no major differences between messages)=E2=80=A6 So, may= be the > > >> question is =E2=80=9Cis it good or bad to have RFC dependency?=E2=80= =9D then update > > >> the draft according the answer... > > >> > > >> > > >> > > >> Pierrick > > >> > > >> > > >> > > >> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi > > >> Yokota > > >> Envoy=C3=A9 : jeudi 19 juin 2014 06:41 > > >> =C3=80 : netext@ietf.org > > >> Objet : Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> > > >> Hello Carlos, > > >> > > >> Thanks for updating the draft. > > >> I have a couple of questions and comments: > > >> > > >> o In Section 3.2.1, which is the shared prefix case, there is no > > >> message exchange between the LMA and MAG, so there is no flow > > >> information on the MAG side. It should work in the sense of routing, > > >> but if, for example, each flow has a specific QoS, the MAG should al= so > > >> need to know which flow should go on which QoS path especially for > > >> upstream traffic towards the LMA. Or, the MAG may want to send a > > >> trigger for flow mobility to the MN (the exact mechanism is out of > > >> scope). Some mobility signaling should be there, too. > > >> > > >> o In Section 3.3, FMI/FMA are revived considering the case where UPN > > >> is not supported, but they convey very little information. There is = no > > >> special information that cannot be conveyed by the existing messages= . > > >> Since RFC7077 is now a proposed standard, I cannot think of a > > >> situation where the UPN/UPA are not supported, nevertheless FMI/FMA > > >> are supported. It rather seems more natural to mandate the support o= f > > >> RFC7077 or to mandate FMI/FMA for all flow mobility operations. > > >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to > > >> convey different set of parameters in Figure 7. Could you clarify it= a > > >> little bit more please? > > >> > > >> o In Section 3.3, just above Figure 7, there is a description: "..., > > >> and the type of flow mobility operation (add flow)", but does RFC608= 9 > > >> define such an operation code? This kind of operation should also be > > >> defined in the draft. > > >> > > >> Regards, > > >> > > >> > > >> > > >> -- > > >> Hidetoshi Yokota > > >> > > >> KDDI R&D Laboratories, Inc. > > >> e-mail:yokota@kddilabs.jp > > >> > > >> > > >> > > >> (2014/06/14 2:16), Carlos Jes=C3=BAs Bernardos Cano wrote: > > >> > > >> > > >> Hi, > > >> > > >> As agreed in London, I've updated the flow mobility draft t= o > include > > >> also the FMI/FMA signaling option (in addition to the use o= f > Update > > >> Notifications). The draft also includes a mechanism to allo= w > selecting > > >> which one of the two signaling mechanisms to use. > > >> > > >> In my personal opinion, it'd be much cleaner and simpler to > just specify > > >> one signaling mechanism, but this is up to the WG to decide= . > > >> > > >> Comments, reviews and discussion on this new revision would > be welcome. > > >> Hopefully we could get at least a new revision before > Toronto. > > >> > > >> Thanks, > > >> > > >> Carlos > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > >> > > >> > > >> > > >> > > >> > _________________________________________________________________________= ________________________________________________ > > >> > > >> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > >> Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > >> > > >> This message and its attachments may contain confidential or > privileged information that may be protected by law; > > >> they should not be distributed, used or copied without authorisation= . > > >> If you have received this email in error, please notify the sender > and delete this message and its attachments. > > >> As emails may be altered, Orange is not liable for messages that hav= e > been modified, changed or falsified. > > >> Thank you. > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --047d7bf10b121f1c0204fe29b930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Carlos, Yokota-san,

s= orry for the delay in my response.

I would like to= clarify something: The FMI/FMA messages make use of the UPN/UPA format wit= h specific New Reason/Status Codes. In other words, the _only_ requirement = is to support the UPN/UPA messages for these specific FMI/FMA purposes, and= that there is no requirement to support RFC 7077 in its entirety. So, I su= ggest adding the following text, perhaps in the Message Format section.

"= This specification requires implementation of UPN [RFC7077] and = UPA [RFC7077] messages with the specific Notification Reason and Status Cod= e as defined by this document. This document does not require implementatio= n of any other aspects of RFC 7077."

I am supportive of adding the Flow ID mobility option.<= /div>

Regards,

-Rajeev



On Tue, Jul 1, 2014 at 5:37 PM, Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.u= c3m.es> wrote:
Hi Hidetoshi,

Thanks again for your comments. Please see inline below some
comments/replies from my side:

On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote:
> Hi Carlos,
>
> I briefly reviewed the updated draft and have a couple of comments. >
> o The messages named as FMI/FMA in this document are actually UPN/UPA,=
> so the description is confusing since it looks as if new messages were=
> defined. I would propose a new flag or notification reason/status code=
> to indicate that UPN/UPA are used for flow mobility.

The use of FMI/FMA is simply to make clearer that these UPN/UPA messa= ges
are for flow mobility purposes. New notification reason codes are
actually defined in the document for this purpose.

>
> o In the previous version, FMI could convey the Flow ID mobility optio= n,
> but the latest version can convey only HNPs. This looks like a
> degradation and I'm not sure how both LMA and MAG can share the sa= me
> flow mobility cache.

With the UPN/UPA signaling option, the document has never supported conveying the Flow ID mobility option. Ensuring that both the LMA and
MAG keep the same flow mobility cache was out of the scope of the
document. If the WG agrees, we could add the possibility of supporting
UPN/UPA (FMI/FMA) optionally conveying the Flow ID mobility option. What do other people think?

>
> o The flow mobility operation such as "add" or "remove&= quot; should be able
> to specify the targeted flow. To this end, the Flow ID mobility option=
> in RFC6089 should be used. The flow binding action sub-option defined = in
> RFC7109 can be used for the flow mobility operation.

In the current version "add" and "remove" are per= formed with prefix
granularity (as I mentioned in a previous e-mail, this was the consensus reached some time ago, but we can revisit this if the WG wants to do
so).

Thanks!

Carlos

>
> Please take these points into consideration.
>
> Regards,
> --
> Hidetoshi
>
> (2014/06/26 7:05), Carlos Jes=C3=BAs Bernardos Cano wrote:
> > Hi,
> >
> > I've just posted -10, now including only one single signaling=
> > mechanisms, as discussed on the ML.
> >
> > I think this version is ready for WGLC.
> >
> > Carlos
> >
> > On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrot= e:
> >> Hi Carlos/All,
> >>
> >>
> >> Can we plan to close this work in the next few days. AFAIK, t= his
> >> FMI/FMA issue is now resolved. If you still doubt the consens= us on
> >> this issue, we can wait for 2 days for any comments and post = the next
> >> rev.
> >>
> >>
> >> I'm hoping we will close this work this week and go LC on= Monday (if
> >> chairs agree). Waiting for Toronto meeting can delay the work= by
> >> another few months.
> >>
> >>
> >>
> >>
> >> Regards
> >> Sri
> >>
> >>
> >> From: Sri Gundavelli <sgundave@cisco.com>
> >> Date: Thursday, June 19, 2014 6:46 AM
> >> To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>, = Hidetoshi
> >> Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org>
> >> Subject: Re: [netext] [Fwd: I-D Action:
> >> draft-ietf-netext-pmipv6-flowmob-09.txt]
> >>
> >>
> >>
> >> Hi Pierrick,
> >>
> >>
> >> After the NETEXT meeting in London, we had some offline discu= ssions
> >> with Rajiv and folks. There is agreement to use the RFC-7077 = (UPN)
> >> messaging format for FMI/FMA. So, the Flow Mobility spec may = refer to
> >> this message as FMI/FMA, but the underneath messaging format = will
> >> confirm to RFC-7077 format and will have references to RFC-70= 77. We
> >> are not going to define a new MH message. This closes the key= issue of
> >> using two notification approaches in the same spec. AFAIK, no= one has
> >> any objection to this. If any does, its now time to speak up = :)
> >>
> >>
> >> Regards
> >> Sri
> >>
> >>
> >>
> >>
> >> From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>=
> >> Date: Thursday, June 19, 2014 1:32 AM
> >> To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org"
> >> <nete= xt@ietf.org>
> >> Subject: Re: [netext] [Fwd: I-D Action:
> >> draft-ietf-netext-pmipv6-flowmob-09.txt]
> >>
> >>
> >>
> >> Hi Hidetoshi/all,
> >>
> >>
> >>
> >> Release -08 mandates RFC7077 and the doc was good, IMHO. But,= in
> >> London, we have decided (group consensus) to reintroduce FMI/= FMA to
> >> avoid dependency between RFC. Now, it=E2=80=99s true that int= roducing 2
> >> options for message format makes the solution more complex fo= r little
> >> added-value (no major differences between messages)=E2=80=A6 = So, maybe the
> >> question is =E2=80=9Cis it good or bad to have RFC dependency= ?=E2=80=9D then update
> >> the draft according the answer...
> >>
> >>
> >>
> >> Pierrick
> >>
> >>
> >>
> >> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi > >> Yokota
> >> Envoy=C3=A9 : jeudi 19 juin 2014 06:41
> >> =C3=80 : netext@ietf.org
> >> Objet : Re: [netext] [Fwd: I-D Action:
> >> draft-ietf-netext-pmipv6-flowmob-09.txt]
> >>
> >>
> >>
> >>
> >> Hello Carlos,
> >>
> >> Thanks for updating the draft.
> >> I have a couple of questions and comments:
> >>
> >> o In Section 3.2.1, which is the shared prefix case, there is= no
> >> message exchange between the LMA and MAG, so there is no flow=
> >> information on the MAG side. It should work in the sense of r= outing,
> >> but if, for example, each flow has a specific QoS, the MAG sh= ould also
> >> need to know which flow should go on which QoS path especiall= y for
> >> upstream traffic towards the LMA. Or, the MAG may want to sen= d a
> >> trigger for flow mobility to the MN (the exact mechanism is o= ut of
> >> scope). =C2=A0Some mobility signaling should be there, too. > >>
> >> o In Section 3.3, FMI/FMA are revived considering the case wh= ere UPN
> >> is not supported, but they convey very little information. Th= ere is no
> >> special information that cannot be conveyed by the existing m= essages.
> >> Since RFC7077 is now a proposed standard, I cannot think of a=
> >> situation where the UPN/UPA are not supported, nevertheless F= MI/FMA
> >> are supported. It rather seems more natural to mandate the su= pport of
> >> RFC7077 or to mandate FMI/FMA for all flow mobility operation= s.
> >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA se= em to
> >> convey different set of parameters in Figure 7. Could you cla= rify it a
> >> little bit more please?
> >>
> >> o In Section 3.3, just above Figure 7, there is a description= : "...,
> >> and the type of flow mobility operation (add flow)", but= does RFC6089
> >> define such an operation code? This kind of operation should = also be
> >> defined in the draft.
> >>
> >> Regards,
> >>
> >>
> >>
> >> --
> >> Hidetoshi Yokota
> >>
> >> KDDI R&D Laboratories, Inc.
> >> e-mail:yokota@kddilabs.jp
> >>
> >>
> >>
> >> (2014/06/14 2:16), Carlos Jes=C3=BAs Bernardos Cano wrote: > >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As agreed in London, I'= ve updated the flow mobility draft to include
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also the FMI/FMA signaling = option (in addition to the use of Update
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Notifications). The draft a= lso includes a mechanism to allow selecting
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which one of the two signal= ing mechanisms to use.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my personal opinion, it&= #39;d be much cleaner and simpler to just specify
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one signaling mechanism, bu= t this is up to the WG to decide.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Comments, reviews and discu= ssion on this new revision would be welcome.
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully we could get at l= east a new revision before Toronto.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Carlos
> >>
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0___________________________= ____________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netext mailing list
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netext@ietf.org
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailma= n/listinfo/netext
> >>
> >>
> >>
> >>
> >> _____________________________________________________________= ____________________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informa= tions confidentielles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si = vous avez recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointe= s. Les messages electroniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete alter= e, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or = privileged information that may be protected by law;
> >> they should not be distributed, used or copied without author= isation.
> >> If you have received this email in error, please notify the s= ender and delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages t= hat have been modified, changed or falsified.
> >> Thank you.
> >> _______________________________________________
> >> netext mailing list
> >> netext@i= etf.org
> >> https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >
> >
>


_______________________________________________
netext mailing list
netext@ietf.org = https://www.ietf.org/mailman/listinfo/netext

--047d7bf10b121f1c0204fe29b930-- From nobody Sat Jul 19 02:01:32 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ADC1A002C for ; Sat, 19 Jul 2014 02:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nibdP71hVhow for ; Sat, 19 Jul 2014 02:01:26 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9727A1A0111 for ; Sat, 19 Jul 2014 02:01:25 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5550215152E9; Sat, 19 Jul 2014 11:01:23 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [172.20.10.3] (198.Red-88-29-126.staticIP.rima-tde.net [88.29.126.198]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id EEF409D27BC; Sat, 19 Jul 2014 11:01:22 +0200 (CEST) Message-ID: <1405760481.4134.9.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Rajeev Koodli Date: Sat, 19 Jul 2014 11:01:21 +0200 In-Reply-To: References: <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20826.006 X-TM-AS-Result: No--27.587-7.0-31-1 X-imss-scan-details: No--27.587-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/iNORw_kJ92-PIvelMvTq9DbBbxc Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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: Sat, 19 Jul 2014 09:01:31 -0000 Hi Rajeev, Hidetoshi, all, Please see some comments inline below. On Mon, 2014-07-14 at 09:24 -0700, Rajeev Koodli wrote: > > Hi Carlos, Yokota-san, > > > sorry for the delay in my response. > > > I would like to clarify something: The FMI/FMA messages make use of > the UPN/UPA format with specific New Reason/Status Codes. In other > words, the _only_ requirement is to support the UPN/UPA messages for > these specific FMI/FMA purposes, and that there is no requirement to > support RFC 7077 in its entirety. So, I suggest adding the following > text, perhaps in the Message Format section. > > > "This specification requires implementation of UPN [RFC7077] and UPA > [RFC7077] messages with the specific Notification Reason and Status > Code as defined by this document. This document does not require > implementation of any other aspects of RFC 7077." I'm fine adding some text along those lines. > > > I am supportive of adding the Flow ID mobility option. OK, we can check the consensus during the meeting and if the group is supporting, I'll add it. Carlos > > > Regards, > > > -Rajeev > > > > > On Tue, Jul 1, 2014 at 5:37 PM, Carlos Jesús Bernardos Cano > wrote: > Hi Hidetoshi, > > Thanks again for your comments. Please see inline below some > comments/replies from my side: > > On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote: > > Hi Carlos, > > > > I briefly reviewed the updated draft and have a couple of > comments. > > > > o The messages named as FMI/FMA in this document are > actually UPN/UPA, > > so the description is confusing since it looks as if new > messages were > > defined. I would propose a new flag or notification > reason/status code > > to indicate that UPN/UPA are used for flow mobility. > > > The use of FMI/FMA is simply to make clearer that these > UPN/UPA messages > are for flow mobility purposes. New notification reason codes > are > actually defined in the document for this purpose. > > > > > o In the previous version, FMI could convey the Flow ID > mobility option, > > but the latest version can convey only HNPs. This looks like > a > > degradation and I'm not sure how both LMA and MAG can share > the same > > flow mobility cache. > > > With the UPN/UPA signaling option, the document has never > supported > conveying the Flow ID mobility option. Ensuring that both the > LMA and > MAG keep the same flow mobility cache was out of the scope of > the > document. If the WG agrees, we could add the possibility of > supporting > UPN/UPA (FMI/FMA) optionally conveying the Flow ID mobility > option. What > do other people think? > > > > > o The flow mobility operation such as "add" or "remove" > should be able > > to specify the targeted flow. To this end, the Flow ID > mobility option > > in RFC6089 should be used. The flow binding action > sub-option defined in > > RFC7109 can be used for the flow mobility operation. > > > In the current version "add" and "remove" are performed with > prefix > granularity (as I mentioned in a previous e-mail, this was the > consensus > reached some time ago, but we can revisit this if the WG wants > to do > so). > > Thanks! > > Carlos > > > > > Please take these points into consideration. > > > > Regards, > > -- > > Hidetoshi > > > > (2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote: > > > Hi, > > > > > > I've just posted -10, now including only one single > signaling > > > mechanisms, as discussed on the ML. > > > > > > I think this version is ready for WGLC. > > > > > > Carlos > > > > > > On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli > (sgundave) wrote: > > >> Hi Carlos/All, > > >> > > >> > > >> Can we plan to close this work in the next few days. > AFAIK, this > > >> FMI/FMA issue is now resolved. If you still doubt the > consensus on > > >> this issue, we can wait for 2 days for any comments and > post the next > > >> rev. > > >> > > >> > > >> I'm hoping we will close this work this week and go LC on > Monday (if > > >> chairs agree). Waiting for Toronto meeting can delay the > work by > > >> another few months. > > >> > > >> > > >> > > >> > > >> Regards > > >> Sri > > >> > > >> > > >> From: Sri Gundavelli > > >> Date: Thursday, June 19, 2014 6:46 AM > > >> To: "pierrick.seite@orange.com" > , Hidetoshi > > >> Yokota , "netext@ietf.org" > > > >> Subject: Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> Hi Pierrick, > > >> > > >> > > >> After the NETEXT meeting in London, we had some offline > discussions > > >> with Rajiv and folks. There is agreement to use the > RFC-7077 (UPN) > > >> messaging format for FMI/FMA. So, the Flow Mobility spec > may refer to > > >> this message as FMI/FMA, but the underneath messaging > format will > > >> confirm to RFC-7077 format and will have references to > RFC-7077. We > > >> are not going to define a new MH message. This closes the > key issue of > > >> using two notification approaches in the same spec. > AFAIK, no one has > > >> any objection to this. If any does, its now time to speak > up :) > > >> > > >> > > >> Regards > > >> Sri > > >> > > >> > > >> > > >> > > >> From: "pierrick.seite@orange.com" > > > >> Date: Thursday, June 19, 2014 1:32 AM > > >> To: Hidetoshi Yokota , > "netext@ietf.org" > > >> > > >> Subject: Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> Hi Hidetoshi/all, > > >> > > >> > > >> > > >> Release -08 mandates RFC7077 and the doc was good, IMHO. > But, in > > >> London, we have decided (group consensus) to reintroduce > FMI/FMA to > > >> avoid dependency between RFC. Now, it’s true that > introducing 2 > > >> options for message format makes the solution more > complex for little > > >> added-value (no major differences between messages)… So, > maybe the > > >> question is “is it good or bad to have RFC dependency?” > then update > > >> the draft according the answer... > > >> > > >> > > >> > > >> Pierrick > > >> > > >> > > >> > > >> De : netext [mailto:netext-bounces@ietf.org] De la part > de Hidetoshi > > >> Yokota > > >> Envoyé : jeudi 19 juin 2014 06:41 > > >> À : netext@ietf.org > > >> Objet : Re: [netext] [Fwd: I-D Action: > > >> draft-ietf-netext-pmipv6-flowmob-09.txt] > > >> > > >> > > >> > > >> > > >> Hello Carlos, > > >> > > >> Thanks for updating the draft. > > >> I have a couple of questions and comments: > > >> > > >> o In Section 3.2.1, which is the shared prefix case, > there is no > > >> message exchange between the LMA and MAG, so there is no > flow > > >> information on the MAG side. It should work in the sense > of routing, > > >> but if, for example, each flow has a specific QoS, the > MAG should also > > >> need to know which flow should go on which QoS path > especially for > > >> upstream traffic towards the LMA. Or, the MAG may want to > send a > > >> trigger for flow mobility to the MN (the exact mechanism > is out of > > >> scope). Some mobility signaling should be there, too. > > >> > > >> o In Section 3.3, FMI/FMA are revived considering the > case where UPN > > >> is not supported, but they convey very little > information. There is no > > >> special information that cannot be conveyed by the > existing messages. > > >> Since RFC7077 is now a proposed standard, I cannot think > of a > > >> situation where the UPN/UPA are not supported, > nevertheless FMI/FMA > > >> are supported. It rather seems more natural to mandate > the support of > > >> RFC7077 or to mandate FMI/FMA for all flow mobility > operations. > > >> Also, when compared with UPN/UPA case in Figure 4, > FMI/FMA seem to > > >> convey different set of parameters in Figure 7. Could you > clarify it a > > >> little bit more please? > > >> > > >> o In Section 3.3, just above Figure 7, there is a > description: "..., > > >> and the type of flow mobility operation (add flow)", but > does RFC6089 > > >> define such an operation code? This kind of operation > should also be > > >> defined in the draft. > > >> > > >> Regards, > > >> > > >> > > >> > > >> -- > > >> Hidetoshi Yokota > > >> > > >> KDDI R&D Laboratories, Inc. > > >> e-mail:yokota@kddilabs.jp > > >> > > >> > > >> > > >> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote: > > >> > > >> > > >> Hi, > > >> > > >> As agreed in London, I've updated the flow > mobility draft to include > > >> also the FMI/FMA signaling option (in addition > to the use of Update > > >> Notifications). The draft also includes a > mechanism to allow selecting > > >> which one of the two signaling mechanisms to > use. > > >> > > >> In my personal opinion, it'd be much cleaner and > simpler to just specify > > >> one signaling mechanism, but this is up to the > WG to decide. > > >> > > >> Comments, reviews and discussion on this new > revision would be welcome. > > >> Hopefully we could get at least a new revision > before Toronto. > > >> > > >> Thanks, > > >> > > >> Carlos > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > >> > > >> > > >> > > >> > > >> > _________________________________________________________________________________________________________________________ > > >> > > >> Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent > donc > > >> pas etre diffuses, exploites ou copies sans autorisation. > Si vous avez recu ce message par erreur, veuillez le signaler > > >> a l'expediteur et le detruire ainsi que les pieces > jointes. Les messages electroniques etant susceptibles > d'alteration, > > >> Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > >> > > >> This message and its attachments may contain confidential > or privileged information that may be protected by law; > > >> they should not be distributed, used or copied without > authorisation. > > >> If you have received this email in error, please notify > the sender and delete this message and its attachments. > > >> As emails may be altered, Orange is not liable for > messages that have been modified, changed or falsified. > > >> Thank you. > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From nobody Mon Jul 21 20:49:07 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9951A03AD; Mon, 21 Jul 2014 20:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSaFU8RoVKZR; Mon, 21 Jul 2014 20:49:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 701D61A0323; Mon, 21 Jul 2014 20:49:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722034904.1850.87323.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 20:49:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/4RWh3G-iJ9pWqDORHygwV973B1c Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 03:49:05 -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 : Extensions to the PMIPv6 Access Network Identifier Option Authors : Rajesh S. Pazhyannur Sebastian Speicher Sri Gundavelli Jouni Korhonen John Kaippallimalil Filename : draft-ietf-netext-ani-location-00.txt Pages : 11 Date : 2014-07-21 Abstract: Access Network Identifier (ANI) Mobility option was introduced in [RFC6757] enabling a MAG to convey information like network identifier, geo-location, operator-identifier. This specification extends Access Network Identifier mobility option with sub-options to carry Civic Location and MAG Group Identifer This specificaton also defines a ANI update timer sub-option that informs the the LMA when (and how often) the ANI will be updated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-ani-location-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 22:13:03 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B741A04D2; Mon, 21 Jul 2014 22:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR-MwDG8fRyH; Mon, 21 Jul 2014 22:12:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBF31A04B0; Mon, 21 Jul 2014 22:12:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722051253.25801.6601.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 22:12:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/k_Zfzja5HvJFXLrM-IpMS611Y9w Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 05:12:55 -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 : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-09.txt Pages : 16 Date : 2014-07-21 Abstract: With Wi-Fi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted Wi-Fi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 07:37:03 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD731A0AB6; Tue, 22 Jul 2014 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRPngKvFCWjG; Tue, 22 Jul 2014 07:36:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6361B1A0019; Tue, 22 Jul 2014 07:36:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722143659.25179.78172.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 07:36:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6ucmag98-7ytXUjWcBAyv0fqwns Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 14:37:00 -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 : Extensions to the PMIPv6 Access Network Identifier Option Authors : Rajesh S. Pazhyannur Sebastian Speicher Sri Gundavelli Jouni Korhonen John Kaippallimalil Filename : draft-ietf-netext-ani-location-01.txt Pages : 11 Date : 2014-07-22 Abstract: Access Network Identifier (ANI) Mobility option was introduced in [RFC6757] enabling a MAG to convey identifiers like network identifier, Geo-location, and operator-identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry Civic Location and MAG Group Identifier. This specification also defines a ANI Update timer sub-option that determines when and how often the ANI will be updated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-ani-location-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 23 07:42:34 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46D1A031C; Wed, 23 Jul 2014 07:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzBFW3cNX8g0; Wed, 23 Jul 2014 07:42:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB561B27EA; Wed, 23 Jul 2014 07:42:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723144219.7706.6575.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 07:42:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/DzkRc8UkF9QcU4VW04g-af_9xSo Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 14:42:25 -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 : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-11.txt Pages : 22 Date : 2014-07-23 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 23 09:44:31 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9084A1B2B77 for ; Wed, 23 Jul 2014 09:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA0BnsHBvAqa for ; Wed, 23 Jul 2014 09:44:28 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F761B2B4B for ; Wed, 23 Jul 2014 09:44:27 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so1153047lab.34 for ; Wed, 23 Jul 2014 09:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Q+FTQuC29KFLclvAar4A6YWKGu1Dm3Nonfxxr68/gQY=; b=G+0L+6DFXQ2sRk/V4R3De4YiV+/46e4S2RGjzqqEz+z8Y8z4mPHfbIrP2jwqA7HxTL eCIGTeOY5XrnWx05/eu6aw757YNx1Y4JGBJitPR0FH3WjeeUhb6swmJWBLR0IorFVglH DBZDdcvc3pz0KfSTjMj5UInFIcwaOqsdewuvPEsbVLZlWn0vCnejBxgutJJx4Pf7Puqw hx+JVsWO7PnCr7jpvnVgc/MJTRufTAZqw3pY6FqeK5ksKZhISIVjuzAQWmm9KApXiT8v XpUdbt+7l0/383KRspj52QhXzKuEOLZ84g3XQEetVSZkBaqkqOaCc/C2AmD7ZHkLn+9E mH8w== MIME-Version: 1.0 X-Received: by 10.152.116.105 with SMTP id jv9mr2779732lab.47.1406133866324; Wed, 23 Jul 2014 09:44:26 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Wed, 23 Jul 2014 09:44:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jul 2014 11:44:26 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/f7FSpUmOStmk7bt1gx-AkM85kXM Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Wed, 23 Jul 2014 16:44:29 -0000 Hi Sri, On Tue, Jul 8, 2014 at 5:46 PM, Sri Gundavelli (sgundave) wrote: > Behcet, > > Please post your proposed changes to the ML. I expected that the chairs would post Rev. 11 on the list, it seems they did not. I am going to post it hopefully before the meeting. > There is an editor for the > document, so its more appropriate you let the WG decide as what goes into > the document. Document editor just follows the WG consensus. You know this > all very well .. You mean when you say something it is consensus when I say something it is not? The editor is supposed to handle all comments. I don't remember the editors asking the WG for every comment made, is there consensus on this comment? I did not know that IETF worked like that. Regards, Behcet > > > Regards > Sri > > > > On 7/8/14 9:46 AM, "Behcet Sarikaya" wrote: > >>Hi all, >> >>I have been commenting on draft-ietf-netext-pmipv6-flowmob for years. >>At some point the chairs set up the issue tracker and asked us to use >>it. I did put many comments on the issue tracker. >> >>In the meantime I have been involved in HA based flow binding entitled >>Flow Bindings Initiated by Home Agents for Mobile IPv6 >>work was published as RFC 7109. >> >>I have noticed that the editor has consistently ignored all these efforts. >> >>Now that we came to a point of final decision, I decided to put all my >>comments in writing. I made an xml file from Rev. 10 >>(BTW we had asked the editor to submit xml file for the draft but he >>did not listen as usual) and produced a complete revision which I >>called Rev. 11 and sent it in an email to the chairs. >> >>Here are the main points in this draft: >>This version is 5+ pages shorter than Rev. 10. >>This version removes the use cases section and replaces it with an >>overview of flow mobility actions describing the flow mobility >>protocol explicitly. >>This version removes FMI/FMA section. >>This version adds Local Mobility Anchor Considerations, Mobile Access >>Gateway considerations >>and much needed IPv4 flow mobility support sections. >>This section uses UPN/UPA messages to carry Flow Identification >>Mobility option and Flow Binding Action Sub-Option >> and Target Care-of Address Sub-Option defined in RFC7109. >> >>I propose this version to be used for further work and let Carlos >>further maintain the document in just a few steps that are left. >> >>Regards, >> >>Behcet >> >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext > From nobody Wed Jul 23 10:03:32 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0329F1B2973 for ; Wed, 23 Jul 2014 10:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vigxd0kGTnWX for ; Wed, 23 Jul 2014 10:03:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0E71B2890 for ; Wed, 23 Jul 2014 10:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4075; q=dns/txt; s=iport; t=1406135004; x=1407344604; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=O9SoeFupA5vtzJGvbd/O+dE6agIJraoMp50T28NoJf4=; b=bubV2GC6Qq+o3vgklAlvj3Qu2Ne8pqmMdUSAtyGgsYfMrpCMceo28bFH 023NCUqJ7JTbGAriD/uI0z4Lh+9y+Wzeha6BLTeCbYBUrGN4W3wqYWh1T /pqQRfZSm4EK6fEMEwIpbZYv6vFryYNrClMwbJAWtu/fftD1NT5dexrCR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFTqz1OtJA2I/2dsb2JhbABZgw5SVwTHWwqGclMBgQsWdoQEAQEEAQEBNzQLEgEIGB4xBgslAgQOBYguAxENuTsNhxQTBI0egUsRAVAHhEYFjkWKZYIDjiKGHoNIbIEMOQ X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342302994" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jul 2014 17:03:24 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NH3NiP001243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:03:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:03:23 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" Thread-Topic: [netext] Flow Mobility Draft Thread-Index: AQHPppgCTmRrE/hmjkOD6MZuW43UGg== Date: Wed, 23 Jul 2014 17:03:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.144.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <192681B2A0F18F4B989EE1C684A86B56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/KrOwK254TVUS_LFr8vnSAb8ma68 Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 17:03:29 -0000 Behcet, Ok. Fair enough. I introduced a change related to UPN/FMI/FMA in the current version of the document. The proposal based on offline discussions was posted on June/19/2014 and subsequently when no objections were cited, the editor of the document drafted the text and inserted the same into the document.=20 Now lets discuss the issue on your proposed changes. AFAIK, no one in the WG, not a single person, understands what they are and why they are needed. When Suresh was chairing one of the NETEXT sessions, he ran a consensus call on the same asking if any one understood what the issue is and you know the result. Bottom line, if you have a issue with the current version, please post your issue. State the problem, suggest the text. Do not send your version of the document to the Editor to be included. I will not agree with you or any one else editing the document and inserting text for an issue that has no WG consensus. The point is on the consensus on on the issue and let the Editor do the drafting. But, if the issue is with the Editor's text, post it to the group and challenge it/suggest changes, don't just edit WG document. =20 Please play by the rules. Sri=20 On 7/23/14 9:44 AM, "Behcet Sarikaya" wrote: >Hi Sri, > >On Tue, Jul 8, 2014 at 5:46 PM, Sri Gundavelli (sgundave) > wrote: >> Behcet, >> >> Please post your proposed changes to the ML. > >I expected that the chairs would post Rev. 11 on the list, it seems >they did not. >I am going to post it hopefully before the meeting. > > > >> There is an editor for the >> document, so its more appropriate you let the WG decide as what goes >>into >> the document. Document editor just follows the WG consensus. You know >>this >> all very well .. > >You mean when you say something it is consensus when I say something it >is not? > >The editor is supposed to handle all comments. I don't remember the >editors asking the WG for every comment made, is there consensus on >this comment? I did not know that IETF worked like that. > >Regards, > >Behcet > >> >> >> Regards >> Sri >> >> >> >> On 7/8/14 9:46 AM, "Behcet Sarikaya" wrote: >> >>>Hi all, >>> >>>I have been commenting on draft-ietf-netext-pmipv6-flowmob for years. >>>At some point the chairs set up the issue tracker and asked us to use >>>it. I did put many comments on the issue tracker. >>> >>>In the meantime I have been involved in HA based flow binding entitled >>>Flow Bindings Initiated by Home Agents for Mobile IPv6 >>>work was published as RFC 7109. >>> >>>I have noticed that the editor has consistently ignored all these >>>efforts. >>> >>>Now that we came to a point of final decision, I decided to put all my >>>comments in writing. I made an xml file from Rev. 10 >>>(BTW we had asked the editor to submit xml file for the draft but he >>>did not listen as usual) and produced a complete revision which I >>>called Rev. 11 and sent it in an email to the chairs. >>> >>>Here are the main points in this draft: >>>This version is 5+ pages shorter than Rev. 10. >>>This version removes the use cases section and replaces it with an >>>overview of flow mobility actions describing the flow mobility >>>protocol explicitly. >>>This version removes FMI/FMA section. >>>This version adds Local Mobility Anchor Considerations, Mobile Access >>>Gateway considerations >>>and much needed IPv4 flow mobility support sections. >>>This section uses UPN/UPA messages to carry Flow Identification >>>Mobility option and Flow Binding Action Sub-Option >>> and Target Care-of Address Sub-Option defined in RFC7109. >>> >>>I propose this version to be used for further work and let Carlos >>>further maintain the document in just a few steps that are left. >>> >>>Regards, >>> >>>Behcet >>> >>>_______________________________________________ >>>netext mailing list >>>netext@ietf.org >>>https://www.ietf.org/mailman/listinfo/netext >> From nobody Wed Jul 23 10:23:10 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ABE1A02F7 for ; Wed, 23 Jul 2014 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuKap0CzxaBS for ; Wed, 23 Jul 2014 10:23:01 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2FE1B2B94 for ; Wed, 23 Jul 2014 10:22:25 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so1129307lbi.41 for ; Wed, 23 Jul 2014 10:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g+2t2FcQ0KMUgd30ZoezZamgYD1GJFE8edntyRhcZ7w=; b=XMArlgLXkNSQr91s2Kg8sJmjqD/ytYxK0tg67Q3WSZWg5NmdHQ7UWwcfwYazU6IrXo RhXuULBTRjGqXHGM/dvSiKkCf46JWnN6rM+SO3uAA3FZa+GXdIzVR64Rt+2tvZeUmJjQ O+UFtJY1We63T5KTAXcdslXILPec2D5JpZrjcGnXRxZRy6QFmy4I9ULaIF8cMshjMQGq NR2+bDPMXUmIvoTCvFOAmNf+vbe9qOmkQ9ir9ZLVlyX+OkzwmlE4l9lXzhR9fcndxWxu qVTZ6/dpROPVbkfaWTMhCfLufbxjMOlLAyKyJG84j+0wZtEmfFlYg3BlDUmeILvx2IhH l3cA== MIME-Version: 1.0 X-Received: by 10.152.29.72 with SMTP id i8mr3205857lah.38.1406136144159; Wed, 23 Jul 2014 10:22:24 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Wed, 23 Jul 2014 10:22:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jul 2014 12:22:24 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/rd7Y3MF8QZZZx__Bq6pEPpomzc8 Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Wed, 23 Jul 2014 17:23:03 -0000 Sri, On Wed, Jul 23, 2014 at 12:03 PM, Sri Gundavelli (sgundave) wrote: > Behcet, > > Ok. Fair enough. I introduced a change related to UPN/FMI/FMA in the > current version of the document. The proposal based on offline discussions > was posted on June/19/2014 and subsequently when no objections were cited, > the editor of the document drafted the text and inserted the same into the > document. The story does not stop there, there are other thing on UPN/UPA (by the way it is UPN/UPA not UPN/FMI/FMA). > Bottom line, if you have a issue with the current version, please post > your issue. State the problem, suggest the text. Do not send your version > of the document to the Editor to be included. I will not agree with you or > any one else editing the document and inserting text for an issue that has > no WG consensus. The point is on the consensus on on the issue and let the > Editor do the drafting. But, if the issue is with the Editor's text, post > it to the group and challenge it/suggest changes, don't just edit WG > document. > > Please play by the rules. > I already did. You can check in the archive. I asked many questions and received no replies. I read Rev. 10 sentence by sentence. I don't think anybody else did this in the WG. I can claim that I know flow mobility and I can show my credentials. My assessment was that the only way to incorporate my comments is to edit Rev. 10 completely and that's what I did. Regards, Behcet > > > Sri > > > > > On 7/23/14 9:44 AM, "Behcet Sarikaya" wrote: > >>Hi Sri, >> >>On Tue, Jul 8, 2014 at 5:46 PM, Sri Gundavelli (sgundave) >> wrote: >>> Behcet, >>> >>> Please post your proposed changes to the ML. >> >>I expected that the chairs would post Rev. 11 on the list, it seems >>they did not. >>I am going to post it hopefully before the meeting. >> >> >> >>> There is an editor for the >>> document, so its more appropriate you let the WG decide as what goes >>>into >>> the document. Document editor just follows the WG consensus. You know >>>this >>> all very well .. >> >>You mean when you say something it is consensus when I say something it >>is not? >> >>The editor is supposed to handle all comments. I don't remember the >>editors asking the WG for every comment made, is there consensus on >>this comment? I did not know that IETF worked like that. >> >>Regards, >> >>Behcet >> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> On 7/8/14 9:46 AM, "Behcet Sarikaya" wrote: >>> >>>>Hi all, >>>> >>>>I have been commenting on draft-ietf-netext-pmipv6-flowmob for years. >>>>At some point the chairs set up the issue tracker and asked us to use >>>>it. I did put many comments on the issue tracker. >>>> >>>>In the meantime I have been involved in HA based flow binding entitled >>>>Flow Bindings Initiated by Home Agents for Mobile IPv6 >>>>work was published as RFC 7109. >>>> >>>>I have noticed that the editor has consistently ignored all these >>>>efforts. >>>> >>>>Now that we came to a point of final decision, I decided to put all my >>>>comments in writing. I made an xml file from Rev. 10 >>>>(BTW we had asked the editor to submit xml file for the draft but he >>>>did not listen as usual) and produced a complete revision which I >>>>called Rev. 11 and sent it in an email to the chairs. >>>> >>>>Here are the main points in this draft: >>>>This version is 5+ pages shorter than Rev. 10. >>>>This version removes the use cases section and replaces it with an >>>>overview of flow mobility actions describing the flow mobility >>>>protocol explicitly. >>>>This version removes FMI/FMA section. >>>>This version adds Local Mobility Anchor Considerations, Mobile Access >>>>Gateway considerations >>>>and much needed IPv4 flow mobility support sections. >>>>This section uses UPN/UPA messages to carry Flow Identification >>>>Mobility option and Flow Binding Action Sub-Option >>>> and Target Care-of Address Sub-Option defined in RFC7109. >>>> >>>>I propose this version to be used for further work and let Carlos >>>>further maintain the document in just a few steps that are left. >>>> >>>>Regards, >>>> >>>>Behcet >>>> >>>>_______________________________________________ >>>>netext mailing list >>>>netext@ietf.org >>>>https://www.ietf.org/mailman/listinfo/netext >>> > From nobody Wed Jul 23 10:31:17 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9AE1B2BAD for ; Wed, 23 Jul 2014 10:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqXHwKYflrqh for ; Wed, 23 Jul 2014 10:30:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE181B2A1E for ; Wed, 23 Jul 2014 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=796; q=dns/txt; s=iport; t=1406136635; x=1407346235; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qKv/C7bNx7wv7lI39RI1oWNo3t8rXLXKV9LBjxFeczs=; b=YLP2lULek1ZxeTTaPR2qHaTb07SPAB2XK2SyHDmDfALHtkzyRM35eUih /qgHVt2bJ4v89oZUUsCr9X9UV8vXfDrqu4Gk6660P1N0LOshLVHmsDrJ9 9doa2kGuQRgASkTkXuFnG/G9FCzYh6wasck7IY6d9Qeh/bj0InBlT5R5b Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALPwz1OtJV2S/2dsb2JhbABZgw6BLc8qAYELFnaEBAIEOj8SAQg2QiUCBA6IR8BCF49LB4RGAQSbLZRAg0iCMQ X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342091694" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jul 2014 17:30:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6NHUXYF019929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:30:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:30:33 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" Thread-Topic: [netext] Flow Mobility Draft Thread-Index: AQHPppvNA2n8r6ZKjUK+WtNeZdtb0A== Date: Wed, 23 Jul 2014 17:30:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.144.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/-7xedZMhQO7V_LWmqmff1FBYcl0 Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 17:31:05 -0000 Behcet, > >I already did. You can check in the archive. I asked many questions >and received no replies. > >I read Rev. 10 sentence by sentence. I don't think anybody else did >this in the WG. >I can claim that I know flow mobility and I can show my credentials. > >My assessment was that the only way to incorporate my comments is to >edit Rev. 10 completely and that's what I did. Its not about your credentials. I don't understand your approach of editing a WG document. =20 Chairs can comment, but as a WG member I'm not comfortable with you or any one else editing the document and posting the same with out WG review; Why do we have a Editor then ? Editor may choose to accept all your changes, that's at his discretion. Please talk to Carlos. Regards Sri From nobody Wed Jul 23 10:47:23 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12281B2A18 for ; Wed, 23 Jul 2014 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A5cVYpYjDU8 for ; Wed, 23 Jul 2014 10:47:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BB11A0AE7 for ; Wed, 23 Jul 2014 10:47:04 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8C31F88118 for ; Wed, 23 Jul 2014 10:47:04 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 331151368082 for ; Wed, 23 Jul 2014 10:47:04 -0700 (PDT) Message-ID: <53CFF515.9040706@innovationslab.net> Date: Wed, 23 Jul 2014 13:47:01 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9pmlgWrNuAbhdM9il06AUvnupjLtEV9qg" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/0eb-gu6aLwq3I1MB-E3kz6I3DXw Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 17:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9pmlgWrNuAbhdM9il06AUvnupjLtEV9qg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, Consider the following to be spoken with my AD hat firmly on my head= =2E.. On 7/23/14 1:30 PM, Sri Gundavelli (sgundave) wrote: > Behcet, >=20 >=20 >> >> I already did. You can check in the archive. I asked many questions >> and received no replies. >> >> I read Rev. 10 sentence by sentence. I don't think anybody else did >> this in the WG. >> I can claim that I know flow mobility and I can show my credentials. >> >> My assessment was that the only way to incorporate my comments is to >> edit Rev. 10 completely and that's what I did. >=20 >=20 > Its not about your credentials. I don't understand your approach of > editing a WG document. > =20 > Chairs can comment, but as a WG member I'm not comfortable with you or= > any one else editing the document and posting the same with out WG revi= ew; > Why do we have a Editor then ? Editor may choose to accept all your > changes, that's at his discretion. Please talk to Carlos. Providing a complete re-write of a WG draft is not only inappropriate, it is disruptive. Please read that sentence again. The WG has an issue tracker set up for this document. It appears that the document editor and chairs are using it to track issues raised. Why should these concerns be handled any differently. Perusal of the mailing list archives and the minutes of previous netext meetings reveals no support within the WG for these perceived defects. That could be a result of a disagreement with the concerns raised or could a result of people not understanding the concerns. Regards, Brian --9pmlgWrNuAbhdM9il06AUvnupjLtEV9qg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTz/UVAAoJEBOZRqCi7goq/G0IAM+q4gPwEXgvivW6GWhCZOEB bZLeVMQIIyIlROfS+WW7ril+hb6f1bcnR80ZVXbjevWV2FFF//ShZEAM3foWwg6Y voLGur1FHAFhF9qiWUzCojD2mdsYL69y2H3orqvqBAM085OfejDxtm76cCIjjp1t bBX9NE8yfCzIw7y+WRovY1UNtZElWqr1yeHdhM/IalAUQfPxU8VnllLoxWnJ3jJu h0svxBWP+wWK0SFBSkvSstsFga4x0bRGZB+4YfEZBT7BddXTjCrA3Jd9uWZGtXph UqWpt57fx6hB/pWE+PCZ7Segsts3A4MyEdbtdlIgkxN9Bvz+9tx0nX2nDHjqmy8= =g2+o -----END PGP SIGNATURE----- --9pmlgWrNuAbhdM9il06AUvnupjLtEV9qg-- From nobody Thu Jul 24 06:20:19 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C081B1A0299 for ; Thu, 24 Jul 2014 06:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKPBiAcQNG7i for ; Thu, 24 Jul 2014 06:20:10 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B4E1A0309 for ; Thu, 24 Jul 2014 06:20:09 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so2241079lbd.22 for ; Thu, 24 Jul 2014 06:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ixf6p52reZ3sYSr/zwCZjhHrY+/i3WcT5YrEbS46d2Q=; b=O00FswnM21wlgAEFVDoovpslJsxeAdOmlUNuBsx8pYj7o+8ayQyF8ayx3/IvxcwV0O raauQmwjcDGF5P/oFPq7WEM8DGfjtvH58gftfknfTpG9TL1tt89Af6DekjTMAvAi2HUn TKqnt1vOlgKYYxX+bDjk1UtDS+enXfK3moFabP9SuXgCCH5LHPlQeoViYSyUqTtUzA0r Foq9aG538wwifP7qF8Vv5UDYCzZ0p9eXTXNHpJ3M+QIW4J0gkRLR7AT+5rSBRwSr5UMt zm4RjsdYAa6P/DebH+Oj0Rp5tb863Io6+wjyexvV41yxEunR9ZlVWwNMRrAEb0jIRglF AT4w== MIME-Version: 1.0 X-Received: by 10.152.116.105 with SMTP id jv9mr9290189lab.47.1406208007932; Thu, 24 Jul 2014 06:20:07 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Thu, 24 Jul 2014 06:20:07 -0700 (PDT) In-Reply-To: <53CFF515.9040706@innovationslab.net> References: <53CFF515.9040706@innovationslab.net> Date: Thu, 24 Jul 2014 08:20:07 -0500 Message-ID: From: Behcet Sarikaya To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/x-gyzC_QRExi3sxVsiVIjuNNC1Q Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Thu, 24 Jul 2014 13:20:16 -0000 Hi Brian, On Wed, Jul 23, 2014 at 12:47 PM, Brian Haberman wrote: > All, > Consider the following to be spoken with my AD hat firmly on my head... > > On 7/23/14 1:30 PM, Sri Gundavelli (sgundave) wrote: >> Behcet, >> >> >>> >>> I already did. You can check in the archive. I asked many questions >>> and received no replies. >>> >>> I read Rev. 10 sentence by sentence. I don't think anybody else did >>> this in the WG. >>> I can claim that I know flow mobility and I can show my credentials. >>> >>> My assessment was that the only way to incorporate my comments is to >>> edit Rev. 10 completely and that's what I did. >> >> >> Its not about your credentials. I don't understand your approach of >> editing a WG document. >> >> Chairs can comment, but as a WG member I'm not comfortable with you or >> any one else editing the document and posting the same with out WG review; >> Why do we have a Editor then ? Editor may choose to accept all your >> changes, that's at his discretion. Please talk to Carlos. > > Providing a complete re-write of a WG draft is not only inappropriate, > it is disruptive. Please read that sentence again. > OK, understood. > The WG has an issue tracker set up for this document. It appears that > the document editor and chairs are using it to track issues raised. Why > should these concerns be handled any differently. Please refer to the Issue Tracker page: http://trac.tools.ietf.org/wg/netext/trac/report/1 I did have several issues there. The editor replied some of them but I was not happy with them. Unfortunately the Tracker has not been used since two years even though this document is still around. Some comments were made on the list and I received no reply. > > Perusal of the mailing list archives and the minutes of previous netext > meetings reveals no support within the WG for these perceived defects. > That could be a result of a disagreement with the concerns raised or > could a result of people not understanding the concerns. > There at least two common concerns that I believe several people share: where is the flow mobility protocol in the draft? Why is LMA prefix allocation policy a use case for flow mobility protocol? If the Editor does not understand these issues then he needs to read the revision I mentioned. I am withholding it as per your instructions, anybody can request it I'll be happy to email it. Regards, Behcet > Regards, > Brian > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From nobody Thu Jul 24 06:24:27 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBDA1A0316 for ; Thu, 24 Jul 2014 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8lL3QgguHvj for ; Thu, 24 Jul 2014 06:24:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C9E1A0317 for ; Thu, 24 Jul 2014 06:24:24 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C41078814A; Thu, 24 Jul 2014 06:24:24 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0A4BA71B0001; Thu, 24 Jul 2014 06:24:23 -0700 (PDT) Message-ID: <53D10901.4000103@innovationslab.net> Date: Thu, 24 Jul 2014 09:24:17 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <53CFF515.9040706@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CQVFkAW1dQ1MDM3IWL8scTWfOcDRTGEsw" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/46noqedOCDqTt5IAxov1p-jGlo0 Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Jul 2014 13:24:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CQVFkAW1dQ1MDM3IWL8scTWfOcDRTGEsw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/24/14 9:20 AM, Behcet Sarikaya wrote: >> The WG has an issue tracker set up for this document. It appears that= >> the document editor and chairs are using it to track issues raised. W= hy >> should these concerns be handled any differently. >=20 > Please refer to the Issue Tracker page: > http://trac.tools.ietf.org/wg/netext/trac/report/1 >=20 > I did have several issues there. > The editor replied some of them but I was not happy with them. Has anyone expressed support for those concerns? >=20 >> >> Perusal of the mailing list archives and the minutes of previous netex= t >> meetings reveals no support within the WG for these perceived defects.= >> That could be a result of a disagreement with the concerns raised or >> could a result of people not understanding the concerns. >> >=20 > There at least two common concerns that I believe several people share:= You believe or know? Why have they not expressed those concerns on the mailing list? If they have, can you provide a pointer? >=20 > where is the flow mobility protocol in the draft? >=20 > Why is LMA prefix allocation policy a use case for flow mobility protoc= ol? >=20 >=20 > If the Editor does not understand these issues then he needs to read > the revision I mentioned. No. As I said, that is not an appropriate way to express concerns. You have several concise questions listed above. Why not expound on those with the WG? Regards, Brian --CQVFkAW1dQ1MDM3IWL8scTWfOcDRTGEsw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0QkHAAoJEBOZRqCi7goqIoIH/RKOOGi2gI7Kl7epXEeiz+Gn oKIKyiO0TchKmjkI7RT4r59KuYfyNQV81HWQAIkJPCIxDRXa1iB3gMgISq4Mi+fp h3YsXoFC77YF9jpbaEakt5fLjPb63iROf4K9n5GnsxxV2R5+mrW0EwfQO99bYuYI /66lYmM7bfATagW/j5f4hZwtIckWO+jpcY+hSYdZObRa0+29M9QOJyUbtRrHxnwZ VWh/9cqBMoLWpgqmKDlPOj4w4l5C7Kw5qDWg8ijg84ucBLcoOdn8B0b9Y+M1nhGh e1q8SxHDAxxqQdRExQryqPo+sIL/Ecyz1dIvqJenaGRv6ndGmZ8TZ5VpO3aKr1E= =Qmt0 -----END PGP SIGNATURE----- --CQVFkAW1dQ1MDM3IWL8scTWfOcDRTGEsw-- From nobody Thu Jul 24 07:11:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0081A032E for ; Thu, 24 Jul 2014 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2GReXBoBwDA for ; Thu, 24 Jul 2014 07:10:58 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9861A031A for ; Thu, 24 Jul 2014 07:10:57 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id w7so2339028lbi.1 for ; Thu, 24 Jul 2014 07:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kS2qIavoYHlRd6UmVTzm5qqwBXy2hiTnKdgNMS58aIk=; b=rVyqDo1In67IKZYGb5I0uhu7/ytT5OewyMHigZ+45g5wovvPrbqocckWqlR2MhHWfV QPAEyPerBakfB1fRolIjwaSmVGyjP4/btiZgRNWqxqzoLpevEK56CfzWm8aF6Lzd/mu/ MLebTcQ4Opy667GxydtCZzm7Ba+A5tKWrsXBwLLmiD/H4Abdv/ck5rlVK31haRyCII+j YvLDZKIu1YR5h5u8IjExvscyiBGvhedwTV6TNiXVFmowbIcvLOYQg+lygszftspRFSJc /SYxXvnySC5Zs5M79vsEA2VtD//Z20s1diWdeRk6WzO5aFyS4aFgEgrVCg4poJbLFeDs 1Rgg== MIME-Version: 1.0 X-Received: by 10.152.27.197 with SMTP id v5mr4311760lag.84.1406211055967; Thu, 24 Jul 2014 07:10:55 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Thu, 24 Jul 2014 07:10:55 -0700 (PDT) In-Reply-To: <53D10901.4000103@innovationslab.net> References: <53CFF515.9040706@innovationslab.net> <53D10901.4000103@innovationslab.net> Date: Thu, 24 Jul 2014 09:10:55 -0500 Message-ID: From: Behcet Sarikaya To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/2Rw-VGqw9YQpDfYM_67hx18Eb8c Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Thu, 24 Jul 2014 14:10:59 -0000 Another issue with the editor has been his attuitude. He has always been stubborn he never said things like why don't you provide some text? or let's edit the document together. This document has not originated from his own document, it has come out of a design team so the editor's rigid approach was not warranted. Regards, Behcet On Thu, Jul 24, 2014 at 8:24 AM, Brian Haberman wrote: > > > On 7/24/14 9:20 AM, Behcet Sarikaya wrote: > >>> The WG has an issue tracker set up for this document. It appears that >>> the document editor and chairs are using it to track issues raised. Why >>> should these concerns be handled any differently. >> >> Please refer to the Issue Tracker page: >> http://trac.tools.ietf.org/wg/netext/trac/report/1 >> >> I did have several issues there. >> The editor replied some of them but I was not happy with them. > > Has anyone expressed support for those concerns? > >> >>> >>> Perusal of the mailing list archives and the minutes of previous netext >>> meetings reveals no support within the WG for these perceived defects. >>> That could be a result of a disagreement with the concerns raised or >>> could a result of people not understanding the concerns. >>> >> >> There at least two common concerns that I believe several people share: > > You believe or know? Why have they not expressed those concerns on the > mailing list? If they have, can you provide a pointer? > >> >> where is the flow mobility protocol in the draft? >> >> Why is LMA prefix allocation policy a use case for flow mobility protocol? >> >> >> If the Editor does not understand these issues then he needs to read >> the revision I mentioned. > > No. As I said, that is not an appropriate way to express concerns. You > have several concise questions listed above. Why not expound on those > with the WG? > > Regards, > Brian > From nobody Thu Jul 24 07:13:25 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBA1A02E7 for ; Thu, 24 Jul 2014 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHylxlK2T16f for ; Thu, 24 Jul 2014 07:13:20 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9C11A02EC for ; Thu, 24 Jul 2014 07:13:20 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5FD1B88116; Thu, 24 Jul 2014 07:13:20 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 14A5313680C0; Thu, 24 Jul 2014 07:13:19 -0700 (PDT) Message-ID: <53D11478.9050402@innovationslab.net> Date: Thu, 24 Jul 2014 10:13:12 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <53CFF515.9040706@innovationslab.net> <53D10901.4000103@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wfHLqOolqF7E9HW7unfiq9M5A6qMpHXLm" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/R9dxaoxcGOzwGj6801FsVhIzND4 Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Jul 2014 14:13:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wfHLqOolqF7E9HW7unfiq9M5A6qMpHXLm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/24/14 10:10 AM, Behcet Sarikaya wrote: > Another issue with the editor has been his attuitude. He has always > been stubborn he never said things like why don't you provide some > text? or let's edit the document together. >=20 > This document has not originated from his own document, it has come > out of a design team so the editor's rigid approach was not warranted. This document is a WG document. That means there must be consensus to add/delete/change text. Show me the consensus to make the changes you proposed. Regards, Brian --wfHLqOolqF7E9HW7unfiq9M5A6qMpHXLm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0RR+AAoJEBOZRqCi7goqSygH/2wXFAVEdMkOVxLG8kpn8n8y 4CK5xysqGM2R3hvOBlCRurUtUUbpFGcJbW5amm+BWOxW15FyExA7aV1g+mvuw3tk YQWhDL/4uNNQs/ViSyGKZvb++lvfIedrohx4nqoxY6FFVABdZX5WpNmBsD2wDnND GSD3puWTvug0C4IziUQiAi1XNEa/YP4DkHDa0uY1l/qi67QauvDjv6mxoe693LjJ qdrOWo0E9/mK3o3eqWHwMD6vn2sUoSCUDmiuxPxWG7cTjs1mRXJEFZ3UIWin5G8A uFULIubb/41zzV47m8GFOfx3D7hKPQ0V5iyZZNzW4cfPrnxsKnGKwGfNGb+RDy0= =T5dW -----END PGP SIGNATURE----- --wfHLqOolqF7E9HW7unfiq9M5A6qMpHXLm-- From nobody Thu Jul 24 07:26:39 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00A1A0375 for ; Thu, 24 Jul 2014 07:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNDCQzja7nF3 for ; Thu, 24 Jul 2014 07:26:36 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B72E1A004E for ; Thu, 24 Jul 2014 07:26:35 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so2790374wgh.11 for ; Thu, 24 Jul 2014 07:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJwOgIOkDGaqUOq0I8t82URez2MLF/aK4QL99qmQ79k=; b=nimy/TCU6BVBY5WTS+ZKbstn0OSKnwCZ0/W8A24HFQ11tLRvxLLbSmKXqZZnNulB1X TzAcKBzxaqWFB9VIi9bFnzpx3gweLCIebGANxy8fSzJGtWw7Yc6LgdCfis8jMqjxIaDR kerMcizN/Z/lnxaJ5ynlRMBIryp1k9fHeNy5YSoQDNXWPTrQXDyOGEhIzhcgQg/pW+Cn DSM9b3qqh+zGAeXbp2Y/fJ6sZL2U9xDvSCstNqy+f9fv9PEPzW+pvIDcpo1KEj5x+PBF ODLp6+xUEvMMXG4OK69NboSGP9L6l1yKETwBUTaPx9626Zq9sMphTnoqTVCtQDWr+5LI Sh0A== MIME-Version: 1.0 X-Received: by 10.180.84.7 with SMTP id u7mr50561603wiy.1.1406211993871; Thu, 24 Jul 2014 07:26:33 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Thu, 24 Jul 2014 07:26:33 -0700 (PDT) In-Reply-To: References: <53CFF515.9040706@innovationslab.net> <53D10901.4000103@innovationslab.net> Date: Thu, 24 Jul 2014 07:26:33 -0700 Message-ID: From: Rajeev Koodli To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=f46d0418255c5fac7d04fef13ea3 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/UiawWE8uW-tfslnVM5c3uxZDDEw Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Jul 2014 14:26:38 -0000 --f46d0418255c5fac7d04fef13ea3 Content-Type: text/plain; charset=UTF-8 Hi Behcet, let us not use this ML/WG for personal issues. Just to be clear: Carlos is the Editor of this ID, and he has chairs support. At this point, my sense is that the WG is ready to move ahead with the ID. Will talk during the meeting. Regards, -Rajeev On Thu, Jul 24, 2014 at 7:10 AM, Behcet Sarikaya wrote: > Another issue with the editor has been his attuitude. He has always > been stubborn he never said things like why don't you provide some > text? or let's edit the document together. > > This document has not originated from his own document, it has come > out of a design team so the editor's rigid approach was not warranted. > > Regards, > > Behcet > > On Thu, Jul 24, 2014 at 8:24 AM, Brian Haberman > wrote: > > > > > > On 7/24/14 9:20 AM, Behcet Sarikaya wrote: > > > >>> The WG has an issue tracker set up for this document. It appears that > >>> the document editor and chairs are using it to track issues raised. > Why > >>> should these concerns be handled any differently. > >> > >> Please refer to the Issue Tracker page: > >> http://trac.tools.ietf.org/wg/netext/trac/report/1 > >> > >> I did have several issues there. > >> The editor replied some of them but I was not happy with them. > > > > Has anyone expressed support for those concerns? > > > >> > >>> > >>> Perusal of the mailing list archives and the minutes of previous netext > >>> meetings reveals no support within the WG for these perceived defects. > >>> That could be a result of a disagreement with the concerns raised or > >>> could a result of people not understanding the concerns. > >>> > >> > >> There at least two common concerns that I believe several people share: > > > > You believe or know? Why have they not expressed those concerns on the > > mailing list? If they have, can you provide a pointer? > > > >> > >> where is the flow mobility protocol in the draft? > >> > >> Why is LMA prefix allocation policy a use case for flow mobility > protocol? > >> > >> > >> If the Editor does not understand these issues then he needs to read > >> the revision I mentioned. > > > > No. As I said, that is not an appropriate way to express concerns. You > > have several concise questions listed above. Why not expound on those > > with the WG? > > > > Regards, > > Brian > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --f46d0418255c5fac7d04fef13ea3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Behcet,

let us not us= e this ML/WG for personal issues.

Just to be clear= : Carlos is the Editor of this ID, and he has chairs support.

At this point, my sense is that the WG= is ready to move ahead with the ID.=C2=A0
= Will talk during the meeting.

Regards,

-Rajeev




On Thu, Jul 24, 2014 at 7:10 AM, Behcet Sarikaya <sarikaya2012@gmai= l.com> wrote:
Another issue with the editor has been his a= ttuitude. He has always
been stubborn he never said things like why don't you provide some
text? or let's edit the document together.

This document has not originated from his own document, it has come
out of a design team so the editor's rigid approach was not warranted.<= br>
Regards,

Behcet

On Thu, Jul 24, 2014 at 8:24 AM, Brian Haberman
<brian@innovationslab.net> wrote:
>
>
> On 7/24/14 9:20 AM, Behcet Sarikaya wrote:
>
>>> The WG has an issue tracker set up for this document. =C2=A0It= appears that
>>> the document editor and chairs are using it to track issues ra= ised. =C2=A0Why
>>> should these concerns be handled any differently.
>>
>> Please refer to the Issue Tracker page:
>> http://trac.tools.ietf.org/wg/netext/trac/report/1
>>
>> I did have several issues there.
>> The editor replied some of them but I was not happy with them.
>
> Has anyone expressed support for those concerns?
>
>>
>>>
>>> Perusal of the mailing list archives and the minutes of previo= us netext
>>> meetings reveals no support within the WG for these perceived = defects.
>>> That could be a result of a disagreement with the concerns rai= sed or
>>> could a result of people not understanding the concerns.
>>>
>>
>> There at least two common concerns that I believe several people s= hare:
>
> You believe or know? =C2=A0Why have they not expressed those concerns = on the
> mailing list? =C2=A0If they have, can you provide a pointer?
>
>>
>> where is the flow mobility protocol in the draft?
>>
>> Why is LMA prefix allocation policy a use case for flow mobility p= rotocol?
>>
>>
>> If the Editor does not understand these issues then he needs to re= ad
>> the revision I mentioned.
>
> No. =C2=A0As I said, that is not an appropriate way to express concern= s. =C2=A0You
> have several concise questions listed above. =C2=A0Why not expound on = those
> with the WG?
>
> Regards,
> Brian
>

_______________________= ________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

--f46d0418255c5fac7d04fef13ea3-- From nobody Thu Jul 24 07:49:44 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B0B1A03C7 for ; Thu, 24 Jul 2014 07:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBLIiLMdc_JK for ; Thu, 24 Jul 2014 07:49:41 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCC61A03B7 for ; Thu, 24 Jul 2014 07:49:40 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so1996755lab.32 for ; Thu, 24 Jul 2014 07:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xuy/x5vg9WxlPOnIWpjxgWJLrPwnfTk/jSalVmtCmoI=; b=lLx5pG0gPhz3+t29bF+uFBzBUdJoefnQhnCK4VorMY3h5DG1XaJmDKHIT28rAPJCJ0 6fJBYWknt8kQUn+iFh/68irGqSJ/OTqI+CKA2uWaCgdYeLZ4TfDNF55X2iMDLpfeN9Y7 Qlg5bV7RuGrtqe3cjwNyqS83oztyP/3ab8q7SWhRyydEI0Rwqz5397tEgncyePDILE6a Isctusm2DrzVjbJeUtJox1LYP11n5bkXi/qgvnLTFD65gxky1HdkU7t29Phpybn+4aKv PjA5a1VmqblV9bk9BbveuYSCX2A4i2ipT55UffTlxWUwvBuDSU9f5f48ktOf8a8m3JSP /v4g== MIME-Version: 1.0 X-Received: by 10.152.29.72 with SMTP id i8mr10011007lah.38.1406213379048; Thu, 24 Jul 2014 07:49:39 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Thu, 24 Jul 2014 07:49:38 -0700 (PDT) In-Reply-To: <53D11478.9050402@innovationslab.net> References: <53CFF515.9040706@innovationslab.net> <53D10901.4000103@innovationslab.net> <53D11478.9050402@innovationslab.net> Date: Thu, 24 Jul 2014 09:49:38 -0500 Message-ID: From: Behcet Sarikaya To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/-9jrMfSHjO3FjNzwoNn3ZW_KQYE Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility Draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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: Thu, 24 Jul 2014 14:49:42 -0000 On Thu, Jul 24, 2014 at 9:13 AM, Brian Haberman wrote: > > > On 7/24/14 10:10 AM, Behcet Sarikaya wrote: >> Another issue with the editor has been his attuitude. He has always >> been stubborn he never said things like why don't you provide some >> text? or let's edit the document together. >> >> This document has not originated from his own document, it has come >> out of a design team so the editor's rigid approach was not warranted. > > This document is a WG document. That means there must be consensus to > add/delete/change text. Show me the consensus to make the changes you > proposed. We discussed this with Sri on the list yesterday. Comments are posted by individuals and the editor replies them. I am not familiar with any IETF document that says that the commenter has to get WG consensus in making his/her comments. In any case I have not seen any other people who commented on this draft did get WG consensus, maybe they did I did not see it. It is quite common by WG draft editors to ask for text contributions. I have been attending IETF since more than 10 years but maybe I don't know anything. In short my two questions above are valid, maybe the chairs can ask this afternoon in the session. I know that at least one person (Hidetoshi Yokata) has similar concerns, but due to job situation he could not post any mails recently on the list. I have presentations in a parallel session this afternoon, I can maybe only follow over Jabber. Regards, Behcet > > Regards, > Brian > From nobody Thu Jul 24 11:48:25 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465961A0A90 for ; Thu, 24 Jul 2014 11:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_ZYabj6Tigz for ; Thu, 24 Jul 2014 11:48:18 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4F11A0146 for ; Thu, 24 Jul 2014 11:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17700; q=dns/txt; s=iport; t=1406227698; x=1407437298; h=from:to:subject:date:message-id:mime-version; bh=Qf98MNPyVbEU+h3GnAdPi/irtnvJ7LCLAOfzmUpiWKo=; b=mgwHa6xLdu6lmSIE8LucnQpqxSGn/y56jvRBeuVOx7e7IaMek/DdYAbF sK1lY3KZjqve70AfsP52vxvV0WwKutHJnSXgP5O6OT/9k1RhLavhsDBE0 ohGpgO9FTRlQHejW5BsYyD/Qm9ti0si8oyBkCPuQBs6yzx8+Ouz2qADyM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHBU0VOtJV2b/2dsb2JhbABYgkdHUlvQewGBDRZ3hAUBBCcGXgEqViYBBBuIOphZpm8XjxqDZoEYBa97g0iCMQ X-IronPort-AV: E=Sophos; i="5.01,725,1400025600"; d="scan'208,217"; a="63775477" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 24 Jul 2014 18:48:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6OImGRY017423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 18:48:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 13:48:16 -0500 From: "Kent Leung (kleung)" To: "netext@ietf.org" Thread-Topic: draft-ietf-netext-ani-location-01 comments Thread-Index: Ac+nb9MUFzOTbU0+Ssi3Vco6rZsw7Q== Date: Thu, 24 Jul 2014 18:48:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.119] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB4DED11F8xmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/FhQ3rlSbaXfLt5PFE_VDEcRoEZA Subject: [netext] draft-ietf-netext-ani-location-01 comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Jul 2014 18:48:20 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED11F8xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajesh et al. A few comments on this draft. 1. Abstract section: "Geo-location" -> "geolocation"? 2. "operator-identifier" -> "operator identifier" 3. "Civic Location" -> "civic location" 4. "MAG Group Identifier -> "MAG group identifier"? 5. Introduction: "ANI mobility Option" -> "ANI mobility option" 6. "may contain SSID and BSSID of the Access Point (AP)" (remove comma= ) 7. "Geo-Location of the AP" -> "geolocation of the AP" 8. "Operator-Identifier" -> "operator identifier"? 9. "Geo-spatial" -> "geospatial"? 10. "The group-identifier is used a proxy for coarse location" -> "The g= roup identifier is used as proxy for coarse location" 11. "group-identifier" -> "group identifier" (global change) 12. General comment on consistency for words: geolocation, civic locatio= n, AP group identifier, etc. 13. Sect. 3.1: How is the XML encoding represented? 14. "as identifier by an operator-identifier" -> "as identifier by an op= erator" 15. Reserved field description is missing (e.g. MUST be set to zero when= sending and ignored when received.) 16. Sect. 3.2: "2 octet integer" -> "2 octet unsigned integer"? 17. "left to implementation. )" (extra space before parenthesis) 18. Sect. 3.3: Extra reserved field description 19. "It indicates the time in seconds before the MAG sends an update val= ue of ANI mobility options assuming ANI value changed"? Kent --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED11F8xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rajesh et al. A few co= mments on this draft.

 <= /b>

1. = ;     Abstract sect= ion: “Geo-location” -> “geolocation”?=

2. = ;     “operat= or-identifier” -> “operator identifier”

3. = ;     “Civic = Location” -> “civic location”

4. = ;     “MAG Gr= oup Identifier -> “MAG group identifier”?<= /b>

5. = ;     Introduction:= “ANI mobility Option” -> “ANI mobility option”<= o:p>

6. = ;     “may co= ntain SSID and BSSID of the Access Point (AP)” (remove comma)

7. = ;     “Geo-Lo= cation of the AP” -> “geolocation of the AP”

8. = ;     “Operat= or-Identifier” -> “operator identifier”?

9. = ;     “Geo-sp= atial” -> “geospatial”?

10.&nbs= p;   “The gr= oup-identifier is used a proxy for coarse location” -> “The = group identifier is used as proxy for coarse location”

11.&nbs= p;   “group-= identifier” -> “group identifier” (global change)=

12.&nbs= p;   General comme= nt on consistency for words: geolocation, civic location, AP group identifi= er, etc.

13.&nbs= p;   Sect. 3.1: Ho= w is the XML encoding represented?

14.&nbs= p;   “as ide= ntifier by an operator-identifier” -> “as identifier by an o= perator”

15.&nbs= p;   Reserved fiel= d description is missing (e.g. MUST be set to zero when sending and ignored= when received.)

16.&nbs= p;   Sect. 3.2: &#= 8220;2 octet integer” -> “2 octet unsigned integer”?

17.&nbs= p;   “left t= o implementation. )” (extra space before parenthesis)

18.&nbs= p;   Sect. 3.3: Ex= tra reserved field description

19.&nbs= p;   “It ind= icates the time in seconds before the MAG sends an update value of ANI mobi= lity options assuming ANI value changed”?

 <= /span>

 <= /b>

Kent

 

--_000_CD85F32117029D4F9AEF48BDEF5536AB4DED11F8xmbalnx03ciscoc_-- From nobody Mon Jul 28 07:40:23 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8E1A0292 for ; Mon, 28 Jul 2014 07:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZm6nHTZuts0 for ; Mon, 28 Jul 2014 07:40:20 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B2E1B2830 for ; Mon, 28 Jul 2014 07:40:19 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 21154D23112; Mon, 28 Jul 2014 16:40:18 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 16107D2307D; Mon, 28 Jul 2014 16:40:18 +0200 (CEST) Message-ID: <1406558418.4203.46.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "netext@ietf.org" Date: Mon, 28 Jul 2014 16:40:18 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-20844.007 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/-5AQGZMnd-sZnK-OmlhNnHkVdCQ Cc: Hidetoshi Yokota Subject: [netext] WG poll about including flow identification information in draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 28 Jul 2014 14:40:22 -0000 Hi, As discussed in Toronto, I'd like to poll the WG about one issue posted by Hidetoshi. He suggested to add back in the signaling flow identification information, so not only prefix information is exchanged (for routing purposes due to flow mobility). He pointed that the actual use cases would require more than just routing. For example, the new MAG might need to know which flow(s) is/are coming within that prefix to link it/them to proper QoS path(s) and optionally to inform the MN about it. My proposal is to also support the inclusion in the signaling flow identification options (ala RFC 6089). The consensus of the room was to do it. If you have any comment, especially is you don't agree, please say so by Thursday. I'd like to submit a new revision of the draft, ready for WGLC by the end of this week/beginning of next one. Thanks, Carlos From nobody Wed Jul 30 18:02:29 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EDD1A014E for ; Wed, 30 Jul 2014 18:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwgmtejT5JLx for ; Wed, 30 Jul 2014 18:02:27 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE5E1A016D for ; Wed, 30 Jul 2014 18:02:26 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so1980360wgh.25 for ; Wed, 30 Jul 2014 18:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZGp1ugf5Q3gFLu5AjjQTb+y6pIRoxWDDJUE5Gh+fpPY=; b=bbswqSTrnKCIkZMLKONM/92Q6cwZ/NvWSCGmWxKT17BWwbULUQF6NIWUY8qO7rlO8F saFrDdWHQczryC/CLK/WvkWEKMz8uohrbOM4XaftUrZmjfLE+7nGFheviB9A06ZDHgPk 4ZIDpj4m1VQQasAzWr0rpZWemZc1DnVH+RBm+LFxbUk1YbyDFcT2YY+Lch63ygTdaFSn bcsUD/GUCJ3lcyC67q+GyJCS7+bij+B/Ku7fY1fQ53nuRkPWlRuMQku75pGfh1wUurRh fCZgPIXZUA8nC0OLjweULZyc2I0U+7FAURm6cM1LGyYtIY7eGtluYkM16ToCNYuhESkX xqgA== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr10771706wiv.65.1406768545784; Wed, 30 Jul 2014 18:02:25 -0700 (PDT) Received: by 10.194.2.236 with HTTP; Wed, 30 Jul 2014 18:02:25 -0700 (PDT) Date: Wed, 30 Jul 2014 18:02:25 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f0473e75f04ff72d317 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Xh6AosQrFkGci9lL9Cn5vkT7YmU Subject: [netext] Interest to review the Logical Interface ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 31 Jul 2014 01:02:29 -0000 --f46d043c7f0473e75f04ff72d317 Content-Type: text/plain; charset=UTF-8 Hi, as discussed at the Toronto meeting, we are looking for at least three people who are interested in reviewing the ID: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-09 Please respond if you are interested, and Cc the chairs: netext-chairs@ietf.org Thanks. -Rajeev --f46d043c7f0473e75f04ff72d317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

as discussed at the = Toronto meeting, we are looking for at least three people who are intereste= d in reviewing the ID:=C2=A0http://tools.ietf.= org/html/draft-ietf-netext-logical-interface-support-09

Please respond if you are interested, and Cc the chairs= : netext-chairs= @ietf.org

Thanks.

-Ra= jeev


--f46d043c7f0473e75f04ff72d317-- From nobody Thu Jul 31 00:00:36 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92251A0377 for ; Thu, 31 Jul 2014 00:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7ctGIxM1d04 for ; Thu, 31 Jul 2014 00:00:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918F21A036F for ; Thu, 31 Jul 2014 00:00:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6V70Ras031854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jul 2014 07:00:27 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6V70QZh018784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 09:00:26 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 31 Jul 2014 09:00:21 +0200 Received: from DEMUMBX008.nsn-intra.net ([169.254.8.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0195.001; Thu, 31 Jul 2014 09:00:21 +0200 From: "Riegel, Maximilian (NSN - DE/Munich)" To: ext Rajeev Koodli , "netext@ietf.org" Thread-Topic: [netext] Interest to review the Logical Interface ID Thread-Index: AQHPrFscTKKvVctEEkWt/h/nMJ6nE5u5uwhQ Date: Thu, 31 Jul 2014 07:00:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.124] Content-Type: multipart/alternative; boundary="_000_CE3022AA8028FE4BA38A31768F1716BA06293634DEMUMBX008nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9726 X-purgate-ID: 151667::1406790027-000005B1-15288876/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/OkN7t4uNz3M1iTBBs2sjZpKtYtc Subject: Re: [netext] Interest to review the Logical Interface ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 31 Jul 2014 07:00:32 -0000 --_000_CE3022AA8028FE4BA38A31768F1716BA06293634DEMUMBX008nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBSYWplZXYsDQoNCk9ubHkgdmVyeSByZWNlbnRseSBieSBhIHByZXNlbnRhdGlvbiBpbiB0 aGUgSUVFRSA4MDIuMSBPbW5pUkFOIFRHIEkgYmVjYW1lIGF3YXJlIG9mIHRoaXMgSS1ELiBXaGVu IGdvaW5nIHRocm91Z2ggdGhlIHRleHQgSSBnb3QgaW5mb3JtYXRpb24gd2hpY2ggd291bGQgaGF2 ZSBiZWVuIGV4dHJlbWVseSB2YWx1YWJsZSBpbiBkaXNjdXNzaW9ucyB3aXRoIG1vYmlsZSBvcGVy YXRvcnMgbmVhcmx5IHR3byB5ZWFycyBhZ28gZXhwbGFpbmluZyB3aHkgaW5zdGFsbGF0aW9uIG9m IFMyYSBpbiB0aGUgbmV0d29yayBpcyBub3QgcHJvdmlkaW5nIHRoZSBzZWFtbGVzcyBjb25uZWN0 aXZpdHkgYmV0d2VlbiBXaS1GaSBhbmQgY2VsbHVsYXIgdGhleSB3ZXJlIGRlc3BlcmF0ZWx5IHNl ZWtpbmcgZm9yLiBJIG11c3QgYWRtaXQgaXQgd2FzIGEgZGlmZmljdWx0IGRpc2N1c3Npb24gYXMg bm90IG1hbnkgcGVvcGxlIGhhdmUgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgYm9yZGVybGlu ZSBiZXR3ZWVuIGxheWVyIDIgYW5kIGxheWVyIDMuDQoNClNhaWQgdGhpcywgSSBiZWxpZXZlIHRo ZSBkb2N1bWVudCBpcyBpbXBvcnRhbnQgdG8gYmUgY29tcGxldGVkIGFuZCBwdWJsaXNoZWQgYXMg UkZDLiDigJhjb21wbGV0ZWTigJkgYmVjYXVzZSBJTUhPIHRoZSBJLUQgaXMgbm90IHlldCBjb21w cmVoZW5zaXZlIGVub3VnaC4gSWYgeW91IGFyZSB3aWxsaW5nIHRvIHByb2NlZWQgd2l0aCB0aGUg ZG9jdW1lbnQgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHNwZW5kIGEgZmV3IGhvdXJzIG1vcmUgb24g aXQgYW5kIHByb3ZpZGUgYSBtb3JlIGNvbXByZWhlbnNpdmUgcmV2aWV3Lg0KDQpCeWUNCk1heA0K DQpGcm9tOiBuZXRleHQgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGV4dCBSYWplZXYgS29vZGxpDQpTZW50OiBUaHVyc2RheSwgSnVseSAzMSwgMjAxNCAwMzow Mg0KVG86IG5ldGV4dEBpZXRmLm9yZw0KU3ViamVjdDogW25ldGV4dF0gSW50ZXJlc3QgdG8gcmV2 aWV3IHRoZSBMb2dpY2FsIEludGVyZmFjZSBJRA0KDQoNCkhpLA0KDQphcyBkaXNjdXNzZWQgYXQg dGhlIFRvcm9udG8gbWVldGluZywgd2UgYXJlIGxvb2tpbmcgZm9yIGF0IGxlYXN0IHRocmVlIHBl b3BsZSB3aG8gYXJlIGludGVyZXN0ZWQgaW4gcmV2aWV3aW5nIHRoZSBJRDogaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtbG9naWNhbC1pbnRlcmZhY2Utc3VwcG9y dC0wOQ0KDQpQbGVhc2UgcmVzcG9uZCBpZiB5b3UgYXJlIGludGVyZXN0ZWQsIGFuZCBDYyB0aGUg Y2hhaXJzOiBuZXRleHQtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRleHQtY2hhaXJzQGlldGYu b3JnPg0KDQpUaGFua3MuDQoNCi1SYWplZXYNCg0KDQo= --_000_CE3022AA8028FE4BA38A31768F1716BA06293634DEMUMBX008nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRlYXIgUmFqZWV2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5P bmx5IHZlcnkgcmVjZW50bHkgYnkgYSBwcmVzZW50YXRpb24gaW4gdGhlIElFRUUgODAyLjEgT21u aVJBTiBURyBJIGJlY2FtZSBhd2FyZSBvZiB0aGlzIEktRC4gV2hlbiBnb2luZyB0aHJvdWdoIHRo ZSB0ZXh0IEkgZ290IGluZm9ybWF0aW9uIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBleHRyZW1lbHkN CiB2YWx1YWJsZSBpbiBkaXNjdXNzaW9ucyB3aXRoIG1vYmlsZSBvcGVyYXRvcnMgbmVhcmx5IHR3 byB5ZWFycyBhZ28gZXhwbGFpbmluZyB3aHkgaW5zdGFsbGF0aW9uIG9mIFMyYSBpbiB0aGUgbmV0 d29yayBpcyBub3QgcHJvdmlkaW5nIHRoZSBzZWFtbGVzcyBjb25uZWN0aXZpdHkgYmV0d2VlbiBX aS1GaSBhbmQgY2VsbHVsYXIgdGhleSB3ZXJlIGRlc3BlcmF0ZWx5IHNlZWtpbmcgZm9yLiBJIG11 c3QgYWRtaXQgaXQgd2FzIGEgZGlmZmljdWx0IGRpc2N1c3Npb24NCiBhcyBub3QgbWFueSBwZW9w bGUgaGF2ZSBnb29kIHVuZGVyc3RhbmRpbmcgb2YgdGhpcyBib3JkZXJsaW5lIGJldHdlZW4gbGF5 ZXIgMiBhbmQgbGF5ZXIgMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2FpZCB0aGlzLCBJ IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIGltcG9ydGFudCB0byBiZSBjb21wbGV0ZWQgYW5kIHB1 Ymxpc2hlZCBhcyBSRkMuIOKAmGNvbXBsZXRlZOKAmSBiZWNhdXNlIElNSE8gdGhlIEktRCBpcyBu b3QgeWV0IGNvbXByZWhlbnNpdmUgZW5vdWdoLiBJZiB5b3UgYXJlIHdpbGxpbmcNCiB0byBwcm9j ZWVkIHdpdGggdGhlIGRvY3VtZW50IEkgd291bGQgYmUgd2lsbGluZyB0byBzcGVuZCBhIGZldyBo b3VycyBtb3JlIG9uIGl0IGFuZCBwcm92aWRlIGEgbW9yZSBjb21wcmVoZW5zaXZlIHJldmlldy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBuZXRleHQgW21haWx0bzpuZXRl eHQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ZXh0IFJhamVldiBLb29k bGk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgMDM6MDI8YnI+DQo8 Yj5Ubzo8L2I+IG5ldGV4dEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbmV0ZXh0XSBJ bnRlcmVzdCB0byByZXZpZXcgdGhlIExvZ2ljYWwgSW50ZXJmYWNlIElEPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXMgZGlzY3Vzc2VkIGF0IHRoZSBUb3JvbnRvIG1l ZXRpbmcsIHdlIGFyZSBsb29raW5nIGZvciBhdCBsZWFzdCB0aHJlZSBwZW9wbGUgd2hvIGFyZSBp bnRlcmVzdGVkIGluIHJldmlld2luZyB0aGUgSUQ6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtbG9naWNhbC1pbnRlcmZhY2Utc3VwcG9y dC0wOSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbmV0ZXh0LWxvZ2ljYWwtaW50ZXJmYWNlLXN1cHBvcnQtMDk8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSByZXNwb25kIGlm IHlvdSBhcmUgaW50ZXJlc3RlZCwgYW5kIENjIHRoZSBjaGFpcnM6IDxhIGhyZWY9Im1haWx0bzpu ZXRleHQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpuZXRleHQtY2hhaXJzQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi1SYWplZXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE3022AA8028FE4BA38A31768F1716BA06293634DEMUMBX008nsnin_--