From tsirtsis@googlemail.com Mon Nov 2 02:05:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000E33A68BB for ; Mon, 2 Nov 2009 02:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U+QDiwGb4xJ for ; Mon, 2 Nov 2009 02:05:20 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6353B3A67E1 for ; Mon, 2 Nov 2009 02:05:18 -0800 (PST) Received: by bwz23 with SMTP id 23so6100537bwz.29 for ; Mon, 02 Nov 2009 02:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=2N1DWNSlk+5HbSs7/AfZ+kke04pQXJ8q9ijJbPkW5Lg=; b=AGzeOm9m/F/yDSgNhmj0rkZqkxuwNnE0Rz7AXp9ioqKQKpL8V+20puoTe7jpom5LHV FW2nXs+z+4dK43z822Oa48fHPd/oOwVek498xtPqURLFeuHXPiA9IoS2sIKmqRkLSwFT QdGz5TY0GKrOeLZV9dbXlC2i4iMsYUiMe66zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NHBMybwllbpXxQsgzkX90DWei7CSENdvHwqlS740+J6CWK5klL2JUHL9Dw8nB1Z5Ce OMDY08cgJ6CUrpoI2v8SlZCLSlKuyRNy0kGwB0U2LTY9WoxIz/VlQNa+5D0Bu0nqZjuI Swd8ATIFKW1oiZW0p/ThvFQmQUzp247SwzhJ4= MIME-Version: 1.0 Received: by 10.239.142.155 with SMTP id g27mr523573hba.62.1257156334681; Mon, 02 Nov 2009 02:05:34 -0800 (PST) Date: Mon, 2 Nov 2009 10:05:34 +0000 Message-ID: From: George Tsirtsis To: IETF MEXT WG ML , draft-ietf-mext-flow-binding@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 10:05:21 -0000 Hi all, Thanks a lot for the many detailed online reviews during the WGLC as well as a number of reviews and suggestions received off-line. Although the reviews allowed us to clarify a number of issues, no significant changes had to be made to the protocol. I have updated the draft but since I missed the deadline I posted it here: http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt I will post this officially as soon as the Editor starts accepting I-Ds. Regards George From tsirtsis@googlemail.com Mon Nov 2 03:07:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1713A6A09 for ; Mon, 2 Nov 2009 03:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QipnUp67gqI for ; Mon, 2 Nov 2009 03:07:01 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 40CFD3A6A07 for ; Mon, 2 Nov 2009 03:07:01 -0800 (PST) Received: by ewy18 with SMTP id 18so4268979ewy.43 for ; Mon, 02 Nov 2009 03:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=TsXtd0AJlJTiwgHHoJEBnoyKLeu1TNMHeGeb/ST5l5I=; b=FOw9ZvVRbFoWrxwJy5PNfTd57bIqr7Yk0alKHDZdiERUbbxMiQRn9eWjC4PmAZ/LWQ y8lsR4oehIXvRNOjpzrV62DhL+oWIAKgG9K3+uI0qgeFW8PG+8LfUtLz7x7CniJbuwIw AmOO4QreIIY3HEqroBuiLvp8gOEJ8Eg4rntz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Gy+TdO+yA1CQBFyM9XpFo9VBpjzXsDS6ZZ1lyP0q8RzCyApW7FIiUW2szp5zyaeQdd lsdjRRo93pVcEmC9KRnBI4422VZ6fUz9EIeZDoc++jxgx6YmQQpmQvNAG40etgu/WRZv XdOMnVV8ywee9RQFwsu/7mu1WxBpYmfXlP/Ts= MIME-Version: 1.0 Received: by 10.239.158.7 with SMTP id s7mr552523hbc.53.1257160037491; Mon, 02 Nov 2009 03:07:17 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2009 11:07:17 +0000 Message-ID: From: George Tsirtsis To: IETF MEXT WG ML , draft-ietf-mext-flow-binding@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 11:07:02 -0000 I do not exactly follow you but the "0" values are already reserved for all of these, and for FID and FID-PRI, "MUST NOT be used" is indicated. George On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis wrote: > Hi all, > > Thanks a lot for the many detailed online reviews during the WGLC as > well as a number of reviews and suggestions received off-line. > Although the reviews allowed us to clarify a number of issues, no > significant changes had to be made to the protocol. > > I have updated the draft but since I missed the deadline I posted it here: > http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt > > I will post this officially as soon as the Editor starts accepting I-Ds. > > Regards > George > From tsirtsis@googlemail.com Mon Nov 2 13:04:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA8C3A6767 for ; Mon, 2 Nov 2009 13:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS5amew8hK57 for ; Mon, 2 Nov 2009 13:04:28 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id 406AF3A67D1 for ; Mon, 2 Nov 2009 13:04:19 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so683668gvc.15 for ; Mon, 02 Nov 2009 13:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=C2oycRrY1P7u4LGeRot+/npuSC6H5zTEszssx2/nk90=; b=rxqMzsCvZUMvT5yHQmpymK4chrPbhm7ldaDPem1jq1/EjcfM70UJl8XwOCsAWNTG40 gCbTn0k7ZZollkNkNuxhE7uHgSWta8M/LebAxMOG+nqZREXJEAnfMV0TfUo3OaT3iNii gSH8uHE/kcs/xbOp1hLJCtVste/zPiFAk178o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=X41QMKClTiD34RVQ4x1Lssm05V1DeG/ic36bZ2ixAds6Y+V3TPG8f+lFqEknEXmEzD kh9mt4R03q6rJ95tUtdJnaMAsYbneCW+bqbgSnunLUxmWLESnEJW/v27Jo16aako0lMW 3Zsp/Tse8OqlJ7W8A1i5jjqmO2vC3RNvvodl8= MIME-Version: 1.0 Received: by 10.239.145.5 with SMTP id q5mr591397hba.89.1257195874494; Mon, 02 Nov 2009 13:04:34 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2009 21:04:34 +0000 Message-ID: From: George Tsirtsis To: IETF MEXT WG ML , draft-ietf-mext-flow-binding@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:04:29 -0000 Someone pointed out to me that my e-mail below does not seem to include the original question. My e-mail was a response to a question sent to me personally but somehow I managed to respond to the mailing list.instead....well no harm done I think. George On Mon, Nov 2, 2009 at 11:07 AM, George Tsirtsis wrote: > I do not exactly follow you but the "0" values are already reserved > for all of these, and for FID and FID-PRI, "MUST NOT be used" is > indicated. > > George > > On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis > wrote: >> Hi all, >> >> Thanks a lot for the many detailed online reviews during the WGLC as >> well as a number of reviews and suggestions received off-line. >> Although the reviews allowed us to clarify a number of issues, no >> significant changes had to be made to the protocol. >> >> I have updated the draft but since I missed the deadline I posted it here: >> http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt >> >> I will post this officially as soon as the Editor starts accepting I-Ds. >> >> Regards >> George >> > From julienl@qualcomm.com Mon Nov 2 16:21:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177EB28C13C for ; Mon, 2 Nov 2009 16:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.467 X-Spam-Level: X-Spam-Status: No, score=-105.467 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBzKfX67zk9d for ; Mon, 2 Nov 2009 16:21:49 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2F86F3A62C1 for ; Mon, 2 Nov 2009 16:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1257207729; x=1288743729; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20|Date:=20Mon,=202=20Nov =202009=2016:22:04=20-0800|Subject:=20Slides=20for=20MEXT =20sessions=20@=20IETF-76|Thread-Topic:=20Slides=20for=20 MEXT=20sessions=20@=20IETF-76|Thread-Index:=20AcpaaFdM6T1 yqPCDSLeTimqhYMPGxQBsro5Q|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5790"=3B=20a=3D"26683719"; bh=H5o+eW7SBco9V7Jd94szK7CUHCtbx8tSsbQetOLO9jo=; b=xVJDXYYbduFWcZsc04U8cKMAmrGLHYTkq5hPpmUvYqxQGot4WYh5VTPJ +JGRtu9Vn3RRxo/X8q060nnNZ+j1MwMjZwXUkZ9kZDSCMGQgnyIvhnM5o ALZY5uscj9mTeTeuwnYef5p6MAf7tM/UF8r5n66+iIeDqHgM4suUWkUWu Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5790"; a="26683719" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2009 16:22:09 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nA30M8cs029283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2009 16:22:09 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nA30M3xs026441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Nov 2009 16:22:08 -0800 (PST) Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 2 Nov 2009 16:22:06 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 2 Nov 2009 16:22:06 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Mon, 2 Nov 2009 16:22:04 -0800 Thread-Topic: Slides for MEXT sessions @ IETF-76 Thread-Index: AcpaaFdM6T1yqPCDSLeTimqhYMPGxQBsro5Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] Slides for MEXT sessions @ IETF-76 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 00:21:50 -0000 Presenters, Could you please make sure that you send your slides to both Marcelo and me= at least 24 hours before the session into which you're scheduled to presen= t so that they can be uploaded on the meeting material server. =20 Thank you for your support. --julien & marcelo From conny.larsson@ericsson.com Tue Nov 3 00:37:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3543828C179 for ; Tue, 3 Nov 2009 00:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ba3cMCafMmk for ; Tue, 3 Nov 2009 00:37:37 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DB22B28C168 for ; Tue, 3 Nov 2009 00:37:36 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b2-4aefebe3ba70 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4E.F5.24026.3EBEFEA4; Tue, 3 Nov 2009 09:37:56 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:37:55 +0100 Received: from [127.0.0.1] ([153.88.45.177]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:37:55 +0100 Message-ID: <4AEFEBDE.6040903@ericsson.com> Date: Tue, 03 Nov 2009 09:37:50 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000605020400080908040308" X-OriginalArrivalTime: 03 Nov 2009 08:37:55.0285 (UTC) FILETIME=[F05EF050:01CA5C60] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 08:37:38 -0000 This is a multi-part message in MIME format. --------------000605020400080908040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi George, Well the idea was that it should be allowed to use for instance the "0" value and this should be interpreted as "this field is not used". As of today it says "MUST NOT be used" but I would like it to be treated as an allowed value. Regards Conny George Tsirtsis wrote: > I do not exactly follow you but the "0" values are already reserved > for all of these, and for FID and FID-PRI, "MUST NOT be used" is > indicated. > > George > > On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis > wrote: > >> Hi all, >> >> Thanks a lot for the many detailed online reviews during the WGLC as >> well as a number of reviews and suggestions received off-line. >> Although the reviews allowed us to clarify a number of issues, no >> significant changes had to be made to the protocol. >> >> I have updated the draft but since I missed the deadline I posted it here: >> http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt >> >> I will post this officially as soon as the Editor starts accepting I-Ds. >> >> Regards >> George >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------000605020400080908040308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi George,

Well the idea was that it should be allowed to use for instance the "0" value and this should be interpreted as "this field is not used". As of today it says "MUST NOT be used" but I would like it to be treated as an allowed value.

Regards
Conny

George Tsirtsis wrote: 
I do not exactly follow you but the "0" values are already reserved
for all of these, and for FID and FID-PRI, "MUST NOT be used" is
indicated.

George

On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis
<tsirtsis@googlemail.com> wrote:
  
Hi all,

Thanks a lot for the many detailed online reviews during the WGLC as
well as a number of reviews and suggestions received off-line.
Although the reviews allowed us to clarify a number of issues, no
significant changes had to be made to the protocol.

I have updated the draft but since I missed the deadline I posted it here:
http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt

I will post this officially as soon as the Editor starts accepting I-Ds.

