From denghui02@hotmail.com Thu Sep 6 17:34:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2E621F86AB for ; Thu, 6 Sep 2012 17:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5jNj9ooQjFE for ; Thu, 6 Sep 2012 17:34:03 -0700 (PDT) Received: from col0-omc2-s7.col0.hotmail.com (col0-omc2-s7.col0.hotmail.com [65.55.34.81]) by ietfa.amsl.com (Postfix) with ESMTP id E663521F86A8 for ; Thu, 6 Sep 2012 17:34:02 -0700 (PDT) Received: from COL125-W46 ([65.55.34.72]) by col0-omc2-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Sep 2012 17:34:02 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_98b162b6-e569-4621-993f-5c8e32b64855_" X-Originating-IP: [221.130.253.135] From: Hui Deng To: Date: Fri, 7 Sep 2012 08:34:02 +0800 Importance: Normal In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 00:34:02.0418 (UTC) FILETIME=[7AA14120:01CD8C90] Subject: [mif] FW: Help the NomCom: Nominations and Feedback X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:34:03 -0000 --_98b162b6-e569-4621-993f-5c8e32b64855_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Please help > From: nomcom-chair@ietf.org > To: wgchairs@ietf.org > Subject: Help the NomCom: Nominations and Feedback > Date: Wed, 5 Sep 2012 17:21:29 -0700 > > The IETF Nominations Committee (NomCom) is currently seeking > nominations for individuals to serve on the IESG, IAB, and IAOC. > Additionally, this is an announcement that the NomCom is seeking > feedback on individuals who have accepted nominations for IETF > leadership positions. > > It is very important to the NomCom process that we get input from a > broad spectrum of the community. Therefore, in case members of your > working group do not read the IETF announcement and discussion lists, > the NomCom would appreciate your help in disseminating the following > information. > > The NomCom website contains information about this year's NomCom > including the positions we are seeking to fill, and the qualifications > required for these positions: > > https://www.ietf.org/group/nomcom/2012/ > > The NomCom is accepting nominations until September 24. Nominations > for any position can be made using the following web tool: > > https://www.ietf.org/group/nomcom/2012/nominate > > Feedback about individuals who the NomCom is considering can be > providing using the following web tool: > > https://www.ietf.org/group/nomcom/2012/input > > The feedback tool provides a list of individuals who have agreed to be > considered for each position. We will be updating this list in the coming > weeks as more individuals accept nominations. > > Feedback provided to the NomCom is kept strictly confidential! > > Note that use of the NomCom web tools require an ietf.org (i.e., > datatracker) account. You can create an ietf.org account by visiting the > following URL: > > https://datatracker.ietf.org/accounts/create/ > > As an alternative to using the web tools, you can send email to the > NomCom at nomcom12@ietf.org to make a nomination or provide input to > the committee. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org --_98b162b6-e569-4621-993f-5c8e32b64855_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Please help
 
> From: nomcom-chair@ietf.org
> To: wgchairs@ietf.org
> Subject: Help the NomCom: Nominations and Feedback
> Date: Wed, 5 Sep 2012 17:21:29 -0700
>
> The IETF Nominations Committee (NomCom) is currently seeking
> nominations for individuals to serve on the IESG, IAB, and IAOC.
> Additionally, this is an announcement that the NomCom is seeking
> feedback on individuals who have accepted nominations for IETF
> leadership positions.
>
> It is very important to the NomCom process that we get input from a
> broad spectrum of the community. Therefore, in case members of your
> working group do not read the IETF announcement and discussion lists,
> the NomCom would appreciate your help in disseminating the following
> information.
>
> The NomCom website contains information about this year's NomCom
> including the positions we are seeking to fill, and the qualifications
> required for these positions:
>
> https://www.ietf.org/group/nomcom/2012/
>
> The NomCom is accepting nominations until September 24. Nominations
> for any position can be made using the following web tool:
>
> https://www.ietf.org/group/nomcom/2012/nominate
>
> Feedback about individuals who the NomCom is considering can be
> providing using the following web tool:
>
> https://www.ietf.org/group/nomcom/2012/input
>
> The feedback tool provides a list of individuals who have agreed to be
> considered for each position. We will be updating this list in the coming
> weeks as more individuals accept nominations.
>
> Feedback provided to the NomCom is kept strictly confidential!
>
> Note that use of the NomCom web tools require an ietf.org (i.e.,
> datatracker ) account. You can create an ietf.org account by visiting the
> following URL:
>
> https://datatracker.ietf.org/accounts/create/
>
> As an alternative to using the web tools, you can send email to the
> NomCom at nomcom12@ietf.org to make a nomination or provide input to
> the committee.
>
> Thank you for your help,
> - Matt Lepinski
> nomcom-chair@ietf.org
--_98b162b6-e569-4621-993f-5c8e32b64855_-- From alexandru.petrescu@gmail.com Thu Sep 20 02:35:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF41321F8773 for ; Thu, 20 Sep 2012 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl6TO8-EHXKw for ; Thu, 20 Sep 2012 02:35:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id D535721F8704 for ; Thu, 20 Sep 2012 02:35:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q8K9ZXWI018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Sep 2012 11:35:33 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q8K9ZW5Z008774 for ; Thu, 20 Sep 2012 11:35:32 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q8K9ZVZH018988 for ; Thu, 20 Sep 2012 11:35:32 +0200 Message-ID: <505AE364.2010000@gmail.com> Date: Thu, 20 Sep 2012 11:35:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Announcing DRLO v2 draft-mouton-mif-dhcpv6-drlo-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:35:36 -0000 Hello participants to MIF WG, We have just posted a new version of draft-mouton-mif-dhcpv6-drlo-02.txt: http://tools.ietf.org/html/draft-mouton-mif-dhcpv6-drlo-02 There are several changes: - added three use-cases: large mobility network, Mi-Fi coverage extension and M2M constrained device. - stressing its experimental characteristics, implementation. - rephrasing abstract and other textual cleanup. - expanded authorship. I would like to ask for feedback - what do you think about this draft? Thanks in advance, Alex > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Default Router List Option for DHCPv6 (DRLO) > Author(s) : Alexandru Petrescu Kostas Pentikousis Christophe > Janneteau Maximilien Mouton Filename : > draft-mouton-mif-dhcpv6-drlo-02.txt Pages : 17 Date > : 2012-09-19 > > Abstract: This document specifies an experimental DHCPv6 default > route option which provisions static routing information to client > nodes. The option facilitates central configuration of a > multi-access client node's default router list with the IPv6 address, > MAC address, and lifetime of the route, which is preferred in certain > multi-access network environments. In addition, the DHCP option > defined in this document can provide operational simplicity in > network coverage extension scenarios using inexpensive (and limited > resource) consumer-grade equipment. Finally, the proposed DHCP > option has been implemented and tested in practice; its experimental > use points to benefits with respect to reduced signaling and energy > consumption compared to existing default route configuration > mechanisms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mouton-mif-dhcpv6-drlo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mouton-mif-dhcpv6-drlo-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-mouton-mif-dhcpv6-drlo-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From pierrick.seite@orange.com Thu Sep 20 05:30:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A621F87EE for ; Thu, 20 Sep 2012 05:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ndv3bpeWVEQ for ; Thu, 20 Sep 2012 05:30:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72821F87E1 for ; Thu, 20 Sep 2012 05:30:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 280D32DC174 for ; Thu, 20 Sep 2012 14:30:33 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 085FB23811A for ; Thu, 20 Sep 2012 14:30:33 +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.02.0298.004; Thu, 20 Sep 2012 14:30:32 +0200 From: To: "'mif@ietf.org'" Thread-Topic: application of MIF API Thread-Index: Ac2XK7l5cOKhMTb8Sf6zUwgyUwQUbg== Date: Thu, 20 Sep 2012 12:30:32 +0000 Message-ID: <20576_1348144233_505B0C69_20576_1084_1_81C77F07008CA24F9783A98CFD706F71038D94@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [mif] application of MIF API X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:30:35 -0000 Hello, We have posted a new document dealing with the application of the MIF API.= This I-D is a discussion paper trying to figure out how a connection mana= ger may use the MIF API. It must be clear that the goal is _not_ to speci= fy a connection manager but to focus on the interface between the MIF API a= nd the connection manager. The draft also discusses the interaction betwee= n the MIF API and the 802.21 MIH abstraction layer.=20 The URL is: http://www.ietf.org/internet-drafts/draft-seite-mif-cm-00.txt= =20 The goal of this draft is only to illustrate the use of MIF API and, in -0= 0, we made the choice to not change the MIF API. However, we think that th= e MIF API should be the unique interface for manipulation of IP objects. If= we go in this direction, it would lead to introduce new messages for the M= IF API (e.g. for routing configuration). So, this I-D includes couple of d= iscussion points on which we would like to have the feedback from the WG. Q= uoting the main questions: - Should the MIF API be the unique API for manipulation of IP object? - If yes, should the MIF API be upgraded? BR, Pierrick and Juan-Carlos ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From pierrick.seite@orange.com Tue Sep 25 08:36:55 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E686721F8805 for ; Tue, 25 Sep 2012 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDjVGD6OeNS6 for ; Tue, 25 Sep 2012 08:36:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA121F87F8 for ; Tue, 25 Sep 2012 08:36:54 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DA3AB3B44B0; Tue, 25 Sep 2012 17:36:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BEEA327C0B2; Tue, 25 Sep 2012 17:36:51 +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.02.0298.004; Tue, 25 Sep 2012 17:36:51 +0200 From: To: 'Ted Lemon' , Dapeng Liu Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbw== Date: Tue, 25 Sep 2012 15:36:51 +0000 Message-ID: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.25.145415 Cc: "'mif@ietf.org'" Subject: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:36:56 -0000 Hi Ted, Dapeng, I have few questions about draft-ietf-mif-api-extension: A subscriber can subscribe to configuration element and address announcemen= ts (respectively sections 3.5.9 and 3.5.13); however a subscriber cannot un= subscribe, i.e. neither "Stop announcing configuration element" nor "Stop a= nnouncing address" are specified in the I-D. Is there a reason to this? In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going away" a= nd "interface is going up". However, according to examples given (interface= s switched on/off) these notification messages are sent when the interface = is already down or up. So, I think "is going" is confusing here, maybe thes= e messages should be "interface down" and "interface up", right? What is the difference between notifications "interface is going down/up" (= sections 3.5.23.4 and 3.5.23.5) and interface announcement/no interface ann= ouncement in section 3.5.3 and 3.5.4? IMHO, the application subscribes to = interface announcement and resulting announcements are the same as "interfa= ce is going down/up", so I think there no need for specific messages 3.5.23= .4 and 3.5.23.5. We have a "get configuration data", shouldn't we have a "set configuration = data" as well? Br, Pierrick ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ted.Lemon@nominum.com Tue Sep 25 08:54:15 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310AF21F8809 for ; Tue, 25 Sep 2012 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS+bz4pz4Lrp for ; Tue, 25 Sep 2012 08:54:14 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 761CA21F87E4 for ; Tue, 25 Sep 2012 08:54:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUGHTptV0VK8rcaPocn61/r2iEvXNtaXP@postini.com; Tue, 25 Sep 2012 08:54:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9EDE31B8306 for ; Tue, 25 Sep 2012 08:54:13 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 950AF19005C; Tue, 25 Sep 2012 08:54:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 25 Sep 2012 08:54:08 -0700 From: Ted Lemon To: " " Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+A Date: Tue, 25 Sep 2012 15:54:07 +0000 Message-ID: References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dapeng Liu , "mif@ietf.org" Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:54:15 -0000 On Sep 25, 2012, at 11:36 AM, wrote: > A subscriber can subscribe to configuration element and address announcem= ents (respectively sections 3.5.9 and 3.5.13); however a subscriber cannot = unsubscribe, i.e. neither "Stop announcing configuration element" nor "Stop= announcing address" are specified in the I-D. Is there a reason to this? No, I think it's an oversight. > In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going away"= and "interface is going up". However, according to examples given (interfa= ces switched on/off) these notification messages are sent when the interfac= e is already down or up. So, I think "is going" is confusing here, maybe th= ese messages should be "interface down" and "interface up", right? This section needs work. There actually should be a notification that the= interface is still up but that the system intends to take it down; there s= hould be another when it is in fact down. > What is the difference between notifications "interface is going down/up"= (sections 3.5.23.4 and 3.5.23.5) and interface announcement/no interface a= nnouncement in section 3.5.3 and 3.5.4? IMHO, the application subscribes t= o interface announcement and resulting announcements are the same as "inter= face is going down/up", so I think there no need for specific messages 3.5.= 23.4 and 3.5.23.5. Interface announce just announces the presence of an interface that may hav= e identity associations. Typically when an application starts, there will= already be a set of interfaces; as soon as the application subscribes to t= he interface announcement message, it will get an announcement for each suc= h interface. > We have a "get configuration data", shouldn't we have a "set configuratio= n data" as well? No, I don't think so. Configuration data comes from either on-host, stati= c configuration, or from dynamic protocols like RA and DHCP. What would b= e the context for an application pushing configuration information up? Th= is just sounds like an attack vector to me=97a malicious app could capture = traffic from another app by gaming the configuration settings.= From pierrick.seite@orange.com Wed Sep 26 01:27:25 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B9C21F87BC for ; Wed, 26 Sep 2012 01:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0ABUIFhxHzR for ; Wed, 26 Sep 2012 01:27:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0321F87B5 for ; Wed, 26 Sep 2012 01:27:24 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BF3422DC3D6; Wed, 26 Sep 2012 10:27:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 993714C0CD; Wed, 26 Sep 2012 10:27:22 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 10:27:22 +0200 From: To: 'Ted Lemon' Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+AABF870A= Date: Wed, 26 Sep 2012 08:27:22 +0000 Message-ID: <23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.26.55415 Cc: "'mif@ietf.org'" Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:27:25 -0000 Hi Ted, Thanks for super fast answer :-) please see inline for comments. Pierrick > -----Message d'origine----- > De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Envoy=E9=A0: mardi 25 septembre 2012 17:54 > =C0=A0: SEITE Pierrick RD-RESA > Cc=A0: Dapeng Liu; mif@ietf.org > Objet=A0: Re: questions on draft-ietf-mif-api-extension >=20 > On Sep 25, 2012, at 11:36 AM, > wrote: > > A subscriber can subscribe to configuration element and address > announcements (respectively sections 3.5.9 and 3.5.13); however a > subscriber cannot unsubscribe, i.e. neither "Stop announcing > configuration element" nor "Stop announcing address" are specified in > the I-D. Is there a reason to this? >=20 > No, I think it's an oversight. >=20 > > In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going > away" and "interface is going up". However, according to examples given > (interfaces switched on/off) these notification messages are sent when > the interface is already down or up. So, I think "is going" is > confusing here, maybe these messages should be "interface down" and > "interface up", right? >=20 > This section needs work. There actually should be a notification that > the interface is still up but that the system intends to take it down; > there should be another when it is in fact down. >=20 Ok, I see. I agree, we need Interface_going_down and Interface_going_up to= "prepare" the application for a future change of the interface status. We also need for reactive notifications Interface_down (the interface went = down suddenly, e.g loss of wi-fi coverage, user switched off the interface)= and Interface_up. Here, I guess it can be done with "Interface announcemen= t" and "no Interface announcement", right? > > What is the difference between notifications "interface is going > down/up" (sections 3.5.23.4 and 3.5.23.5) and interface announcement/no > interface announcement in section 3.5.3 and 3.5.4? IMHO, the > application subscribes to interface announcement and resulting > announcements are the same as "interface is going down/up", so I think > there no need for specific messages 3.5.23.4 and 3.5.23.5. >=20 > Interface announce just announces the presence of an interface that may > have identity associations. Typically when an application starts, > there will already be a set of interfaces; as soon as the application > subscribes to the interface announcement message, it will get an > announcement for each such interface. >=20 Ok, understood. > > We have a "get configuration data", shouldn't we have a "set > configuration data" as well? >=20 > No, I don't think so. Configuration data comes from either on-host, > static configuration, or from dynamic protocols like RA and DHCP. > What would be the context for an application pushing configuration > information up?=20=20 I'm thinking about the case where the application is a connection manager. = After making a decision, e.g. regarding the mapping of a flow to a given in= terface, the connection manager needs to associate a routing table to the f= low, configure NAT, modify firewall rules and policy table for source addre= ss selection,...=20 This just sounds like an attack vector to me-a > malicious app could capture traffic from another app by gaming the > configuration settings. Well, currently, connection managers can leverage on kernel tools (e.g. Lin= ux/iptables) to dynamically influence the configuration. So, if we consider= that the MIF API should be the unique interface for manipulation of IP obj= ects, IMHO, "set configuration" should be part of the MIF API services.=20= =09 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ted.Lemon@nominum.com Wed Sep 26 05:54:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622E921F86D8 for ; Wed, 26 Sep 2012 05:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhGiMzZIWQGs for ; Wed, 26 Sep 2012 05:54:39 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D94CC21F86CB for ; Wed, 26 Sep 2012 05:54:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUGL7DpODZKVQeFSv5Md/yedUDDblOBWk@postini.com; Wed, 26 Sep 2012 05:54:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DA1E51B8058 for ; Wed, 26 Sep 2012 05:54:37 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D0B5419005C; Wed, 26 Sep 2012 05:54:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 05:54:37 -0700 From: Ted Lemon To: " " Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+AABF870AAGojRgA== Date: Wed, 26 Sep 2012 12:54:37 +0000 Message-ID: <604144AF-FA1F-4D42-9428-34A31E88C7B0@nominum.com> References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8903664C398A104E86D714ED4069BED1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:54:40 -0000 On Sep 26, 2012, at 4:27 AM, wrote: > We also need for reactive notifications Interface_down (the interface wen= t down suddenly, e.g loss of wi-fi coverage, user switched off the interfac= e) and Interface_up. Here, I guess it can be done with "Interface announcem= ent" and "no Interface announcement", right? Yes. Of course, the fact that you are asking these questions means that t= he document needs work! > I'm thinking about the case where the application is a connection manager= . After making a decision, e.g. regarding the mapping of a flow to a given = interface, the connection manager needs to associate a routing table to the= flow, configure NAT, modify firewall rules and policy table for source add= ress selection,...=20 Yes, if you want to implement a connection manager, you will need additiona= l API functionality. When we originally scoped the document, we assumed t= hat the connection manager was implicitly *part* of the MIF API, rather tha= n a customer of it. Of course the expectation is that some parts of the M= IF API would be usable by the connection manager, but that the connection m= anager would require an extensively richer API. I think in this discussion that it's important to think about who could ben= efit from the document. It sounds like you have a wish to have a document= that would allow you to implement a connection manager, perhaps one that c= ould show the same behavior across different handsets produced by different= manufacturers. If that's your motivation, it's certainly a valid use cas= e for a MIF API. However, when we originally scoped this, we were not including that as part= of the intended set of users for the documents=97we were specifically targ= eting applications. Part of the reason for this was the understanding tha= t most existing devices that we had in mind (e.g., iOS devices and Android = devices) already had a pretty complete connection manager function, and tha= t we didn't have the expertise to tell Apple or Google how to do a connecti= on manager=97that was expertise that they had already developed in-house, a= nd we would expect substantial resistance to us trying to get them to actua= lly do an API like that. That's not to say that such an API is a bad idea, but it's definitely scope= creep for the work we are doing now. If you are interested in having an = API with this functionality, I would argue that it ought to be presented as= a supplementary API to the current document, rather than being added on to= the current document. Otherwise, I don't think we have any hope of compl= eting the current document in a timely manner (it could be argued that we h= ave already failed to do so).=20 What I would encourage you to do if you want to go down this path is think = about the current document in terms of what it might _prevent_ you from doi= ng in the supplementary document, and ask us to fix those bits. From pierrick.seite@orange.com Wed Sep 26 06:36:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5021F885A for ; Wed, 26 Sep 2012 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl2XVV1pFolB for ; Wed, 26 Sep 2012 06:36:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7921F882D for ; Wed, 26 Sep 2012 06:36:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 392B32644E8; Wed, 26 Sep 2012 15:36:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1AFD92380A7; Wed, 26 Sep 2012 15:36:40 +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.02.0298.004; Wed, 26 Sep 2012 15:36:39 +0200 From: To: 'Ted Lemon' Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+AABF870AAGojRgAAN6BQg Date: Wed, 26 Sep 2012 13:36:39 +0000 Message-ID: <7356_1348666600_506304E8_7356_6703_1_81C77F07008CA24F9783A98CFD706F7103A1D0@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <604144AF-FA1F-4D42-9428-34A31E88C7B0@nominum.com> In-Reply-To: <604144AF-FA1F-4D42-9428-34A31E88C7B0@nominum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.26.111518 Cc: "mif@ietf.org" Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:36:42 -0000 > -----Message d'origine----- > De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Envoy=E9=A0: mercredi 26 septembre 2012 14:55 > =C0=A0: SEITE Pierrick RD-RESA > Cc=A0: mif@ietf.org > Objet=A0: Re: questions on draft-ietf-mif-api-extension >=20 > On Sep 26, 2012, at 4:27 AM, > wrote: > > We also need for reactive notifications Interface_down (the interface > went down suddenly, e.g loss of wi-fi coverage, user switched off the > interface) and Interface_up. Here, I guess it can be done with > "Interface announcement" and "no Interface announcement", right? >=20 > Yes. Of course, the fact that you are asking these questions means > that the document needs work! >=20 Sorry for asking stupid question :-) but I just want to be sure to understa= nd correctly the current MIF API :-)=20 > > I'm thinking about the case where the application is a connection > manager. After making a decision, e.g. regarding the mapping of a flow > to a given interface, the connection manager needs to associate a > routing table to the flow, configure NAT, modify firewall rules and > policy table for source address selection,... >=20 > Yes, if you want to implement a connection manager, you will need > additional API functionality. When we originally scoped the document, > we assumed that the connection manager was implicitly *part* of the MIF > API, rather than a customer of it. Of course the expectation is that > some parts of the MIF API would be usable by the connection manager, > but that the connection manager would require an extensively richer > API. >=20=09 > I think in this discussion that it's important to think about who could > benefit from the document. It sounds like you have a wish to have a > document that would allow you to implement a connection manager, > perhaps one that could show the same behavior across different handsets > produced by different manufacturers. If that's your motivation,=20 Exactly :-) it's > certainly a valid use case for a MIF API. >=20 > However, when we originally scoped this, we were not including that as > part of the intended set of users for the documents-we were > specifically targeting applications. Part of the reason for this was > the understanding that most existing devices that we had in mind (e.g., > iOS devices and Android devices) already had a pretty complete > connection manager function, and that we didn't have the expertise to > tell Apple or Google how to do a connection manager-that was expertise > that they had already developed in-house, and we would expect > substantial resistance to us trying to get them to actually do an API > like that. >=20=09 I couldn't agree more. My intention is clearly not to specify a connection = manager in MIF. I'm trying to figure out what services/messages, from the MIF API (or MIF A= PI+ OS API), can be useful for connection manager developers.=20 > That's not to say that such an API is a bad idea, but it's definitely > scope creep for the work we are doing now. If you are interested in > having an API with this functionality, I would argue that it ought to > be presented as a supplementary API to the current document, rather > than being added on to the current document.=20=20=20 Actually, Juan-Carlos and myself have submitted a discussion draft to addre= ss this point. Now, I understand better the purpose of the MIF API and we n= eed to revise according to your feedback. Hopefully, we'll be ready to disc= uss it at the next IETF. > Otherwise, I don't think we have any hope of completing the current docum= ent in a timely manner > (it could be argued that we have already failed to do so). >=20 > What I would encourage you to do if you want to go down this path is > think about the current document in terms of what it might _prevent_ > you from doing in the supplementary document, and ask us to fix those > bits. I see. Thanks again for your feedback. Pierrick ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ted.Lemon@nominum.com Wed Sep 26 07:31:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C023221F86DC for ; Wed, 26 Sep 2012 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvmQQMzUbPNc for ; Wed, 26 Sep 2012 07:31:43 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id D711D21F86E5 for ; Wed, 26 Sep 2012 07:31:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUGMRzm2p5bP8aO+cbdbMi4MuWGUHPecw@postini.com; Wed, 26 Sep 2012 07:31:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 396C11B829C for ; Wed, 26 Sep 2012 07:31:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3184A19005C; Wed, 26 Sep 2012 07:31:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 07:31:42 -0700 From: Ted Lemon To: " " Thread-Topic: questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+AABF870AAGojRgAAN6BQg//+r3wA= Date: Wed, 26 Sep 2012 14:31:42 +0000 Message-ID: <98C5D681-7EE7-459C-A967-AA56615F3395@nominum.com> References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <604144AF-FA1F-4D42-9428-34A31E88C7B0@nominum.com> <7356_1348666600_506304E8_7356_6703_1_81C77F07008CA24F9783A98CFD706F7103A1D0@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <7356_1348666600_506304E8_7356_6703_1_81C77F07008CA24F9783A98CFD706F7103A1D0@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6F90385644187349B2990166C717C952@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 14:31:43 -0000 On Sep 26, 2012, at 9:36 AM, wrote: > Actually, Juan-Carlos and myself have submitted a discussion draft to add= ress this point. Now, I understand better the purpose of the MIF API and we= need to revise according to your feedback. Hopefully, we'll be ready to di= scuss it at the next IETF. Yup, I was happy to see that, but haven't had time to read it yet. If you= get a new version out before the next IETF, I'll be ready to discuss it wi= th you there. :)