Regards
George

    
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------000605020400080908040308-- From tsirtsis@googlemail.com Tue Nov 3 04:29:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A8E3A68DF for ; Tue, 3 Nov 2009 04:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUyrlxBHj+dd for ; Tue, 3 Nov 2009 04:29:45 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id EEAAC3A68DE for ; Tue, 3 Nov 2009 04:29:42 -0800 (PST) Received: by ewy3 with SMTP id 3so1896078ewy.37 for ; Tue, 03 Nov 2009 04:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=742VY2I5CH+o/tJIem/a4JydwVKW5Dekt+7a98istR4=; b=gZlMlj5GBUYpJ3s6HXYNOQ/BkOu0Lcd+N7MTlw4IRs7GM39P37rq+ZT9hnphxHKOh9 wYiPyzQ/9fgkDV/x2qrYQ9U0ryrUiLZKjYHrMK5G7gJOyUm4MzJuqH8i9fs9g6C9YEFu TgPdbbNGmLweCaG9cKC4a+mu0urdkmb15Jme4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NZWBGSGPnxJwrlXiiGQVU1QMGmatBxffpVPlEvNJyQS7o8bUnDpOAggrfjBqVDxYb0 jp0KX+z9pE7TG8fUn1kZX292qGs2+ccV9xBRo5bmNuUfyqejS4OzHJTBJgb9HLek2eKZ ks/D20JbcwjQaF4DFFQaketWu9O9XNdYBTik8= MIME-Version: 1.0 Received: by 10.239.143.219 with SMTP id l27mr780160hba.162.1257251398669; Tue, 03 Nov 2009 04:29:58 -0800 (PST) In-Reply-To: <4AEFEBDE.6040903@ericsson.com> References: <4AEFEBDE.6040903@ericsson.com> Date: Tue, 3 Nov 2009 12:29:58 +0000 Message-ID: From: George Tsirtsis To: Conny Larsson Content-Type: text/plain; charset=UTF-8 Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 12:29:46 -0000 Hi Conny, I updated http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt so that all of these are now marked as "Value "0" is reserved and SHOULD NOT be used". This seems to be the way it is handled in other RFCs since it allows a future document (or even an implementation that knows what it is doing) to overwrite it. I hope that is OK. George On Tue, Nov 3, 2009 at 8:37 AM, Conny Larsson wrote: > Hi George, > > Well the idea was that it should be allowed to use for instance the "0" > value and this should be interpreted as "this field is not used". As of > today it says "MUST NOT be used" but I would like it to be treated as an > allowed value. > > Regards > Conny > > George Tsirtsis wrote: > > I do not exactly follow you but the "0" values are already reserved > for all of these, and for FID and FID-PRI, "MUST NOT be used" is > indicated. > > George > > On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis > wrote: > > > Hi all, > > Thanks a lot for the many detailed online reviews during the WGLC as > well as a number of reviews and suggestions received off-line. > Although the reviews allowed us to clarify a number of issues, no > significant changes had to be made to the protocol. > > I have updated the draft but since I missed the deadline I posted it here: > http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt > > I will post this officially as soon as the Editor starts accepting I-Ds. > > Regards > George > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Tue Nov 3 05:12:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACCC3A68FA for ; Tue, 3 Nov 2009 05:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0fLZsyulVmS for ; Tue, 3 Nov 2009 05:12:56 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id A43C73A68EC for ; Tue, 3 Nov 2009 05:12:56 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so702804gvc.15 for ; Tue, 03 Nov 2009 05:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=YTONtHZr94+nv9p70+s5bOgAAc5mYV9TarPyWMFD7K4=; b=xEMQOdcZEGACMXWmX1eYX+63jwPwspBTja73hjuGPZDvGuXt1+Sa/S/WNN6/PX6set 5z9vNilk9/XAxOpaTDjH1gga5YN8Hl4RMTC5fot9dT2cGY2U53UoXNoncj7kUoKMajP0 kv99bamvwiItTvdyWYA1QiD9yjsZ64F0s8umE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oa1uQfaQT4LjnllZtKC939ZGw8DXP8pyxOQmvc+234DfoXNoau1sTYTP9avkGn/Zf4 E8zWYOMU9T+t1O18N3BvLUlNlwp2y2p6BSOqdhwNPzQnKAL+IRWTPjKwx5bEz81MKDXx yzHTOz4M4M5iVVy1zewmEudmn2GPerFdWi53M= MIME-Version: 1.0 Received: by 10.239.139.211 with SMTP id u19mr716711hbu.97.1257253993748; Tue, 03 Nov 2009 05:13:13 -0800 (PST) Date: Tue, 3 Nov 2009 13:13:13 +0000 Message-ID: From: George Tsirtsis To: IETF MEXT WG ML Content-Type: text/plain; charset=UTF-8 Subject: [MEXT] preview of binary traffic selectors v01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:12:57 -0000 Hi all, I updated the Binary TS draft to better match the new Flow Bindings drafts. You can preview the draft at: http://www.tsirtsis.com/draft-ietf-mext-binary-ts-pre_01.txt and I will post to the editor early next week. Comments always welcome. George From conny.larsson@ericsson.com Tue Nov 3 06:50:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F036B3A6A25 for ; Tue, 3 Nov 2009 06:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikRL7OzCrHoD for ; Tue, 3 Nov 2009 06:50:02 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2AF5B3A6959 for ; Tue, 3 Nov 2009 06:50:01 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-a3-4af0432d1e7a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 99.31.31706.D2340FA4; Tue, 3 Nov 2009 15:50:21 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 15:50:14 +0100 Received: from [127.0.0.1] ([153.88.44.89]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 15:50:14 +0100 Message-ID: <4AF04322.9@ericsson.com> Date: Tue, 03 Nov 2009 15:50:10 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: George Tsirtsis References: <4AEFEBDE.6040903@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 14:50:14.0197 (UTC) FILETIME=[F3666650:01CA5C94] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:50:04 -0000 Hi George, Yes, that sounds good. Thanks. Another thing. I have mentioned it several times but I will bring it up one last time. The length of the "Option Len" field in the "Flow Identification Mobility" option is in 8-octets units. But RFC3775, section 6.2.1, defines the Mobility Option "Option Length" field as an "8-bit unsigned integer, representing the length in octets of the mobility option, not including the Option Type and Option Length fields". Is there a reason for changing this convention, i.e. 8-octet units instead of octets? Regards Conny George Tsirtsis wrote: > Hi Conny, > > I updated http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt > so that all of these are now marked as "Value "0" is reserved and > SHOULD NOT be used". > > This seems to be the way it is handled in other RFCs since it allows a > future document (or even an implementation that knows what it is > doing) to overwrite it. > > I hope that is OK. > > George > > On Tue, Nov 3, 2009 at 8:37 AM, Conny Larsson > wrote: > >> Hi George, >> >> Well the idea was that it should be allowed to use for instance the "0" >> value and this should be interpreted as "this field is not used". As of >> today it says "MUST NOT be used" but I would like it to be treated as an >> allowed value. >> >> Regards >> Conny >> >> George Tsirtsis wrote: >> >> I do not exactly follow you but the "0" values are already reserved >> for all of these, and for FID and FID-PRI, "MUST NOT be used" is >> indicated. >> >> George >> >> On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis >> wrote: >> >> >> Hi all, >> >> Thanks a lot for the many detailed online reviews during the WGLC as >> well as a number of reviews and suggestions received off-line. >> Although the reviews allowed us to clarify a number of issues, no >> significant changes had to be made to the protocol. >> >> I have updated the draft but since I missed the deadline I posted it here: >> http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt >> >> I will post this officially as soon as the Editor starts accepting I-Ds. >> >> Regards >> George >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From tsirtsis@googlemail.com Tue Nov 3 07:18:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7707C3A69A5 for ; Tue, 3 Nov 2009 07:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LQbCe05ac6j for ; Tue, 3 Nov 2009 07:18:08 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 57A393A691D for ; Tue, 3 Nov 2009 07:18:08 -0800 (PST) Received: by mail-qy0-f203.google.com with SMTP id 41so3011967qyk.29 for ; Tue, 03 Nov 2009 07:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O5ElPPUPOQacaYONqvl9HI6a7v/g2YRtfVb5e2KxWkA=; b=uvRv8sRiTdxKHUTE0RGnSEvRwyzbhD+nOIuJnrAvunu469CXKwmum+m4+czIGd1AW/ S97RP69YOYom6XEKl0jfFCnjt6SMbj1Ohb71zSf1VroPPjXm4ee9GvnXJ9+AvLTfE+gd +WKXMIHH5p5F/Ejw8jtdRsoYOSyeg5XSiwnKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uyd0UOTV0O3cydixAi3hoqe71fl3cfh7HPSnJDfo0/hsZ16/KINApYoJXXA9yiZQOQ mIGQjWCg4bHlGL1mI0ptrwlEPLFh+D801vVz+9Mzc7O6UqUED3Kr//nBxx34vnhPYMrf DvTap12NaGh9rujRwROi1oC2lovTCn9m/9+L8= MIME-Version: 1.0 Received: by 10.239.130.145 with SMTP id 17mr14042hbj.52.1257261507696; Tue, 03 Nov 2009 07:18:27 -0800 (PST) In-Reply-To: <4AF04322.9@ericsson.com> References: <4AEFEBDE.6040903@ericsson.com> <4AF04322.9@ericsson.com> Date: Tue, 3 Nov 2009 15:18:27 +0000 Message-ID: From: George Tsirtsis To: Conny Larsson Content-Type: text/plain; charset=UTF-8 Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:18:09 -0000 I thought I had corrected this so good catch. I fixed it now in: http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt Thanks George On Tue, Nov 3, 2009 at 2:50 PM, Conny Larsson wrote: > Hi George, > > Yes, that sounds good. Thanks. > > Another thing. I have mentioned it several times but I will bring it up one > last time. The length of the "Option Len" field in the "Flow Identification > Mobility" option is in 8-octets units. But RFC3775, section 6.2.1, defines > the Mobility Option "Option Length" field as an "8-bit unsigned integer, > representing the length in octets of the mobility option, not including the > Option Type and Option Length fields". > > Is there a reason for changing this convention, i.e. 8-octet units instead > of octets? > > > Regards > Conny > > George Tsirtsis wrote: >> >> Hi Conny, >> >> I updated http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt >> so that all of these are now marked as "Value "0" is reserved and >> SHOULD NOT be used". >> >> This seems to be the way it is handled in other RFCs since it allows a >> future document (or even an implementation that knows what it is >> doing) to overwrite it. >> >> I hope that is OK. >> >> George >> >> On Tue, Nov 3, 2009 at 8:37 AM, Conny Larsson >> wrote: >> >>> >>> Hi George, >>> >>> Well the idea was that it should be allowed to use for instance the "0" >>> value and this should be interpreted as "this field is not used". As of >>> today it says "MUST NOT be used" but I would like it to be treated as an >>> allowed value. >>> >>> Regards >>> Conny >>> >>> George Tsirtsis wrote: >>> >>> I do not exactly follow you but the "0" values are already reserved >>> for all of these, and for FID and FID-PRI, "MUST NOT be used" is >>> indicated. >>> >>> George >>> >>> On Mon, Nov 2, 2009 at 10:05 AM, George Tsirtsis >>> wrote: >>> >>> >>> Hi all, >>> >>> Thanks a lot for the many detailed online reviews during the WGLC as >>> well as a number of reviews and suggestions received off-line. >>> Although the reviews allowed us to clarify a number of issues, no >>> significant changes had to be made to the protocol. >>> >>> I have updated the draft but since I missed the deadline I posted it >>> here: >>> http://www.tsirtsis.com/draft-ietf-mext-flow-binding-pre_04.txt >>> >>> I will post this officially as soon as the Editor starts accepting I-Ds. >>> >>> Regards >>> George >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > > From denghui02@gmail.com Wed Nov 4 15:19:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B383A684E for ; Wed, 4 Nov 2009 15:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAtJbMXUS+Hy for ; Wed, 4 Nov 2009 15:19:36 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 9B8563A67A2 for ; Wed, 4 Nov 2009 15:19:36 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1890425qwb.31 for ; Wed, 04 Nov 2009 15:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1Fuq9rCr++IHchw1EXWZpGE3iXoz0RbIGUkTxfpQy4w=; b=cTEGwaLqq6NH9UKYuFKorwZkiXuyvEad+B0IPeFVnz86O1A/53wk0zVOhrsapA4mdj dZiMT42YNgc5K90NGXwm6mjJcg+BASdATpVC6XyecxBiDb0Ze9X4KLmqp51mGBFD3uqY Z7+HrwAvZnoRxW1bR8ldC5DuX4Xms6CC65HN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CRSHVoRJtYJzHSrs2Sz0vEFXwN06piehEKPcDALCPxIY8jL9aiAYv4jId1sKfkweJ+ rAXDXbBf1jJnPz1O2usOcQdHpcN+jeFpBOSCjt/LA9dtgKNGp8I8KgotID39BxE6VA/1 yPDuudVWjazfWZvGFs9/SKASSOZQzr5KqvIKA= MIME-Version: 1.0 Received: by 10.224.104.130 with SMTP id p2mr1102405qao.164.1257376793116; Wed, 04 Nov 2009 15:19:53 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Nov 2009 07:19:53 +0800 Message-ID: <1d38a3350911041519p18fe1144nbd7512057a81f6e3@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext , Frank Brockners Subject: Re: [MEXT] Gateway Initiated Dual-stack lite Support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 23:19:37 -0000 So you are resolving IPv4 running out issue other than IPv6 issue because GRE is used here. -Hui 2009/10/17 Sri Gundavelli : > Hi Ralph, > > Thanks for the comment. Please see below. > > > > On Sat, 17 Oct 2009, Ralph Droms wrote: > >> Quick question about your draft... >> >> I understand about stitching the tunnels together in a gateway. =A0In th= e >> case of DS-lite, there is a NAT function in the DSLTC as well as a tunne= l >> concentrator function. =A0Presumably, that NAT function appeared somewhe= re >> else in the scenarios you describe in the I-D. =A0Where is that NAT func= tion >> before the addition of DS-lite and how does DS-lite change the NAT funct= ion? >> > > The application of DS-lite is not changing the placement of the NAT > function. The NAT function is outside the anchor (HA/PDN), performing > address translation on the MN's traffic, when overlapping addressing > is in use. Now, if the home network and the access network are in > seperate domains seperated by NAT (such as in RFC-3519, RFC-5555), the > mobility tunnel may go through some translation, but that has no bearing > on the MN's traffic and the placement of the NAT in the home network is > still outside the anchor. The transport tunnel has little purpose in > the the MN's addressing and translation context. > > Now, when we apply Dual-stack lite function to these architectures, > based on any of the modes (GTP, MIPv6, or PMIPv6), we are making the > anchor point (HA/LMA/PDN) perform the DS lite initiator function to > the DSLTC (LSN), with no change in where the NAT is placed. We are > building a unique softwire-id for each mobility session, but using a > single tunnel between the anchor and the DSLTC, using GRE to identify > the user flows. This is very close to the gateway mode that the DS-lite > draft supports, except using GRE to identify the flows and mapping the > access tunnel to the CGN tunnel. > > This approach results in: > > - Allocation of the same IP (overlapping addresses) to all MN's. > =A0Solves the issues for some operators who dont have enough RFC-1918 > =A0address space > - No *changes* to MN (UE)'s host stack, requirement for some handset > =A0vendors > - No bearing on the type of transport used for the mobility tunnel. > =A0Allows the operator to migrate their network in incremental steps, > =A0allowing IPv6-only or IPv4 transport network. > - Just using NAT44 and we are not doing 4 to 6 translation and > =A0back 6 to 4, avoiding all those side affects of NAT464. > - No additional overahead of the CGN tunnel in the access network > =A0or on the MN. Just one tunnel from the anchor to the LSN. > - Minimal changes to anchor (HA/LMA/PDN). > > Regards > Sri > > > > > > > > > > > > > >> - Ralph >> >> On Oct 13, 2009, at 9:27 PM 10/13/09, Sri Gundavelli wrote: >> >>> >>> We have posted a draft on using Gateway Initiated Dual-stack lite >>> approach for IPv6 migration support. Following is the pointer to >>> the draft. >>> >>> >>> http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-0= 0.txt >>> >>> The key aspect of this solution is the approach by which we are applyin= g >>> dual-stack lite solution to IP mobility architectures. In this gateway >>> initiated dual-stack lite mode we are leveraging the mobile tunnel >>> by extending it to the CGN, and by using a UE specific softwire for >>> session identification. >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julienl@qualcomm.com Fri Nov 6 00:07:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3133A3A6B88 for ; Fri, 6 Nov 2009 00:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.54 X-Spam-Level: X-Spam-Status: No, score=-105.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aEC3+Bz37Kn for ; Fri, 6 Nov 2009 00:07:27 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5126A3A6B8B for ; Fri, 6 Nov 2009 00:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1257494870; x=1289030870; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20|Date:=20Fri,=206=20Nov =202009=2000:07:44=20-0800|Subject:=20Note=20takers=20and =20jabber=20scribes|Thread-Topic:=20Note=20takers=20and =20jabber=20scribes|Thread-Index:=20AcpeuDiUH6zB6EIxTY+eG CalOZOlHA=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-2 022-jp"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5793"=3B=20a=3D"26987340"; bh=4xxoofwPcftNNiRVk6drzAleeXD+GNIhdpv7856mMWg=; b=sH2c8QNvupxB06KG/CRTycW89W9sYn2O3zlP+Ojznk76Daklwyf/v+YX XgDD4yuvhQv/EYpV3OI66z0piF0mJmgWjExvYqocC2YKaT3VsAoY7vmrD jZubcxhxZABkik0hQS0rrfyb2Qk0TUI1ficcquMhLWvWG9q5QUZUYYEo3 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5793"; a="26987340" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2009 00:07:50 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nA687opT028399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2009 00:07:50 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nA687lDR022773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Nov 2009 00:07:50 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 6 Nov 2009 00:07:47 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Fri, 6 Nov 2009 00:07:47 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Fri, 6 Nov 2009 00:07:44 -0800 Thread-Topic: Note takers and jabber scribes Thread-Index: AcpeuDiUH6zB6EIxTY+eGCalOZOlHA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] Note takers and jabber scribes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 08:07:28 -0000 Hello folks, Let's win two times five useful minutes of meeting time by having volunteer= s for taking notes and/or scribing on jabber ahead of our sessions.=20 Please reply to me and Marcelo if you want to support the working group in = this important functions. Thank you. See you next week in =1B$B9-Eg=1B(B! --julien & marcelo From Xiangsong.Cui@huawei.com Sun Nov 8 05:07:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278853A6A17 for ; Sun, 8 Nov 2009 05:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.79 X-Spam-Level: ** X-Spam-Status: No, score=2.79 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia6ViotbIoT8 for ; Sun, 8 Nov 2009 05:07:51 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BEDBD3A6981 for ; Sun, 8 Nov 2009 05:07:50 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSS002ANKHQ06@szxga03-in.huawei.com> for mext@ietf.org; Sun, 08 Nov 2009 21:08:14 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSS004POKHPFL@szxga03-in.huawei.com> for mext@ietf.org; Sun, 08 Nov 2009 21:08:13 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [133.93.128.49]) by szxmc03-in.huawei.com (mshttpd); Sun, 08 Nov 2009 21:08:13 +0800 Date: Sun, 08 Nov 2009 21:08:13 +0800 From: cuixiangsong 00111037 In-reply-to: <20091028150245.3A1E828C16B@core3.amsl.com> To: mext@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_zYkq/eplgZUmigpZ0SyGbA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <20091028150245.3A1E828C16B@core3.amsl.com> Cc: antti.makela@tkk.fi Subject: [MEXT] A new extension to Binding Revocation//Re : Protocol Action: 'Binding Revocation for IPv6 Mobility' to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 13:07:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zYkq/eplgZUmigpZ0SyGbA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi all=2C In my understanding=2C this Proposed Standard doesn=27t include the case that CN revoks the binding from the mobile node in = route optimization mode=2C and this new extension is difficult to be included in the proposed standard=2C so we wrote a new draft=2C please find it in the attachment=2E I wish this case were included in the approved document=2C but i did notice this issue just recently=2E What do you think about this new extension=3F Comments are always welcome! Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A The IESG =3Ciesg-secretary=40ietf=2Eorg=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=D4=C2 28=C8=D5=2C 2009 =CF=C2= =CE=E711=3A03 =D6=F7=CC=E2=3A =5BMEXT=5D Protocol Action=3A =27Binding Revocation for I= Pv6 Mobility=27 to Proposed Standard =CA=D5=BC=FE=C8=CB=3A IETF-Announce =3Cietf-announce=40ietf=2Eorg=3E =B3=AD=CB=CD=3A mext mailing list =3Cmext=40ietf=2Eorg=3E=2C Internet Arc= hitecture Board =3Ciab=40iab=2Eorg=3E=2C mext chair =3Cmext-chairs=40tool= s=2Eietf=2Eorg=3E=2C RFC Editor =3Crfc-editor=40rfc-editor=2Eorg=3E =3E The IESG has approved the following document=3A =3E = =3E - =27Binding Revocation for IPv6 Mobility =27 =3E =3Cdraft-ietf-mext-binding-revocation-14=2Etxt=3E as a Proposed Sta= ndard =3E = =3E = =3E This document is the product of the Mobility EXTensions for IPv6 = =3E Working Group=2E = =3E = =3E The IESG contact persons are Jari Arkko and Ralph Droms=2E =3E = =3E A URL of this Internet-Draft is=3A =3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ietf-mext-binding- =3E revocation-14=2Etxt =3E = =3E Technical Summary =3E = =3E This document defines a binding revocation mechanism to = =3E terminate a = =3E mobile node=27s mobility session and the associated resources=2E Th= ese =3E semantics are generic enough and can be used by mobility = =3E entities in =3E the case of Mobile IPv6 and its extensions=2E This mechanism = =3E allows the =3E mobility entity which initiates the revocation procedure to request= =3E its corresponding one to terminate either one=2C multiple or all = =3E specified binding cache entries=2E =3E = =3E Working Group Summary =3E = =3E This is a product of the MEXT WG=2E The document=27s progress was = =3E coordinated with the NETLMM WG=2E =3E = =3E Document Quality =3E = =3E The mechanism specified by this document is relied upon by the =3E Evolved Packet System developed by 3GPP and as thus will be =3E implemented by 3GPP vendors=2E =3E = =3E Personnel =3E = =3E Document Shepherd is Julien Laganier=2E The Sponsoring AD =3E is Jari Arkko=2E =3E = =3E RFC Editor Note =3E = =3E Add an =22Updates=3A RFC 3775=22 header to the top =3E = =3E Change in the Abstract=3A =3E OLD=3A =3E These =3E semantics are generic enough and can be used by mobility = =3E entities in =3E the case of Mobile IPv6 and its extensions=2E This mechanism allow= s =3E the mobility entity which initiates the revocation procedure to =3E request its corresponding one to terminate either one=2C multiple o= r =3E all specified binding cache entries=2E =3E NEW=3A =3E This mechanism can be used both with base Mobile IPv6 and =3E its extensions=2C such as Proxy Mobile IPv6=2E The mechanism allows= =3E the mobility entity which initiates the revocation procedure to =3E request its peer to terminate either one=2C multiple or =3E all specified binding cache entries=2E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E MEXT mailing list =3E MEXT=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/mext =3E --Boundary_(ID_zYkq/eplgZUmigpZ0SyGbA) Content-type: text/plain; NAME=draft-cui-mext-cn-binding-revocation-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-cui-mext-cn-binding-revocation-00.txt Mext Working Group X. Cui (Ed.) Internet Draft Huawei Intended status: Standards Track A. Makela Expires: May 2010 TKK November 9, 2009 Binding Revocation from correspondent node in Route Optimization Mode draft-cui-mext-cn-binding-revocation-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 8 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui Expires May 8, 2010 [Page 1] Internet-Draft CN Binding Revocation November 2009 Abstract This document specifies an extension to Binding Revocation mechanism; the correspondent node may also initiate the binding revocation in Route Optimization mode. This extension provides a method to change the Route Optimization mode to the Bidirectional Tunneling mode. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Cui Expires May 8, 2010 [Page 2] Internet-Draft CN Binding Revocation November 2009 Table of Contents 1. Introduction..................................................4 2. Terminology...................................................4 3. Protocol and Use Case Overview................................5 4. Correspondent Node Operation..................................6 5. Mobile Node Operation.........................................7 6. Messages and Options..........................................8 7. Security Considerations.......................................8 8. IANA Considerations...........................................8 9. Acknowledgments...............................................8 10. References...................................................8 10.1. Normative References....................................8 10.2. Informative References..................................9 Author's Addresses...............................................9 Cui Expires May 8, 2010 [Page 3] Internet-Draft CN Binding Revocation November 2009 1. Introduction Mobility Support in IPv6 [RFC3775] specifies two possible modes for communications between the Mobile Node (MN) and a Correspondent Node (CN), Bidirectional Tunneling mode and Route Optimization (RO) mode. As specified in [RFC3775], Route Optimization mode "requires the mobile node to register its current binding at the correspondent node." When the mobile node want to transmit a packet, it also need check whether there is a Binding Update List entry for the destination of the packet, as specified in section 11.3.1 of [RFC3775]. If the mobile node confirms that the correspondent node has a suitable Binding Cache entry, the mobile node may send the packet to the correspondent node in route optimization mode. For the mobile node, which mode to be used depends on whether the correspondent node Binding Update List entry exists or not. [mext-binding-revocation] specifies a binding revocation mechanism, which permit HA/LMA to send Binding Revocation Indication to the MN/MAG, to terminate the MN's mobility session and release the associated resources. The binding revocation mechanism specified in [mext-binding-revocation] is only applied for the binding in Home Agent or Local Mobility Anchor, but can not be applied for the binding in correspondent node. In some cases, the correspondent node also needs the capability to revoke the correspondent binding from the mobile node during a route optimized session. This document is used to introduce the mechanism used by correspondent node to terminate the correspondent node binding in the MN's Binding Update List. 2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 [RFC3775] and [mext-binding- revocation]. Cui Expires May 8, 2010 [Page 4] Internet-Draft CN Binding Revocation November 2009 3. Protocol and Use Case Overview The overview of correspondent node binding revocation procedure is as below: MN HA CN | | | | HoTI | | (a) |--------------------->| HoTI | (b) | |--------------------->| | | HoT | (c) | HoT |<---------------------| (d) |<---------------------| | | | | CoTI | (e) |-------------------------------------------->| | CoT | (f) |<--------------------------------------------| | | | Binding Update | (g) |-------------------------------------------->| | Binding Ack | (h) |<--------------------------------------------| | | | Binding Revocation Indication | (i) |<--------------------------------------------| | Binding Revocation Acknowledgement | (j) |-------------------------------------------->| | | Figure 1 CN binding and revocation. The detailed descriptions are as follows: (a)~(f) Normal Return Routability procedure as specified in [RFC3775]. (g)~(h) Normal Route Optimization binding registration as specified in [RFC3775]. (i) The correspondent node sends the Binding Revocation Indication packet to the mobile node, including the Binding Authorization Data Option in the message. Cui Expires May 8, 2010 [Page 5] Internet-Draft CN Binding Revocation November 2009 (j) The mobile node deletes the correspondent node binding, releases related resource and replies the Binding Revocation Acknowledgement message to the correspondent node. After this step, the Route Optimization mode is released and the Bidirectional Tunneling mode is applied. 4. Correspondent Node Operation To terminate the correspondent node binding in the MN's Binding Update List, the correspondent node sends a packet to the mobile node containing a Binding Revocation Indication as specified in section 7 of [mext-binding-revocation], with the exception as following: o The source address of the packet MUST be set as the IP address of the correspondent node, if the correspondent node is a mobile node the home address of the node MUST be taken as the IP address. o The Binding Authorization Data option, which is specified in section 6.2.7 of [RFC3775], MUST be included in the Binding Revocation Indication packet. Since the communication between the mobile node and the correspondent node is not protected by security association, the sender of the BRI MUST provide the Authorization option. The Binding Management Key specified in [RFC3775], the calculation of the Kbm specified in the section 5.2.5 of [RFC3775] and the calculation of the Authenticator specified in the section 6.2.7 of [RFC3775] are reused in this document. o After the Binding Revocation Indication packet has been sent, the correspondent MUST set a flag in the correspondent Binding Cache entry to indicate the "Revocation Pending" state and stop transmitting any outgoing packets (except retransmitted BRI) destined directly for the mobile node. o In the "Revocation Pending" state the correspondent node MUST accept incoming route optimized packets until the Binding Cache entry is freed. o The correspondent node SHOULD maintain the "Revocation Pending" state until Binding Revocation Acknowledgement has been received or the maximum number of retransmissions have been conducted as specified in section 6.3 of [mext-binding-revocation]. Cui Expires May 8, 2010 [Page 6] Internet-Draft CN Binding Revocation November 2009 o The correspondent node MAY free all resources associated with this mobile node binding in the cases of receiving the Binding Revocation Acknowledgement or finishing the retransmission procedure. o If the correspondent node receives packet containing Home Address option after it has freed the Binding Cache entry and related resource, whether to accept the packet or not depends on the implementation of the correspondent node. This is out of the scope of this document. 5. Mobile Node Operation Upon receiving a packet carrying a Binding Revocation Indication, the mobile node MUST validate the packet according to Section 6.2 of [mext-binding-revocation], with the addition of following tests: o The mobile node MUST verify that the IP address in the Type 2 routing header is its Home Address. If the test fails, the mobile node SHOULD silently discard the received Binding Revocation Indication message. o The mobile node MUST verify the source address of the received Binding Revocation Indication packet. If the mobile node Binding Update List contains an entry for the IP address, the mobile node MUST check the Binding Authorization Data option contained in this packet. If the Authenticator is valid and other tests are verified, the mobile node MUST accept this Binding Revocation Indication. Otherwise the mobile node SHOULD silently discard the received Binding Revocation Indication message. The Binding Management Key specified in [RFC3775], the calculation of the Kbm specified in the section 5.2.5 of [RFC3775] and the calculation of the Authenticator specified in the section 6.2.7 of [RFC3775] are reused in this document. o If the mobile node accepts this Binding Revocation Indication, the mobile node MUST send a successful Binding Revocation Acknowledgement to the correspondent node. Otherwise the mobile node MUST send a rejected Binding Revocation Acknowledgement. o After the mobile node has accepted the Binding Revocation Indication message, the mobile node MAY free the resources related to the correspondent node Binding Update List entry. The mobile node MUST stop transmitting any outgoing packets destined directly for the correspondent node after acknowledgement has been sent. Cui Expires May 8, 2010 [Page 7] Internet-Draft CN Binding Revocation November 2009 o If the mobile node receives packet containing type 2 routing header after it has freed the correspondent node binding, whether to accept the packet or not depends on the implementation of the mobile node. This is out of the scope of this document. [[ Note: This case is also possible in basic MIP6 network. The mobile node maybe receives packet containing type 2 routing header before the Binding Acknowledgement message, because the BA message and route optimized packets are transported disorderly in the IP network.]] 6. Messages and Options TBD. 7. Security Considerations TBD. 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgments The authors would like to thank Mext Working Group for the review, comment and discussion. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cui Expires May 8, 2010 [Page 8] Internet-Draft CN Binding Revocation November 2009 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [mext-binding-revocation] Ahmad, M., Mohamed, K., Sri, G., Kuntal, C. and Parviz, Y., "Binding Revocation for IPv6 Mobility", October 2009. 10.2. Informative References Author's Addresses Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Antti Makela Helsinki University of Technology P.O. BOX 3000 FIN-02105 TKK FINLAND Phone: +358 9 451 5590 Email: antti.makela@tkk.fi Cui Expires May 8, 2010 [Page 9] --Boundary_(ID_zYkq/eplgZUmigpZ0SyGbA) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for cuixiangsong 00111037 begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_zYkq/eplgZUmigpZ0SyGbA)-- From wwwrun@core3.amsl.com Fri Nov 6 10:42:20 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E225B3A6A7F; Fri, 6 Nov 2009 10:42:20 -0800 (PST) To: Hesham@elevatemobile.com From: IETF Secretariat Message-Id: <20091106184220.E225B3A6A7F@core3.amsl.com> Date: Fri, 6 Nov 2009 10:42:20 -0800 (PST) X-Mailman-Approved-At: Sun, 08 Nov 2009 21:16:08 -0800 Cc: julienl@qualcomm.com, jari.arkko@piuha.net, mext@ietf.org, ipr-announce@ietf.org Subject: [MEXT] Posting of IPR Disclosure related to Nokia Corporation's Statement about IPR related to RFC 5555 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 18:42:21 -0000 Dear Hesham Soliman: An IPR disclosure that pertains to your RFC entitled "Mobile IPv6 Support for Dual Stack Hosts and Routers" (RFC5555) was submitted to the IETF Secretariat on 2009-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1202/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to RFC 5555." The IETF Secretariat From root@core3.amsl.com Sun Nov 8 22:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9630D3A6ACF; Sun, 8 Nov 2009 22:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109060001.9630D3A6ACF@core3.amsl.com> Date: Sun, 8 Nov 2009 22:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and NEMO Basic Support Author(s) : H. Soliman, et al. Filename : draft-ietf-mext-flow-binding-04.txt Pages : 37 Date : 2009-11-08 This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-flow-binding-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08214608.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Nov 8 22:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9A0C93A6ACC; Sun, 8 Nov 2009 22:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109060001.9A0C93A6ACC@core3.amsl.com> Date: Sun, 8 Nov 2009 22:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binary-ts-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Traffic Selectors for Flow Bindings Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-binary-ts-01.txt Pages : 18 Date : 2009-11-08 This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjuction with flow bindings for Mobile IPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binary-ts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08214958.I-D@ietf.org> --NextPart-- From tsirtsis@googlemail.com Mon Nov 9 01:45:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D542E28C1E2 for ; Mon, 9 Nov 2009 01:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jveYUzkf+Gv for ; Mon, 9 Nov 2009 01:45:11 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id BD7F828C1DE for ; Mon, 9 Nov 2009 01:45:10 -0800 (PST) Received: by fxm7 with SMTP id 7so904458fxm.29 for ; Mon, 09 Nov 2009 01:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hoPDZAbr/fPQ0xaYQ9MzSEsMksVpY0AG7Vis3QmifqE=; b=dQkI1ehM7u0S/3vEg8XjnH0GtYrxFw1QqL2WbJbH96iG5ADz0SdsvAoyuf4syWBaai Asum7kczYC/n98IrxhqfWC2dv+R+0xOiKf/YaxNC7gqHR8IvN2AhiBx8lPfsBEp25S7m PGBE+PhU/Ei7DSvDiwODCUVZysI61z0foQfWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iV/IAVbA4VGlf4x7XwNzkNzQUcSZIkEIbW7gMuOp0IxL8zL7qINebswYtmcGq7Z0yt 3J9jPJ3dnMG6fLsqQEHXgqana8biS4bWp6ctPGdKSjVNNIzCAIVsvIvoGs+MqE9jxafV jbxpY1oFYLTi0jm5Qar6kXf+vndFFewCP1YI4= MIME-Version: 1.0 Received: by 10.239.138.34 with SMTP id n34mr806120hbn.64.1257759930385; Mon, 09 Nov 2009 01:45:30 -0800 (PST) Date: Mon, 9 Nov 2009 18:45:30 +0900 Message-ID: From: George Tsirtsis To: IETF MEXT WG ML Content-Type: text/plain; charset=UTF-8 Subject: [MEXT] Flow Bindings and Binary Traffic Selector drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:45:11 -0000 Hi folks, The two drafts are now published so I removed the pre- versions from tsirtsis.com site. See you all tomorrow Thanks George From julienl@qualcomm.com Mon Nov 9 17:39:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA0E28C197 for ; Mon, 9 Nov 2009 17:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.573 X-Spam-Level: X-Spam-Status: No, score=-105.573 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfekHUM0188K for ; Mon, 9 Nov 2009 17:39:52 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id BDA7F3A68E0 for ; Mon, 9 Nov 2009 17:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1257817219; x=1289353219; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Mon,=209 =20Nov=202009=2017:40:15=20-0800|Subject:=20REMINDER:=20N ote=20takers=20and=20jabber=20scribes|Thread-Topic:=20REM INDER:=20Note=20takers=20and=20jabber=20scribes |Thread-Index:=20AcpeuDiUH6zB6EIxTY+eGCalOZOlHAC7jLIQ |Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-2022-jp" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5797"=3B=20a=3D"27237140"; bh=1N4ZnPT5Bo6t+h/YkyEZf3CpJwq6ZM3Uf2mq+qr/0CA=; b=fCQpi787WCGqD4aI8KPaGkgUax0p1MU6R/MGKA6Wc/uMSvMNK7fmAUis y5E6/4+WDdo5ptm2Akr8ANkz/J2D+hBc9EbVNB5U5tlN9ex3plotIClqC S3H9R9wDneszIqB51FbNUKxhaGPubtiMDWCtoYNx0yLEtDykIoMud3RUG E=; X-IronPort-AV: E=McAfee;i="5300,2777,5797"; a="27237140" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Nov 2009 17:40:19 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAA1eJLK029525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Nov 2009 17:40:19 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAA1eI2M026558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 9 Nov 2009 17:40:19 -0800 (PST) Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 17:40:18 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Mon, 9 Nov 2009 17:40:18 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Mon, 9 Nov 2009 17:40:15 -0800 Thread-Topic: REMINDER: Note takers and jabber scribes Thread-Index: AcpeuDiUH6zB6EIxTY+eGCalOZOlHAC7jLIQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] REMINDER: Note takers and jabber scribes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:39:53 -0000 Folks, Unfortunately nobody has volunteered yet and the first scheduled MEXT sessi= on is this afternoon... Please consider volunteering as note taker and/or jabber scribe and let us = have more meeting time for the presentations and discussions. Thank you, --julien & marcelo > Hello folks, >=20 > Let's win two times five useful minutes of meeting time by having > volunteers for taking notes and/or scribing on jabber ahead of our > sessions. >=20 > Please reply to me and Marcelo if you want to support the working group > in this important functions. >=20 > Thank you. See you next week in =1B$B9-Eg=1B(B! >=20 > --julien & marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Fri Nov 13 02:02:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77F43A6A06 for ; Fri, 13 Nov 2009 02:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VXXfBJ+R70n for ; Fri, 13 Nov 2009 02:02:13 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D8EBF3A69E5 for ; Fri, 13 Nov 2009 02:02:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nADA2e7u015809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Nov 2009 11:02:41 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nADA2ejP024966 for ; Fri, 13 Nov 2009 11:02:40 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nADA2dTH005678 for ; Fri, 13 Nov 2009 11:02:40 +0100 Message-ID: <4AFD2EBF.8060900@gmail.com> Date: Fri, 13 Nov 2009 11:02:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 10:02:13 -0000 I believe this morning the slides "Issues in NEMO RO for ITS" http://www.ietf.org/proceedings/09nov/slides/mext-6.pdf mentioning draft-jhlee-mext-mnpp-00 were presented. I was sleeping. Let me now say that the draft draft-jhlee-mext-mnpp-00 presented in these slides is very similar to some of our previous work on Mobile Router to Mobile Router communications for an incident scene scenario (NANO) http://tools.ietf.org/html/draft-petrescu-manemo-nano-00 in which we present how two MRs can exchange their MNPs by means of extended Router Advertisements, and without Access Point. We can report further implementation experience with our draft, when necessary. In the mean time, what were the results of the draft-jhlee-mext-mnpp-00 meeting presentation in Hiroshima? Were there comments? Thanks, Alex From jonghyouk@gmail.com Fri Nov 13 05:08:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1923A68C0 for ; Fri, 13 Nov 2009 05:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bznWvFZ39+oc for ; Fri, 13 Nov 2009 05:08:35 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 05B693A67ED for ; Fri, 13 Nov 2009 05:08:34 -0800 (PST) Received: by bwz23 with SMTP id 23so3424451bwz.29 for ; Fri, 13 Nov 2009 05:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VABxtDGX6GIi2qv7hQ7tSHQMUBreYf0mwz2UHX+IFFc=; b=V+L9+WEbBM1iOuGmjnNiGibKY3AFq+A9+GVyD3tIp7XYeo9XqropbFodgTAncvHWXE rD7pUw8laBXZDcEEN6OQK9D6KDww11VbAiq3OeQ9kOLU/H790L5BzpuZ21U9/Dmc01Sx +iApGOwCBTVYJB/WcJ7HbcSKDxaWyyyDjuR2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eZKOEdtPV5PQQtIxtsiUFztjBPG/5vsb8nGrcH/ipgsC3V3faM4k+utbjTdKCBXH7D haHBFTHYV/ygcmQUqDlaWsLTWmwUvkLXjwqz0AjixwIX2C6Ax5Ai21LzPYvmvLMrnUum CPUdZHgedT8sVTuudOe5qbuTPk5Vk4M6WE8c8= MIME-Version: 1.0 Received: by 10.239.179.98 with SMTP id c34mr447272hbg.17.1258117740977; Fri, 13 Nov 2009 05:09:00 -0800 (PST) In-Reply-To: <4AFD2EBF.8060900@gmail.com> References: <4AFD2EBF.8060900@gmail.com> Date: Fri, 13 Nov 2009 14:09:00 +0100 Message-ID: From: Jong-Hyouk Lee To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manabu.tsukada@inria.fr, mext Subject: Re: [MEXT] About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 13:08:36 -0000 Hi, Alexandru. I've check the previous draft you already made in 2007. Yes, I agress with you. The two approaches are very very similar. Actually, we have needed to develop a mechanism to exchange the MNPs being used in vehicles for ITS. So, we designed and implemented it. Note that actually we're working on an ITS-related project. I'm happy to see your previous draft. At least, it means that we didn't take on a wrong way. I'd like to know how you're going on the your draft. Is there any progessive? Many thanks. PS: Thierry presented it at the meeting and is now travelling to come back to France. So, now he cannot get the Internet access. On Fri, Nov 13, 2009 at 11:02 AM, Alexandru Petrescu wrote: > I believe this morning the slides "Issues in NEMO RO for ITS" > http://www.ietf.org/proceedings/09nov/slides/mext-6.pdf mentioning > draft-jhlee-mext-mnpp-00 were presented. =A0I was sleeping. > > Let me now say that the draft draft-jhlee-mext-mnpp-00 presented in > these slides is very similar to some of our previous work > on Mobile Router to Mobile Router communications for an incident scene > scenario (NANO) http://tools.ietf.org/html/draft-petrescu-manemo-nano-00 > in which we present how two MRs can exchange their MNPs by means of > extended Router Advertisements, and without Access Point. > > We can report further implementation experience with our draft, when > necessary. > > In the mean time, what were the results of the draft-jhlee-mext-mnpp-00 > meeting presentation in Hiroshima? =A0Were there comments? > > Thanks, > > Alex > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --=20 IMARA Team, INRIA, France. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) f= r #webpage: http://hurryon.googlepages.com/ From alexandru.petrescu@gmail.com Fri Nov 13 10:09:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A30B3A6838 for ; Fri, 13 Nov 2009 10:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaMLShwE4DR3 for ; Fri, 13 Nov 2009 10:09:37 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 147673A6882 for ; Fri, 13 Nov 2009 10:09:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nADIA4RH030523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2009 19:10:04 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nADIA49X023631; Fri, 13 Nov 2009 19:10:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nADIA3lv026574; Fri, 13 Nov 2009 19:10:04 +0100 Message-ID: <4AFDA0FB.2090501@gmail.com> Date: Fri, 13 Nov 2009 19:10:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jong-Hyouk Lee References: <4AFD2EBF.8060900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manabu.tsukada@inria.fr, mext Subject: Re: [MEXT] About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 18:09:38 -0000 Jong-Hyouk Lee a écrit : > Hi, Alexandru. > > I've check the previous draft you already made in 2007. Yes, I agress > with you. The two approaches are very very similar. Actually, we > have needed to develop a mechanism to exchange the MNPs being used in > vehicles for ITS. So, we designed and implemented it. Note that > actually we're working on an ITS-related project. > > I'm happy to see your previous draft. At least, it means that we > didn't take on a wrong way. I'd like to know how you're going on the > your draft. Is there any progessive? Well, yes, there is progress in the implementation of our draft. We have now an implementation on linux which extends radvd. We also have a wireshark dissector such as to show the messages properly in wireshark. However, I am afraid our dissector will not understand the messages developped by your draft and, worse, our Mobile Router will not understand the messages your Mobile Router sends, because the message formats are completely different between the two drafts (even if both carry MNPs in RAs). What kind of implementation do you make/use? Alex > > Many thanks. > > PS: Thierry presented it at the meeting and is now travelling to come > back to France. So, now he cannot get the Internet access. > > On Fri, Nov 13, 2009 at 11:02 AM, Alexandru Petrescu > wrote: >> I believe this morning the slides "Issues in NEMO RO for ITS" >> http://www.ietf.org/proceedings/09nov/slides/mext-6.pdf mentioning >> draft-jhlee-mext-mnpp-00 were presented. I was sleeping. >> >> Let me now say that the draft draft-jhlee-mext-mnpp-00 presented in >> these slides is very similar to some of our previous work on >> Mobile Router to Mobile Router communications for an incident scene >> scenario (NANO) >> http://tools.ietf.org/html/draft-petrescu-manemo-nano-00 in which >> we present how two MRs can exchange their MNPs by means of extended >> Router Advertisements, and without Access Point. >> >> We can report further implementation experience with our draft, >> when necessary. >> >> In the mean time, what were the results of the >> draft-jhlee-mext-mnpp-00 meeting presentation in Hiroshima? Were >> there comments? >> >> Thanks, >> >> Alex >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> > > > From jonghyouk@gmail.com Fri Nov 13 11:16:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDF03A69A1 for ; Fri, 13 Nov 2009 11:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIOQ3yPfA0ib for ; Fri, 13 Nov 2009 11:16:53 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.185]) by core3.amsl.com (Postfix) with ESMTP id 79B513A67D6 for ; Fri, 13 Nov 2009 11:16:49 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so575083gvc.15 for ; Fri, 13 Nov 2009 11:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VDB6QbFWsaOUlFH9yuQYnjJxjUpKCzeyaa8Iemm/wCk=; b=T+qZAn0uuZNwqo6gay1UxOT5bEPDTSaqjPxEuDLKr4oB3JlRsajwS9XN+NPqOMkxFt AqL2/agxX1bwF/MUq4tAO6SVCA79eJWqxbIP+zW+2VcElKX0Ea63cxZXkDEDPRYJC35N 4S7J5a81B9q8PQXt0IVehYAUuNSVKBroRwdYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CU0AemC6GgdJsz2nIA7ZNjGJBZmkV+YcrXr3V2w+2DuJLxdLHAVLUBUJAWQWgVTizB pXRkyyvxDd4rGbLNiCZHBK1auHWyuLGpNJAOChjA4ebf4J/GZeuftNcxFj6Op7nGlDR2 +kCNnLOa+MTPXoExm/e8F2iYJNnM8z4zCv6oU= MIME-Version: 1.0 Received: by 10.239.237.77 with SMTP id i13mr463232hbp.198.1258139836064; Fri, 13 Nov 2009 11:17:16 -0800 (PST) In-Reply-To: References: <4AFD2EBF.8060900@gmail.com> <4AFDA0FB.2090501@gmail.com> Date: Fri, 13 Nov 2009 20:17:16 +0100 Message-ID: From: Jong-Hyouk Lee To: Alexandru Petrescu , thierry.ernst@inria.fr, manabu.tsukada@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: [MEXT] Fwd: About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:16:54 -0000 Hi, Alexandru. On Fri, Nov 13, 2009 at 7:10 PM, Alexandru Petrescu wrote: > Jong-Hyouk Lee a =E9crit : >> >> Hi, Alexandru. >> >> I've check the previous draft you already made in 2007. Yes, I agress >> =A0with you. The two approaches are very very similar. Actually, we have >> needed to develop a mechanism to exchange the MNPs being used in >> =A0vehicles for ITS. So, we designed and implemented it. Note that actua= lly >> we're working on an ITS-related project. >> >> I'm happy to see your previous draft. At least, it means that we didn't >> take on a wrong way. I'd like to know how you're going on the your draft= . Is >> there any progessive? > > Well, yes, there is progress in the implementation of our draft. =A0We > have now an implementation on linux which extends radvd. =A0We also have = a > wireshark dissector such as to show the messages properly in wireshark. Wow. Yes, the implementation of MNPP (our implementation) is also based on radvd. Actually, it is an extension (patch) of radvd v1.5. I have not made the wireshark dissector, but extended radvdump also. So, the modified radvdump can capture and provide essential information from the modified RA message that carries the MNP being used in the MR. > > However, I am afraid our dissector will not understand the messages > developped by your draft and, worse, our Mobile Router will not > understand the messages your Mobile Router sends, because the message > formats are completely different between the two drafts (even if both > carry MNPs in RAs). Yes. Because we (you and I) have different message formats. ;-) > > What kind of implementation do you make/use? > > Alex Many thanks. --=20 IMARA Team, INRIA, France. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) f= r #webpage: http://hurryon.googlepages.com/ From alexandru.petrescu@gmail.com Fri Nov 13 11:37:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270333A693E for ; Fri, 13 Nov 2009 11:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgsYLnoLjSQU for ; Fri, 13 Nov 2009 11:37:26 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 379EA3A683E for ; Fri, 13 Nov 2009 11:37:25 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nADJbrrM008788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2009 20:37:53 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nADJbcug007050; Fri, 13 Nov 2009 20:37:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nADJbRZZ014189; Fri, 13 Nov 2009 20:37:28 +0100 Message-ID: <4AFDB577.2020206@gmail.com> Date: Fri, 13 Nov 2009 20:37:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jong-Hyouk Lee References: <4AFD2EBF.8060900@gmail.com> <4AFDA0FB.2090501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manabu.tsukada@inria.fr, mext Subject: Re: [MEXT] Fwd: About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:37:27 -0000 Jong-Hyouk Lee a écrit : [...] >> However, I am afraid our dissector will not understand the messages >> developped by your draft and, worse, our Mobile Router will not >> understand the messages your Mobile Router sends, because the >> message formats are completely different between the two drafts >> (even if both carry MNPs in RAs). > > Yes. Because we (you and I) have different message formats. ;-) YEs, that situation could be improved. That is why I am wondering what has been discussed at the meeting about the jhlee mnpp draft. Alex From julienl@qualcomm.com Wed Nov 18 07:56:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A203A6979 for ; Wed, 18 Nov 2009 07:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awxc4bes8v0h for ; Wed, 18 Nov 2009 07:56:55 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 537A63A6970 for ; Wed, 18 Nov 2009 07:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1258559814; x=1290095814; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20,=0D=0A=20=20=20=20=20 =20=20=20"draft-ietf-mext-binary-ts@tools.ietf.org"=0D=0A =09|Date:=20Wed ,=2018=20Nov=202009=2007:56:46=20-0800|Subject:=20[WGLC] =20draft-ietf-mext-binary-ts-01|Thread-Topic:=20[WGLC]=20 draft-ietf-mext-binary-ts-01|Thread-Index:=20AcpoZ7tLGBWV 4/j+TkKRHFf6ZYILLw=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5805"=3B=20a=3D"27889668"; bh=664bu/G1hf6RrU2+ODZVfVxJeXij2noYqtSjWWx2VBU=; b=QafBLwJi0Vvo3LacQoxRBogCHFM5q+zpJVjmyeUftAD9KbODkXldfC36 vREazVaX3eA2p+WWTtnyDtE9I/vo+aVJCAQAywd1jQi6xonvYHPD4QmRW fOiWX5W6BeMUr6oVQk6hSUUzCM+yUR0sPXTKY0a08eB6Kbrkx8AsZRnZs E=; X-IronPort-AV: E=McAfee;i="5300,2777,5805"; a="27889668" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2009 07:56:53 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIFurUV031838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2009 07:56:53 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIFuqrC006956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Nov 2009 07:56:52 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 Nov 2009 07:56:48 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 18 Nov 2009 07:56:48 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Wed, 18 Nov 2009 07:56:46 -0800 Thread-Topic: [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:56:56 -0000 Folks, As stated during the meeting, we're starting a two weeks WGLC on our "Traff= ic Selectors for Flow Bindings" document, available at the following URL: Please review the specification, post your comments to the mailing list, an= d state whether or not you think the document is ready to be forwarded to I= ESG before 2009-12-02 6:00PM PST. =20 Thank you for your support. =20 --julien & marcelo, MEXT chairs From julienl@qualcomm.com Wed Nov 18 08:04:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4528128C0EF for ; Wed, 18 Nov 2009 08:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iALKbFLaNRB for ; Wed, 18 Nov 2009 08:04:37 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 89FAB28C0DF for ; Wed, 18 Nov 2009 08:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1258560276; x=1290096276; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20,=0D=0A=20=20=20=20=20 =20=20=20"draft-ietf-mext-flow-binding@tools.ietf.org"=0D =0A=09|Date: =20Wed,=2018=20Nov=202009=2008:04:21=20-0800|Subject:=20C losing=20on=20draft-ietf-mext-flow-binding-04=20(Was:=20[ WGLC]=0D=0A=20draft-ietf-mext-flow-binding-03) |Thread-Topic:=20Closing=20on=20draft-ietf-mext-flow-bind ing-04=20(Was:=20[WGLC]=0D=0A=20draft-ietf-mext-flow-bind ing-03)|Thread-Index:=20AcpG3PrETCpXfQpNQraj6B7QmoF8mwhin DMQ|Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5805"=3B=20a=3D"27890317"; bh=Gcm9yoMcnA6ZVxsqaA8uY9PvPDPOoTY2bir7yaBm1xQ=; b=j8e6CUkj+GepBomNFWotzzOst6mmTsK65B+PTTiFjKZxix+UFcLYWxZx NF+tD6bXJPYVj7JGRt3qnpZRZ1skM2tSyWq3sieUXOM3BDoJwVgnCwZne tlXniGk4rUvxIt2uqjOfpeEnItfJMZXRLQVPTavjfVLKdAWrXR1E1gpzP w=; X-IronPort-AV: E=McAfee;i="5300,2777,5805"; a="27890317" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2009 08:04:35 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIG4ZCQ032532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2009 08:04:35 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIG4DZj008580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Nov 2009 08:04:28 -0800 (PST) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 Nov 2009 08:04:22 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 18 Nov 2009 08:04:22 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Wed, 18 Nov 2009 08:04:21 -0800 Thread-Topic: Closing on draft-ietf-mext-flow-binding-04 (Was: [WGLC] draft-ietf-mext-flow-binding-03) Thread-Index: AcpG3PrETCpXfQpNQraj6B7QmoF8mwhinDMQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-flow-binding@tools.ietf.org" Subject: [MEXT] Closing on draft-ietf-mext-flow-binding-04 (Was: [WGLC] draft-ietf-mext-flow-binding-03) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:04:39 -0000 Folks, A new version of our "Flow Bindings in Mobile IPv6 and NEMO Basic Support" = document addressing WGLC comments as been made available by the authors at = the following URL: Please check whether your comments were addressed before 2009-11-25 6:00PM = PST, at which point we'll consider that all WGLC comments have been address= ed and the draft is ready to be forwarded to IESG. =20 Thank you. --julien & marcelo, MEXT chairs > -----Original Message----- > From: Laganier, Julien > Sent: Tuesday, October 06, 2009 4:30 PM > To: mext@ietf.org > Subject: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Folks, >=20 > Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile > IPv6 and NEMO Basic Support" document, available at the following URL: >=20 > >=20 > Please review the specification, post your comments to the mailing list, > and state whether or not you think the document is ready to be > forwarded to IESG before 2009-10-20 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Wed Nov 18 10:12:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4BA3A6782 for ; Wed, 18 Nov 2009 10:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mva54ToMYN5 for ; Wed, 18 Nov 2009 10:12:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 685933A677E for ; Wed, 18 Nov 2009 10:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1258567969; x=1290103969; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Wed,=201 8=20Nov=202009=2010:12:43=20-0800|Subject:=20RE:=20[WGLC] =20draft-ietf-mext-binary-ts-01|Thread-Topic:=20[WGLC]=20 draft-ietf-mext-binary-ts-01|Thread-Index:=20AcpoZ7tLGBWV 4/j+TkKRHFf6ZYILLwAErokA|Message-ID:=20 |References:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5806"=3B=20a=3D"27903906"; bh=zLMnjGmVNn1xn1IY2+xPX6SrYUSI1ykfymoBk7uTGAo=; b=TKf47/gw7jOMvTaiYuYLYBfj6EHTpNnG3gBOz8kyDXSZ+XMjegtv5DaC crDPq3iHd1DZsyGhCxNw2JzM8GHxIrOIz15VzUhqCxPI8UKwkds3UHCSs zCKpPPlLGYh/v02bwTCWOpSVCh4E1U5glTj3b+az1vffV4vXFVkvPleLe A=; X-IronPort-AV: E=McAfee;i="5300,2777,5806"; a="27903906" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2009 10:12:48 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIICmS3016662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Nov 2009 10:12:48 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAIICgut013581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 Nov 2009 10:12:48 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 Nov 2009 10:12:44 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 18 Nov 2009 10:12:44 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Wed, 18 Nov 2009 10:12:43 -0800 Thread-Topic: [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwAErokA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:12:51 -0000 Someone pointed out that I sent a broken URL for the draft, sorry about tha= t. The correct URL is: --julien > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Laganier, Julien > Sent: Wednesday, November 18, 2009 7:57 AM > To: mext@ietf.org > Cc: draft-ietf-mext-binary-ts@tools.ietf.org > Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 >=20 > Folks, >=20 > As stated during the meeting, we're starting a two weeks WGLC on our > "Traffic Selectors for Flow Bindings" document, available at the > following URL: >=20 > >=20 > Please review the specification, post your comments to the mailing list, > and state whether or not you think the document is ready to be > forwarded to IESG before 2009-12-02 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From thierry.ernst@inria.fr Thu Nov 19 14:23:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E959A3A635F for ; Thu, 19 Nov 2009 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id culXwyZmcibF for ; Thu, 19 Nov 2009 14:23:20 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 994DD28C0F7 for ; Thu, 19 Nov 2009 14:21:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,773,1249250400"; d="vcf'?scan'208";a="40451675" Received: from vpn-rocq-159.inria.fr (HELO switch-bat02.inria.fr) ([128.93.42.159]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Nov 2009 23:21:40 +0100 Message-ID: <4B057688.6070709@inria.fr> Date: Thu, 19 Nov 2009 17:47:04 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mext References: <4AFD2EBF.8060900@gmail.com> <4AFDA0FB.2090501@gmail.com> <4AFDB577.2020206@gmail.com> In-Reply-To: <4AFDB577.2020206@gmail.com> Content-Type: multipart/mixed; boundary="------------000507040305080602060601" Subject: Re: [MEXT] Fwd: About draft-jhlee-mext-mnpp-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:23:21 -0000 This is a multi-part message in MIME format. --------------000507040305080602060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The draft was simply presented for informational purposes. It was discussed if such work belongs to MEXT and one interesting discussion point was security. We work on securiry and next version of the draft will include some text about the security issues and identified ways to solve them using SeND and other mechanisms. Then we will seek for more feedback on the security aspects. However, many people usually attending the IETF were not there, particularly on the last day. Thierry Alexandru Petrescu wrote: > Jong-Hyouk Lee a écrit : > [...] >>> However, I am afraid our dissector will not understand the messages >>> developped by your draft and, worse, our Mobile Router will not >>> understand the messages your Mobile Router sends, because the >>> message formats are completely different between the two drafts >>> (even if both carry MNPs in RAs). >> >> Yes. Because we (you and I) have different message formats. ;-) > > YEs, that situation could be improved. > > That is why I am wondering what has been discussed at the meeting about > the jhlee mnpp draft. > > Alex --------------000507040305080602060601 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------000507040305080602060601-- From julienl@qualcomm.com Fri Nov 20 16:27:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF733A6829 for ; Fri, 20 Nov 2009 16:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSI39DDj9H7V for ; Fri, 20 Nov 2009 16:27:31 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5C6C23A6824 for ; Fri, 20 Nov 2009 16:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1258763249; x=1290299249; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"akisada@t ahi.org"=20|Date:=20Fri,=2020=20Nov=202 009=2016:27:23=20-0800|Subject:=20FYI:=20The=2010th=20TAH I=20Test=20Event|Thread-Topic:=20FYI:=20The=2010th=20TAHI =20Test=20Event|Thread-Index:=20AcpqQWVO8lwwpYKXTti/keXSd H8Jow=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5808"=3B=20a=3D"28094485"; bh=YNQdWvPO/0qfGRSPLPXKk+UoP6Z/tWyHJJVWsvc0IGY=; b=RtHD9Gw+hyXRaQPd0jzXGPnLfjYlXWW9VNjAZml9fjp6sH/kP0b4AesI FFoS1ztHf1FsulGRX6h5uNHkuObdwFJsMH8h4g/yvjYXhhY/Cu7AJ5o6p oMzjsL6nItS/+/3/cFjvAskdjTLEOmUlWhGCnfi2Vfe3753a9+LID9SJP g=; X-IronPort-AV: E=McAfee;i="5300,2777,5808"; a="28094485" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2009 16:27:28 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAL0RSrr001090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2009 16:27:28 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAL0RRLd014010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Nov 2009 16:27:28 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Nov 2009 16:27:25 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 20 Nov 2009 16:27:24 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Fri, 20 Nov 2009 16:27:23 -0800 Thread-Topic: FYI: The 10th TAHI Test Event Thread-Index: AcpqQWVO8lwwpYKXTti/keXSdH8Jow== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] FYI: The 10th TAHI Test Event X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:27:32 -0000 Hello Folks, I've been asked to pass the following information which is relevant to the = MEXT WG: The TAHI Project will organize an IPv6 test event in Japan in January at Ja= pan. The conformance test includes both MIPv6 and NEMO basic support. For more information, please visit --julien From Benjamin.Limck@sg.panasonic.com Sun Nov 29 22:07:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9EC3A683D for ; Sun, 29 Nov 2009 22:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.21 X-Spam-Level: ** X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MANGLED_FORM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXuviAt6xG8z for ; Sun, 29 Nov 2009 22:07:12 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4158E3A6914 for ; Sun, 29 Nov 2009 22:07:10 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id nAU66tpD023326 for ; Mon, 30 Nov 2009 15:06:55 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id nAU66qN04800 for ; Mon, 30 Nov 2009 15:06:52 +0900 (JST) Received: from [10.81.113.115] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 14:06:29 +0800 Message-ID: <4B136025.6070200@sg.panasonic.com> Date: Mon, 30 Nov 2009 14:03:17 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "mext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2009 06:06:29.0807 (UTC) FILETIME=[422843F0:01CA7183] Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 06:07:14 -0000 Hi, I have reviewed the draft and have some questions/editorials stated below. Regards, Benjamin Lim ----------- > Abstract > > This document defines binary formats for IPv4 and IPv6 traffic > selectors to be used in conjuction with flow bindings for Mobile [Ben] s/ conjuction/ conjunction > IPv6. ... > 2. Introduction > > This document defines binary formats for IPv4 and IPv6 Traffic > Selector sub-options as defined in [I-D.ietf-mext-flow-binding]. > > The binary traffic selector sub-options defined here, allow efficient > identification of flow(s) based on well known fields in IPv4 > [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP > [RFC0793] and UDP [RFC0768]. [Ben] Propose to rephrase to "The binary traffic selector sub-options defined here, allow for efficient..." ... > 3.1. IPv4 binary traffic selector ... > > (B)End Source Address > > If more than one contiguous source addresses need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start Source Address field. This > field MUST NOT be included unless the Start Source Address field is > included. When this field is included the receiver will match all of > the addresses between fields (A) and (B), inclusive of (A) and (B). [Ben] For clarification, if it is only to match one IP address of CN, does it mean that "(A)Start Source Address" and "(B)End Source Address" would be of the same IP address? The same question applies to those fields that allow specifying ranges. ... > > (D)End Destination Address > > If more than one contiguous destination addresses need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a > range starting from the value of the Start Destination Address field. > This field MUST NOT be included unless the Start Destination Address > field is included. When this field is included the receiver will > match all of the addresses between fields (C) and (D), inclusive of > (C) and (D). ... > (F)End SPI - Security Parameter Index > > If more than one contiguous SPI values need to be mached then this [Ben] s/ mached/ matched > field can be used to indicate the end value of a range starting from > the value of the Start SPI field. This field MUST NOT be included > unless the Start SPI field is included. When this field is included > the receiver will match all of the SPI values between fields (E) and > (F), inclusive of (E) and (F). ... > (H)End Source Port > > If more than one contiguous source port numbers need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start Source Port field. This field > MUST NOT be included unless the Start Source Port field is included. > When this field is included the receiver will match all of the port > numbers between fields (G) and (H), inclusive of (G) and (H). ... > (J)End Destination Port > > If more than one contiguous destination port numbers need to be > mached then this field can be used to indicate the end value of a [Ben] s/ mached/ matched > range starting from the value of the Start Destination Port field. > This field MUST NOT be included unless the Start Destination Port > field is included. When this field is included the receiver will > match all of the port numbers between fields (I) and (K), [Ben] s/ (K)/ (J) > inclusive of (I) and (J). > > (K)Start DS - Differential Services > > This field identifies the first differential services value, from the > range of differential services values to be matched, on data packets > as seen by the home agent. Note that this field is called Type of > Service field in [RFC0791]. [RFC3260] then clarified that the field > has been redefined as 6 bits DS field and 2 bits reserved, later > claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the > purpose of this specification the DS field is 8bit long, were the 6 [Ben] s/ 8bit/ 8 bits > most significant bits indicating the DS > field to be matched and the 2 list significant bits MUST be set to 0 > by the sender and ignored by the receiver. > > (L)End DS - Differential Services > > If more than one contiguous DS values need to be mached then this [Ben] s/ mached/ matched > field can be used to indicate the end value of a range starting from > the value of the Start DS field. This field MUST NOT be included > unless the Start DS field is included. When this field is included > the receiver will match all of the values between fields (K) and (L), > inclusive of (K) and (L). [Ben] I assume that same note for (K) on how to format the bits in the DS field applies to (L) also? I.e. For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 list significant bits MUST be set to 0 by the sender and ignored by the receiver. ... > (N)End Protocol > > If more than one contiguous protocol values need to be mached then [Ben] s/ mached/ matched > this field can be used to indicate the end value of a range starting > from the value of the Start Protocol field. This field MUST NOT be > included unless the Start Protocol field is included. When this field > is included the receiver will match all of the values between fields > (M) and (N), inclusive of (M) and (N). [Ben] For my understanding, can I ask what is the purpose of the "Protocol field"? ... > 3.2. IPv6 binary traffic selector ... > (B)End Source Address > > If more than one contiguous source addresses need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start Source Address field. This > field MUST NOT be included unless the Start Source Address field is > included. When this field is included the receiver will match all of > the addresses between fields (A) and (B), inclusive of (A) and (B). ... > (D)End Destination Address > > If more than one contiguous destination addresses need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a > range starting from the value of the Start Destination Address field. > This field MUST NOT be included unless the Start Destination Address > field is included. When this field is included the receiver will > match all of the addresses between fields (C) and (D), inclusive of > (C) and (D). ... > (F)End SPI - Security Parameter Index > > If more than one contiguous SPI values need to be mached then this [Ben] s/ mached/ matched > field can be used to indicate the end value of a range starting from > the value of the Start SPI field. This field MUST NOT be included > unless the Start SPI field is included. When this field is included > the receiver will match all of the SPI values between fields (E) and > (F), inclusive of (E) and (F). ... > (G)Start Flow Label > > This field identifies the first flow label value, from the range of > flow label values to be matched, on data packets as seen by the home > agent. According to [RFC2460] the flow label is 24-bit long. For the > purpose of this specification the sender of this options MUST prefix > flow label values with 8-bits of "0" before inserting it in this > field. [Ben] Reword the above sentence to "For the purpose of this specification the sender of this option MUST prefix the flow label values with 8-bits of "0" before inserting it into this field." > The receive SHOULD ignore the first 8-bits of [Ben] s/ receive/ receiver > this field. > > (H)End Flow Label > > If more than one contiguous flow label values need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start Flow Label field. This field > MUST NOT be included unless the Start Flow Label field is included. > When this field is included the receiver will match all of the flow > label values between fields (G) and (H), inclusive of (G) and (H). ... > (J)End Source Port > > If more than one contiguous source port numbers need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start Source Port field. This field > MUST NOT be included unless the Start Source Port field is included. > When this field is included the receiver will match all of the port > numbers between fields (I) and (J), inclusive of (I) and (J). ... > (L)End Destination Port > > If more than one contiguous destination port numbers need to be > mached then this field can be used to indicate the end value of a [Ben] s/ mached/ matched > range starting from the value of the Start Destination Port field. > This field MUST NOT be included unless the Start Destination Port > field is included. When this field is included the receiver will > match all of the port numbers between fields (K) and (L), inclusive > of (K) and (L). > > (M)Start DS - Differential Services > > This field identifies the first differential services value, from the > range of differential services values to be matched, on data packets > as seen by the home agent. Note that this field is called Type of > Service field in [RFC0791]. [RFC3260] then clarified that the field > has been redefined as 6 bits DS field and 2 bits reserved, later > claimed by Explicit Congestion Notification (ECN) [RFC3168]. For the > purpose of this specification the DS field is 8bit long, were the 6 [Ben] s/ 8bit/ 8 bits > most significant bits indicating the DS > field to be matched and the 2 list significant bits MUST be set to 0 > by the sender and ignored by the receiver. > > (N)End DS - Differential Services > > If more than one contiguous DS values need to be mached then this [Ben] s/ mached/ matched > field can be used to indicate the end value of a range starting from > the value of the Start DS field. This field MUST NOT be included > unless the Start DS field is included. When this field is included > the receiver will match all of the values between fields (M) and (N), > inclusive of (M) and (N). [Ben] I assume that same note for (M) on how to format the bits in the DS field applies to (N) also? I.e. For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 list significant bits MUST be set to 0 by the sender and ignored by the receiver. ... > (P)End NH - Next Header > > If more than one contiguous next header values need to be mached [Ben] s/ mached/ matched > then this field can be used to indicate the end value of a range > starting from the value of the Start NH field. This field MUST NOT > be included unless the Start next header field is included. When this > field is included the receiver will match all of the values between > fields (O) and (P), inclusive of (O) and (P). ... > 4. Security Considerations > > This draft defines the format of traffic selector sub-options defined > in the flow bindings [I-D.ietf-mext-flow-binding]. The authors have > not identified any security concenrs pertaining to this draft beyond [Ben] s/ concenrs/ concerns > what is already identified in [I-D.ietf-mext-flow-binding]. ... > 6. Aknowledgements [Ben] s/ Aknowledgements/ Acknowledgements > > The authors would like to thank Patrick Stupar and Julien Laganier > for their contributions to this document. From julienl@qualcomm.com Mon Nov 30 13:44:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370153A692C for ; Mon, 30 Nov 2009 13:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.757 X-Spam-Level: X-Spam-Status: No, score=-103.757 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRoROngip10a for ; Mon, 30 Nov 2009 13:44:26 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 373433A6924 for ; Mon, 30 Nov 2009 13:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259617459; x=1291153459; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"Laganier,=20Julien"=20,=20" mext@ietf.org"=20|CC:=20"draft-ietf-mext-b inary-ts@tools.ietf.org"=0D=0A=09|Date:=20Mon,=2030=20Nov=202009=2013:44 :16=20-0800|Subject:=20RE:=20[WGLC]=20draft-ietf-mext-bin ary-ts-01|Thread-Topic:=20[WGLC]=20draft-ietf-mext-binary -ts-01|Thread-Index:=20AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwFrrM Ig|Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5818"=3B=20a=3D"28736048"; bh=mkYWHrG8b4ZqZ+Ou2e2pY7s+a6YIg24okYDmNmKLcc4=; b=UXqgKBqY9GC4awVCPp8T0Hjh6NFWPVW5P/f4Emm8GXys6L7MNCxVmFh4 UrE4L75VI4IBPkBvExDRq447QJ9nRU6JdHk8ZX5ijrZaVHJbuofLW18G/ yYdCvCceEv8reLBB085x6+naJ2oUSOmPaCFnrT43mN1bHYehBrJbhX0/C o=; X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28736048" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 30 Nov 2009 13:44:19 -0800 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAULiIlI000423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 13:44:19 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAULiIQ2000879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Nov 2009 13:44:18 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 13:44:18 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 30 Nov 2009 13:44:17 -0800 From: "Laganier, Julien" To: "Laganier, Julien" , "mext@ietf.org" Date: Mon, 30 Nov 2009 13:44:16 -0800 Thread-Topic: [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwFrrMIg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:44:27 -0000 Folks - This is my hat-less draft review: I think the draft is ready provided that the minor points below are address= ed: 1- We should include the following alignments requirements for the sub-opti= ons:=20 * IPv4 TS: - 4n aligned if A, B, C, D, E or F is set - 2n aligned if G, H, I or J is set - n aligned otherwise * IPv6 TS: - 8n aligned if A, B, C, or D is set - 4n aligned if E, F, G, or H is set - 2n aligned if I, J, K, or L is set - n aligned otherwise 2- I feel that the text describing the Start/End field for ranges could be = made simpler by formulating a la RFC 4306 (IKEv2), as per this template: * Start () - Value specifying the smallest allowed by this Traffic Selector. If the End field is not included, this is the only allowed by this=20 Traffic Selector. * End () - Value specifying the largest allowed by this Traffic Selector. This field MUST NOT=20 be included unless the Start field is included.=20 Thanks, --julien Laganier, Julien wrote: >=20 > Folks, >=20 > As stated during the meeting, we're starting a two weeks WGLC on our > "Traffic Selectors for Flow Bindings" document, available at the > following URL: >=20 > >=20 > Please review the specification, post your comments to the mailing list, > and state whether or not you think the document is ready to be > forwarded to IESG before 2009-12-02 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Mon Nov 30 13:48:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1D828C132 for ; Mon, 30 Nov 2009 13:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.712 X-Spam-Level: X-Spam-Status: No, score=-105.712 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9sbJObkDrT9 for ; Mon, 30 Nov 2009 13:48:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E35B23A69B8 for ; Mon, 30 Nov 2009 13:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259617707; x=1291153707; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"draft-iet f-mext-binary-ts@tools.ietf.org"=0D=0A=09|Date:=20Mon,=2030=20Nov=202009 =2013:48:24=20-0800|Subject:=20[REMINDER]=20[WGLC]=20draf t-ietf-mext-binary-ts-01|Thread-Topic:=20[REMINDER]=20[WG LC]=20draft-ietf-mext-binary-ts-01|Thread-Index:=20AcpoZ7 tLGBWV4/j+TkKRHFf6ZYILLwJnuvKQ|Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5818"=3B=20a=3D"28733795"; bh=ZcCofeHk3AuGe8YSKkx+J8kbyAVJQurN8Z+KVD8EYgE=; b=uECT5KVN4MJzXqCQPQVan/jV1YZ/XgXa8YstgSMXJVtbqnpWm0nDbLCg 9ntLYKSq0lNXWMJVVgSfdeBWaCpN13oeRQdblwTJDboJozH3s5iMvgWus tfybbhGkulvJXwBrCrZtJ8Wg8Tfgly8BG2+HIAg7SgFQSPh83TK2ugkSV s=; X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28733795" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 30 Nov 2009 13:48:27 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAULmQem000925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 13:48:26 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAULmQA2032473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Nov 2009 13:48:26 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 13:48:26 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 30 Nov 2009 13:48:26 -0800 From: "Laganier, Julien" To: "mext@ietf.org" Date: Mon, 30 Nov 2009 13:48:24 -0800 Thread-Topic: [REMINDER] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwJnuvKQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" Subject: [MEXT] [REMINDER] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:48:35 -0000 This is a reminder that there are only two days left to review this draft a= s part of the WGLC.=20 --julien=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Laganier, Julien > Sent: Wednesday, November 18, 2009 7:57 AM > To: mext@ietf.org > Cc: draft-ietf-mext-binary-ts@tools.ietf.org > Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 >=20 > Folks, >=20 > As stated during the meeting, we're starting a two weeks WGLC on our > "Traffic Selectors for Flow Bindings" document, available at the > following URL: >=20 > >=20 > Please review the specification, post your comments to the mailing list, > and state whether or not you think the document is ready to be > forwarded to IESG before 2009-12-02 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From dave.craig4@gmail.com Mon Nov 30 16:48:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD023A6863 for ; Mon, 30 Nov 2009 16:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1rY8aUzPmGF for ; Mon, 30 Nov 2009 16:48:13 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 37F033A67CF for ; Mon, 30 Nov 2009 16:48:13 -0800 (PST) Received: by pxi14 with SMTP id 14so3268072pxi.31 for ; Mon, 30 Nov 2009 16:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Nn71uQh3i31MOGEpJIb3tFASnTPOb7CsE6AFec72xFw=; b=A/5DF62xFhgF+rMxGC7ItsGp4SLjJ6FkKPQ/YjXZzwygpimqrtn/8vDuE6DKgT4qiG QmKuPNWIa+319T/ZNWajV2A+odnbGQ9JuKd2anXO4R5OoDjujtWpCOT+oc1mhCJqmmsU s5YrhfAZTWNWBAnLEYotV0E1ud1MAWnQq7DTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sn+Yu4oOJMyb6rafHmn9dNEcmz6H8M9uIWj44C7e1EHCM5ZUccYkHD82FTxsO8qBEz x3wM/xa21HvC4LK71Ar1JrTdgQ2hmnuts6RJo3ThUOWcvvNYpAxumRkCJT07jQP1FQck qo16ZDU/GA348OJSNbWRw84bG98w3/d/v1zVI= MIME-Version: 1.0 Received: by 10.114.214.24 with SMTP id m24mr9273402wag.93.1259628483495; Mon, 30 Nov 2009 16:48:03 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2009 16:48:03 -0800 Message-ID: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> From: Dave Craig To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 00:48:14 -0000 3. page 5. =A0How about specifying 0x1 for IPv4 traffic selector and 0x2 for IPv6 traffic selector? 3.1. page 6, How about adding the following to the end of the SPI field descriptions (EF), "A present SPI field does not match traffic without an IPsec header." =A0Also applies to 3.2. page 10. 3.1. page 7, How about adding the following to the end of the port field description (GHIJ), "A present port field does not match traffic with IP protocols that do not define a transport port." =A0Also add a reference to the port number definitions, so it is not ambiguous which port you're talking about. http://www.iana.org/assignments/port-numbers. 3.2. page 12 (OP), Suggest making the next header match against any of the IPv6 next headers. =A0This would enable a filter to match against a jumbo payload that might be behind a router alert. =A0New text might read, "This field identifies the first 8-bit next header value" of any of the next headers in the packet, "from the..." 3.2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | (G)Start Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | (H)End Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ probably should update the block for DS, too. 3.2. For the purpose of this specification, the sender of this option =A0 =A0 =A0MUST prefix flow label values with 8-bits of "0" before insertin= g =A0 =A0 =A0it in this field. s/mached/matched/ s/2 list significant/2 least significant/ 3.2(M) /3.1(K) For the purpose of this specification the DS field is 8 bits long, where the 6 most... Hope this helps, Dave On Wed, Nov 18, 2009 at 7:56 AM, Laganier, Julien wr= ote: > Folks, > > As stated during the meeting, we're starting a two weeks WGLC on our "Tra= ffic Selectors for Flow Bindings" document, available at the following URL: > > > > Please review the specification, post your comments to the mailing list, = and state whether or not you think the document is ready to be forwarded to= IESG before 2009-12-02 6:00PM PST. > > Thank you for your support. > > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From dave.craig4@gmail.com Mon Nov 30 17:18:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727043A6813 for ; Mon, 30 Nov 2009 17:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeqKhHyEHrO1 for ; Mon, 30 Nov 2009 17:18:14 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id C72873A67AE for ; Mon, 30 Nov 2009 17:18:14 -0800 (PST) Received: by pxi14 with SMTP id 14so3285644pxi.31 for ; Mon, 30 Nov 2009 17:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b+iRy3/rP1vJP8vANaxoLhq5+JXBroNHYRbST9yF3qs=; b=DQbOT+pCj3LhOufzwRJgy6ztvJQUi9Z+Fv9xkx7Xpzb+aGT61xVGIHziRa8n9sDQL1 xLRpAYL8vNm0nI+Jm9U6zLJejB7f6mINOSNElfESQnOq24+Z+QwqkBM+MKxa2LDbtl/a jmzcQ8RGMZ9y9CJdVZfx+KUoOHkRH1GCDoBaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Cpr9QFxiRDMwmaVDP4Y7la3mGyYW6OIWYvhZhzLkbcHG4RySKaXPwk4OCRP15D0XAi AKLbBc2hB7r0mVHP/afeWZg0hh21MokBGsJjVCaTnpqm9xvSomxy4XDRejSsg5VDLFDk yqO6zOXzHZ9cLp7xkePoHeD6/BN9bv1ld4HBc= MIME-Version: 1.0 Received: by 10.115.84.32 with SMTP id m32mr9349318wal.7.1259630283952; Mon, 30 Nov 2009 17:18:03 -0800 (PST) In-Reply-To: <4B136025.6070200@sg.panasonic.com> References: <4B136025.6070200@sg.panasonic.com> Date: Mon, 30 Nov 2009 17:18:03 -0800 Message-ID: <40b8fe770911301718pdc26b81u7a15cb82558af2e9@mail.gmail.com> From: Dave Craig To: Benjamin Lim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:18:15 -0000 >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Source Address field. =A0This >> field MUST NOT be included unless the Start Source Address field is >> included. =A0When this field is included the receiver will match all of >> the addresses between fields (A) and (B), inclusive of (A) and (B). > > [Ben] For clarification, if it is only to match one IP address of CN, > does it mean that "(A)Start Source Address" and "(B)End Source Address" > would be of the same IP address? The same question applies to those > fields that allow specifying ranges. > > ... [Dave] I believe you may have found a way to half the number of flags and eliminate incorrectly formatted messages. What about coalescing start and end flags into a single flag that specifies whether both fields are valid? Scenario 1: no range specified * Single flag approach, flag for start&end unset * Start/end flag approach start/stop flags unset Scenario 2: single match value specified * Single flag approach, flag for start&end set, start value =3D=3D end value =3D=3D match value * Double flag approach, flag for start set, start set to match value Scenario 3: range specified * Single flag approach, flag for start&end set, start and end field values independently set * Double flag approach, flag for start and end set, start and end field values independently set Hope this helps, Dave From julienl@qualcomm.com Mon Nov 30 17:18:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9362E3A6781 for ; Mon, 30 Nov 2009 17:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.666 X-Spam-Level: X-Spam-Status: No, score=-105.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTGDeNlaNwEz for ; Mon, 30 Nov 2009 17:18:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8E89D3A6A11 for ; Mon, 30 Nov 2009 17:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259630307; x=1291166307; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Dave=20Craig=20|CC:=20"mext @ietf.org"=20,=0D=0A=20=20=20=20=20=20=20 =20"draft-ietf-mext-binary-ts@tools.ietf.org"=0D=0A=09|Date:=20Mon,=2030 =20Nov=202009=2017:18:24=20-0800|Subject:=20RE:=20[MEXT] =20[WGLC]=20draft-ietf-mext-binary-ts-01|Thread-Topic:=20 [MEXT]=20[WGLC]=20draft-ietf-mext-binary-ts-01 |Thread-Index:=20AcpyH/RtAkq3/tSXSQWG4zDGuQOjDgAAzCHQ |Message-ID:=20|References:=20=0D=0A=20<40b8fe770911301648m51b82a37o179596ab208565bc @mail.gmail.com>|In-Reply-To:=20<40b8fe770911301648m51b82 a37o179596ab208565bc@mail.gmail.com>|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5818"=3B=20a=3D"28749396"; bh=Imfv0OlxbquqVjAChJ+Ki6UHqNbJ7DGtMgR7DDBK71U=; b=L8TWGRG0muTEfoWSuJA91mJM+gn89oi6kFrc93QwYwgM/YbKZfCxmU7U pWu7nZg7Mx9YKXQ8fBMmxxZmO51jcHKsHcruA2vPAXJhuSuuLU/7KUUo8 SwMbtnwARJ3JW6A2/i7H8NWRY77fQjf6PmauqkvJZyRyEYxhV3YL4ky7j 4=; X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28749396" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 30 Nov 2009 17:18:27 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB11IRGo008686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 17:18:27 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB11IQxG020453 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Nov 2009 17:18:26 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 17:18:25 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 30 Nov 2009 17:18:26 -0800 From: "Laganier, Julien" To: Dave Craig Date: Mon, 30 Nov 2009 17:18:24 -0800 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpyH/RtAkq3/tSXSQWG4zDGuQOjDgAAzCHQ Message-ID: References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> In-Reply-To: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:18:35 -0000 Dave Craig wrote: > > [...] >=20 > 3.1. page 6, How about adding the following to the end of the SPI > field descriptions (EF), "A present SPI field does not match traffic > without an IPsec header." =A0Also applies to 3.2. page 10. Would it be simpler to say "this field MUST NOT be present if the protocol = is neither IPsec AH nor ESP"? =20 > 3.1. page 7, How about adding the following to the end of the port > field description (GHIJ), "A present port field does not match traffic > with IP protocols that do not define a transport port." =A0Also add a > reference to the port number definitions, so it is not ambiguous which > port you're talking about. > http://www.iana.org/assignments/port-numbers. I am not sure we want to cite the port-numbers registry. This seems to impl= y that only the ports as registered in the registry are legal in terms of t= his specification, and I'm not sure we want that... As to restricting the port field to protocols defining a transport port, I'= m wondering whether we want to have a provision similar to that of RFC 4306= (IKEv2) w.r.t. ICMP: For the ICMP protocol, the two one-octet fields Type and Code are treate= d as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purpos= es of filtering based on this field. --julien From julienl@qualcomm.com Mon Nov 30 17:24:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D513A686E for ; Mon, 30 Nov 2009 17:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.397 X-Spam-Level: X-Spam-Status: No, score=-105.397 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw0Sl7ZMFftp for ; Mon, 30 Nov 2009 17:24:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6D6AD3A67AE for ; Mon, 30 Nov 2009 17:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259630661; x=1291166661; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Dave=20Craig=20,=0D=0A=20 =20=20=20=20=20=20=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Mon,=2030=20Nov=202009=2017:24:18=20-0800 |Subject:=20RE:=20[MEXT]=20[WGLC]=20draft-ietf-mext-binar y-ts-01|Thread-Topic:=20[MEXT]=20[WGLC]=20draft-ietf-mext -binary-ts-01|Thread-Index:=20AcpyJCp5QzYu3ehzSJu/BUuvO7K 5bAAADPKA|Message-ID:=20|References:=20=0D=0A=09<4B136025.6070200@sg.panasonic.com> =0D=0A=20<40b8fe770911301718pdc26b81u7a15cb82558af2e9@mai l.gmail.com>|In-Reply-To:=20<40b8fe770911301718pdc26b81u7 a15cb82558af2e9@mail.gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5818"=3B=20a=3D"28749850"; bh=Ie6l3rjEJQvPn2neE7KH5OSPsXCYYjSG45eSM1fJbz0=; b=V8LR90cvReOBGfHtCHJGb2+10c9mcXW0HmMHZpVnNr25w5ZKfU5d+Vao lVIrDai8rJBdzy3M56hVC3UIozaeWM9rDlzfYMTtS5/RbAWbJk06AFmaO BgSg3VYI5b7AHtFjiEYAzCXo5SJ48iEUyDbkG+Mv9OHYsWNLSKCMRDOwl 4=; X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28749850" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 30 Nov 2009 17:24:21 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB11OLwK030293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 17:24:21 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB11OKfE008967 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Nov 2009 17:24:20 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 17:24:20 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 30 Nov 2009 17:24:20 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Mon, 30 Nov 2009 17:24:19 -0800 From: "Laganier, Julien" To: Dave Craig , Benjamin Lim Date: Mon, 30 Nov 2009 17:24:18 -0800 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpyJCp5QzYu3ehzSJu/BUuvO7K5bAAADPKA Message-ID: References: <4B136025.6070200@sg.panasonic.com> <40b8fe770911301718pdc26b81u7a15cb82558af2e9@mail.gmail.com> In-Reply-To: <40b8fe770911301718pdc26b81u7a15cb82558af2e9@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:24:29 -0000 >=20 > >> then this field can be used to indicate the end value of a range > >> starting from the value of the Start Source Address field. =A0This > >> field MUST NOT be included unless the Start Source Address field is > >> included. =A0When this field is included the receiver will match all > >> of the addresses between fields (A) and (B), inclusive of (A) and=20 > >> (B). > > > > [Ben] For clarification, if it is only to match one IP address of CN, > > does it mean that "(A)Start Source Address" and "(B)End Source > > Address" would be of the same IP address? The same question applies=20 > > to those fields that allow specifying ranges. > > > > ... >=20 > [Dave] I believe you may have found a way to half the number of flags > and eliminate incorrectly formatted messages. What about coalescing > start and end flags into a single flag that specifies whether both > fields are valid? This is what I had in mind (i.e., single flag for both start & end fields) = when I originally proposed to encode ranges instead of single values in the= traffic selectors as IKEv2 does. The current design with separate start & = end flags allows for smaller traffic selectors when single values are encod= ed, at the price of double the number of flags. It seemed like a good trade= -off. --julien =20 > Scenario 1: no range specified > * Single flag approach, flag for start&end unset > * Start/end flag approach start/stop flags unset >=20 > Scenario 2: single match value specified > * Single flag approach, flag for start&end set, start value =3D=3D end > value =3D=3D match value > * Double flag approach, flag for start set, start set to match value >=20 > Scenario 3: range specified > * Single flag approach, flag for start&end set, start and end field > values independently set > * Double flag approach, flag for start and end set, start and end > field values independently set >=20 >=20 >=20 > Hope this helps, > Dave > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From dave.craig4@gmail.com Mon Nov 30 18:07:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6233A6AB2 for ; Mon, 30 Nov 2009 18:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4AHF-obFMUO for ; Mon, 30 Nov 2009 18:07:20 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id B27FB3A6A11 for ; Mon, 30 Nov 2009 18:07:20 -0800 (PST) Received: by pwi6 with SMTP id 6so2345682pwi.29 for ; Mon, 30 Nov 2009 18:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hjBnPeJNaEpO+zBZWySypTQVlCvIuZiaklC3KnFoxi4=; b=aSwUsUn2k35ip91HgOw5erU8m9N3nLl2wEiDgWjqBQjhMn3YhRE/ArNSKQ1hwVrmBB QS/8UYW5KwQjI5wd+8FpGesp95jwkI+bsPctLscosSJJtlAkXR+j7cZYhzg2Mrtyf/Wk QNt5I7pQEi4QlwNrfOJyvnIT77H2NGYVxYNQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qQclQbza00ex+Eb/B+le+TNetGqI8bNjGacTCIKc5YC9aGMycFz7Q+6ofxTbqrks2a oyEomVMUQt+liWF8cfwHxBqTlC7zvLhQSxiOcaKPYQvTiSh0h6BH0vphk8Qhf/45ELHa /OX/v+9PXkqgwgC6OK/XJNg6+psCGLeHufHzE= MIME-Version: 1.0 Received: by 10.114.2.29 with SMTP id 29mr9436349wab.48.1259633230957; Mon, 30 Nov 2009 18:07:10 -0800 (PST) In-Reply-To: References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> Date: Mon, 30 Nov 2009 18:07:10 -0800 Message-ID: <40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com> From: Dave Craig To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 02:07:21 -0000 On Mon, Nov 30, 2009 at 5:18 PM, Laganier, Julien wr= ote: > Dave Craig wrote: >> >> [...] >> >> 3.1. page 6, How about adding the following to the end of the SPI >> field descriptions (EF), "A present SPI field does not match traffic >> without an IPsec header." =A0Also applies to 3.2. page 10. > > Would it be simpler to say "this field MUST NOT be present if the protoco= l is neither IPsec AH nor ESP"? > Both solutions would work, but is there a reason to add more verification logic and possible causes for failure messages in the protocol? >> 3.1. page 7, How about adding the following to the end of the port >> field description (GHIJ), "A present port field does not match traffic >> with IP protocols that do not define a transport port." =A0Also add a >> reference to the port number definitions, so it is not ambiguous which >> port you're talking about. >> http://www.iana.org/assignments/port-numbers. > > I am not sure we want to cite the port-numbers registry. This seems to im= ply that only the ports as registered in the registry are legal in terms of= this specification, and I'm not sure we want that... > > As to restricting the port field to protocols defining a transport port, = I'm wondering whether we want to have a provision similar to that of RFC 43= 06 (IKEv2) w.r.t. ICMP: > > =A0 For the ICMP protocol, the two one-octet fields Type and Code are tre= ated > =A0 as a single 16-bit integer (with Type in the most significant eight b= its > =A0 and Code in the least significant eight bits) port number for the pur= poses > =A0 of filtering based on this field. > Which fields would you use for a GRE packet when the filter only specifies ports? Suggest paring down the problem to match only specified protocol where you know the mapping, then. IPv6 NH also matches ICMPv6 type+code. IPv4 protocol also matches ICMP type + code. > --julien > From dave.craig4@gmail.com Mon Nov 30 18:11:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC153A6A11 for ; Mon, 30 Nov 2009 18:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXdkH0WyODMd for ; Mon, 30 Nov 2009 18:11:12 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 317373A6405 for ; Mon, 30 Nov 2009 18:11:12 -0800 (PST) Received: by pwi6 with SMTP id 6so2347779pwi.29 for ; Mon, 30 Nov 2009 18:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xxXw1qrLqvqUCTBZ8DzMsbcXqADB78lkmb/0HQuNFUE=; b=vitFmR9kjSvfYhs/aiID4OoaKh/1cqr2/0+zHpR1FpTvKe4cMnpKr+7POS0BmPqe9X PWxIEnfIfUu3myboxaVWUa4ooB9+VXuy2/LEYj/l3tSG3NFBS/myT4hCgFc0i4GYcCl7 w78a2XPina8qkcJqOa0y8UBLZlraxED8dQKfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tK/oyfXuO3dTSknyiHlc6rwKiUiTwL8ZR6zfu2G5gQuhy4mSKne9DapZcexuyeZazk d7AXMo7sbXnOpefrU6J5WrOKqhrD0arF2aZhIo81KMC8hSx3CCQjqDLGWSc90gTuy/lm kAbaj+TtNyLobo/sfipmab+7rIoJMVlwn/OF8= MIME-Version: 1.0 Received: by 10.114.2.29 with SMTP id 29mr9445286wab.48.1259633464536; Mon, 30 Nov 2009 18:11:04 -0800 (PST) In-Reply-To: References: <4B136025.6070200@sg.panasonic.com> <40b8fe770911301718pdc26b81u7a15cb82558af2e9@mail.gmail.com> Date: Mon, 30 Nov 2009 18:11:04 -0800 Message-ID: <40b8fe770911301811o242c90daje8afcdc53d2da95f@mail.gmail.com> From: Dave Craig To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 02:11:13 -0000 On Mon, Nov 30, 2009 at 5:24 PM, Laganier, Julien wr= ote: >> >> >> then this field can be used to indicate the end value of a range >> >> starting from the value of the Start Source Address field. =A0This >> >> field MUST NOT be included unless the Start Source Address field is >> >> included. =A0When this field is included the receiver will match all >> >> of the addresses between fields (A) and (B), inclusive of (A) and >> >> (B). >> > >> > [Ben] For clarification, if it is only to match one IP address of CN, >> > does it mean that "(A)Start Source Address" and "(B)End Source >> > Address" would be of the same IP address? The same question applies >> > to those fields that allow specifying ranges. >> > >> > ... >> >> [Dave] I believe you may have found a way to half the number of flags >> and eliminate incorrectly formatted messages. =A0What about coalescing >> start and end flags into a single flag that specifies whether both >> fields are valid? > > This is what I had in mind (i.e., single flag for both start & end fields= ) when I originally proposed to encode ranges instead of single values in t= he traffic selectors as IKEv2 does. The current design with separate start = & end flags allows for smaller traffic selectors when single values are enc= oded, at the price of double the number of flags. It seemed like a good tra= de-off. > > --julien I misinterpreted "present" as "valid". Ok Dave