From jouni.nospam@gmail.com Mon Apr 1 23:56:05 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1521F9884 for ; Mon, 1 Apr 2013 23:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWWt2QQJ5CVl for ; Mon, 1 Apr 2013 23:56:05 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65921F9883 for ; Mon, 1 Apr 2013 23:56:01 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so88352lab.19 for ; Mon, 01 Apr 2013 23:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=WJnKncKLq1hhL9EdPhZ8WKnkvXKcSisAEOMVlMmzzeI=; b=k+bIbzOWL/VOCkETVa4eWg7D0E2lSlMpzyRPh6rDQsW7hkno1eGkurnwM0QH5pWsZZ LAWpQNuU0KS/ZcLayGlfZNav87QgDU81z1PjhgzuPWxxC+j9DLtQPrxDXQfyUwsROVBS FfjMssxRlrwFOYC3CtPH9iuvJEAneNRCmHpYxvRTenXUYZFkP/TER5uKGQEYBt8yQeVI ObcO6bXzwjuHWRc8nHdR3U4+S35iwflcyr8LYVSwdrtANalAnMtQ6uWNH2IZ6HIsFykM qgevl8fvd9AtaL4stS8fJiOaMkLApUk5zltQprOE4aEv/Vz29S2lnrDsas2T8+Wpgzf7 S6xw== X-Received: by 10.112.163.130 with SMTP id yi2mr1723670lbb.79.1364885760296; Mon, 01 Apr 2013 23:56:00 -0700 (PDT) Received: from [192.168.250.135] ([194.100.71.98]) by mx.google.com with ESMTPS id sl5sm277200lbb.10.2013.04.01.23.55.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 23:55:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 2 Apr 2013 09:55:56 +0300 Content-Transfer-Encoding: 7bit Message-Id: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> References: To: "dmm@ietf.org" , h chan X-Mailer: Apple Mail (2.1503) Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 06:56:05 -0000 Just a reminder. There has been zero WGLC reviews so far.. - Jouni On Mar 20, 2013, at 7:06 AM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > The issues, even editorials, should be recorded into the Issue Tracker > for a control tracking whether everything has been addressed. We > require minimum three reviews. The more the better, though. > > The WGLC ends on Wednesday 3rd April. > > - Jouni & Julien From Marco.Liebsch@neclab.eu Wed Apr 3 07:45:22 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C521F8B9C for ; Wed, 3 Apr 2013 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tgC7wxu4BPI for ; Wed, 3 Apr 2013 07:45:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5981321F8B9B for ; Wed, 3 Apr 2013 07:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BA2B2103A4F; Wed, 3 Apr 2013 16:45:20 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0g423xfsrx7; Wed, 3 Apr 2013 16:45:20 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 9DF231034BE; Wed, 3 Apr 2013 16:45:05 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.4]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 3 Apr 2013 16:44:15 +0200 From: Marco Liebsch To: Julien Laganier , Behcet Sarikaya Thread-Topic: [DMM] DMM framework vs architecture Thread-Index: Ac4jwyd0o5dubgjlTAOiOiBKbgiAVAI0eH0AAADwzQAA95IE0A== Date: Wed, 3 Apr 2013 14:44:15 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D55213FA7@DAPHNIS.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551E82A4@PALLENE.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM framework vs architecture X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:45:22 -0000 Julien,=20 not sure what you mean with moot. We are aware that a framework is not yet considered by the charter. And I agree that the WG's focus should be on the current charter items. However, the group is discussing requirements now fo= r 1.5 years.. Looking ahead now and providing input that can help the WG to progress does not seem to be a bad idea, IMHO. And there was some support from the WG for having a framework. marco =20 >-----Original Message----- >From: Julien Laganier [mailto:julien.ietf@gmail.com] >Sent: Freitag, 29. M=E4rz 2013 18:17 >To: Behcet Sarikaya >Cc: Marco Liebsch; dmm@ietf.org >Subject: Re: [DMM] DMM framework vs architecture > >Hi Marco, > >I guess the point I made you are referring to is moot, given the timeline = for the >DMM work. At this stage we are looking at completing the gap analysis as s= oon >as possible and we would like all the group's energy to focus on that crit= ical step. > >Best, > >--julien > >On Fri, Mar 29, 2013 at 9:49 AM, Behcet Sarikaya >wrote: >> Hi Marco, >> >> Sorry to interfere as this mail was not addressed to me. >> >> On Mon, Mar 18, 2013 at 5:45 AM, Marco Liebsch >> >> wrote: >>> >>> Julien, all, >>> >>> let me comment to your statement in Orlando about the DMM framework >>> draft-liebsch-dmm-framework-analysis: >>> >>> You commented that the framework assumes an architecture. Well, yes, >>> a 'functional' architecture as it's always done by a functional framewo= rk. >>> We identify functional entities and dependencies between these function= s. >>> Dependencies are coordinated via reference points/interfaces between >>> these functions. Functions can be co-located to a single protocol >>> architecture component or distributed. Functions and reference points >>> may apply to a solution or may not, dependent on the targeted >>> protocol support and requirements. >>> So, the draft does not go beyond what a framework should do. >>> It simply supports building any protocol solution without being >>> dependent on the underlaying protocols. >>> >>> Please see e.g. RFC 3154, which did the same for Dormant Mode Host >>> Alerting. >>> The approach applies to many other frameworks. >>> >> >> I am one of the co-authors of RFC 3154. >> It was nostalgic for me to see your reference to this work. I believe >> that IETF missed a good opportunity to make some difference in mobile >> networks by staying out of developing an IP based paging protocol. >> >> I think you are referring to Section 5 in this document. >> The functional architecture in Section 5 was an obvious one, it was >> built on widely agreed components and their connections. >> >> I can not see how you are going to project it to the DMM case? In dmm >> we do not yet have the same consensus on the architectural entities. >> Until then it is good to keep different choices up and help build >> consensus on one such thing whatever it is. >> >> Behcet >>> >>> Hope you can agree to this approach. >>> >>> marco >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> From sarikaya2012@gmail.com Wed Apr 3 12:58:58 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3152021F874E for ; Wed, 3 Apr 2013 12:58:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqO8TYD-VC9c for ; Wed, 3 Apr 2013 12:58:57 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9721F86E3 for ; Wed, 3 Apr 2013 12:58:57 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so1818262lab.37 for ; Wed, 03 Apr 2013 12:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WJLSe6KZJ9UkSewir8DYSwfaasrdJHWdfuFe0JatUDQ=; b=r7JueeoNo2CLr5uqh4tuX+sC9nzaC5psdO0yrd0CJFuY0FpCDKsSrojmCbxGTM2/qQ RbccisFaxwslCSucHE6NpG3YGPg9vGoKkU/a1Jf/ga58FhDkcn39NF3vb/XRif0cTKwh KCehVVMG0EALSdoAtpkrvPjw9QwrAmaY0XA1oA3uEZULV+VJQrXIeQhog+X/P4alriFL lIHsDXRwnqzfiYPLDMsqLZTNkA97MZuI16yvKawXCTs+GxQuboGvDDMuV33pGDFDjcr8 L2f8t0U7oKbY8gXFsvIdiHqAJF753F7u+lYrDkBTcDVp6LtvCNKRpzCWlCR81bIttjwY yJzA== MIME-Version: 1.0 X-Received: by 10.112.43.198 with SMTP id y6mr1817637lbl.93.1365019136155; Wed, 03 Apr 2013 12:58:56 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Wed, 3 Apr 2013 12:58:56 -0700 (PDT) In-Reply-To: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> Date: Wed, 3 Apr 2013 14:58:56 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=bcaec52d4d31b8eaa704d97a482b Cc: "dmm@ietf.org" , dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:58:58 -0000 --bcaec52d4d31b8eaa704d97a482b Content-Type: text/plain; charset=ISO-8859-1 Hi all, If Section 4.7 is removed, I am willing to support this call. The reason: it is immature to say anything on this issue even as a should. Regards, Behcet On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen wrote: > > Just a reminder. There has been zero WGLC reviews so far.. > > - Jouni > > > On Mar 20, 2013, at 7:06 AM, Jouni Korhonen > wrote: > > > Folks, > > > > This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > > The issues, even editorials, should be recorded into the Issue Tracker > > for a control tracking whether everything has been addressed. We > > require minimum three reviews. The more the better, though. > > > > The WGLC ends on Wednesday 3rd April. > > > > - Jouni & Julien > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --bcaec52d4d31b8eaa704d97a482b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

If Section 4.7 is removed, I am willing to support this call= .

The reason: it is immature to say anything on this issue even as a= should.

Regards,

Behcet


On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen <jouni.nospam@gmail.co= m> wrote:

Just a reminder. There has been zero WGLC reviews so far..

- Jouni


On Mar 20, 2013, at 7:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

> Folks,
>
> This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > The issues, even editorials, should be recorded into the Issue Tracker=
> for a control tracking whether everything has been addressed. We
> require minimum three reviews. The more the better, though.
>
> The WGLC ends on Wednesday 3rd April.
>
> - Jouni & Julien

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--bcaec52d4d31b8eaa704d97a482b-- From seiljeon@av.it.pt Wed Apr 3 13:26:13 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014A621F8C9A for ; Wed, 3 Apr 2013 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8RDh517ECDG for ; Wed, 3 Apr 2013 13:26:12 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id DE77A21F8C26 for ; Wed, 3 Apr 2013 13:26:11 -0700 (PDT) Received: from [193.136.93.96] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 68547931; Wed, 03 Apr 2013 21:26:09 +0100 From: "Seil Jeon" To: References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> In-Reply-To: Date: Wed, 3 Apr 2013 21:26:09 +0100 Message-ID: <001501ce30a9$7a120290$6e3607b0$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CE30B1.DBD8B480" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1Vb4QRmrWDQY1UjfElFXACk1enAJyWx+2AhIHk5iYUoFY4A== Content-Language: ko Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 20:26:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01CE30B1.DBD8B480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Behcet and all, With regards to what you said, I believe it was already answered several times in the list while it was made. Regards, Seil From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Wednesday, April 03, 2013 8:59 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 Hi all, If Section 4.7 is removed, I am willing to support this call. The reason: it is immature to say anything on this issue even as a should. Regards, Behcet On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen wrote: Just a reminder. There has been zero WGLC reviews so far.. - Jouni On Mar 20, 2013, at 7:06 AM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > The issues, even editorials, should be recorded into the Issue Tracker > for a control tracking whether everything has been addressed. We > require minimum three reviews. The more the better, though. > > The WGLC ends on Wednesday 3rd April. > > - Jouni & Julien _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ------=_NextPart_000_0016_01CE30B1.DBD8B480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Behcet and all,

 

With regards to what you said, I believe it was already answered = several times in the list while it was made.

 

Regards,

 

Seil

 

From:= = dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Behcet Sarikaya
Sent: Wednesday, April 03, 2013 8:59 = PM
To: Jouni Korhonen
Cc: dmm@ietf.org; = dmm-chairs@tools.ietf.org
Subject: Re: [DMM] WGLC starts for = draft-ietf-dmm-requirements-03

 

Hi all,

If Section 4.7 is removed, = I am willing to support this call.

The reason: it is immature to = say anything on this issue even as a should. =

Regards,

Behcet

On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Just a reminder. There has been zero WGLC reviews = so far..

- = Jouni



On Mar 20, 2013, at 7:06 AM, Jouni Korhonen = <jouni.nospam@gmail.com> = wrote:

> Folks,
>
> This mail starts a two week = WGLC for draft-ietf-dmm-requirements-03.
> The issues, even = editorials, should be recorded into the Issue Tracker
> for a = control tracking whether everything has been addressed. We
> = require minimum three reviews. The more the better, = though.
>
> The WGLC ends on Wednesday 3rd = April.
>
> - Jouni & = Julien

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

 

------=_NextPart_000_0016_01CE30B1.DBD8B480-- From karagian@cs.utwente.nl Wed Apr 3 19:34:46 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898D11E80A4 for ; Wed, 3 Apr 2013 19:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-mzVyu+vqea for ; Wed, 3 Apr 2013 19:34:45 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id C364511E80A2 for ; Wed, 3 Apr 2013 19:34:44 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 4 Apr 2013 04:34:43 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Thu, 4 Apr 2013 04:34:42 +0200 From: To: , Thread-Topic: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOJSis6g/kUYXtEkOk75snvKj52pjCcmYAgAJtGgCAAAebgIAAh+CUgAAAovY= Date: Thu, 4 Apr 2013 02:34:41 +0000 Message-ID: References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> , <001501ce30a9$7a120290$6e3607b0$@av.it.pt> In-Reply-To: <001501ce30a9$7a120290$6e3607b0$@av.it.pt> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37AC10EXMBX23adutwent_" MIME-Version: 1.0 Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 02:34:46 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37AC10EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Seil, What is the issue with Section 4.7? Do we need to modify it, or is a requirement related multicast excluded fro= m what the DMM WG needs to focus on? Best regards, Georgios ________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Seil Jeon [seiljeon= @av.it.pt] Verzonden: woensdag 3 april 2013 22:26 To: sarikaya@ieee.org Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Onderwerp: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 Hi Behcet and all, With regards to what you said, I believe it was already answered several ti= mes in the list while it was made. Regards, Seil From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Behce= t Sarikaya Sent: Wednesday, April 03, 2013 8:59 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 Hi all, If Section 4.7 is removed, I am willing to support this call. The reason: it is immature to say anything on this issue even as a should. Regards, Behcet On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen > wrote: Just a reminder. There has been zero WGLC reviews so far.. - Jouni On Mar 20, 2013, at 7:06 AM, Jouni Korhonen > wrote: > Folks, > > This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > The issues, even editorials, should be recorded into the Issue Tracker > for a control tracking whether everything has been addressed. We > require minimum three reviews. The more the better, though. > > The WGLC ends on Wednesday 3rd April. > > - Jouni & Julien _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37AC10EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Seil,

 

What is the issue with Section 4.7?

Do we need to modify it, or is a requirement related multicast excluded = from what the DMM WG needs to focus on?

 

Best regards,

Georgios

Van: dmm-bounces@ietf.org [dmm-bounces@iet= f.org] namens Seil Jeon [seiljeon@av.it.pt]
Verzonden: woensdag 3 april 2013 22:26
To: sarikaya@ieee.org
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Onderwerp: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03<= br>

Hi Behcet and all,

 

With regards to what you said, I believe it = was already answered several times in the list while it was made.

 

Regards,

 

Seil

 

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.= org] On Behalf Of Behcet Sarikaya
Sent: Wednesday, April 03, 2013 8:59 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03

 

Hi all,

If Section 4.7 is removed, I am willing to support this call.

The reason: it is immature to say anything on this issue even as a should. =

Regards,

Behcet

On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen <<= a href=3D"mailto:jouni.nospam@gmail.com" target=3D"_blank">jouni.nospam@gma= il.com> wrote:


Just a reminder. There has been zero WGLC reviews so far..

- Jouni



On Mar 20, 2013, at 7:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

> Folks,
>
> This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > The issues, even editorials, should be recorded into the Issue Tracker=
> for a control tracking whether everything has been addressed. We
> require minimum three reviews. The more the better, though.
>
> The WGLC ends on Wednesday 3rd April.
>
> - Jouni & Julien

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37AC10EXMBX23adutwent_-- From Marco.Liebsch@neclab.eu Thu Apr 4 01:32:19 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2DD21F9632 for ; Thu, 4 Apr 2013 01:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRbN8YmWbZ07 for ; Thu, 4 Apr 2013 01:32:19 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 16BDF21F9630 for ; Thu, 4 Apr 2013 01:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AA548103A71; Thu, 4 Apr 2013 10:32:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAq+LHPQspUw; Thu, 4 Apr 2013 10:32:15 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 8F0B81034BE; Thu, 4 Apr 2013 10:31:55 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 4 Apr 2013 10:31:55 +0200 From: Marco Liebsch To: "sarikaya@ieee.org" , Jouni Korhonen Thread-Topic: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOJSi0081TDxXyP0a64unmt/Y1RZjCcmYAgAJtGgCAAPGqIA== Date: Thu, 4 Apr 2013 08:31:31 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:32:19 -0000 I do not have a strong opinion on 4.7, but adding such requirement came from Multimob. Now you propose removing this requirement again. Does it mean you do not want to have it in at all? If yes, why? Another option is that the Multimob group proposes alternative text to be more concrete about a multicast requirement according to the Multimob group's view how this should be covered. marco >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >Behcet Sarikaya >Sent: Mittwoch, 3. April 2013 21:59 >To: Jouni Korhonen >Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org >Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 > >Hi all, > >If Section 4.7 is removed, I am willing to support this call. > >The reason: it is immature to say anything on this issue even as a should. > >Regards, > >Behcet > > > >On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen >wrote: > > > > Just a reminder. There has been zero WGLC reviews so far.. > > - Jouni > > > > On Mar 20, 2013, at 7:06 AM, Jouni Korhonen > wrote: > > > Folks, > > > > This mail starts a two week WGLC for draft-ietf-dmm-requirements- >03. > > The issues, even editorials, should be recorded into the Issue Tracker > > for a control tracking whether everything has been addressed. We > > require minimum three reviews. The more the better, though. > > > > The WGLC ends on Wednesday 3rd April. > > > > - Jouni & Julien > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From jouni.nospam@gmail.com Thu Apr 4 01:41:49 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E621F8573 for ; Thu, 4 Apr 2013 01:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsmkSORQQyGx for ; Thu, 4 Apr 2013 01:41:48 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 15AB521F8556 for ; Thu, 4 Apr 2013 01:41:47 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so2222356lab.5 for ; Thu, 04 Apr 2013 01:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=iMFQA+QnALjuraqNYYStkiWMeEeiiSd//GWZkbKXvrc=; b=hl8aJJtyu+wC/u4Utf1SVU5KfHDREro7grCkq0o9lNPApErVX+3tO65/s+++cRbk4o jLRsVgkB3i2aVq1hpF0yJSJOGTP9yMr0tc7L2gzxZoRmN7spQiXDSXSJuDPIJxDUxIXJ j5w13My9mx6oAsO4OVUn28pfM32NApW/Cd7uOe5MKG1T3dx6BmLSH6TZ4uoMVNKGWYp8 k5zKiNLFrJ8ZCCTdXYGw0kI+to68Je3aOIwYU/hNoA+qK2ajkmC8b2FJwvMyFIKKKsHG DPQ7MBHXb+CrFA3S0pbx+vp3ioksG1NMke1cM2exG0hU6eQWN4AHjeP37cUoeTeExNgM su8g== X-Received: by 10.112.136.33 with SMTP id px1mr2851043lbb.95.1365064907042; Thu, 04 Apr 2013 01:41:47 -0700 (PDT) Received: from [192.168.250.45] ([194.100.71.98]) by mx.google.com with ESMTPS id i3sm3605623lbn.0.2013.04.04.01.41.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 01:41:45 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 4 Apr 2013 11:41:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1503) Cc: "dmm@ietf.org" , dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:41:49 -0000 Behcet, You know very well why the Section 4.7 got inserted into the document in the first place. If you have specific issues with the current text, point those out and propose modifications. - Jouni On Apr 3, 2013, at 10:58 PM, Behcet Sarikaya = wrote: > Hi all, >=20 > If Section 4.7 is removed, I am willing to support this call. >=20 > The reason: it is immature to say anything on this issue even as a = should.=20 >=20 > Regards, >=20 > Behcet >=20 >=20 > On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen = wrote: >=20 > Just a reminder. There has been zero WGLC reviews so far.. >=20 > - Jouni >=20 >=20 > On Mar 20, 2013, at 7:06 AM, Jouni Korhonen = wrote: >=20 > > Folks, > > > > This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. > > The issues, even editorials, should be recorded into the Issue = Tracker > > for a control tracking whether everything has been addressed. We > > require minimum three reviews. The more the better, though. > > > > The WGLC ends on Wednesday 3rd April. > > > > - Jouni & Julien >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 From jouni.nospam@gmail.com Thu Apr 4 01:45:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF05421F940D for ; Thu, 4 Apr 2013 01:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L63+oJPHWeyY for ; Thu, 4 Apr 2013 01:45:37 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D421F9408 for ; Thu, 4 Apr 2013 01:45:36 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id q13so2411826lbi.23 for ; Thu, 04 Apr 2013 01:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=sBASDQD3dXYreccQtroyq9maLLafq4PScKR7jr+NEF0=; b=jGG8Y+9N9swq4h1nPqabgpumxcnu6X2/hH001usTKiFBC1lOXycOdjdCr448oHZbHk VrWLJnqvtIH0mPH/BZ1JHBngXvZ2bGRK4pYbyr4cYVYXXVmSiWuzJxTL23JEqvwEM6Xf LOG06fPz7Pl/UA5n5xzU38P4Qx3W6rqko8j1I48VhaUOf3KdevbFMcV1NuJ4C9D0tLHJ MQiUZaetQ6kXjuhZTWfwb++ozdOzVhnzXJu6zF+kSTBSv345a8gmEEotHKwYuJFXF6wl l/jI/qHoV4xK2mXCQCyzfScIbdEwERODZIE11dSmINRLucIbawiPy5WXVKL+wpAV/0k6 M4Tg== X-Received: by 10.112.100.166 with SMTP id ez6mr2869413lbb.86.1365065135687; Thu, 04 Apr 2013 01:45:35 -0700 (PDT) Received: from [192.168.250.45] ([194.100.71.98]) by mx.google.com with ESMTPS id z1sm3606167lbk.2.2013.04.04.01.45.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 01:45:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> Date: Thu, 4 Apr 2013 11:45:31 +0300 Content-Transfer-Encoding: 7bit Message-Id: <48141844-7F2D-48E0-AD8A-BEFD364C77CE@gmail.com> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> To: "dmm@ietf.org" , h chan X-Mailer: Apple Mail (2.1503) Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:45:37 -0000 Folk, Due the lack of feedback, the I-D did not pass the WGLC. We'll initiate another one soon. - Jouni On Apr 2, 2013, at 9:55 AM, Jouni Korhonen wrote: > > Just a reminder. There has been zero WGLC reviews so far.. > > - Jouni > > > On Mar 20, 2013, at 7:06 AM, Jouni Korhonen wrote: > >> Folks, >> >> This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. >> The issues, even editorials, should be recorded into the Issue Tracker >> for a control tracking whether everything has been addressed. We >> require minimum three reviews. The more the better, though. >> >> The WGLC ends on Wednesday 3rd April. >> >> - Jouni & Julien > From julien.ietf@gmail.com Thu Apr 4 08:27:40 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8721F9605 for ; Thu, 4 Apr 2013 08:27:40 -0700 (PDT) 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=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni2+cbHGuq5t for ; Thu, 4 Apr 2013 08:27:39 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85321F9600 for ; Thu, 4 Apr 2013 08:27:39 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hz11so2418260vcb.23 for ; Thu, 04 Apr 2013 08:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=i3Z7KQjkh2dzsoPZQxInuPWRCy/ko13pveJObB6bec0=; b=hPu3opPwNSYZtnZ8uQQ3wP8/KdNs/G8RWb4Y3/S0QgQIMc7bHDuoIuSeTgjAAuOmha 1dgET4c8aEmdcWofqFXvmbadZf8WTH/g0VusMXkqGJiPBolqFOeIdR/uAh9VedHK4/iF NVQQ2WMtpUQ0s3iK5xHGh13Q8zYCyX2jP6bzUjaTrkSIJtKCd4bFcNEb/5Ze+MBpdJtk Wk5A4rxDH9V1eV4iF+ZbaP/IhNQdQJAVfDlzVGzBtvAzugZIWt2lbRxUl8XNcRf8fQOc atieM5xF4Ez+dvosUjKXD6KgUMl49SmxILUahXDCmYVEoArkoaTa395+meE4as1JZxLL pZcg== MIME-Version: 1.0 X-Received: by 10.220.153.143 with SMTP id k15mr5108606vcw.33.1365089259075; Thu, 04 Apr 2013 08:27:39 -0700 (PDT) Received: by 10.52.63.52 with HTTP; Thu, 4 Apr 2013 08:27:39 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D55213FA7@DAPHNIS.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551E82A4@PALLENE.office.hd> <69756203DDDDE64E987BC4F70B71A26D55213FA7@DAPHNIS.office.hd> Date: Thu, 4 Apr 2013 08:27:39 -0700 Message-ID: From: Julien Laganier To: Marco Liebsch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM framework vs architecture X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:27:40 -0000 As I said for the time being we'd like the WG to focus on completing the existing deliverables. Thank you. On Wed, Apr 3, 2013 at 7:44 AM, Marco Liebsch wro= te: > Julien, > not sure what you mean with moot. We are aware that a framework is not ye= t > considered by the charter. And I agree that the WG's focus should be on t= he > current charter items. However, the group is discussing requirements now = for > 1.5 years.. Looking ahead now and providing input that can help the WG to > progress does not seem to be a bad idea, IMHO. And there was some support > from the WG for having a framework. > > marco > > > > >>-----Original Message----- >>From: Julien Laganier [mailto:julien.ietf@gmail.com] >>Sent: Freitag, 29. M=E4rz 2013 18:17 >>To: Behcet Sarikaya >>Cc: Marco Liebsch; dmm@ietf.org >>Subject: Re: [DMM] DMM framework vs architecture >> >>Hi Marco, >> >>I guess the point I made you are referring to is moot, given the timeline= for the >>DMM work. At this stage we are looking at completing the gap analysis as = soon >>as possible and we would like all the group's energy to focus on that cri= tical step. >> >>Best, >> >>--julien >> >>On Fri, Mar 29, 2013 at 9:49 AM, Behcet Sarikaya >>wrote: >>> Hi Marco, >>> >>> Sorry to interfere as this mail was not addressed to me. >>> >>> On Mon, Mar 18, 2013 at 5:45 AM, Marco Liebsch >>> >>> wrote: >>>> >>>> Julien, all, >>>> >>>> let me comment to your statement in Orlando about the DMM framework >>>> draft-liebsch-dmm-framework-analysis: >>>> >>>> You commented that the framework assumes an architecture. Well, yes, >>>> a 'functional' architecture as it's always done by a functional framew= ork. >>>> We identify functional entities and dependencies between these functio= ns. >>>> Dependencies are coordinated via reference points/interfaces between >>>> these functions. Functions can be co-located to a single protocol >>>> architecture component or distributed. Functions and reference points >>>> may apply to a solution or may not, dependent on the targeted >>>> protocol support and requirements. >>>> So, the draft does not go beyond what a framework should do. >>>> It simply supports building any protocol solution without being >>>> dependent on the underlaying protocols. >>>> >>>> Please see e.g. RFC 3154, which did the same for Dormant Mode Host >>>> Alerting. >>>> The approach applies to many other frameworks. >>>> >>> >>> I am one of the co-authors of RFC 3154. >>> It was nostalgic for me to see your reference to this work. I believe >>> that IETF missed a good opportunity to make some difference in mobile >>> networks by staying out of developing an IP based paging protocol. >>> >>> I think you are referring to Section 5 in this document. >>> The functional architecture in Section 5 was an obvious one, it was >>> built on widely agreed components and their connections. >>> >>> I can not see how you are going to project it to the DMM case? In dmm >>> we do not yet have the same consensus on the architectural entities. >>> Until then it is good to keep different choices up and help build >>> consensus on one such thing whatever it is. >>> >>> Behcet >>>> >>>> Hope you can agree to this approach. >>>> >>>> marco >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> From jouni.nospam@gmail.com Thu Apr 4 23:23:26 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C6E21F8FEC for ; Thu, 4 Apr 2013 23:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.089 X-Spam-Level: X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTcEOo7a3+FZ for ; Thu, 4 Apr 2013 23:23:25 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB0521F8FEB for ; Thu, 4 Apr 2013 23:23:25 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r10so3379694lbi.22 for ; Thu, 04 Apr 2013 23:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=PwN0jtbSvRjU7x4ByPGqldNjVe/k0XZ4s9OuArc2yQ0=; b=tnWe+n9TOcqA8yvPl253A6IvYcCWUDuV5Mu5WLqgOHGhRxMUP38SHmeQYrv3MTbpp4 Cez3zP4KS2N4nxhfvSwost+TY+WiiZCpQr/+XgrlqJzZM8uiU2qlyul3XjWxJXW3dpsp ofjBQZidFu6IUxpXva9c/eq5CXJ+zusOUfQpSxqQTpKYydDvrSdjjlIXKD7wEoocHrQ4 GSPuCDa70uyMZIStfxyimIhAYilMmoQ+oqa34b+OE6QZv1PR8khYoKLx/9/dz8AshEOa e1z4IwXkviE2vjz86SZkCfHFuxs6hnQTkDk+VNZJLWC/Yo/2r+CR80I3TN3sN1gpFKxm 65iA== X-Received: by 10.152.47.242 with SMTP id g18mr5165947lan.42.1365143004259; Thu, 04 Apr 2013 23:23:24 -0700 (PDT) Received: from [192.168.250.119] ([194.100.71.98]) by mx.google.com with ESMTPS id jh4sm5116843lab.7.2013.04.04.23.23.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 23:23:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <48141844-7F2D-48E0-AD8A-BEFD364C77CE@gmail.com> Date: Fri, 5 Apr 2013 09:23:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <306E62E9-9A04-4AEB-82FE-D88CF32BB34E@gmail.com> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <48141844-7F2D-48E0-AD8A-BEFD364C77CE@gmail.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1503) Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 06:23:26 -0000 Folks, I hope you as a WG realise we are stuck with the next steps and possible future work/rechartering etc until we get some of the existing milestones completed. That involves: 1) getting requirements out of the WG 2) getting the gap analysis into the state that we can really pinpoint the gaps that cannot be solved with current deployment practises Recruiting people outside the (plentiful) authors to do a proper review (i.e., a bit more challenging than a one liner) should not be an overwhelming task.. The DMM list itself has 795 members.=20 - Jouni & Julien On Apr 4, 2013, at 11:45 AM, Jouni Korhonen = wrote: >=20 > Folk, >=20 > Due the lack of feedback, the I-D did not pass the WGLC. We'll > initiate another one soon.=20 >=20 > - Jouni >=20 >=20 > On Apr 2, 2013, at 9:55 AM, Jouni Korhonen = wrote: >=20 >>=20 >> Just a reminder. There has been zero WGLC reviews so far..=20 >>=20 >> - Jouni >>=20 >>=20 >> On Mar 20, 2013, at 7:06 AM, Jouni Korhonen = wrote: >>=20 >>> Folks, >>>=20 >>> This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. >>> The issues, even editorials, should be recorded into the Issue = Tracker >>> for a control tracking whether everything has been addressed. We >>> require minimum three reviews. The more the better, though. >>>=20 >>> The WGLC ends on Wednesday 3rd April. >>>=20 >>> - Jouni & Julien >>=20 >=20 From sarikaya2012@gmail.com Mon Apr 8 12:46:03 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883421F9401 for ; Mon, 8 Apr 2013 12:46:03 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaKU+s9ySlS1 for ; Mon, 8 Apr 2013 12:46:02 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BA9CC21F949A for ; Mon, 8 Apr 2013 12:46:01 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs12so1035459lab.8 for ; Mon, 08 Apr 2013 12:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:date:message-id:subject:from:to :content-type; bh=GvXQdsuxba6d/UyuHrR6LSkNx6+QG7MQ1tM4MEWTDq4=; b=HnkNyoNy5pbZgGspLEEXz84MvGPsBfaQf5fFdOl6IpOi+fFZqcWSt2SvLgPebFxoMj DUXIQoxfRzQREKG5QaCs5WncnUr8IBk8z6825i5kIriw3IcsOX+9a4G1Of7fkKr3E7mC LCN6vrSATBEU5QO+QVlkKGw4NutTK0uQHyEsbElwmu7S65uQf9lQp86azDA4qlj9Cepf x1e4Rwpz91U9iveGLdb1AaN27csAAkYCyJDVWgPuESNSEA3Om8r+voVAaJ8WcCf8wqFa Ulhlz4fQsSlCnaJyk+dJrILS+BIuE2rMEmpPfrQlopJEOzbT84XG3v0dfnDtF7Tjukkz UdWw== MIME-Version: 1.0 X-Received: by 10.112.173.169 with SMTP id bl9mr12017532lbc.37.1365450360325; Mon, 08 Apr 2013 12:46:00 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Mon, 8 Apr 2013 12:45:59 -0700 (PDT) Date: Mon, 8 Apr 2013 14:45:59 -0500 Message-ID: From: Behcet Sarikaya To: dmm@ietf.org Content-Type: multipart/alternative; boundary=001a11c3275caf8db604d9deaf11 Subject: [DMM] Section 4.7 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:46:04 -0000 --001a11c3275caf8db604d9deaf11 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, all, I have concerns on the text in this section. It seems like this text has mainly been contributed by Seil. No offense to Seil, please. Let me explain the background here: when DMM discussed some solution proposals in the past, in Multimob, we had a few out of charter slots to discuss DMM multicast. Seil was a presenter. We had other presenters as well. The discussions produced no consensus. Since then we stopped such discussions. Also, let me explain the background on RFC 6224 here: Multimob developed RFC 6224 with the first charter which required no protocol extensions. Since then this requirement has been removed and we developed some solutions we might even develop an alternative solution. Hope this clarifies my concern. Regards, Behcet --001a11c3275caf8db604d9deaf11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jouni, all,

I have concerns on the text in this section.
It se= ems like this text has mainly been contributed by Seil.
No offense to Se= il, please.

Let me explain the background here: when DMM discussed s= ome solution proposals in the past, in Multimob, we had a few out of charte= r slots to discuss DMM multicast. Seil was a presenter. We had other presen= ters as well.

The discussions produced no consensus. Since then we stopped such discu= ssions.

Also, let me explain the background on RFC 6224 here:
Mul= timob developed RFC 6224 with the first charter which required no protocol = extensions. Since then this requirement has been removed and we developed s= ome solutions we might even develop an alternative solution.

Hope this clarifies my concern.

Regards,

Behcet
--001a11c3275caf8db604d9deaf11-- From stig@venaas.com Mon Apr 8 13:12:25 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454321F92EF for ; Mon, 8 Apr 2013 13:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enXbtv6VJlfL for ; Mon, 8 Apr 2013 13:12:24 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 653B021F9298 for ; Mon, 8 Apr 2013 13:12:24 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 40730806B; Mon, 8 Apr 2013 22:12:22 +0200 (CEST) Message-ID: <51632454.2020405@venaas.com> Date: Mon, 08 Apr 2013 13:11:00 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jouni Korhonen References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <48141844-7F2D-48E0-AD8A-BEFD364C77CE@gmail.com> <306E62E9-9A04-4AEB-82FE-D88CF32BB34E@gmail.com> In-Reply-To: <306E62E9-9A04-4AEB-82FE-D88CF32BB34E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:12:25 -0000 On 4/4/2013 11:23 PM, Jouni Korhonen wrote: > > Folks, > > I hope you as a WG realise we are stuck with the next steps > and possible future work/rechartering etc until we get some > of the existing milestones completed. That involves: FWIW, the document looks good to me. I know the WGLC has ended though, and I haven't followed the discussions in the wg as closely as I should, so I don't know how well it matches the view of the group. Stig > 1) getting requirements out of the WG > 2) getting the gap analysis into the state that we can > really pinpoint the gaps that cannot be solved with > current deployment practises > > Recruiting people outside the (plentiful) authors to do a > proper review (i.e., a bit more challenging than a one liner) > should not be an overwhelming task.. The DMM list itself has > 795 members. > > - Jouni & Julien > > > On Apr 4, 2013, at 11:45 AM, Jouni Korhonen wrote: > >> >> Folk, >> >> Due the lack of feedback, the I-D did not pass the WGLC. We'll >> initiate another one soon. >> >> - Jouni >> >> >> On Apr 2, 2013, at 9:55 AM, Jouni Korhonen wrote: >> >>> >>> Just a reminder. There has been zero WGLC reviews so far.. >>> >>> - Jouni >>> >>> >>> On Mar 20, 2013, at 7:06 AM, Jouni Korhonen wrote: >>> >>>> Folks, >>>> >>>> This mail starts a two week WGLC for draft-ietf-dmm-requirements-03. >>>> The issues, even editorials, should be recorded into the Issue Tracker >>>> for a control tracking whether everything has been addressed. We >>>> require minimum three reviews. The more the better, though. >>>> >>>> The WGLC ends on Wednesday 3rd April. >>>> >>>> - Jouni & Julien >>> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From jouni.nospam@gmail.com Mon Apr 8 23:43:08 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5221F8FC6 for ; Mon, 8 Apr 2013 23:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAs5+YstueLK for ; Mon, 8 Apr 2013 23:43:08 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C6F5921F8F9E for ; Mon, 8 Apr 2013 23:43:07 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id z10so2576877ead.26 for ; Mon, 08 Apr 2013 23:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=go0yR2L7Z5MB390xhJ6kiJAHar4zM7AzeDr/5EiV2o0=; b=SBwceJKNpDqvSTqyZgPgYSK5x7/tQ0L+cOYEogwaEKeamLbhMxIx+dppX95HPKmRkn FNf3yN4ryMMmV+B2QGOdr8LMjg7CrdQ2qZpQWNApeO3bEAl3/MKCsF4VyZ0k0oDb8TDD uypjItuwdiiJ4l91f/iPCvM985PHwmgw5EnVHBOBkojEJwWYsYhyklOk0FJmfyRfVNhu a1rfiAyo+0HzfF4GVZDqRzFozkyX6JiJh9oDo2MDQl8dluCrcfB7bGTWIsaJIUUOV7m2 VD9eqUvAelE+j+FiufxQM1VMo9ZRRqSmUP2RxU53csTLaK41tui/7yR3p3Dea/3VAN+G Z5Pw== X-Received: by 10.14.5.137 with SMTP id 9mr56406191eel.30.1365489786527; Mon, 08 Apr 2013 23:43:06 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id b5sm4297788eew.16.2013.04.08.23.43.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 23:43:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Tue, 9 Apr 2013 09:43:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <75D1C939-3E59-44BA-9B9A-759A3B91D064@gmail.com> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1283) Cc: dmm@ietf.org Subject: Re: [DMM] Section 4.7 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 06:43:08 -0000 Behcet, On Apr 8, 2013, at 10:45 PM, Behcet Sarikaya wrote: > Hi Jouni, all, >=20 > I have concerns on the text in this section. Could you pinpoint which part of the text and propose changes. - Jouni > It seems like this text has mainly been contributed by Seil. > No offense to Seil, please. >=20 > Let me explain the background here: when DMM discussed some solution = proposals in the past, in Multimob, we had a few out of charter slots to = discuss DMM multicast. Seil was a presenter. We had other presenters as = well. >=20 > The discussions produced no consensus. Since then we stopped such = discussions. >=20 > Also, let me explain the background on RFC 6224 here: > Multimob developed RFC 6224 with the first charter which required no = protocol extensions. Since then this requirement has been removed and we = developed some solutions we might even develop an alternative solution. >=20 > Hope this clarifies my concern. >=20 > Regards, >=20 > Behcet > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From sarikaya2012@gmail.com Tue Apr 9 15:10:49 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2562B21F9908 for ; Tue, 9 Apr 2013 15:10:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ScAlWDQrEBv for ; Tue, 9 Apr 2013 15:10:48 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9221F9616 for ; Tue, 9 Apr 2013 15:10:47 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1270589lab.27 for ; Tue, 09 Apr 2013 15:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Secv48gKG8t18qW2RD8tyfqYGu1qvsMxFxWs8MlPeDA=; b=FwoB13MuVxZhTFDJk/N5fXY4MqzOIwHLHPBPBAGOPwNCFdJfrlcUN/yLeeaNaSlHwF Sx5ubjZUpL6W5hmSv/gD7PpVxR1MwHkGUZCb+mYQOG53IAs1A7wyr3c7MJoLncxsNGpo DmLmH6s92zXYLtNeMy9KDz45pu6qc3bOntuZMMb/Ouj8naBQw+/xeCQDw9C15SBkecLC isw/Ap5iNmV+oz18D0DYObcTlA9wL92xnF7mMp78vrVc7GwHuheI1n7UJUSeVP440mZr wvtcVKSpakfTDLewJuWWlnC6x6n3t+r3+7y0zSjDsgM24senUxylI8q8+wmp4QgNhHUd EQDg== MIME-Version: 1.0 X-Received: by 10.112.129.137 with SMTP id nw9mr14885452lbb.56.1365545446162; Tue, 09 Apr 2013 15:10:46 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Tue, 9 Apr 2013 15:10:46 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> Date: Tue, 9 Apr 2013 17:10:46 -0500 Message-ID: From: Behcet Sarikaya To: Marco Liebsch Content-Type: multipart/alternative; boundary=047d7b3a7f103e469404d9f4d34d Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:10:49 -0000 --047d7b3a7f103e469404d9f4d34d Content-Type: text/plain; charset=ISO-8859-1 Hi Marco, The requirement did not come from Multimob. Multimob was discussing DMM multicast and then some people said maybe this should be discussed in dmm. Only individual opinions were expressed. Then there started some discussions on dmm regarding adding multicast requirements. It seems like the final product, i.e. Section 4.7 contains a lot of text I can easily object with my chair hat on or off. I explained these in my previous mail. Now, after so much discussion, we could come up with this very controversial text, my suggestion would be to remove it, why not? I believe multicast is a distraction to dmm at this moment. Hope this clarifies. Regards, Behcet On Thu, Apr 4, 2013 at 3:31 AM, Marco Liebsch wrote: > I do not have a strong opinion on 4.7, but adding such requirement > came from Multimob. Now you propose removing this requirement again. > Does it mean you do not want to have it in at all? If yes, why? > > Another option is that the Multimob group proposes alternative text > to be more concrete about a multicast requirement according to the > Multimob group's view how this should be covered. > > marco > > >-----Original Message----- > >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > >Behcet Sarikaya > >Sent: Mittwoch, 3. April 2013 21:59 > >To: Jouni Korhonen > >Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > >Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 > > > >Hi all, > > > >If Section 4.7 is removed, I am willing to support this call. > > > >The reason: it is immature to say anything on this issue even as a should. > > > >Regards, > > > >Behcet > > > > > > > >On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen > >wrote: > > > > > > > > Just a reminder. There has been zero WGLC reviews so far.. > > > > - Jouni > > > > > > > > On Mar 20, 2013, at 7:06 AM, Jouni Korhonen > > wrote: > > > > > Folks, > > > > > > This mail starts a two week WGLC for draft-ietf-dmm-requirements- > >03. > > > The issues, even editorials, should be recorded into the Issue > Tracker > > > for a control tracking whether everything has been addressed. We > > > require minimum three reviews. The more the better, though. > > > > > > The WGLC ends on Wednesday 3rd April. > > > > > > - Jouni & Julien > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > --047d7b3a7f103e469404d9f4d34d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marco,

The requirement did not come from Multimob.
Multimob wa= s discussing DMM multicast and then some people said maybe this should be d= iscussed in dmm. Only individual opinions were expressed.

Then ther= e started some discussions on dmm regarding adding multicast requirements.<= br>
It seems like the final product, i.e. Section 4.7 contains a lot of tex= t I can easily object with my chair hat on or off. I explained these in my = previous mail.

Now, after so much discussion, we could come up with = this very controversial text, my suggestion would be to remove it, why not?=

I believe multicast is a distraction to dmm at this moment.

Hope= this clarifies.

Regards,

Behcet

On Thu, Apr 4, 2013 at 3:31 AM, Marco Liebsch <<= a href=3D"mailto:Marco.Liebsch@neclab.eu" target=3D"_blank">Marco.Liebsch@n= eclab.eu> wrote:
I do not have a strong opinion on 4.7, but a= dding such requirement
came from Multimob. Now you propose removing this requirement again.
Does it mean you do not want to have it in at all? If yes, why?

Another option is that the Multimob group proposes alternative text
to be more concrete about a multicast requirement according to the
Multimob group's view how this should be covered.

marco

>-----Original Message-----
>From: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] O= n Behalf Of
>Behcet Sarikaya
>Sent: Mittwoch, 3. April 2013 21:59
>To: Jouni Korhonen
>Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
>Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03
>
>Hi all,
>
>If Section 4.7 is removed, I am willing to support this call.
>
>The reason: it is immature to say anything on this issue even as a shou= ld.
>
>Regards,
>
>Behcet
>
>
>
>On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen <jouni.nospam@gmail.com>
>wrote:
>
>
>
> =A0 =A0 =A0 Just a reminder. There has been zero WGLC reviews so far..=
>
> =A0 =A0 =A0 - Jouni
>
>
>
> =A0 =A0 =A0 On Mar 20, 2013, at 7:06 AM, Jouni Korhonen
><jouni.nospam@gmail.com> wrote:
>
> =A0 =A0 =A0 > Folks,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > This mail starts a two week WGLC for draft-ietf-dmm-r= equirements-
>03.
> =A0 =A0 =A0 > The issues, even editorials, should be recorded into = the Issue Tracker
> =A0 =A0 =A0 > for a control tracking whether everything has been ad= dressed. We
> =A0 =A0 =A0 > require minimum three reviews. The more the better, t= hough.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The WGLC ends on Wednesday 3rd April.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > - Jouni & Julien
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 dmm mailing list
> =A0 =A0 =A0 dmm@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/dmm
>
>


--047d7b3a7f103e469404d9f4d34d-- From jouni.nospam@gmail.com Wed Apr 10 00:19:07 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1920C21F8FED for ; Wed, 10 Apr 2013 00:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBtif5VrD3Fv for ; Wed, 10 Apr 2013 00:19:06 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 539D521F8FE8 for ; Wed, 10 Apr 2013 00:19:06 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so142481lab.30 for ; Wed, 10 Apr 2013 00:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=tqCWWfj2U6D3v2YVqu3pwBq8JPGscRzUzqazNtI5RFY=; b=VKE3thY2tvL4QvjZCEbizAPxMqnVgSZ1OVRqLkqmHGrUfQRgOrtkUy2dRkCCNpUMZS be+zhm6k/CVrife7T7LQIi5wmzoKCNavZxojNGXe9XUwzg5X9pP5ALWJrgDdwAg0aYXW dOWRrLdXt9beK7x4jb4w9jReDgJrki5z3RD9D3RrpqdAOMIjIoB2CWi0wyf1xCAeGcEZ lgkaPY4oDFiN7DsLTseb52CGO3OcG/t7ocjUMCkzxUTM5ouW+CEkC0NXHezhjqgLHWVl UjY5ZTlmPStysF23CV6JP+Gw3MQw/RsvDTWlc1fk8w3+QVUQ44chFQi3SvkZ1LsFXBjg OBEw== X-Received: by 10.112.9.10 with SMTP id v10mr631112lba.47.1365578345310; Wed, 10 Apr 2013 00:19:05 -0700 (PDT) Received: from [192.168.250.151] ([194.100.71.98]) by mx.google.com with ESMTPS id l20sm8690395lbv.9.2013.04.10.00.19.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 00:19:04 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 10 Apr 2013 10:19:04 +0300 Message-Id: To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "dmm-chairs@tools.ietf.org" Subject: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:19:07 -0000 Folks, This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. The issues, even editorials, must be recorded into the Issue Tracker, otherwise they are likely to be neglected. We require minimum three reviews (that are more than one liners). The more the better, though. The WGLC ends on Wednesday 24rd April. - Jouni & Julien From brian@innovationslab.net Wed Apr 10 08:02:23 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A1F21F96B3 for ; Wed, 10 Apr 2013 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3C34U4-asOM for ; Wed, 10 Apr 2013 08:02:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 019E021F9628 for ; Wed, 10 Apr 2013 08:02:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E86C28810A for ; Wed, 10 Apr 2013 08:02:22 -0700 (PDT) Received: from 102526111.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A898B14000D for ; Wed, 10 Apr 2013 08:02:22 -0700 (PDT) Message-ID: <51657EFF.1070102@innovationslab.net> Date: Wed, 10 Apr 2013 11:02:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmm@ietf.org References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:02:23 -0000 On 4/9/13 6:10 PM, Behcet Sarikaya wrote: > > I believe multicast is a distraction to dmm at this moment. > I am curious as to why you call it a distraction. It seems to me that having multicast support considered at the beginning of the process is much better than trying to bolt it on after the fact. That is the reason that I suggested that DMM-related multicast be discussed in DMM. Could you explain why multicast should not be considered by DMM? Regards, Brian From stig@venaas.com Wed Apr 10 11:06:56 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645F221F8A6B for ; Wed, 10 Apr 2013 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-HPZeUlmal4 for ; Wed, 10 Apr 2013 11:06:55 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id B4C1121F8B16 for ; Wed, 10 Apr 2013 11:06:55 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5042F8025; Wed, 10 Apr 2013 20:06:54 +0200 (CEST) Message-ID: <5165A9EC.5080809@venaas.com> Date: Wed, 10 Apr 2013 11:05:32 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian Haberman References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> <51657EFF.1070102@innovationslab.net> In-Reply-To: <51657EFF.1070102@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 18:06:56 -0000 On 4/10/2013 8:02 AM, Brian Haberman wrote: > On 4/9/13 6:10 PM, Behcet Sarikaya wrote: >> >> I believe multicast is a distraction to dmm at this moment. >> > > I am curious as to why you call it a distraction. It seems to me that > having multicast support considered at the beginning of the process is > much better than trying to bolt it on after the fact. That is the > reason that I suggested that DMM-related multicast be discussed in DMM. This is why I (and I believe a few other people) wanted this in the requirements document. Is your objection that multicast is mentioned at all, or the wording of the section? Stig > Could you explain why multicast should not be considered by DMM? > > Regards, > Brian > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From stig@venaas.com Wed Apr 10 11:08:24 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C521F8F12 for ; Wed, 10 Apr 2013 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDx9+07fOuX6 for ; Wed, 10 Apr 2013 11:08:23 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A6C1121F8F05 for ; Wed, 10 Apr 2013 11:08:23 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id E00C98025; Wed, 10 Apr 2013 20:08:18 +0200 (CEST) Message-ID: <5165AA40.5000006@venaas.com> Date: Wed, 10 Apr 2013 11:06:56 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jouni Korhonen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 18:08:24 -0000 On 4/10/2013 12:19 AM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > The issues, even editorials, must be recorded into the Issue Tracker, > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though. I believe the document is ready as is. I responded too late to the first last call, so I'm now responding a second time. Stig > The WGLC ends on Wednesday 24rd April. > > - Jouni & Julien > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From jouni.nospam@gmail.com Sat Apr 13 05:23:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF9021F8A69 for ; Sat, 13 Apr 2013 05:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLbqgd4IN2tQ for ; Sat, 13 Apr 2013 05:23:03 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4999D21F869C for ; Sat, 13 Apr 2013 05:23:03 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id q14so1555190eaj.22 for ; Sat, 13 Apr 2013 05:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=h+wlJsIJFOcxfAlcYM3etGqtV3H8VIW6Yk0nSpR+PvQ=; b=faSaA7PI4YkML5H8nQ85kffhdfxcQhyt0hJaMc9whHjnaCXVJ+mF5kvVRnVtPIsrgH 4RQdbbFEIJOCrLu0n78e8vexEv3mdnXyJG4aLHqNmlntRrSU74iLub1ZocGaDV/ileC9 DytHWKentm9NDswQHlglUsnmgC6O1v6lg9LKpcg+lzOJ5LbaOES6zRL15XVIYjhG8b0u Nrnj+UiegUZxkPDjlndJXhYdofY2XVr1vxxgtxzZULmBI5leGaKnqgiBnd45HF2X1Juh 1i8NV7s9yqZfM/dg6fT/cuoOjRW6AI3FA85qV5yj3S5wE1iUUm6p8twfsjT1nmuxdind YIFQ== X-Received: by 10.15.94.200 with SMTP id bb48mr39206453eeb.21.1365855782298; Sat, 13 Apr 2013 05:23:02 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPS id ca4sm16099798eeb.15.2013.04.13.05.22.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 05:22:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <5165A9EC.5080809@venaas.com> Date: Sat, 13 Apr 2013 15:22:58 +0300 Content-Transfer-Encoding: 7bit Message-Id: <1AE99116-5EC2-4535-A5FF-7F45EBFC397E@gmail.com> References: <05DBD8E5-631C-4103-8681-5C27B05B9BAF@gmail.com> <69756203DDDDE64E987BC4F70B71A26D552153D5@DAPHNIS.office.hd> <51657EFF.1070102@innovationslab.net> <5165A9EC.5080809@venaas.com> To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 12:23:06 -0000 My take on this is that if we leave the multicast requirements out (that are very brief already) is an ostrich approach.. pretending there are no multicast to take into account. Having the requirements does not mean we spend all effort dedicated to multicast but at minimum we need to ensure the possible protocol design allows easy inclusion of multicast at some point of time. It is just a basis for good protocol design, not relying on a patchwork later on. - Jouni (as an individual) On Apr 10, 2013, at 9:05 PM, Stig Venaas wrote: > On 4/10/2013 8:02 AM, Brian Haberman wrote: >> On 4/9/13 6:10 PM, Behcet Sarikaya wrote: >>> >>> I believe multicast is a distraction to dmm at this moment. >>> >> >> I am curious as to why you call it a distraction. It seems to me that >> having multicast support considered at the beginning of the process is >> much better than trying to bolt it on after the fact. That is the >> reason that I suggested that DMM-related multicast be discussed in DMM. > > This is why I (and I believe a few other people) wanted this in the > requirements document. > > Is your objection that multicast is mentioned at all, or the wording > of the section? > > Stig > >> Could you explain why multicast should not be considered by DMM? >> >> Regards, >> Brian >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Mon Apr 15 13:18:48 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C421F93D7 for ; Mon, 15 Apr 2013 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVd8xJ7M8EhE for ; Mon, 15 Apr 2013 13:18:37 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 329D621F93C4 for ; Mon, 15 Apr 2013 13:18:37 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c41so2503080eek.31 for ; Mon, 15 Apr 2013 13:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=AIbzR5CouOhqcxAG447T06syDiaPewckJAR0DRy1jFQ=; b=tCeXyJ9MEiXd354DNLmK/GReIKa6gTChYE4xVoKRf8WjZGqd+8B6kE2udwoqEkgeVV +l2gFFpS64sVupNwR3WunYIRJmmjZHWwiJyWb017xa8Vk0WYc6r2dZAV+hKWQ+PMP58B VvWvPil0hTBqXayvn1+C2DmtV3aDEG0NvKGRfS8CNDpZyurmHjtcu9Du9T90QMo7axFX bcVQu1WEb+XNMITUispCvXeHUzSyQjKXZkZvVjWdiKCwBR+DB+YcgMem1VexXzaNhr8p DTXSqX5ehtNAubC79+S4Fjh5Ji7D0XvC2rXCngWm4Ig3YiyGXbbk5peFW8w6ELwzaJva a7og== X-Received: by 10.14.218.66 with SMTP id j42mr65361455eep.46.1366057116305; Mon, 15 Apr 2013 13:18:36 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPS id b47sm9130483eez.2.2013.04.15.13.18.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 13:18:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 15 Apr 2013 23:18:32 +0300 Content-Transfer-Encoding: 7bit Message-Id: <045B0AE7-90CA-44E1-B023-EB3CCAEE81A4@gmail.com> References: To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:18:49 -0000 Hi, My WGLC comments of the I-D as a chair, not the document co-author. I will also put them one by one into the issue tracker. - Jouni 1) Abstract Management (DMM) in IPv6 deployments. The traditionally hierarchical structure of cellular networks has led to deployment models which are in practice centralized. Mobility management with logically Why are we only concerned about cellular networks? Could this be generalized? Next sentences then start talking about mobile networks. Use consistent language. 2) Abstract when needed, and so on. Distributed mobility management must be secure and compatible with existing network deployments and end hosts. I would argue a DMM mechanisms, unless completely done on the network side, cannot be compatible with existing end host.. It can be backward compatible, which means there is a way to allow mixing DMM aware and legacy hosts in a case the DMM solution would require even a configuration change in the end host. 3) Warnings from automated IDnits (parsed): == Unused Reference: 'I-D.ietf-netext-pd-pmip' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC6224' is defined on line 663, but no explicit reference was found in the text == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (ED: maybe putting RFC2119 language into 'front' section using ... ) == The copyright year in the IETF Trust and authors Copyright Line does not match the current year 4) Section 1 a centralized mobility anchor providing global reachability and an always-on experience to the user; extensions to the base protocols to optimize handover performance while users roam across wireless cells; and extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. smartphones). o Make this to a bulleted list. 5) Section 1 The presence of the centralized mobility anchor allows a mobile node to remain reachable when it is not connected to its home domain. The o "home domain" strikes out, which might not be obvious unless you are familiar with mobile (cellular) lingo. Give a reference to a document that a reader can read & get familiar with "home domains" and such. 6) Section 1 and scalability, which require costly network dimensioning and o Ins't distribution dimensioning as well? 7) Section 1 Moreover, the availability of multi-mode devices and the possibility of using several network interfaces simultaneously have motivated the development of even more protocol extensions to add more capabilities and to combine IP multicasting to the base protocol. In the end, deployment is further complicated with the multitude of extensions. o While "multi-mode" is correct, within IETF I would say "multiple interface host" is better. o I do not understand how "to combine IP multicasting to the base protocol" relates to the paragraph. o What is the "base protocol" here? 8) Section 1 mobile/fixed Internet Service Providers network requires taking into o Service Providers network (ISP) 9) Section 1 strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO [TS.23829]) through alternative access networks (e.g. o I would replace [TS.23829] with [TS.23.401] since both LIPA/SIPTO are part of those document these days and the TR is just a technical report. 8) Section 1 in a truly flat mobile architecture would anchor the traffic closer to the point of attachment of the user, overcoming the suboptimal route stretch of a centralized mobility scheme. o This statement is more or less from the IP layer point of view. The actual layer-2 aggregation can make the claim of "overcoming route stretch" more challenging than it sounds. 9) Section 1 considerable periods of time [Paper-Locating.User] . Therefore it is o misplaced '.' 10) Section 1 with application intelligence suggest that mobility can be provided selectively, thus simplifying the context maintained in the different nodes of the mobile network. o "..mobility could be provided.." o I would argue that having "simple IP" and "Mobile IP" selectively does not simplify the context in the network, it actually makes the network side more complex to implement. However, I would agree that it would _reduce_ the amount of context maintained in the network. 11) Section 1 The DMM charter addresses two complementary aspects of mobility management procedures: the distribution of mobility anchors towards a more flat network and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former aims at positioning mobility anchors (HA, LMA) closer to the user; ideally, mobility agents could be collocated with the management support -- thus reducing the amount of state information that must be maintained in various mobility agents of the mobile network. The key idea is that dynamic mobility management relaxes some of the constraints of previously-standardized mobility management solutions and, by doing so, it can avoid the establishment of non-optimal tunnels between two topologically distant anchors. o expand DMM on the first use (excluding the abstract expansion here). o "..anchors (HA, LMA).." -> "..anchors (e.g., HA, LMA).." o The last sentence start discussion about tunnels. They are now mentioned for the first time. Where the use of tunnels originated at this point? It should be clarified at least with a reference. o The last sentence states "non-optimal tunnels between two topologically distant anchors". Where does that originates? Which protocols we are implicitly referring to? 12) Section 2.1 (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System (EPS) networks employ centralized mobility management too. In particular, Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) in the 3GPP UMTS hierarchical network, and the Packet data network Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP EPS network, respectively, act as anchors in a hierarchy. o It is not really UMTS networks, .. rather say GPRS networks. o Packet Data Network Gateway (P-GW) o Since in 3GPP example SGSNs and SGWs are taken into anchoring discussion, then in GPRS case the text should also discuss RNC, which like SGW is the L2 anchor point for base stations. o The text should be more clear when talking about anchoring that it concerns IP layer and specifically user plane traffic. For example, 3GPP GPRS is rather hierarchical at L2 and mobility is handled at every level of hierarchy rather independently. o Figure 1 is incomplete in case of GPRS. RNC should be in the picture as well. o Figure 1 should change UMTS -> 3G GPRS if RNC is in picture, otherwise GPRS is just fine. 13) Section 3.2 former case only the data plane is distributed. Fully distributed mobility management implies that both the data plane and the control plane are distributed. These different approaches are described in o Data and control plane separation is not really something we have practiced so far in IETF, at least not with the mobility protocols developed within IETF. I would give a pointer to further reading to architectures that have that separation and mention also IETF developed mobility protocols do not have similar concept so far. 14) Section 4.1 REQ1: Distributed deployment o This requirement must imho state why route optimization (MIPv6) or localized routing (PMIPv6) as of today are not adequate/enough. The requirement text itself is OK but the question above needs an answer. 15) Section 4.2 example, when, upon change of point of attachment to the Internet, an application flow cannot cope with a change in the o s/Internet/network PS5: Wasting resources to provide mobility support to nodes that do not need such support o s/Wasting/Unnecessarily reserving the tunnel, keep alive, etc.) is not turned off for peer-to- o s/keep alive/keep alive signaling keep alives, etc.) wastes network resources for no application o s/keep alives/keep alive signaling 16) Section 4.5 o Earlier lists were indexed using (a), (b) etc.. here different style (1), (2) is used. Choose one style. 17) Section 4.5 PS7: (Related problem) Complicated deployment with too many MIP variants and extensions Deployment is complicated with many variants and extensions of MIP. When introducing new functions which may add to the complexity, existing solutions are more vulnerable to break. o I would argue this "related problem" could be removed. I see REQ5 as a requirement for backward compatibility, not a MIP flavour complexity issue. 18) Section 4.6 the mobility support provided by the DMM solution; signaling message protection in terms of authentication, encryption, etc.; data integrity and confidentiality; opt-in or opt-out data confidentiality to signaling messages depending on network environments or user requirements. o Get rid of "etc". It does not really fit in a middle of a list. o Some rewording needed. The use of semicolon is confusing. 19) Section 4.6 o The security discussed in "motivation" part seems to be mostly about the first hop / on-link security. Why not saying that then instead of listing a job lot of different threats.. their traffic. As signaling messages may travel over the Internet, end-to-end security could be required. o "could" is rather weak.. I would say MUST. Also, e2e security between what? That needs to be stated as well. 20) Section 4.7 4.7. Flexible multicast distribution REQ7: DMM should enable multicast solutions in flexible distribution scenario. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints. o What is "flexible distribution scenario"? That is not mentioned earlier or defined. o I would reword the section title to something else like plain "Multicast" or "Multicast considerations". o "..using multiple endpoint." is supposed to mean what? I kind of understand that as an aggregation or what does it intend to say? 21) Section 4.7 problems described in PS1 and PS6. o For readability I would add references to relevant Sections as well e.g. "..describer in Section 4.1 PS1 and in Section .." 22) Section 5 legitimate mobile host/router to access the DMM service; Second, end- to-end security that protects signaling messages for the DMM service. o e2e security between what? Between nodes that participate in the DMM protocol as a whole or bilaterally between the end host and some xyz functional entity? 23) Section 5 It is necessary to provide sufficient defense against possible security attacks, or to adopt existing security mechanisms and protocols to provide sufficient security protections. For instance, EAP-based authentication can be used for access network security, while IPsec can be used for end-to-end security. o EAP-based security does not necessarily address on-link / first hop threats. You gain access, and then can fool around.. does not sound too promising, unless the security considerations can scope the used link type better i.e. in p2p links this might be sufficient but not in all. On Apr 10, 2013, at 10:19 AM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > The issues, even editorials, must be recorded into the Issue Tracker, > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though. > > The WGLC ends on Wednesday 24rd April. > > - Jouni & Julien From jouni.nospam@gmail.com Wed Apr 17 00:22:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2BA21F9588 for ; Wed, 17 Apr 2013 00:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sFDSyvtPeBG for ; Wed, 17 Apr 2013 00:22:10 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id B453021F97A7 for ; Wed, 17 Apr 2013 00:22:06 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w20so1316886lbh.18 for ; Wed, 17 Apr 2013 00:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=P1dHdRpDvT5gJGtm0etpy5BhSqJPv1FEeZ79GN9sN84=; b=RTzHr0goOgblPzzdiP5A4BiDRAQscWL3Yt2JDnTcHQ+GX5bVtbD3mVTU+XYzEObNot 58pHjVILPqJNv/8edVazP294MxGuuvSHbTK8wVF9oHXQt+Iop/ICIjV6qXfmL5nYHj7Y zz+7EvpqSdW3+ddJaubb+/rqTLZ+mVc8uNQOaSiNE/3QJQyi0rpR1DXckUwlGcl5W1AK uoNHfPRIgssJXEu+4xkJcffQ/4lxvVv1mQlul3mMfDpZLxbYAzAvuRVOOlUFnD2uhpG4 LFGT0rSXKyq1bQSuSlU53PIDT1k3S1SacR9IXQbHa3sfzMxCa7IiN4HTBqFSBpT/Ds8Z Tyaw== X-Received: by 10.152.26.101 with SMTP id k5mr2856940lag.31.1366183325709; Wed, 17 Apr 2013 00:22:05 -0700 (PDT) Received: from [192.168.250.229] ([194.100.71.98]) by mx.google.com with ESMTPS id v10sm2067050lae.9.2013.04.17.00.22.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 00:22:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 17 Apr 2013 10:22:03 +0300 Content-Transfer-Encoding: 7bit Message-Id: <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> References: To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 07:22:11 -0000 Folks, One week left of the WGLC#2. - Jouni & Julien On Apr 10, 2013, at 10:19 AM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > The issues, even editorials, must be recorded into the Issue Tracker, > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though. > > The WGLC ends on Wednesday 24rd April. > > - Jouni & Julien From macsbug@research.att.com Wed Apr 17 12:44:50 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986AA21F8585 for ; Wed, 17 Apr 2013 12:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYcIQrmaS1Yv for ; Wed, 17 Apr 2013 12:44:50 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id DDDD921F857E for ; Wed, 17 Apr 2013 12:44:49 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 84087120901; Wed, 17 Apr 2013 15:45:17 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 68492E3719; Wed, 17 Apr 2013 15:36:02 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 17 Apr 2013 15:44:49 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: "dmm@ietf.org" Date: Wed, 17 Apr 2013 15:44:49 -0400 Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: Ac47pAVWj1mLcdx3R8yNlj3JQRcgmQ== 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: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 19:44:50 -0000 Hi. Below are my comments on the draft-ietf-dmm-requirements-03. Overall, the draft has much to admire and agreeable on most points. Kudos to the authors. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment 1: REQ2: Transparency to Upper Layers when needed >> I would like to suggest that DMM must provide transparency to upper laye= rs for a limited time only when needed. Upper layer protocols or applicatio= ns that are unaware of IP layer mobility and IP address changes cannot be s= upported indefinitely, without compromising the purpose of DMM. How much ti= me is of course another matter, but that can be discussed during design or = even dynamic. In time, applications and upper layer protocols will have to be updated to = handle IP address changes by reconnect or other means, as long as DMM provi= des temporary shield from packet losses or other disruptions and buy them t= ime to make preparations. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment 2: REQ6: Security considerations=20 >> I think the requirements described here may give the impression that DMM= excludes ephemeral security for the purpose of routing to the correct enti= ties, but not necessarily tied to service authorizations or identities. Als= o, protection requirements beyond what current ISPs deal with for their acc= ess routers seem unnecessary. DMM's own security should be limited to risks= that DMM adds to the access network, not the whole access network security= . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment 3: REQ7: DMM should enable multicast solutions in flexible distribution scena= rio. >> I lack the necessary knowledge on multicast but this seems like a feel-g= ood statement without a point. I suggest to drop this requirement or make a= clearer statement like "DMM should allow multicast to survive IP layer mob= ility without packet loss", or more modestly, "DMM should not foreclose mul= ticast support during IP layer mobility.", etc.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment 4: 5. Security Considerations Distributed mobility management (DMM) requires two kinds of security considerations: First, access network security that only allows a legitimate mobile host/router to access the DMM service; Second, end- to-end security that protects signaling messages for the DMM service. >> Related to my Comment 2, "access network security" is confusing here, as= it often means allowing access to the network to begin with. DMM must assu= me that is already done at least in the lower layer or even IP layer. It ma= y or may not offer DMM service to anyone or only to authorized devices/user= s. I think DMM must cover the situation where the service is offered to any= thing that asks for it, while ensuring the packets are not redirected to wr= ong directions. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bests. Byoung-Jo "J" Kim AT&T Labs - Research https://sites.google.com/site/macsbug/ On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: > Folks, >=20 > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > The issues, even editorials, must be recorded into the Issue Tracker, > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though. >=20 > The WGLC ends on Wednesday 24rd April. >=20 > - Jouni & Julien > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Thu Apr 18 21:05:53 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7DC21F93C6 for ; Thu, 18 Apr 2013 21:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MkmmRaGWBHP for ; Thu, 18 Apr 2013 21:05:53 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B621F8A00 for ; Thu, 18 Apr 2013 21:05:51 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 19 Apr 2013 06:05:55 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Fri, 19 Apr 2013 06:05:49 +0200 From: To: , Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHONbu2iM+VLoL7tkGh7IYBo2ccBpjZ64WAgAMO44eAAACAbA== Date: Fri, 19 Apr 2013 04:05:49 +0000 Message-ID: References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> In-Reply-To: <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37E921EXMBX23adutwent_" MIME-Version: 1.0 Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 04:05:53 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37E921EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am happy with the current version of the DMM draft! So I think that the draft can proceed with the further IETF review process! Best regards, Georgios ________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Jouni Korhonen [jou= ni.nospam@gmail.com] Verzonden: woensdag 17 april 2013 9:22 To: dmm@ietf.org Onderwerp: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Folks, One week left of the WGLC#2. - Jouni & Julien On Apr 10, 2013, at 10:19 AM, Jouni Korhonen wrote= : > Folks, > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > The issues, even editorials, must be recorded into the Issue Tracker, > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though. > > The WGLC ends on Wednesday 24rd April. > > - Jouni & Julien _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37E921EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5EBA504E8A51C7408721D0AB06DC68E5@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable

Hi all,

 

I am happy with the current version of the DMM draft!

So I think that the draft can proceed with the further IETF review proce= ss!

 

Best regards,

Georgios

 

 

 

 

Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Jouni Ko= rhonen [jouni.nospam@gmail.com]
Verzonden: woensdag 17 april 2013 9:22
To: dmm@ietf.org
Onderwerp: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-= 03


Folks,

One week left of the WGLC#2.

- Jouni & Julien

On Apr 10, 2013, at 10:19 AM, Jouni Korhonen <jouni.nospam@gmail.com>= wrote:

> Folks,
>
> This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03= .
> The issues, even editorials, must be recorded into the Issue Tracker,<= br> > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though.<= br> >
> The WGLC ends on Wednesday 24rd April.
>
> - Jouni & Julien

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F37E921EXMBX23adutwent_-- From jonghyouk@gmail.com Fri Apr 19 01:13:53 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0322321F93F3 for ; Fri, 19 Apr 2013 01:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9ByJpyYT5B0 for ; Fri, 19 Apr 2013 01:13:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E294221F93F1 for ; Fri, 19 Apr 2013 01:13:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id gd11so3601977vcb.3 for ; Fri, 19 Apr 2013 01:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bEp2AjiDfI8Iqn+oszwYjiMFj0ccE8p2um1oJORYziM=; b=PxFlhhmtr2mNSG6Cxrc4LYQ446B1t5CkINWX7y39k9x2C0gVWiefVk9cDIDTnXj+Dw QP+UbR0BMn5GPycBh4pv8i945lKiKNArclfBgdEOOOsf5gg5gWN7kPUrmID2yJTBZSth J1T7TEtIdUh1wQm+JpjutmMd/7PiRLDO7Zy7CoPocd0BD9pRGPBsPJht1Ov0V29Nnypy M3O6+zd4xBVNSgxjT9JzvY93x+PHdOvcU3FaOKvYiDZocPbK7eCz2IpedbpP8NoQbhBJ JgVO09fhoLQ+8ZqjdIrSpSVuyT9RINLpiCvUQDKsZajBwotlrO7KSN2cn/g8vwwgdVgP CC6Q== MIME-Version: 1.0 X-Received: by 10.52.163.231 with SMTP id yl7mr9193354vdb.57.1366359228426; Fri, 19 Apr 2013 01:13:48 -0700 (PDT) Received: by 10.58.118.164 with HTTP; Fri, 19 Apr 2013 01:13:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 10:13:48 +0200 Message-ID: From: Jong-Hyouk Lee To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Content-Type: multipart/alternative; boundary=001a11c25012722e2304dab24c3b Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 08:13:53 -0000 --001a11c25012722e2304dab24c3b Content-Type: text/plain; charset=UTF-8 Hello, Byoung-Jo Regarding your comments on the security text, for your comment 2, I do not quite get you. Provide clear text expressing your concern then I will review and try to reflect to the draft. For your comment 5, just you need to be sure that the given text is about the general security consideration. Cheers. On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) < macsbug@research.att.com> wrote: > Hi. > > Below are my comments on the draft-ietf-dmm-requirements-03. > > Overall, the draft has much to admire and agreeable on most points. > Kudos to the authors. > > > =================== > Comment 1: > > REQ2: Transparency to Upper Layers when needed > > >> I would like to suggest that DMM must provide transparency to upper > layers for a limited time only when needed. Upper layer protocols or > applications that are unaware of IP layer mobility and IP address changes > cannot be supported indefinitely, without compromising the purpose of DMM. > How much time is of course another matter, but that can be discussed during > design or even dynamic. > In time, applications and upper layer protocols will have to be updated to > handle IP address changes by reconnect or other means, as long as DMM > provides temporary shield from packet losses or other disruptions and buy > them time to make preparations. > > ==================== > Comment 2: > > REQ6: Security considerations > > >> I think the requirements described here may give the impression that > DMM excludes ephemeral security for the purpose of routing to the correct > entities, but not necessarily tied to service authorizations or identities. > Also, protection requirements beyond what current ISPs deal with for their > access routers seem unnecessary. DMM's own security should be limited to > risks that DMM adds to the access network, not the whole access network > security. > > ===================== > Comment 3: > REQ7: DMM should enable multicast solutions in flexible distribution > scenario. > > >> I lack the necessary knowledge on multicast but this seems like a > feel-good statement without a point. I suggest to drop this requirement or > make a clearer statement like "DMM should allow multicast to survive IP > layer mobility without packet loss", or more modestly, "DMM should not > foreclose multicast support during IP layer mobility.", etc.. > > ==================== > Comment 4: > > 5. Security Considerations > Distributed mobility management (DMM) requires two kinds of security > considerations: First, access network security that only allows a > legitimate mobile host/router to access the DMM service; Second, end- > to-end security that protects signaling messages for the DMM service. > > >> Related to my Comment 2, "access network security" is confusing here, > as it often means allowing access to the network to begin with. DMM must > assume that is already done at least in the lower layer or even IP layer. > It may or may not offer DMM service to anyone or only to authorized > devices/users. I think DMM must cover the situation where the service is > offered to anything that asks for it, while ensuring the packets are not > redirected to wrong directions. > > =================== > > Bests. > > Byoung-Jo "J" Kim > AT&T Labs - Research > https://sites.google.com/site/macsbug/ > > > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: > > > Folks, > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > The issues, even editorials, must be recorded into the Issue Tracker, > > otherwise they are likely to be neglected. We require minimum three > > reviews (that are more than one liners). The more the better, though. > > > > The WGLC ends on Wednesday 24rd April. > > > > - Jouni & Julien > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --001a11c25012722e2304dab24c3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, Byoung-Jo

Regarding your c= omments on the security text, for your comment 2, I do not quite get you. P= rovide clear text expressing your concern then I will review and try to ref= lect to the draft. For your comment 5, just you need to be sure that the gi= ven text is about the general security consideration.

Cheers.


On Wed, Apr 17, 2013 at 9:44 PM, KIM,= BYOUNG-JO J (BYOUNG-JO) <macsbug@research.att.com> w= rote:
Hi.

Below are my comments on the draft-ietf-dmm-requirements-03.

Overall, the draft has much to admire and agreeable on most points.
Kudos to the authors.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Comment 1:

REQ2: =C2=A0Transparency to Upper Layers when needed

>> I would like to suggest that DMM must provide transparency to uppe= r layers for a limited time only when needed. Upper layer protocols or appl= ications that are unaware of IP layer mobility and IP address changes canno= t be supported indefinitely, without compromising the purpose of DMM. How m= uch time is of course another matter, but that can be discussed during desi= gn or even dynamic.
In time, applications and upper layer protocols will have to be updated to = handle IP address changes by reconnect or other means, as long as DMM provi= des temporary shield from packet losses or other disruptions and buy them t= ime to make preparations.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Comment 2:

REQ6: =C2=A0Security considerations

>> I think the requirements described here may give the impression th= at DMM excludes ephemeral security for the purpose of routing to the correc= t entities, but not necessarily tied to service authorizations or identitie= s. Also, protection requirements beyond what current ISPs deal with for the= ir access routers seem unnecessary. DMM's own security should be limite= d to risks that DMM adds to the access network, not the whole access networ= k security.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Comment 3:
REQ7: =C2=A0DMM should enable multicast solutions in flex= ible distribution scenario.

>> I lack the necessary knowledge on multicast but this seems l= ike a feel-good statement without a point. I suggest to drop this requireme= nt or make a clearer statement like "DMM should allow multicast to sur= vive IP layer mobility without packet loss", or more modestly, "D= MM should not foreclose multicast support during IP layer mobility.", = etc..

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Comment 4:

5. =C2=A0Security Considerations
=C2=A0 =C2=A0Distributed mobility management (DMM) requires two kinds of se= curity
=C2=A0 =C2=A0considerations: First, access network security that only allow= s a
=C2=A0 =C2=A0legitimate mobile host/router to access the = DMM service; Second, end-
=C2=A0 =C2=A0to-end security that protects signaling messages for the DMM s= ervice.

>> Related to my Comment 2, "access network security"= is confusing here, as it often means allowing access to the network to beg= in with. DMM must assume that is already done at least in the lower layer o= r even IP layer. It may or may not offer DMM service to anyone or only to a= uthorized devices/users. I think DMM must cover the situation where the ser= vice is offered to anything that asks for it, while ensuring the packets ar= e not redirected to wrong directions.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bests.

Byoung-Jo "J" Kim
AT&T Labs - Research
https:= //sites.google.com/site/macsbug/


On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote:

> Folks,
>
> This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03= .
> The issues, even editorials, must be recorded into the Issue Tracker,<= br> > otherwise they are likely to be neglected. We require minimum three > reviews (that are more than one liners). The more the better, though.<= br> >
> The WGLC ends on Wednesday 24rd April.
>
> - Jouni & Julien
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com
--001a11c25012722e2304dab24c3b-- From macsbug@research.att.com Fri Apr 19 07:01:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DCE21F8DD4 for ; Fri, 19 Apr 2013 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTn8-hZQiBAh for ; Fri, 19 Apr 2013 07:01:05 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A81E721F8C98 for ; Fri, 19 Apr 2013 07:01:05 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 4ADB5120BBE; Fri, 19 Apr 2013 10:01:36 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 057FDE3740; Fri, 19 Apr 2013 09:52:14 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 19 Apr 2013 10:01:05 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: Jong-Hyouk Lee Date: Fri, 19 Apr 2013 10:01:04 -0400 Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: Ac49BlT1IjndVe7RSkC6cAdjV/9IQw== 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: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:01:06 -0000 I wouldn't attempt to rewrite the whole 4.6 REQ6, but I feel it too generic= covering many typical security topics that may not be needed. e.g., "DMM protocol solutions MUST consider security aspects, including confident= iality and integrity." should read "DMM protocol solutions MUST consider security risks introduced by the DMM = service into a network." Another example: This discussion below is probably not necessary before und= erstanding what kind of risk DMM adds. "opt-in or opt-out data confidentiality to signaling messages depending on = network environments or user requirements." I don't wanna appear pedantic (I guess that admits it already), but, someth= ing like this "Mutual authentication and authorization between a mobile host/router and an access router providing the DMM service to the mobile host/router are required to prevent potential attacks in the access network of the DMM service." is discussing solutions already. Of course we don't know either way yet, but DMM may only need indirect or d= irect proof of possession of past and new IP addresses, rather than full AA= A, to serve its purpose safely. I hope this helps. Bests. J. Byoung-Jo "J" Kim AT&T Labs - Research http://sites.google.com/site/macsbug/ On Apr 19, 2013, at 4:13 AM, Jong-Hyouk Lee wrote: > Hello, Byoung-Jo >=20 > Regarding your comments on the security text, for your comment 2, I do no= t quite get you. Provide clear text expressing your concern then I will rev= iew and try to reflect to the draft. For your comment 5, just you need to b= e sure that the given text is about the general security consideration. >=20 > Cheers. >=20 >=20 > On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) wrote: > Hi. >=20 > Below are my comments on the draft-ietf-dmm-requirements-03. >=20 > Overall, the draft has much to admire and agreeable on most points. > Kudos to the authors. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 1: >=20 > REQ2: Transparency to Upper Layers when needed >=20 > >> I would like to suggest that DMM must provide transparency to upper la= yers for a limited time only when needed. Upper layer protocols or applicat= ions that are unaware of IP layer mobility and IP address changes cannot be= supported indefinitely, without compromising the purpose of DMM. How much = time is of course another matter, but that can be discussed during design o= r even dynamic. > In time, applications and upper layer protocols will have to be updated t= o handle IP address changes by reconnect or other means, as long as DMM pro= vides temporary shield from packet losses or other disruptions and buy them= time to make preparations. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 2: >=20 > REQ6: Security considerations >=20 > >> I think the requirements described here may give the impression that D= MM excludes ephemeral security for the purpose of routing to the correct en= tities, but not necessarily tied to service authorizations or identities. A= lso, protection requirements beyond what current ISPs deal with for their a= ccess routers seem unnecessary. DMM's own security should be limited to ris= ks that DMM adds to the access network, not the whole access network securi= ty. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 3: > REQ7: DMM should enable multicast solutions in flexible distribution sce= nario. >=20 > >> I lack the necessary knowledge on multicast but this seems like a feel= -good statement without a point. I suggest to drop this requirement or make= a clearer statement like "DMM should allow multicast to survive IP layer m= obility without packet loss", or more modestly, "DMM should not foreclose m= ulticast support during IP layer mobility.", etc.. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 4: >=20 > 5. Security Considerations > Distributed mobility management (DMM) requires two kinds of security > considerations: First, access network security that only allows a > legitimate mobile host/router to access the DMM service; Second, end- > to-end security that protects signaling messages for the DMM service. >=20 > >> Related to my Comment 2, "access network security" is confusing here, = as it often means allowing access to the network to begin with. DMM must as= sume that is already done at least in the lower layer or even IP layer. It = may or may not offer DMM service to anyone or only to authorized devices/us= ers. I think DMM must cover the situation where the service is offered to a= nything that asks for it, while ensuring the packets are not redirected to = wrong directions. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Bests. >=20 > Byoung-Jo "J" Kim > AT&T Labs - Research > https://sites.google.com/site/macsbug/ >=20 >=20 > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: >=20 > > Folks, > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > The issues, even editorials, must be recorded into the Issue Tracker, > > otherwise they are likely to be neglected. We require minimum three > > reviews (that are more than one liners). The more the better, though. > > > > The WGLC ends on Wednesday 24rd April. > > > > - Jouni & Julien > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > --=20 > RSM Department, TELECOM Bretagne, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >=20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ From danny.moses@intel.com Mon Apr 22 06:39:03 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C304121F8414 for ; Mon, 22 Apr 2013 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MXov94orX8M for ; Mon, 22 Apr 2013 06:39:02 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 349B421F8D84 for ; Mon, 22 Apr 2013 06:39:02 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 22 Apr 2013 06:39:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,526,1363158000"; d="scan'208,217";a="322925428" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by fmsmga001.fm.intel.com with ESMTP; 22 Apr 2013 06:39:00 -0700 Received: from hasmsx103.ger.corp.intel.com (10.184.198.6) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Apr 2013 06:38:59 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.37]) by HASMSX103.ger.corp.intel.com ([169.254.6.244]) with mapi id 14.01.0355.002; Mon, 22 Apr 2013 16:38:56 +0300 From: "Moses, Danny" To: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: Ac47pAVWYRwKLwSL4U2wKRlDpYIsGgBGKbMAAKgch2A= Date: Mon, 22 Apr 2013 13:38:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.12] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28101E5B6FEHASMSX106gercor_" MIME-Version: 1.0 Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:39:03 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28101E5B6FEHASMSX106gercor_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGksDQoNClJlZ2FyZGluZyB0aGUgZmlyc3QgY29tbWVudCBhYm91dCB0cmFuc3BhcmVuY3kgdG8g dXBwZXIgbGF5ZXJzLCBJIGFncmVlIHRoYXQgdGhpcyBpcyBhIHZlcnkgbGltaXRpbmcgcmVxdWly ZW1lbnQgYnV0IGFsc28gdGhpbmsgaXQgaXMgYSBjcnVjaWFsIG9uZSBmb3IgYmFja3dhcmRzIGNv bXBhdGliaWxpdHkuIFNvIEkgZG8gbm90IHRoaW5rIHdlIGNhbiBsaWdodGVuIGl0IGJ5IGRlZmlu aW5nIGEgdGltZSBsaW1pdC4NCg0KSG93ZXZlciwgd2UgY2FuIGFsbG93IG9wdGltaXphdGlvbiBm ZWF0dXJlcyB0aGF0IHJlbHkgb24gdXBwZXItbGF5ZXIgcHJvdG9jb2xzIChvciBhcHBsaWNhdGlv bnMpIGJlaW5nIGF3YXJlIG9mIElQIGxheWVyIG1vYmlsaXR5IGFzIGxvbmcgYXMgdGhlc2UgYXJl IGZvciBvcHRpbWl6YXRpb24gb25seS4gVGhpcyBtZWFucyB0aGF0IHVwcGVyLWxheWVyIHByb3Rv Y29scy9hcHBsaWNhdGlvbnMgdGhhdCBhcmUgTk9UIGF3YXJlIG9mIElQIG1vYmlsaXR5IHdpbGwg Y29udGludWUgdG8gd29yayBjb3JyZWN0bHkgYnV0IHdpdGhvdXQgZXh0cmEgb3B0aW1pemF0aW9u IHRoYXQgIHRob3NlIHdoaWNoIEFSRSBhd2FyZSB3aWxsIHV0aWxpemUuDQoNCkluIGZhY3QsIEkg YmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIFJFUTIgdG8gYWxsb3cgZmVhdHVyZXMg dGhhdCBhcmUgbm90IHRyYW5zcGFyZW50IHRvIHVwcGVyIGxheWVycyBhcyBsb25nIGFzIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQuDQoNClJlZ2FyZHMsDQogICAgICAgICAg ICAgICAgL0Rhbm55DQoNCkZyb206IGRtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG1tLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb25nLUh5b3VrIExlZQ0KU2VudDogRnJpZGF5 LCBBcHJpbCAxOSwgMjAxMyAxMToxNA0KVG86IEtJTSwgQllPVU5HLUpPIEogKEJZT1VORy1KTykN CkNjOiBkbW1AaWV0Zi5vcmc7IGRtbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbRE1NXSBXR0xDICMyIHN0YXJ0cyBmb3IgZHJhZnQtaWV0Zi1kbW0tcmVxdWlyZW1lbnRzLTAz DQoNCkhlbGxvLCBCeW91bmctSm8NCg0KUmVnYXJkaW5nIHlvdXIgY29tbWVudHMgb24gdGhlIHNl Y3VyaXR5IHRleHQsIGZvciB5b3VyIGNvbW1lbnQgMiwgSSBkbyBub3QgcXVpdGUgZ2V0IHlvdS4g UHJvdmlkZSBjbGVhciB0ZXh0IGV4cHJlc3NpbmcgeW91ciBjb25jZXJuIHRoZW4gSSB3aWxsIHJl dmlldyBhbmQgdHJ5IHRvIHJlZmxlY3QgdG8gdGhlIGRyYWZ0LiBGb3IgeW91ciBjb21tZW50IDUs IGp1c3QgeW91IG5lZWQgdG8gYmUgc3VyZSB0aGF0IHRoZSBnaXZlbiB0ZXh0IGlzIGFib3V0IHRo ZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uDQoNCkNoZWVycy4NCg0KT24gV2VkLCBB cHIgMTcsIDIwMTMgYXQgOTo0NCBQTSwgS0lNLCBCWU9VTkctSk8gSiAoQllPVU5HLUpPKSA8bWFj c2J1Z0ByZXNlYXJjaC5hdHQuY29tPG1haWx0bzptYWNzYnVnQHJlc2VhcmNoLmF0dC5jb20+PiB3 cm90ZToNCkhpLg0KDQpCZWxvdyBhcmUgbXkgY29tbWVudHMgb24gdGhlIGRyYWZ0LWlldGYtZG1t LXJlcXVpcmVtZW50cy0wMy4NCg0KT3ZlcmFsbCwgdGhlIGRyYWZ0IGhhcyBtdWNoIHRvIGFkbWly ZSBhbmQgYWdyZWVhYmxlIG9uIG1vc3QgcG9pbnRzLg0KS3Vkb3MgdG8gdGhlIGF1dGhvcnMuDQoN Cg0KPT09PT09PT09PT09PT09PT09PQ0KQ29tbWVudCAxOg0KDQpSRVEyOiAgVHJhbnNwYXJlbmN5 IHRvIFVwcGVyIExheWVycyB3aGVuIG5lZWRlZA0KDQo+PiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2Vz dCB0aGF0IERNTSBtdXN0IHByb3ZpZGUgdHJhbnNwYXJlbmN5IHRvIHVwcGVyIGxheWVycyBmb3Ig YSBsaW1pdGVkIHRpbWUgb25seSB3aGVuIG5lZWRlZC4gVXBwZXIgbGF5ZXIgcHJvdG9jb2xzIG9y IGFwcGxpY2F0aW9ucyB0aGF0IGFyZSB1bmF3YXJlIG9mIElQIGxheWVyIG1vYmlsaXR5IGFuZCBJ UCBhZGRyZXNzIGNoYW5nZXMgY2Fubm90IGJlIHN1cHBvcnRlZCBpbmRlZmluaXRlbHksIHdpdGhv dXQgY29tcHJvbWlzaW5nIHRoZSBwdXJwb3NlIG9mIERNTS4gSG93IG11Y2ggdGltZSBpcyBvZiBj b3Vyc2UgYW5vdGhlciBtYXR0ZXIsIGJ1dCB0aGF0IGNhbiBiZSBkaXNjdXNzZWQgZHVyaW5nIGRl c2lnbiBvciBldmVuIGR5bmFtaWMuDQpJbiB0aW1lLCBhcHBsaWNhdGlvbnMgYW5kIHVwcGVyIGxh eWVyIHByb3RvY29scyB3aWxsIGhhdmUgdG8gYmUgdXBkYXRlZCB0byBoYW5kbGUgSVAgYWRkcmVz cyBjaGFuZ2VzIGJ5IHJlY29ubmVjdCBvciBvdGhlciBtZWFucywgYXMgbG9uZyBhcyBETU0gcHJv dmlkZXMgdGVtcG9yYXJ5IHNoaWVsZCBmcm9tIHBhY2tldCBsb3NzZXMgb3Igb3RoZXIgZGlzcnVw dGlvbnMgYW5kIGJ1eSB0aGVtIHRpbWUgdG8gbWFrZSBwcmVwYXJhdGlvbnMuDQoNCj09PT09PT09 PT09PT09PT09PT09DQpDb21tZW50IDI6DQoNClJFUTY6ICBTZWN1cml0eSBjb25zaWRlcmF0aW9u cw0KDQo+PiBJIHRoaW5rIHRoZSByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGhlcmUgbWF5IGdpdmUg dGhlIGltcHJlc3Npb24gdGhhdCBETU0gZXhjbHVkZXMgZXBoZW1lcmFsIHNlY3VyaXR5IGZvciB0 aGUgcHVycG9zZSBvZiByb3V0aW5nIHRvIHRoZSBjb3JyZWN0IGVudGl0aWVzLCBidXQgbm90IG5l Y2Vzc2FyaWx5IHRpZWQgdG8gc2VydmljZSBhdXRob3JpemF0aW9ucyBvciBpZGVudGl0aWVzLiBB bHNvLCBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cyBiZXlvbmQgd2hhdCBjdXJyZW50IElTUHMgZGVh bCB3aXRoIGZvciB0aGVpciBhY2Nlc3Mgcm91dGVycyBzZWVtIHVubmVjZXNzYXJ5LiBETU0ncyBv d24gc2VjdXJpdHkgc2hvdWxkIGJlIGxpbWl0ZWQgdG8gcmlza3MgdGhhdCBETU0gYWRkcyB0byB0 aGUgYWNjZXNzIG5ldHdvcmssIG5vdCB0aGUgd2hvbGUgYWNjZXNzIG5ldHdvcmsgc2VjdXJpdHku DQoNCj09PT09PT09PT09PT09PT09PT09PQ0KQ29tbWVudCAzOg0KUkVRNzogIERNTSBzaG91bGQg ZW5hYmxlIG11bHRpY2FzdCBzb2x1dGlvbnMgaW4gZmxleGlibGUgZGlzdHJpYnV0aW9uIHNjZW5h cmlvLg0KPj4gSSBsYWNrIHRoZSBuZWNlc3Nhcnkga25vd2xlZGdlIG9uIG11bHRpY2FzdCBidXQg dGhpcyBzZWVtcyBsaWtlIGEgZmVlbC1nb29kIHN0YXRlbWVudCB3aXRob3V0IGEgcG9pbnQuIEkg c3VnZ2VzdCB0byBkcm9wIHRoaXMgcmVxdWlyZW1lbnQgb3IgbWFrZSBhIGNsZWFyZXIgc3RhdGVt ZW50IGxpa2UgIkRNTSBzaG91bGQgYWxsb3cgbXVsdGljYXN0IHRvIHN1cnZpdmUgSVAgbGF5ZXIg bW9iaWxpdHkgd2l0aG91dCBwYWNrZXQgbG9zcyIsIG9yIG1vcmUgbW9kZXN0bHksICJETU0gc2hv dWxkIG5vdCBmb3JlY2xvc2UgbXVsdGljYXN0IHN1cHBvcnQgZHVyaW5nIElQIGxheWVyIG1vYmls aXR5LiIsIGV0Yy4uDQoNCj09PT09PT09PT09PT09PT09PT09DQpDb21tZW50IDQ6DQoNCjUuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KICAgRGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVu dCAoRE1NKSByZXF1aXJlcyB0d28ga2luZHMgb2Ygc2VjdXJpdHkNCiAgIGNvbnNpZGVyYXRpb25z OiBGaXJzdCwgYWNjZXNzIG5ldHdvcmsgc2VjdXJpdHkgdGhhdCBvbmx5IGFsbG93cyBhDQogICBs ZWdpdGltYXRlIG1vYmlsZSBob3N0L3JvdXRlciB0byBhY2Nlc3MgdGhlIERNTSBzZXJ2aWNlOyBT ZWNvbmQsIGVuZC0NCiAgIHRvLWVuZCBzZWN1cml0eSB0aGF0IHByb3RlY3RzIHNpZ25hbGluZyBt ZXNzYWdlcyBmb3IgdGhlIERNTSBzZXJ2aWNlLg0KPj4gUmVsYXRlZCB0byBteSBDb21tZW50IDIs ICJhY2Nlc3MgbmV0d29yayBzZWN1cml0eSIgaXMgY29uZnVzaW5nIGhlcmUsIGFzIGl0IG9mdGVu IG1lYW5zIGFsbG93aW5nIGFjY2VzcyB0byB0aGUgbmV0d29yayB0byBiZWdpbiB3aXRoLiBETU0g bXVzdCBhc3N1bWUgdGhhdCBpcyBhbHJlYWR5IGRvbmUgYXQgbGVhc3QgaW4gdGhlIGxvd2VyIGxh eWVyIG9yIGV2ZW4gSVAgbGF5ZXIuIEl0IG1heSBvciBtYXkgbm90IG9mZmVyIERNTSBzZXJ2aWNl IHRvIGFueW9uZSBvciBvbmx5IHRvIGF1dGhvcml6ZWQgZGV2aWNlcy91c2Vycy4gSSB0aGluayBE TU0gbXVzdCBjb3ZlciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2aWNlIGlzIG9mZmVyZWQg dG8gYW55dGhpbmcgdGhhdCBhc2tzIGZvciBpdCwgd2hpbGUgZW5zdXJpbmcgdGhlIHBhY2tldHMg YXJlIG5vdCByZWRpcmVjdGVkIHRvIHdyb25nIGRpcmVjdGlvbnMuDQoNCj09PT09PT09PT09PT09 PT09PT0NCg0KQmVzdHMuDQoNCkJ5b3VuZy1KbyAiSiIgS2ltDQpBVCZUIExhYnMgLSBSZXNlYXJj aA0KaHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvbWFjc2J1Zy8NCg0KDQpPbiBBcHIgMTAs IDIwMTMsIGF0IDM6MTkgQU0sIEpvdW5pIEtvcmhvbmVuIHdyb3RlOg0KDQo+IEZvbGtzLA0KPg0K PiBUaGlzIG1haWwgc3RhcnRzIGEgdHdvIHdlZWsgV0dMQyAjMiBmb3IgZHJhZnQtaWV0Zi1kbW0t cmVxdWlyZW1lbnRzLTAzLg0KPiBUaGUgaXNzdWVzLCBldmVuIGVkaXRvcmlhbHMsIG11c3QgYmUg cmVjb3JkZWQgaW50byB0aGUgSXNzdWUgVHJhY2tlciwNCj4gb3RoZXJ3aXNlIHRoZXkgYXJlIGxp a2VseSB0byBiZSBuZWdsZWN0ZWQuIFdlIHJlcXVpcmUgbWluaW11bSB0aHJlZQ0KPiByZXZpZXdz ICh0aGF0IGFyZSBtb3JlIHRoYW4gb25lIGxpbmVycykuIFRoZSBtb3JlIHRoZSBiZXR0ZXIsIHRo b3VnaC4NCj4NCj4gVGhlIFdHTEMgZW5kcyBvbiBXZWRuZXNkYXkgMjRyZCBBcHJpbC4NCj4NCj4g LSBKb3VuaSAmIEp1bGllbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1h aWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg0KLS0NClJTTSBEZXBhcnRtZW50 LCBURUxFQ09NIEJyZXRhZ25lLCBGcmFuY2UNCkpvbmctSHlvdWsgTGVlLCBsaXZpbmcgc29tZXdo ZXJlIGJldHdlZW4gL2Rldi9udWxsIGFuZCAvZGV2L3JhbmRvbQ0KDQojZW1haWw6IGpvbmdoeW91 ayAoYXQpIGdtYWlsIChkb3QpIGNvbQ0KI3dlYnBhZ2U6IGh0dHA6Ly9zaXRlcy5nb29nbGUuY29t L3NpdGUvaHVycnlvbi8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9y YXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQK cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cy4K --_000_F0CF5715D3D1884BAC731EA1103AC28101E5B6FEHASMSX106gercor_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgdGhlIGZp cnN0IGNvbW1lbnQgYWJvdXQgdHJhbnNwYXJlbmN5IHRvIHVwcGVyIGxheWVycywgSSBhZ3JlZSB0 aGF0IHRoaXMgaXMgYSB2ZXJ5IGxpbWl0aW5nIHJlcXVpcmVtZW50IGJ1dCBhbHNvIHRoaW5rIGl0 IGlzIGEgY3J1Y2lhbCBvbmUgZm9yIGJhY2t3YXJkcw0KIGNvbXBhdGliaWxpdHkuIFNvIEkgZG8g bm90IHRoaW5rIHdlIGNhbiBsaWdodGVuIGl0IGJ5IGRlZmluaW5nIGEgdGltZSBsaW1pdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvd2V2ZXIsIHdlIGNhbiBhbGxvdyBvcHRpbWl6YXRpb24gZmVhdHVyZXMgdGhhdCBy ZWx5IG9uIHVwcGVyLWxheWVyIHByb3RvY29scyAob3IgYXBwbGljYXRpb25zKSBiZWluZyBhd2Fy ZSBvZiBJUCBsYXllciBtb2JpbGl0eSBhcyBsb25nIGFzIHRoZXNlIGFyZSBmb3Igb3B0aW1pemF0 aW9uDQogb25seS4gVGhpcyBtZWFucyB0aGF0IHVwcGVyLWxheWVyIHByb3RvY29scy9hcHBsaWNh dGlvbnMgdGhhdCBhcmUgTk9UIGF3YXJlIG9mIElQIG1vYmlsaXR5IHdpbGwgY29udGludWUgdG8g d29yayBjb3JyZWN0bHkgYnV0IHdpdGhvdXQgZXh0cmEgb3B0aW1pemF0aW9uIHRoYXQgJm5ic3A7 dGhvc2Ugd2hpY2ggQVJFIGF3YXJlIHdpbGwgdXRpbGl6ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGZhY3QsIEkg YmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIFJFUTIgdG8gYWxsb3cgZmVhdHVyZXMg dGhhdCBhcmUgbm90IHRyYW5zcGFyZW50IHRvIHVwcGVyIGxheWVycyBhcyBsb25nIGFzIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgL0Rhbm55PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkbW0t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5Kb25nLUh5b3VrIExlZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmls IDE5LCAyMDEzIDExOjE0PGJyPg0KPGI+VG86PC9iPiBLSU0sIEJZT1VORy1KTyBKIChCWU9VTkct Sk8pPGJyPg0KPGI+Q2M6PC9iPiBkbW1AaWV0Zi5vcmc7IGRtbS1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtETU1dIFdHTEMgIzIgc3RhcnRzIGZvciBkcmFm dC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IZWxsbywgQnlvdW5nLUpvPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgeW91ciBjb21tZW50cyBvbiB0aGUgc2VjdXJpdHkgdGV4 dCwgZm9yIHlvdXIgY29tbWVudCAyLCBJIGRvIG5vdCBxdWl0ZSBnZXQgeW91LiBQcm92aWRlIGNs ZWFyIHRleHQgZXhwcmVzc2luZyB5b3VyIGNvbmNlcm4gdGhlbiBJIHdpbGwgcmV2aWV3IGFuZCB0 cnkgdG8gcmVmbGVjdCB0byB0aGUgZHJhZnQuIEZvciB5b3VyIGNvbW1lbnQgNSwganVzdCB5b3Ug bmVlZCB0byBiZSBzdXJlIHRoYXQgdGhlDQogZ2l2ZW4gdGV4dCBpcyBhYm91dCB0aGUgZ2VuZXJh bCBzZWN1cml0eSBjb25zaWRlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBBcHIgMTcsIDIwMTMgYXQgOTo0NCBQTSwgS0lNLCBCWU9VTkctSk8gSiAoQllPVU5H LUpPKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hY3NidWdAcmVzZWFyY2guYXR0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1hY3NidWdAcmVzZWFyY2guYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkuPGJyPg0KPGJyPg0KQmVsb3cgYXJlIG15 IGNvbW1lbnRzIG9uIHRoZSBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDMuPGJyPg0KPGJy Pg0KT3ZlcmFsbCwgdGhlIGRyYWZ0IGhhcyBtdWNoIHRvIGFkbWlyZSBhbmQgYWdyZWVhYmxlIG9u IG1vc3QgcG9pbnRzLjxicj4NCkt1ZG9zIHRvIHRoZSBhdXRob3JzLjxicj4NCjxicj4NCjxicj4N Cj09PT09PT09PT09PT09PT09PT08YnI+DQpDb21tZW50IDE6PGJyPg0KPGJyPg0KUkVRMjogJm5i c3A7VHJhbnNwYXJlbmN5IHRvIFVwcGVyIExheWVycyB3aGVuIG5lZWRlZDxicj4NCjxicj4NCiZn dDsmZ3Q7IEkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoYXQgRE1NIG11c3QgcHJvdmlkZSB0cmFu c3BhcmVuY3kgdG8gdXBwZXIgbGF5ZXJzIGZvciBhIGxpbWl0ZWQgdGltZSBvbmx5IHdoZW4gbmVl ZGVkLiBVcHBlciBsYXllciBwcm90b2NvbHMgb3IgYXBwbGljYXRpb25zIHRoYXQgYXJlIHVuYXdh cmUgb2YgSVAgbGF5ZXIgbW9iaWxpdHkgYW5kIElQIGFkZHJlc3MgY2hhbmdlcyBjYW5ub3QgYmUg c3VwcG9ydGVkIGluZGVmaW5pdGVseSwgd2l0aG91dCBjb21wcm9taXNpbmcNCiB0aGUgcHVycG9z ZSBvZiBETU0uIEhvdyBtdWNoIHRpbWUgaXMgb2YgY291cnNlIGFub3RoZXIgbWF0dGVyLCBidXQg dGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGR1cmluZyBkZXNpZ24gb3IgZXZlbiBkeW5hbWljLjxicj4N CkluIHRpbWUsIGFwcGxpY2F0aW9ucyBhbmQgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzIHdpbGwgaGF2 ZSB0byBiZSB1cGRhdGVkIHRvIGhhbmRsZSBJUCBhZGRyZXNzIGNoYW5nZXMgYnkgcmVjb25uZWN0 IG9yIG90aGVyIG1lYW5zLCBhcyBsb25nIGFzIERNTSBwcm92aWRlcyB0ZW1wb3Jhcnkgc2hpZWxk IGZyb20gcGFja2V0IGxvc3NlcyBvciBvdGhlciBkaXNydXB0aW9ucyBhbmQgYnV5IHRoZW0gdGlt ZSB0byBtYWtlIHByZXBhcmF0aW9ucy48YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PTxi cj4NCkNvbW1lbnQgMjo8YnI+DQo8YnI+DQpSRVE2OiAmbmJzcDtTZWN1cml0eSBjb25zaWRlcmF0 aW9uczxicj4NCjxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBkZXNjcmli ZWQgaGVyZSBtYXkgZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IERNTSBleGNsdWRlcyBlcGhlbWVy YWwgc2VjdXJpdHkgZm9yIHRoZSBwdXJwb3NlIG9mIHJvdXRpbmcgdG8gdGhlIGNvcnJlY3QgZW50 aXRpZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgdGllZCB0byBzZXJ2aWNlIGF1dGhvcml6YXRpb25z IG9yIGlkZW50aXRpZXMuIEFsc28sIHByb3RlY3Rpb24gcmVxdWlyZW1lbnRzIGJleW9uZA0KIHdo YXQgY3VycmVudCBJU1BzIGRlYWwgd2l0aCBmb3IgdGhlaXIgYWNjZXNzIHJvdXRlcnMgc2VlbSB1 bm5lY2Vzc2FyeS4gRE1NJ3Mgb3duIHNlY3VyaXR5IHNob3VsZCBiZSBsaW1pdGVkIHRvIHJpc2tz IHRoYXQgRE1NIGFkZHMgdG8gdGhlIGFjY2VzcyBuZXR3b3JrLCBub3QgdGhlIHdob2xlIGFjY2Vz cyBuZXR3b3JrIHNlY3VyaXR5Ljxicj4NCjxicj4NCj09PT09PT09PT09PT09PT09PT09PTxicj4N CkNvbW1lbnQgMzo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJFUTc6ICZuYnNwO0RNTSBzaG91bGQgZW5hYmxl IG11bHRpY2FzdCBzb2x1dGlvbnMgaW4gZmxleGlibGUgZGlzdHJpYnV0aW9uIHNjZW5hcmlvLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBJIGxh Y2sgdGhlIG5lY2Vzc2FyeSBrbm93bGVkZ2Ugb24gbXVsdGljYXN0IGJ1dCB0aGlzIHNlZW1zIGxp a2UgYSBmZWVsLWdvb2Qgc3RhdGVtZW50IHdpdGhvdXQgYSBwb2ludC4gSSBzdWdnZXN0IHRvIGRy b3AgdGhpcyByZXF1aXJlbWVudCBvciBtYWtlIGEgY2xlYXJlciBzdGF0ZW1lbnQgbGlrZSAmcXVv dDtETU0gc2hvdWxkIGFsbG93IG11bHRpY2FzdCB0byBzdXJ2aXZlIElQIGxheWVyIG1vYmlsaXR5 IHdpdGhvdXQNCiBwYWNrZXQgbG9zcyZxdW90Oywgb3IgbW9yZSBtb2Rlc3RseSwgJnF1b3Q7RE1N IHNob3VsZCBub3QgZm9yZWNsb3NlIG11bHRpY2FzdCBzdXBwb3J0IGR1cmluZyBJUCBsYXllciBt b2JpbGl0eS4mcXVvdDssIGV0Yy4uPGJyPg0KPGJyPg0KPT09PT09PT09PT09PT09PT09PT08YnI+ DQpDb21tZW50IDQ6PGJyPg0KPGJyPg0KNS4gJm5ic3A7U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8 YnI+DQombmJzcDsgJm5ic3A7RGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCAoRE1NKSBy ZXF1aXJlcyB0d28ga2luZHMgb2Ygc2VjdXJpdHk8YnI+DQombmJzcDsgJm5ic3A7Y29uc2lkZXJh dGlvbnM6IEZpcnN0LCBhY2Nlc3MgbmV0d29yayBzZWN1cml0eSB0aGF0IG9ubHkgYWxsb3dzIGE8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDtsZWdpdGltYXRlIG1vYmlsZSBob3N0L3JvdXRl ciB0byBhY2Nlc3MgdGhlIERNTSBzZXJ2aWNlOyBTZWNvbmQsIGVuZC08YnI+DQombmJzcDsgJm5i c3A7dG8tZW5kIHNlY3VyaXR5IHRoYXQgcHJvdGVjdHMgc2lnbmFsaW5nIG1lc3NhZ2VzIGZvciB0 aGUgRE1NIHNlcnZpY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsmZ3Q7IFJlbGF0ZWQgdG8gbXkgQ29tbWVudCAyLCAmcXVvdDthY2Nlc3MgbmV0d29y ayBzZWN1cml0eSZxdW90OyBpcyBjb25mdXNpbmcgaGVyZSwgYXMgaXQgb2Z0ZW4gbWVhbnMgYWxs b3dpbmcgYWNjZXNzIHRvIHRoZSBuZXR3b3JrIHRvIGJlZ2luIHdpdGguIERNTSBtdXN0IGFzc3Vt ZSB0aGF0IGlzIGFscmVhZHkgZG9uZSBhdCBsZWFzdCBpbiB0aGUgbG93ZXIgbGF5ZXIgb3IgZXZl biBJUCBsYXllci4gSXQgbWF5IG9yIG1heSBub3QNCiBvZmZlciBETU0gc2VydmljZSB0byBhbnlv bmUgb3Igb25seSB0byBhdXRob3JpemVkIGRldmljZXMvdXNlcnMuIEkgdGhpbmsgRE1NIG11c3Qg Y292ZXIgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmljZSBpcyBvZmZlcmVkIHRvIGFueXRo aW5nIHRoYXQgYXNrcyBmb3IgaXQsIHdoaWxlIGVuc3VyaW5nIHRoZSBwYWNrZXRzIGFyZSBub3Qg cmVkaXJlY3RlZCB0byB3cm9uZyBkaXJlY3Rpb25zLjxicj4NCjxicj4NCj09PT09PT09PT09PT09 PT09PT08YnI+DQo8YnI+DQpCZXN0cy48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+QnlvdW5nLUpvICZxdW90O0omcXVvdDsgS2ltPC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkFUJmFtcDtUIExhYnMgLSBSZXNlYXJjaDwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48YSBocmVmPSJodHRwczovL3NpdGVzLmdv b2dsZS5jb20vc2l0ZS9tYWNzYnVnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2l0ZXMuZ29v Z2xlLmNvbS9zaXRlL21hY3NidWcvPC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk9uIEFwciAxMCwg MjAxMywgYXQgMzoxOSBBTSwgSm91bmkgS29yaG9uZW4gd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBG b2xrcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIG1haWwgc3RhcnRzIGEgdHdvIHdlZWsgV0dM QyAjMiBmb3IgZHJhZnQtaWV0Zi1kbW0tcmVxdWlyZW1lbnRzLTAzLjxicj4NCiZndDsgVGhlIGlz c3VlcywgZXZlbiBlZGl0b3JpYWxzLCBtdXN0IGJlIHJlY29yZGVkIGludG8gdGhlIElzc3VlIFRy YWNrZXIsPGJyPg0KJmd0OyBvdGhlcndpc2UgdGhleSBhcmUgbGlrZWx5IHRvIGJlIG5lZ2xlY3Rl ZC4gV2UgcmVxdWlyZSBtaW5pbXVtIHRocmVlPGJyPg0KJmd0OyByZXZpZXdzICh0aGF0IGFyZSBt b3JlIHRoYW4gb25lIGxpbmVycykuIFRoZSBtb3JlIHRoZSBiZXR0ZXIsIHRob3VnaC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgV0dMQyBlbmRzIG9uIFdlZG5lc2RheSAyNHJkIEFwcmlsLjxicj4N CiZndDs8YnI+DQomZ3Q7IC0gSm91bmkgJmFtcDsgSnVsaWVuPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgZG1tIG1haWxp bmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYu b3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RtbTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SU00gRGVwYXJ0bWVu dCwgVEVMRUNPTSBCcmV0YWduZSwgRnJhbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb25nLUh5b3VrIExlZSwgbGl2aW5nIHNvbWV3aGVyZSBi ZXR3ZWVuIC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5kb208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+I2VtYWlsOiZuYnNwO2pvbmdoeW91ayAoYXQp IGdtYWlsIChkb3QpIGNvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+I3dlYnBhZ2U6IDxhIGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3Np dGUvaHVycnlvbi8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3Np dGUvaHVycnlvbi88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+CkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91 cCBvZiBjb21wYW5pZXM8L3A+Cgo8cD5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+CnRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbjxicj4K Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZDxicj4KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUg YWxsIGNvcGllcy48L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_F0CF5715D3D1884BAC731EA1103AC28101E5B6FEHASMSX106gercor_-- From macsbug@research.att.com Mon Apr 22 08:13:29 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0058321F901D for ; Mon, 22 Apr 2013 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzasFEpJDdU4 for ; Mon, 22 Apr 2013 08:13:27 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 53E2D21F8D92 for ; Mon, 22 Apr 2013 08:13:27 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 04113120917; Mon, 22 Apr 2013 11:14:03 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 789A4E36D3; Mon, 22 Apr 2013 11:04:28 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 22 Apr 2013 11:13:26 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: "Moses, Danny" Date: Mon, 22 Apr 2013 11:13:26 -0400 Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: Ac4/a/A1vbMZz0X2QKK5e5A0lMG+tA== Message-ID: <9080814C-990B-4A67-8E45-8C807F6B8AAB@research.att.com> 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: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:13:29 -0000 I get the feeling we are of similar opinion, but I am afraid the wording is= not working for me. I observe many IP flows lasting many days in some networks. I don't think you actually want to maintain their connections via tunnels o= r what not for that long, if they have been moving about. In fact, these are (mostly) flows that can handle subnet changes behind the= scenes, since they are usually push notification, SIP signaling, or chat s= erver presence connections, that monitor and reconnect if underlying networ= k connections are broken. So, it's not infinity. Then there is some number. DMM should be a "temporary" help to keep packet losses low and give time fo= r apps to prepare a new connection, or hide rapid succession of subnet chan= ges for a limited time. That's what I think it should mean by backward compatibility. If you must hide subnet changes to all apps forever, then we cannot have DM= M. Some apps would break, but I think most of them are not important now or in= the future, and if they wish to be used in mobile environment, they must a= dapt. (and/or the OS) I would like the requirement to say it. J. Byoung-Jo "J" Kim AT&T Labs - Research http://sites.google.com/site/macsbug/ On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote: > Hi, > =20 > Regarding the first comment about transparency to upper layers, I agree t= hat this is a very limiting requirement but also think it is a crucial one = for backwards compatibility. So I do not think we can lighten it by definin= g a time limit. > =20 > However, we can allow optimization features that rely on upper-layer prot= ocols (or applications) being aware of IP layer mobility as long as these a= re for optimization only. This means that upper-layer protocols/application= s that are NOT aware of IP mobility will continue to work correctly but wit= hout extra optimization that those which ARE aware will utilize. > =20 > In fact, I believe that we should modify the REQ2 to allow features that = are not transparent to upper layers as long as backwards compatibility is m= aintained. > =20 > Regards, > /Danny > =20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Jon= g-Hyouk Lee > Sent: Friday, April 19, 2013 11:14 > To: KIM, BYOUNG-JO J (BYOUNG-JO) > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > =20 > Hello, Byoung-Jo > =20 > Regarding your comments on the security text, for your comment 2, I do no= t quite get you. Provide clear text expressing your concern then I will rev= iew and try to reflect to the draft. For your comment 5, just you need to b= e sure that the given text is about the general security consideration. > =20 > Cheers. > =20 >=20 > On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) wrote: > Hi. >=20 > Below are my comments on the draft-ietf-dmm-requirements-03. >=20 > Overall, the draft has much to admire and agreeable on most points. > Kudos to the authors. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 1: >=20 > REQ2: Transparency to Upper Layers when needed >=20 > >> I would like to suggest that DMM must provide transparency to upper la= yers for a limited time only when needed. Upper layer protocols or applicat= ions that are unaware of IP layer mobility and IP address changes cannot be= supported indefinitely, without compromising the purpose of DMM. How much = time is of course another matter, but that can be discussed during design o= r even dynamic. > In time, applications and upper layer protocols will have to be updated t= o handle IP address changes by reconnect or other means, as long as DMM pro= vides temporary shield from packet losses or other disruptions and buy them= time to make preparations. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 2: >=20 > REQ6: Security considerations >=20 > >> I think the requirements described here may give the impression that D= MM excludes ephemeral security for the purpose of routing to the correct en= tities, but not necessarily tied to service authorizations or identities. A= lso, protection requirements beyond what current ISPs deal with for their a= ccess routers seem unnecessary. DMM's own security should be limited to ris= ks that DMM adds to the access network, not the whole access network securi= ty. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 3: > REQ7: DMM should enable multicast solutions in flexible distribution sce= nario. >=20 > >> I lack the necessary knowledge on multicast but this seems like a feel= -good statement without a point. I suggest to drop this requirement or make= a clearer statement like "DMM should allow multicast to survive IP layer m= obility without packet loss", or more modestly, "DMM should not foreclose m= ulticast support during IP layer mobility.", etc.. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 4: >=20 > 5. Security Considerations > Distributed mobility management (DMM) requires two kinds of security > considerations: First, access network security that only allows a > legitimate mobile host/router to access the DMM service; Second, end- > to-end security that protects signaling messages for the DMM service. >=20 > >> Related to my Comment 2, "access network security" is confusing here, = as it often means allowing access to the network to begin with. DMM must as= sume that is already done at least in the lower layer or even IP layer. It = may or may not offer DMM service to anyone or only to authorized devices/us= ers. I think DMM must cover the situation where the service is offered to a= nything that asks for it, while ensuring the packets are not redirected to = wrong directions. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Bests. >=20 > Byoung-Jo "J" Kim > AT&T Labs - Research > https://sites.google.com/site/macsbug/ >=20 >=20 > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: >=20 > > Folks, > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > The issues, even editorials, must be recorded into the Issue Tracker, > > otherwise they are likely to be neglected. We require minimum three > > reviews (that are more than one liners). The more the better, though. > > > > The WGLC ends on Wednesday 24rd April. > > > > - Jouni & Julien > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > =20 > -- > RSM Department, TELECOM Bretagne, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > =20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >=20 From danny.moses@intel.com Mon Apr 22 08:34:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120A421F8E7A for ; Mon, 22 Apr 2013 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS3V5GWzvAOV for ; Mon, 22 Apr 2013 08:34:10 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4C21F8E2C for ; Mon, 22 Apr 2013 08:34:09 -0700 (PDT) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 22 Apr 2013 08:34:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,527,1363158000"; d="scan'208";a="230346227" Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by AZSMGA002.ch.intel.com with ESMTP; 22 Apr 2013 08:34:07 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Apr 2013 08:34:07 -0700 Received: from hasmsx103.ger.corp.intel.com (10.184.198.6) by FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Apr 2013 08:34:07 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.37]) by HASMSX103.ger.corp.intel.com ([169.254.6.244]) with mapi id 14.01.0355.002; Mon, 22 Apr 2013 18:34:03 +0300 From: "Moses, Danny" To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: Ac47pAVWYRwKLwSL4U2wKRlDpYIsGgBGKbMAAKgch2D//+tYAP//ynig Date: Mon, 22 Apr 2013 15:34:03 +0000 Message-ID: References: <9080814C-990B-4A67-8E45-8C807F6B8AAB@research.att.com> In-Reply-To: <9080814C-990B-4A67-8E45-8C807F6B8AAB@research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.12] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:34:11 -0000 Thanks for the clarification. Yes, there was a misunderstanding on my part. I thought you were implying t= hat sometime in the future, we should remove that requirement (hence my rep= ly about backwards compatibility). So actually we have two issues here: 1. How long should tunnels be maintained assuming flows can last for a long= time (forever...) 2. How strong is the transparency requirement in terms of finding solutions= that must not require any IP mobility revealing to upper-layer protocols As to the first issue, I think that dmm should behave in that sense line PM= IP. Whether there is one centralized MA or several distributed MAs should n= ot change the traffic flow (hence, alas, the tunnels must be maintained as = long as there are flows that require them). As to the second issue, as I mentioned in my previous note, I believe that = REQ2 should allow the ability of upper-layers notification for optimization= purposes only. Regards, /Danny -----Original Message----- From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com] = Sent: Monday, April 22, 2013 18:13 To: Moses, Danny Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org; Jong-Hyouk Lee Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 I get the feeling we are of similar opinion, but I am afraid the wording is= not working for me. I observe many IP flows lasting many days in some networks. I don't think you actually want to maintain their connections via tunnels o= r what not for that long, if they have been moving about. In fact, these are (mostly) flows that can handle subnet changes behind the= scenes, since they are usually push notification, SIP signaling, or chat s= erver presence connections, that monitor and reconnect if underlying networ= k connections are broken. So, it's not infinity. Then there is some number. DMM should be a "temporary" help to keep packet losses low and give time fo= r apps to prepare a new connection, or hide rapid succession of subnet chan= ges for a limited time. That's what I think it should mean by backward compatibility. If you must hide subnet changes to all apps forever, then we cannot have DM= M. Some apps would break, but I think most of them are not important now or in= the future, and if they wish to be used in mobile environment, they must a= dapt. (and/or the OS) I would like the requirement to say it. J. Byoung-Jo "J" Kim AT&T Labs - Research http://sites.google.com/site/macsbug/ On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote: > Hi, > = > Regarding the first comment about transparency to upper layers, I agree t= hat this is a very limiting requirement but also think it is a crucial one = for backwards compatibility. So I do not think we can lighten it by definin= g a time limit. > = > However, we can allow optimization features that rely on upper-layer prot= ocols (or applications) being aware of IP layer mobility as long as these a= re for optimization only. This means that upper-layer protocols/application= s that are NOT aware of IP mobility will continue to work correctly but wit= hout extra optimization that those which ARE aware will utilize. > = > In fact, I believe that we should modify the REQ2 to allow features that = are not transparent to upper layers as long as backwards compatibility is m= aintained. > = > Regards, > /Danny > = > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = > Jong-Hyouk Lee > Sent: Friday, April 19, 2013 11:14 > To: KIM, BYOUNG-JO J (BYOUNG-JO) > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > = > Hello, Byoung-Jo > = > Regarding your comments on the security text, for your comment 2, I do no= t quite get you. Provide clear text expressing your concern then I will rev= iew and try to reflect to the draft. For your comment 5, just you need to b= e sure that the given text is about the general security consideration. > = > Cheers. > = > = > On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) wrote: > Hi. > = > Below are my comments on the draft-ietf-dmm-requirements-03. > = > Overall, the draft has much to admire and agreeable on most points. > Kudos to the authors. > = > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 1: > = > REQ2: Transparency to Upper Layers when needed > = > >> I would like to suggest that DMM must provide transparency to upper la= yers for a limited time only when needed. Upper layer protocols or applicat= ions that are unaware of IP layer mobility and IP address changes cannot be= supported indefinitely, without compromising the purpose of DMM. How much = time is of course another matter, but that can be discussed during design o= r even dynamic. > In time, applications and upper layer protocols will have to be updated t= o handle IP address changes by reconnect or other means, as long as DMM pro= vides temporary shield from packet losses or other disruptions and buy them= time to make preparations. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 2: > = > REQ6: Security considerations > = > >> I think the requirements described here may give the impression that D= MM excludes ephemeral security for the purpose of routing to the correct en= tities, but not necessarily tied to service authorizations or identities. A= lso, protection requirements beyond what current ISPs deal with for their a= ccess routers seem unnecessary. DMM's own security should be limited to ris= ks that DMM adds to the access network, not the whole access network securi= ty. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 3: > REQ7: DMM should enable multicast solutions in flexible distribution sce= nario. > = > >> I lack the necessary knowledge on multicast but this seems like a feel= -good statement without a point. I suggest to drop this requirement or make= a clearer statement like "DMM should allow multicast to survive IP layer m= obility without packet loss", or more modestly, "DMM should not foreclose m= ulticast support during IP layer mobility.", etc.. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Comment 4: > = > 5. Security Considerations > Distributed mobility management (DMM) requires two kinds of security > considerations: First, access network security that only allows a > legitimate mobile host/router to access the DMM service; Second, end- > to-end security that protects signaling messages for the DMM service. > = > >> Related to my Comment 2, "access network security" is confusing here, = as it often means allowing access to the network to begin with. DMM must as= sume that is already done at least in the lower layer or even IP layer. It = may or may not offer DMM service to anyone or only to authorized devices/us= ers. I think DMM must cover the situation where the service is offered to a= nything that asks for it, while ensuring the packets are not redirected to = wrong directions. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > Bests. > = > Byoung-Jo "J" Kim > AT&T Labs - Research > https://sites.google.com/site/macsbug/ > = > = > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: > = > > Folks, > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > The issues, even editorials, must be recorded into the Issue = > > Tracker, otherwise they are likely to be neglected. We require = > > minimum three reviews (that are more than one liners). The more the bet= ter, though. > > > > The WGLC ends on Wednesday 24rd April. > > > > - Jouni & Julien > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > = > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > = > = > = > -- > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living = > somewhere between /dev/null and /dev/random > = > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > = > This e-mail and any attachments may contain confidential material for = > the sole use of the intended recipient(s). Any review or distribution = > by others is strictly prohibited. If you are not the intended = > recipient, please contact the sender and delete all copies. > = --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From sfigueiredo@av.it.pt Mon Apr 22 15:00:14 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CAF21E8094 for ; Mon, 22 Apr 2013 15:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oges8yZuYdjd for ; Mon, 22 Apr 2013 15:00:08 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id DDFAA21E8088 for ; Mon, 22 Apr 2013 15:00:07 -0700 (PDT) Received: from [213.22.3.34] (account sfigueiredo@av.it.pt HELO [192.168.0.103]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 68860657; Mon, 22 Apr 2013 23:00:05 +0100 Message-ID: <5175B2E3.2040700@av.it.pt> Date: Mon, 22 Apr 2013 23:00:03 +0100 From: =?ISO-8859-1?Q?S=E9rgio?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jouni Korhonen References: <045B0AE7-90CA-44E1-B023-EB3CCAEE81A4@gmail.com> In-Reply-To: <045B0AE7-90CA-44E1-B023-EB3CCAEE81A4@gmail.com> Content-Type: multipart/alternative; boundary="------------080603090301070609080503" Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 22:00:15 -0000 This is a multi-part message in MIME format. --------------080603090301070609080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Below are my comments regarding multicast-related text, as one of the co-authors. Em 15/04/2013 21:18, Jouni Korhonen escreveu: > Hi, > > My WGLC comments of the I-D as a chair, not the document co-author. I will > also put them one by one into the issue tracker. > > - Jouni (...) > > 7) Section 1 > > Moreover, the availability of multi-mode devices and the possibility > of using several network interfaces simultaneously have motivated the > development of even more protocol extensions to add more capabilities > and to combine IP multicasting to the base protocol. In the end, > deployment is further complicated with the multitude of extensions. > > o While "multi-mode" is correct, within IETF I would say "multiple > interface host" is better. > o I do not understand how "to combine IP multicasting to the base protocol" > relates to the paragraph. > o What is the "base protocol" here? ### Comments on 7) ### SF: In previous version, we tried to motivate for IP multicast considerations within the Introduction by touching down previous text while addressing the justifiability of DMM. But seeing "to combine IP multicasting .." again, it doesn't seem to be perfectly aligned with sub-concluding sentence on the availability of multi-mode terminals. Additionally, "Base Protocol" was meant to refer to any mobility protocol to which multicast support was designed or added as an afterthought. So, our revised text is as follows: -->"Moreover, the availability of multi-mode devices and the possibility of using several network interfaces simultaneously have motivated the development of even more protocol extensions to add more capabilities and to combine IP multicasting to the base protocol. In the end, deployment is further complicated with the multitude of extensions. As an effective transport method for multimedia data delivery, IP multicast support, including optimizations, has been introduced but by "patching-up" procedures, after completing the design of the reference mobility protocol(s), leading to network inefficiency and non-optimal routing." > > 20) Section 4.7 > > 4.7. Flexible multicast distribution > > REQ7: DMM should enable multicast solutions in flexible distribution > scenario. This flexibility enables different IP multicast > flows with respect to a mobile host to be managed (e.g., > subscribed, received and/or transmitted) using multiple > endpoints. > > o What is "flexible distribution scenario"? That is not mentioned earlier > or defined. > o I would reword the section title to something else like plain > "Multicast" or "Multicast considerations". > o "..using multiple endpoint." is supposed to mean what? I kind of > understand that as an aggregation or what does it intend to say? ### Comments on 20) ### SF: Besides the revision of the sub-section title, we also revised REQ7 and motivation parts to give a better description. --> "4.7. Multicast Considerations DMM should enable multicast solutions in flexible distribution scenario. This flexibility pertains to the preservation of IP multicast nature from the perspective of a mobility entity and transmission of multicast packets to/from various multicast-enabled entities. Therefore, this flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints multicast-enabled entities." Additionally, we revised "motivation" part as follows: --> "Motivation: The motivation of this requirement is to consider multicast early in the design process so that solutions can be developed to overcome performance issues in multicast distribution scenario avoid network inefficiency issues in multicast traffic delivery. The multicast solution may should therefore avoid having multicast-capable access routers being restricted to manage restricting the management of all IP multicast traffic relative to a host via a single endpoint, which would lead to the problems described in PS1 and PS6 through a dedicated interface on multicast-capable routers. > > 21) Section 4.7 > > problems described in PS1 and PS6. > > o For readability I would add references to relevant Sections as > well e.g. "..describer in Section 4.1 PS1 and in Section .." > ### Comments on 21) ### SF_ Following your suggestion: --> "This requirement addresses the problems PS1 in Section 4.1. and PS8 in Section 4.7." Best regards, Sérgio --------------080603090301070609080503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

Below are my comments regarding multicast-related text, as one of the co-authors.

Em 15/04/2013 21:18, Jouni Korhonen escreveu:
Hi,

My WGLC comments of the I-D as a chair, not the document co-author. I will
also put them one by one into the issue tracker.

- Jouni
(...)

7) Section 1

   Moreover, the availability of multi-mode devices and the possibility
   of using several network interfaces simultaneously have motivated the
   development of even more protocol extensions to add more capabilities
   and to combine IP multicasting to the base protocol.  In the end,
   deployment is further complicated with the multitude of extensions.

o While "multi-mode" is correct, within IETF I would say "multiple
  interface host" is better.
o I do not understand how "to combine IP multicasting to the base protocol"
  relates to the paragraph.
o What is the "base protocol" here?

### Comments on 7) ###
SF: In previous version, we tried to motivate for IP multicast considerations within the Introduction by touching down previous text while addressing the justifiability of DMM. But seeing "to combine IP multicasting .." again, it doesn't seem to be perfectly aligned with sub-concluding sentence on the availability of multi-mode terminals. Additionally, "Base Protocol" was meant to refer to any mobility protocol to which multicast support was designed or added as an afterthought. So, our revised text is as follows:
 
-->“Moreover, the availability of multi-mode devices and the possibility of using several network interfaces simultaneously have motivated the development of even more protocol extensions to add more capabilities and to combine IP multicasting to the base protocol. In the end, deployment is further complicated with the multitude of extensions.
As an effective transport method for multimedia data delivery, IP multicast support, including optimizations, has been introduced but by “patching-up" procedures, after completing the design of the reference mobility protocol(s), leading to network inefficiency and non-optimal routing.”

20) Section 4.7

4.7.  Flexible multicast distribution

   REQ7:  DMM should enable multicast solutions in flexible distribution
          scenario.  This flexibility enables different IP multicast
          flows with respect to a mobile host to be managed (e.g.,
          subscribed, received and/or transmitted) using multiple
          endpoints.

o What is "flexible distribution scenario"? That is not mentioned earlier
  or defined.
o I would reword the section title to something else like plain
  "Multicast" or "Multicast considerations".
o "..using multiple endpoint." is supposed to mean what? I kind of
  understand that as an aggregation or what does it intend to say?
### Comments on 20) ###

SF: Besides the revision of the sub-section title, we also revised REQ7 and motivation parts to give a better description.

--> "4.7. Multicast Considerations

DMM should enable multicast solutions in flexible distribution scenario. This flexibility pertains to the preservation of IP multicast nature from the perspective of a mobility entity and transmission of multicast packets to/from various multicast-enabled entities. Therefore, this flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints multicast-enabled entities."

Additionally, we revised “motivation” part as follows:

--> "Motivation: The motivation of this requirement is to consider multicast early in the design process so that solutions can be developed to overcome performance issues in multicast distribution scenario avoid network inefficiency issues in multicast traffic delivery. The multicast solution may should therefore avoid having multicast-capable access routers being restricted to manage restricting the management of all IP multicast traffic relative to a host via a single endpoint, which would lead to the problems described in PS1 and PS6 through a dedicated interface on multicast-capable routers.


21) Section 4.7

          problems described in PS1 and PS6.

o For readability I would add references to relevant Sections as
  well e.g. "..describer in Section 4.1 PS1 and in Section .."
### Comments on 21) ###

SF_ Following your suggestion:
--> "This requirement addresses the problems PS1 in Section 4.1. and PS8 in Section 4.7."

Best regards,
Sérgio

--------------080603090301070609080503-- From jonghyouk@gmail.com Tue Apr 23 02:00:29 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5421F9399 for ; Tue, 23 Apr 2013 02:00:29 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7bL8O3TN5Mf for ; Tue, 23 Apr 2013 02:00:27 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5723321F8EBD for ; Tue, 23 Apr 2013 02:00:27 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so347059vbb.9 for ; Tue, 23 Apr 2013 02:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BhtgsDa12XdxPmkYUoh6frS4zqWIQk454WeninUON8U=; b=qssP2M+dzsYU0VBp2BfLxkv8si1z+bZjIGcHAryESs5gIEqcvdZ/PpbnOM1JUKgKe6 Pj0PupaQF/xH7LeVHmSEKwZhbXlx5QRizCD+97krvkck7uFgkc5qGAENc8k/0hlnkI3E PQZlyhHdCCSXblWZXvfMOTBF4U04QXs0wP4dhnZDj5k4lZ3+FF4f8eL1Se+QEQ88XrSr lKWwV/XQ2adHKVZHn/B46hYVFN0DG6llWYRIO5hIEEz2IEnEDDiYiQK8YI65F6vfsh+T 0c3T4JTu51qI6Etao6BY4QKLvUXz+seBYHHqmYG4czZSZekM7BSwwG9avj9RRZ3ytusj Hq1Q== MIME-Version: 1.0 X-Received: by 10.221.9.70 with SMTP id ov6mr17083354vcb.72.1366707626646; Tue, 23 Apr 2013 02:00:26 -0700 (PDT) Received: by 10.58.118.164 with HTTP; Tue, 23 Apr 2013 02:00:26 -0700 (PDT) In-Reply-To: References: <9080814C-990B-4A67-8E45-8C807F6B8AAB@research.att.com> Date: Tue, 23 Apr 2013 11:00:26 +0200 Message-ID: From: Jong-Hyouk Lee To: "Moses, Danny" Content-Type: multipart/alternative; boundary=089e011770f999269104db036a6f Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 09:00:29 -0000 --089e011770f999269104db036a6f Content-Type: text/plain; charset=UTF-8 Hello Moses On Mon, Apr 22, 2013 at 5:34 PM, Moses, Danny wrote: > Thanks for the clarification. > > Yes, there was a misunderstanding on my part. I thought you were implying > that sometime in the future, we should remove that requirement (hence my > reply about backwards compatibility). > > So actually we have two issues here: > Yes here we have the two issues, but we need to distinguish them: > 1. How long should tunnels be maintained assuming flows can last for a > long time (forever...) > It is not the standardization issue even if we may mention it ("session duration" and "session tunneling required") in the DMM requirement document. > 2. How strong is the transparency requirement in terms of finding > solutions that must not require any IP mobility revealing to upper-layer > protocols > The transparency requirement must be addressed in the DMM requirement document, sure. Cheers. > > As to the first issue, I think that dmm should behave in that sense line > PMIP. Whether there is one centralized MA or several distributed MAs should > not change the traffic flow (hence, alas, the tunnels must be maintained as > long as there are flows that require them). > > As to the second issue, as I mentioned in my previous note, I believe that > REQ2 should allow the ability of upper-layers notification for optimization > purposes only. > > Regards, > /Danny > > -----Original Message----- > From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com] > Sent: Monday, April 22, 2013 18:13 > To: Moses, Danny > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org; Jong-Hyouk Lee > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > I get the feeling we are of similar opinion, but I am afraid the wording > is not working for me. > > I observe many IP flows lasting many days in some networks. > I don't think you actually want to maintain their connections via tunnels > or what not for that long, if they have been moving about. > > In fact, these are (mostly) flows that can handle subnet changes behind > the scenes, since they are usually push notification, SIP signaling, or > chat server presence connections, that monitor and reconnect if underlying > network connections are broken. > > So, it's not infinity. Then there is some number. > > DMM should be a "temporary" help to keep packet losses low and give time > for apps to prepare a new connection, or hide rapid succession of subnet > changes for a limited time. > > That's what I think it should mean by backward compatibility. > > If you must hide subnet changes to all apps forever, then we cannot have > DMM. > Some apps would break, but I think most of them are not important now or > in the future, and if they wish to be used in mobile environment, they must > adapt. (and/or the OS) > > I would like the requirement to say it. > > J. > > Byoung-Jo "J" Kim > AT&T Labs - Research > http://sites.google.com/site/macsbug/ > > > On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote: > > > Hi, > > > > Regarding the first comment about transparency to upper layers, I agree > that this is a very limiting requirement but also think it is a crucial one > for backwards compatibility. So I do not think we can lighten it by > defining a time limit. > > > > However, we can allow optimization features that rely on upper-layer > protocols (or applications) being aware of IP layer mobility as long as > these are for optimization only. This means that upper-layer > protocols/applications that are NOT aware of IP mobility will continue to > work correctly but without extra optimization that those which ARE aware > will utilize. > > > > In fact, I believe that we should modify the REQ2 to allow features that > are not transparent to upper layers as long as backwards compatibility is > maintained. > > > > Regards, > > /Danny > > > > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > > Jong-Hyouk Lee > > Sent: Friday, April 19, 2013 11:14 > > To: KIM, BYOUNG-JO J (BYOUNG-JO) > > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > > > Hello, Byoung-Jo > > > > Regarding your comments on the security text, for your comment 2, I do > not quite get you. Provide clear text expressing your concern then I will > review and try to reflect to the draft. For your comment 5, just you need > to be sure that the given text is about the general security consideration. > > > > Cheers. > > > > > > On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) < > macsbug@research.att.com> wrote: > > Hi. > > > > Below are my comments on the draft-ietf-dmm-requirements-03. > > > > Overall, the draft has much to admire and agreeable on most points. > > Kudos to the authors. > > > > > > =================== > > Comment 1: > > > > REQ2: Transparency to Upper Layers when needed > > > > >> I would like to suggest that DMM must provide transparency to upper > layers for a limited time only when needed. Upper layer protocols or > applications that are unaware of IP layer mobility and IP address changes > cannot be supported indefinitely, without compromising the purpose of DMM. > How much time is of course another matter, but that can be discussed during > design or even dynamic. > > In time, applications and upper layer protocols will have to be updated > to handle IP address changes by reconnect or other means, as long as DMM > provides temporary shield from packet losses or other disruptions and buy > them time to make preparations. > > > > ==================== > > Comment 2: > > > > REQ6: Security considerations > > > > >> I think the requirements described here may give the impression that > DMM excludes ephemeral security for the purpose of routing to the correct > entities, but not necessarily tied to service authorizations or identities. > Also, protection requirements beyond what current ISPs deal with for their > access routers seem unnecessary. DMM's own security should be limited to > risks that DMM adds to the access network, not the whole access network > security. > > > > ===================== > > Comment 3: > > REQ7: DMM should enable multicast solutions in flexible distribution > scenario. > > > > >> I lack the necessary knowledge on multicast but this seems like a > feel-good statement without a point. I suggest to drop this requirement or > make a clearer statement like "DMM should allow multicast to survive IP > layer mobility without packet loss", or more modestly, "DMM should not > foreclose multicast support during IP layer mobility.", etc.. > > > > ==================== > > Comment 4: > > > > 5. Security Considerations > > Distributed mobility management (DMM) requires two kinds of security > > considerations: First, access network security that only allows a > > legitimate mobile host/router to access the DMM service; Second, end- > > to-end security that protects signaling messages for the DMM service. > > > > >> Related to my Comment 2, "access network security" is confusing here, > as it often means allowing access to the network to begin with. DMM must > assume that is already done at least in the lower layer or even IP layer. > It may or may not offer DMM service to anyone or only to authorized > devices/users. I think DMM must cover the situation where the service is > offered to anything that asks for it, while ensuring the packets are not > redirected to wrong directions. > > > > =================== > > > > Bests. > > > > Byoung-Jo "J" Kim > > AT&T Labs - Research > > https://sites.google.com/site/macsbug/ > > > > > > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: > > > > > Folks, > > > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > > The issues, even editorials, must be recorded into the Issue > > > Tracker, otherwise they are likely to be neglected. We require > > > minimum three reviews (that are more than one liners). The more the > better, though. > > > > > > The WGLC ends on Wednesday 24rd April. > > > > > > - Jouni & Julien > > > _______________________________________________ > > > dmm mailing list > > > dmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > -- > > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living > > somewhere between /dev/null and /dev/random > > > > #email: jonghyouk (at) gmail (dot) com > > #webpage: http://sites.google.com/site/hurryon/ > > --------------------------------------------------------------------- > > A member of the Intel Corporation group of companies > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --089e011770f999269104db036a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Moses


On Mon, Apr 22, 2013 at 5:34 PM, Moses, Danny <dan= ny.moses@intel.com> wrote:
Thanks for the clarification.

Yes, there was a misunderstanding on my part. I thought you were implying t= hat sometime in the future, we should remove that requirement (hence my rep= ly about backwards compatibility).

So actually we have two issues here:

Yes here we have the two issues, but we need to=C2=A0distinguish them:<= /div>
=C2=A0
1. How long should tunnels be maintained assuming flows can last for a long= time (forever...)

It is not the = standardization issue even if we may mention it ("session duration&quo= t; and "session tunneling required") in the DMM requirement docum= ent.
=C2=A0
2. How strong is the transparency requirement in terms of finding solutions= that must not require any IP mobility revealing to upper-layer protocols

The transparency requirement must = be addressed in the DMM requirement document, sure.

Cheers.
=C2=A0

As to the first issue, I think that dmm should behave in that sense line PM= IP. Whether there is one centralized MA or several distributed MAs should n= ot change the traffic flow (hence, alas, the tunnels must be maintained as = long as there are flows that require them).

As to the second issue, as I mentioned in my previous note, I believe that = REQ2 should allow the ability of upper-layers notification for optimization= purposes only.

Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /Danny

-----Original Message-----
From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com]
Sent: Monday, April 22, 2013 18:13
To: Moses, Danny
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org; Jong-Hyouk Lee
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

I get the feeling we are of similar opinion, but I am afraid the wording is= not working for me.

I observe many IP flows lasting many days in some networks.
I don't think you actually want to maintain their connections via tunne= ls or what not for that long, if they have been moving about.

In fact, these are (mostly) flows that can handle subnet changes behind the= scenes, since they are usually push notification, SIP signaling, or chat s= erver presence connections, that monitor and reconnect if underlying networ= k connections are broken.

So, it's not infinity. Then there is some number.

DMM should be a "temporary" help to keep packet losses low and gi= ve time for apps to prepare a new connection, or hide rapid succession of s= ubnet changes for a limited time.

That's what I think it should mean by backward compatibility.

If you must hide subnet changes to all apps forever, then we cannot have DM= M.
Some apps would break, but I think most of them are not important now or in= the future, and if they wish to be used in mobile environment, they must a= dapt. (and/or the OS)

I would like the requirement to say it.

J.

Byoung-Jo "J" Kim
AT&T Labs - Research
http://= sites.google.com/site/macsbug/


On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote:

> Hi,
>
> Regarding the first comment about transparency to upper layers, I agre= e that this is a very limiting requirement but also think it is a crucial o= ne for backwards compatibility. So I do not think we can lighten it by defi= ning a time limit.
>
> However, we can allow optimization features that rely on upper-layer p= rotocols (or applications) being aware of IP layer mobility as long as thes= e are for optimization only. This means that upper-layer protocols/applicat= ions that are NOT aware of IP mobility will continue to work correctly but = without extra optimization that =C2=A0those which ARE aware will utilize. >
> In fact, I believe that we should modify the REQ2 to allow features th= at are not transparent to upper layers as long as backwards compatibility i= s maintained.
>
> Regards,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /Danny
>
> From: dmm-bounces@ietf.org= [mailto:dmm-bounces@ietf.org] = On Behalf Of
> Jong-Hyouk Lee
> Sent: Friday, April 19, 2013 11:14
> To: KIM, BYOUNG-JO J (BYOUNG-JO)
> Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
> Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 >
> Hello, Byoung-Jo
>
> Regarding your comments on the security text, for your comment 2, I do= not quite get you. Provide clear text expressing your concern then I will = review and try to reflect to the draft. For your comment 5, just you need t= o be sure that the given text is about the general security consideration.<= br> >
> Cheers.
>
>
> On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) <macsbug@research.att.com> wr= ote:
> Hi.
>
> Below are my comments on the draft-ietf-dmm-requirements-03.
>
> Overall, the draft has much to admire and agreeable on most points. > Kudos to the authors.
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Comment 1:
>
> REQ2: =C2=A0Transparency to Upper Layers when needed
>
> >> I would like to suggest that DMM must provide transparency to= upper layers for a limited time only when needed. Upper layer protocols or= applications that are unaware of IP layer mobility and IP address changes = cannot be supported indefinitely, without compromising the purpose of DMM. = How much time is of course another matter, but that can be discussed during= design or even dynamic.
> In time, applications and upper layer protocols will have to be update= d to handle IP address changes by reconnect or other means, as long as DMM = provides temporary shield from packet losses or other disruptions and buy t= hem time to make preparations.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Comment 2:
>
> REQ6: =C2=A0Security considerations
>
> >> I think the requirements described here may give the impressi= on that DMM excludes ephemeral security for the purpose of routing to the c= orrect entities, but not necessarily tied to service authorizations or iden= tities. Also, protection requirements beyond what current ISPs deal with fo= r their access routers seem unnecessary. DMM's own security should be l= imited to risks that DMM adds to the access network, not the whole access n= etwork security.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Comment 3:
> REQ7: =C2=A0DMM should enable multicast solutions in flexible distribu= tion scenario.
>
> >> I lack the necessary knowledge on multicast but this seems li= ke a feel-good statement without a point. I suggest to drop this requiremen= t or make a clearer statement like "DMM should allow multicast to surv= ive IP layer mobility without packet loss", or more modestly, "DM= M should not foreclose multicast support during IP layer mobility.", e= tc..
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Comment 4:
>
> 5. =C2=A0Security Considerations
> =C2=A0 =C2=A0Distributed mobility management (DMM) requires two kinds = of security
> =C2=A0 =C2=A0considerations: First, access network security that only = allows a
> =C2=A0 =C2=A0legitimate mobile host/router to access the DMM service; = Second, end-
> =C2=A0 =C2=A0to-end security that protects signaling messages for the = DMM service.
>
> >> Related to my Comment 2, "access network security" = is confusing here, as it often means allowing access to the network to begi= n with. DMM must assume that is already done at least in the lower layer or= even IP layer. It may or may not offer DMM service to anyone or only to au= thorized devices/users. I think DMM must cover the situation where the serv= ice is offered to anything that asks for it, while ensuring the packets are= not redirected to wrong directions.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Bests.
>
> Byoung-Jo "J" Kim
> AT&T Labs - Research
> h= ttps://sites.google.com/site/macsbug/
>
>
> On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote:
>
> > Folks,
> >
> > This mail starts a two week WGLC #2 for draft-ietf-dmm-requiremen= ts-03.
> > The issues, even editorials, must be recorded into the Issue
> > Tracker, otherwise they are likely to be neglected. We require > > minimum three reviews (that are more than one liners). The more t= he better, though.
> >
> > The WGLC ends on Wednesday 24rd April.
> >
> > - Jouni & Julien
> > _______________________________________________
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> --
> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living
> somewhere between /dev/null and /dev/random
>
> #email: jonghyouk (at) gmail (dot) com
> #webpage: http://sites.google.com/site/hurryon/
> ---------------------------------------------------------------------<= br> > A member of the Intel Corporation group of companies
>
> This e-mail and any attachments may contain confidential material for<= br> > the sole use of the intended recipient(s). Any review or distribution<= br> > by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com
--089e011770f999269104db036a6f-- From k.pentikousis@huawei.com Wed Apr 24 03:18:34 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98221F8EFC for ; Wed, 24 Apr 2013 03:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q+aeJlv-Ke9 for ; Wed, 24 Apr 2013 03:18:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88221F8E9A for ; Wed, 24 Apr 2013 03:18:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQT36652; Wed, 24 Apr 2013 10:18:30 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 11:17:59 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 11:18:28 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.56]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Wed, 24 Apr 2013 18:18:24 +0800 From: Konstantinos Pentikousis To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOPTB4vAXffZiMUkCB6lDkt5ZqEZjlLung Date: Wed, 24 Apr 2013 10:18:23 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23F43CA3A@szxeml511-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 10:18:34 -0000 |"DMM protocol solutions MUST consider security aspects, including |confidentiality and integrity." | |should read | |"DMM protocol solutions MUST consider security risks introduced by the |DMM service into a network." I think this is a reasonable suggestion and I second it, although for some = this may be considered obvious. In the newly suggested text, I would also s= /the DMM service/DMM Best regards, Kostas From hassan.aliahmad@orange.com Wed Apr 24 05:47:04 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624321F8F22 for ; Wed, 24 Apr 2013 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcnsAQ+ORdVo for ; Wed, 24 Apr 2013 05:47:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8B21F8D03 for ; Wed, 24 Apr 2013 05:47:02 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A40AB18D0C4; Wed, 24 Apr 2013 14:47:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8328327C053; Wed, 24 Apr 2013 14:47:01 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 14:47:01 +0200 From: To: 'Konstantinos Pentikousis' , "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOPTB4vAXffZiMUkCB6lDkt5ZqEZjlLunggAAlPiA= Date: Wed, 24 Apr 2013 12:47:00 +0000 Message-ID: <31656_1366807621_5177D445_31656_3647_1_C5B6A9A3D7D5C941A08B34159DEFE902078A0DB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <8D38716F0C1A444BA0CD7E96454366C23F43CA3A@szxeml511-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23F43CA3A@szxeml511-mbx.china.huawei.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.24.114517 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 12:47:04 -0000 Hello, I also support this suggestion; we only need to consider the new security r= isks, if any, introduced by DMM. Regarding the "DMM service" term, it hasn't been defined in the document an= d it's only used in the security requirement (section 4.6). It's not really= clear what this means, even if someone argue that this is obvious for DMM = guys, I don't think it's really the right terminology. DMM is rather a new = architecture, scheme, protocol.. or let us simply just say DMM. I second Konstantinos in replacing "the DMM service" by "DMM" in all the se= curity requirement section. Best regards, Hassan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Konst= antinos Pentikousis Sent: Wednesday, April 24, 2013 12:18 PM To: KIM, BYOUNG-JO J (BYOUNG-JO) Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 |"DMM protocol solutions MUST consider security aspects, including=20 |confidentiality and integrity." | |should read | |"DMM protocol solutions MUST consider security risks introduced by the=20 |DMM service into a network." I think this is a reasonable suggestion and I second it, although for some = this may be considered obvious. In the newly suggested text, I would also s= /the DMM service/DMM Best regards, Kostas _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hassan.aliahmad@orange.com Wed Apr 24 05:53:46 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CCD21F911E for ; Wed, 24 Apr 2013 05:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzSbxtaOFVq8 for ; Wed, 24 Apr 2013 05:53:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1527F21F90D5 for ; Wed, 24 Apr 2013 05:53:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3EF3E264532; Wed, 24 Apr 2013 14:53:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1819A23804B; Wed, 24 Apr 2013 14:53:43 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 14:53:42 +0200 From: To: 'Jong-Hyouk Lee' , "Moses, Danny" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOQAEIvAXffZiMUkCB6lDkt5ZqEZjlVGbQ Date: Wed, 24 Apr 2013 12:53:42 +0000 Message-ID: <30643_1366808023_5177D5D7_30643_155_1_C5B6A9A3D7D5C941A08B34159DEFE902078A0DCB@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <9080814C-990B-4A67-8E45-8C807F6B8AAB@research.att.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_C5B6A9A3D7D5C941A08B34159DEFE902078A0DCBPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.21.220319 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 12:53:46 -0000 --_000_C5B6A9A3D7D5C941A08B34159DEFE902078A0DCBPEXCVZYM11corpo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIERNTSBjaGFydGVyIG1lbnRpb25zOiDigKYgYWxsb3cgZm9yIHNldHRpbmcgdXAgSVAgbmV0 d29ya3Mgc28gdGhhdCB0cmFmZmljIGlzIGRpc3RyaWJ1dGVkIGluIGFuIOKAnG9wdGltYWwgd2F5 4oCd4oCmDQoNClNvIEkgdGhpbmsgdGhhdCB5ZXMgaXTigJlzIGEgc3RhbmRhcmRpemF0aW9uIGlz c3VlIGFuZCBzdWNoIGNhc2VzIHNob3VsZCBiZSBjb25zaWRlcmVkIGluIHRoZSBETU0gcmVxdWly ZW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpIYXNzYW4NCg0KDQpGcm9tOiBkbW0tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9uZy1I eW91ayBMZWUNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIzLCAyMDEzIDExOjAwIEFNDQpUbzogTW9z ZXMsIERhbm55DQpDYzogZG1tQGlldGYub3JnOyBkbW0tY2hhaXJzQHRvb2xzLmlldGYub3JnDQpT dWJqZWN0OiBSZTogW0RNTV0gV0dMQyAjMiBzdGFydHMgZm9yIGRyYWZ0LWlldGYtZG1tLXJlcXVp cmVtZW50cy0wMw0KDQpIZWxsbyBNb3Nlcw0KDQpPbiBNb24sIEFwciAyMiwgMjAxMyBhdCA1OjM0 IFBNLCBNb3NlcywgRGFubnkgPGRhbm55Lm1vc2VzQGludGVsLmNvbTxtYWlsdG86ZGFubnkubW9z ZXNAaW50ZWwuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQpZ ZXMsIHRoZXJlIHdhcyBhIG1pc3VuZGVyc3RhbmRpbmcgb24gbXkgcGFydC4gSSB0aG91Z2h0IHlv dSB3ZXJlIGltcGx5aW5nIHRoYXQgc29tZXRpbWUgaW4gdGhlIGZ1dHVyZSwgd2Ugc2hvdWxkIHJl bW92ZSB0aGF0IHJlcXVpcmVtZW50IChoZW5jZSBteSByZXBseSBhYm91dCBiYWNrd2FyZHMgY29t cGF0aWJpbGl0eSkuDQoNClNvIGFjdHVhbGx5IHdlIGhhdmUgdHdvIGlzc3VlcyBoZXJlOg0KDQpZ ZXMgaGVyZSB3ZSBoYXZlIHRoZSB0d28gaXNzdWVzLCBidXQgd2UgbmVlZCB0byBkaXN0aW5ndWlz aCB0aGVtOg0KDQoxLiBIb3cgbG9uZyBzaG91bGQgdHVubmVscyBiZSBtYWludGFpbmVkIGFzc3Vt aW5nIGZsb3dzIGNhbiBsYXN0IGZvciBhIGxvbmcgdGltZSAoZm9yZXZlci4uLikNCg0KSXQgaXMg bm90IHRoZSBzdGFuZGFyZGl6YXRpb24gaXNzdWUgZXZlbiBpZiB3ZSBtYXkgbWVudGlvbiBpdCAo InNlc3Npb24gZHVyYXRpb24iIGFuZCAic2Vzc2lvbiB0dW5uZWxpbmcgcmVxdWlyZWQiKSBpbiB0 aGUgRE1NIHJlcXVpcmVtZW50IGRvY3VtZW50Lg0KDQoyLiBIb3cgc3Ryb25nIGlzIHRoZSB0cmFu c3BhcmVuY3kgcmVxdWlyZW1lbnQgaW4gdGVybXMgb2YgZmluZGluZyBzb2x1dGlvbnMgdGhhdCBt dXN0IG5vdCByZXF1aXJlIGFueSBJUCBtb2JpbGl0eSByZXZlYWxpbmcgdG8gdXBwZXItbGF5ZXIg cHJvdG9jb2xzDQoNClRoZSB0cmFuc3BhcmVuY3kgcmVxdWlyZW1lbnQgbXVzdCBiZSBhZGRyZXNz ZWQgaW4gdGhlIERNTSByZXF1aXJlbWVudCBkb2N1bWVudCwgc3VyZS4NCg0KQ2hlZXJzLg0KDQoN CkFzIHRvIHRoZSBmaXJzdCBpc3N1ZSwgSSB0aGluayB0aGF0IGRtbSBzaG91bGQgYmVoYXZlIGlu IHRoYXQgc2Vuc2UgbGluZSBQTUlQLiBXaGV0aGVyIHRoZXJlIGlzIG9uZSBjZW50cmFsaXplZCBN QSBvciBzZXZlcmFsIGRpc3RyaWJ1dGVkIE1BcyBzaG91bGQgbm90IGNoYW5nZSB0aGUgdHJhZmZp YyBmbG93IChoZW5jZSwgYWxhcywgdGhlIHR1bm5lbHMgbXVzdCBiZSBtYWludGFpbmVkIGFzIGxv bmcgYXMgdGhlcmUgYXJlIGZsb3dzIHRoYXQgcmVxdWlyZSB0aGVtKS4NCg0KQXMgdG8gdGhlIHNl Y29uZCBpc3N1ZSwgYXMgSSBtZW50aW9uZWQgaW4gbXkgcHJldmlvdXMgbm90ZSwgSSBiZWxpZXZl IHRoYXQgUkVRMiBzaG91bGQgYWxsb3cgdGhlIGFiaWxpdHkgb2YgdXBwZXItbGF5ZXJzIG5vdGlm aWNhdGlvbiBmb3Igb3B0aW1pemF0aW9uIHB1cnBvc2VzIG9ubHkuDQoNClJlZ2FyZHMsDQogICAg ICAgIC9EYW5ueQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS0lNLCBCWU9V TkctSk8gSiAoQllPVU5HLUpPKSBbbWFpbHRvOm1hY3NidWdAcmVzZWFyY2guYXR0LmNvbTxtYWls dG86bWFjc2J1Z0ByZXNlYXJjaC5hdHQuY29tPl0NClNlbnQ6IE1vbmRheSwgQXByaWwgMjIsIDIw MTMgMTg6MTMNClRvOiBNb3NlcywgRGFubnkNCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBp ZXRmLm9yZz47IGRtbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRtbS1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+OyBKb25nLUh5b3VrIExlZQ0KU3ViamVjdDogUmU6IFtETU1dIFdHTEMgIzIg c3RhcnRzIGZvciBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDMNCg0KSSBnZXQgdGhlIGZl ZWxpbmcgd2UgYXJlIG9mIHNpbWlsYXIgb3BpbmlvbiwgYnV0IEkgYW0gYWZyYWlkIHRoZSB3b3Jk aW5nIGlzIG5vdCB3b3JraW5nIGZvciBtZS4NCg0KSSBvYnNlcnZlIG1hbnkgSVAgZmxvd3MgbGFz dGluZyBtYW55IGRheXMgaW4gc29tZSBuZXR3b3Jrcy4NCkkgZG9uJ3QgdGhpbmsgeW91IGFjdHVh bGx5IHdhbnQgdG8gbWFpbnRhaW4gdGhlaXIgY29ubmVjdGlvbnMgdmlhIHR1bm5lbHMgb3Igd2hh dCBub3QgZm9yIHRoYXQgbG9uZywgaWYgdGhleSBoYXZlIGJlZW4gbW92aW5nIGFib3V0Lg0KDQpJ biBmYWN0LCB0aGVzZSBhcmUgKG1vc3RseSkgZmxvd3MgdGhhdCBjYW4gaGFuZGxlIHN1Ym5ldCBj aGFuZ2VzIGJlaGluZCB0aGUgc2NlbmVzLCBzaW5jZSB0aGV5IGFyZSB1c3VhbGx5IHB1c2ggbm90 aWZpY2F0aW9uLCBTSVAgc2lnbmFsaW5nLCBvciBjaGF0IHNlcnZlciBwcmVzZW5jZSBjb25uZWN0 aW9ucywgdGhhdCBtb25pdG9yIGFuZCByZWNvbm5lY3QgaWYgdW5kZXJseWluZyBuZXR3b3JrIGNv bm5lY3Rpb25zIGFyZSBicm9rZW4uDQoNClNvLCBpdCdzIG5vdCBpbmZpbml0eS4gVGhlbiB0aGVy ZSBpcyBzb21lIG51bWJlci4NCg0KRE1NIHNob3VsZCBiZSBhICJ0ZW1wb3JhcnkiIGhlbHAgdG8g a2VlcCBwYWNrZXQgbG9zc2VzIGxvdyBhbmQgZ2l2ZSB0aW1lIGZvciBhcHBzIHRvIHByZXBhcmUg YSBuZXcgY29ubmVjdGlvbiwgb3IgaGlkZSByYXBpZCBzdWNjZXNzaW9uIG9mIHN1Ym5ldCBjaGFu Z2VzIGZvciBhIGxpbWl0ZWQgdGltZS4NCg0KVGhhdCdzIHdoYXQgSSB0aGluayBpdCBzaG91bGQg bWVhbiBieSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Lg0KDQpJZiB5b3UgbXVzdCBoaWRlIHN1Ym5l dCBjaGFuZ2VzIHRvIGFsbCBhcHBzIGZvcmV2ZXIsIHRoZW4gd2UgY2Fubm90IGhhdmUgRE1NLg0K U29tZSBhcHBzIHdvdWxkIGJyZWFrLCBidXQgSSB0aGluayBtb3N0IG9mIHRoZW0gYXJlIG5vdCBp bXBvcnRhbnQgbm93IG9yIGluIHRoZSBmdXR1cmUsIGFuZCBpZiB0aGV5IHdpc2ggdG8gYmUgdXNl ZCBpbiBtb2JpbGUgZW52aXJvbm1lbnQsIHRoZXkgbXVzdCBhZGFwdC4gKGFuZC9vciB0aGUgT1Mp DQoNCkkgd291bGQgbGlrZSB0aGUgcmVxdWlyZW1lbnQgdG8gc2F5IGl0Lg0KDQpKLg0KDQpCeW91 bmctSm8gIkoiIEtpbQ0KQVQmVCBMYWJzIC0gUmVzZWFyY2gNCmh0dHA6Ly9zaXRlcy5nb29nbGUu Y29tL3NpdGUvbWFjc2J1Zy8NCg0KDQpPbiBBcHIgMjIsIDIwMTMsIGF0IDk6MzggQU0sIE1vc2Vz LCBEYW5ueSB3cm90ZToNCg0KPiBIaSwNCj4NCj4gUmVnYXJkaW5nIHRoZSBmaXJzdCBjb21tZW50 IGFib3V0IHRyYW5zcGFyZW5jeSB0byB1cHBlciBsYXllcnMsIEkgYWdyZWUgdGhhdCB0aGlzIGlz IGEgdmVyeSBsaW1pdGluZyByZXF1aXJlbWVudCBidXQgYWxzbyB0aGluayBpdCBpcyBhIGNydWNp YWwgb25lIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gU28gSSBkbyBub3QgdGhpbmsgd2Ug Y2FuIGxpZ2h0ZW4gaXQgYnkgZGVmaW5pbmcgYSB0aW1lIGxpbWl0Lg0KPg0KPiBIb3dldmVyLCB3 ZSBjYW4gYWxsb3cgb3B0aW1pemF0aW9uIGZlYXR1cmVzIHRoYXQgcmVseSBvbiB1cHBlci1sYXll ciBwcm90b2NvbHMgKG9yIGFwcGxpY2F0aW9ucykgYmVpbmcgYXdhcmUgb2YgSVAgbGF5ZXIgbW9i aWxpdHkgYXMgbG9uZyBhcyB0aGVzZSBhcmUgZm9yIG9wdGltaXphdGlvbiBvbmx5LiBUaGlzIG1l YW5zIHRoYXQgdXBwZXItbGF5ZXIgcHJvdG9jb2xzL2FwcGxpY2F0aW9ucyB0aGF0IGFyZSBOT1Qg YXdhcmUgb2YgSVAgbW9iaWxpdHkgd2lsbCBjb250aW51ZSB0byB3b3JrIGNvcnJlY3RseSBidXQg d2l0aG91dCBleHRyYSBvcHRpbWl6YXRpb24gdGhhdCAgdGhvc2Ugd2hpY2ggQVJFIGF3YXJlIHdp bGwgdXRpbGl6ZS4NCj4NCj4gSW4gZmFjdCwgSSBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIG1vZGlm eSB0aGUgUkVRMiB0byBhbGxvdyBmZWF0dXJlcyB0aGF0IGFyZSBub3QgdHJhbnNwYXJlbnQgdG8g dXBwZXIgbGF5ZXJzIGFzIGxvbmcgYXMgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaXMgbWFpbnRh aW5lZC4NCj4NCj4gUmVnYXJkcywNCj4gICAgICAgICAgICAgICAgIC9EYW5ueQ0KPg0KPiBGcm9t OiBkbW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWls dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmIE9mDQo+IEpvbmctSHlvdWsgTGVlDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTksIDIw MTMgMTE6MTQNCj4gVG86IEtJTSwgQllPVU5HLUpPIEogKEJZT1VORy1KTykNCj4gQ2M6IGRtbUBp ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPjsgZG1tLWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86ZG1tLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtETU1dIFdH TEMgIzIgc3RhcnRzIGZvciBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDMNCj4NCj4gSGVs bG8sIEJ5b3VuZy1Kbw0KPg0KPiBSZWdhcmRpbmcgeW91ciBjb21tZW50cyBvbiB0aGUgc2VjdXJp dHkgdGV4dCwgZm9yIHlvdXIgY29tbWVudCAyLCBJIGRvIG5vdCBxdWl0ZSBnZXQgeW91LiBQcm92 aWRlIGNsZWFyIHRleHQgZXhwcmVzc2luZyB5b3VyIGNvbmNlcm4gdGhlbiBJIHdpbGwgcmV2aWV3 IGFuZCB0cnkgdG8gcmVmbGVjdCB0byB0aGUgZHJhZnQuIEZvciB5b3VyIGNvbW1lbnQgNSwganVz dCB5b3UgbmVlZCB0byBiZSBzdXJlIHRoYXQgdGhlIGdpdmVuIHRleHQgaXMgYWJvdXQgdGhlIGdl bmVyYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi4NCj4NCj4gQ2hlZXJzLg0KPg0KPg0KPiBPbiBX ZWQsIEFwciAxNywgMjAxMyBhdCA5OjQ0IFBNLCBLSU0sIEJZT1VORy1KTyBKIChCWU9VTkctSk8p IDxtYWNzYnVnQHJlc2VhcmNoLmF0dC5jb208bWFpbHRvOm1hY3NidWdAcmVzZWFyY2guYXR0LmNv bT4+IHdyb3RlOg0KPiBIaS4NCj4NCj4gQmVsb3cgYXJlIG15IGNvbW1lbnRzIG9uIHRoZSBkcmFm dC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDMuDQo+DQo+IE92ZXJhbGwsIHRoZSBkcmFmdCBoYXMg bXVjaCB0byBhZG1pcmUgYW5kIGFncmVlYWJsZSBvbiBtb3N0IHBvaW50cy4NCj4gS3Vkb3MgdG8g dGhlIGF1dGhvcnMuDQo+DQo+DQo+ID09PT09PT09PT09PT09PT09PT0NCj4gQ29tbWVudCAxOg0K Pg0KPiBSRVEyOiAgVHJhbnNwYXJlbmN5IHRvIFVwcGVyIExheWVycyB3aGVuIG5lZWRlZA0KPg0K PiA+PiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IERNTSBtdXN0IHByb3ZpZGUgdHJhbnNw YXJlbmN5IHRvIHVwcGVyIGxheWVycyBmb3IgYSBsaW1pdGVkIHRpbWUgb25seSB3aGVuIG5lZWRl ZC4gVXBwZXIgbGF5ZXIgcHJvdG9jb2xzIG9yIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSB1bmF3YXJl IG9mIElQIGxheWVyIG1vYmlsaXR5IGFuZCBJUCBhZGRyZXNzIGNoYW5nZXMgY2Fubm90IGJlIHN1 cHBvcnRlZCBpbmRlZmluaXRlbHksIHdpdGhvdXQgY29tcHJvbWlzaW5nIHRoZSBwdXJwb3NlIG9m IERNTS4gSG93IG11Y2ggdGltZSBpcyBvZiBjb3Vyc2UgYW5vdGhlciBtYXR0ZXIsIGJ1dCB0aGF0 IGNhbiBiZSBkaXNjdXNzZWQgZHVyaW5nIGRlc2lnbiBvciBldmVuIGR5bmFtaWMuDQo+IEluIHRp bWUsIGFwcGxpY2F0aW9ucyBhbmQgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzIHdpbGwgaGF2ZSB0byBi ZSB1cGRhdGVkIHRvIGhhbmRsZSBJUCBhZGRyZXNzIGNoYW5nZXMgYnkgcmVjb25uZWN0IG9yIG90 aGVyIG1lYW5zLCBhcyBsb25nIGFzIERNTSBwcm92aWRlcyB0ZW1wb3Jhcnkgc2hpZWxkIGZyb20g cGFja2V0IGxvc3NlcyBvciBvdGhlciBkaXNydXB0aW9ucyBhbmQgYnV5IHRoZW0gdGltZSB0byBt YWtlIHByZXBhcmF0aW9ucy4NCj4NCj4gPT09PT09PT09PT09PT09PT09PT0NCj4gQ29tbWVudCAy Og0KPg0KPiBSRVE2OiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4NCj4gPj4gSSB0aGluayB0 aGUgcmVxdWlyZW1lbnRzIGRlc2NyaWJlZCBoZXJlIG1heSBnaXZlIHRoZSBpbXByZXNzaW9uIHRo YXQgRE1NIGV4Y2x1ZGVzIGVwaGVtZXJhbCBzZWN1cml0eSBmb3IgdGhlIHB1cnBvc2Ugb2Ygcm91 dGluZyB0byB0aGUgY29ycmVjdCBlbnRpdGllcywgYnV0IG5vdCBuZWNlc3NhcmlseSB0aWVkIHRv IHNlcnZpY2UgYXV0aG9yaXphdGlvbnMgb3IgaWRlbnRpdGllcy4gQWxzbywgcHJvdGVjdGlvbiBy ZXF1aXJlbWVudHMgYmV5b25kIHdoYXQgY3VycmVudCBJU1BzIGRlYWwgd2l0aCBmb3IgdGhlaXIg YWNjZXNzIHJvdXRlcnMgc2VlbSB1bm5lY2Vzc2FyeS4gRE1NJ3Mgb3duIHNlY3VyaXR5IHNob3Vs ZCBiZSBsaW1pdGVkIHRvIHJpc2tzIHRoYXQgRE1NIGFkZHMgdG8gdGhlIGFjY2VzcyBuZXR3b3Jr LCBub3QgdGhlIHdob2xlIGFjY2VzcyBuZXR3b3JrIHNlY3VyaXR5Lg0KPg0KPiA9PT09PT09PT09 PT09PT09PT09PT0NCj4gQ29tbWVudCAzOg0KPiBSRVE3OiAgRE1NIHNob3VsZCBlbmFibGUgbXVs dGljYXN0IHNvbHV0aW9ucyBpbiBmbGV4aWJsZSBkaXN0cmlidXRpb24gc2NlbmFyaW8uDQo+DQo+ ID4+IEkgbGFjayB0aGUgbmVjZXNzYXJ5IGtub3dsZWRnZSBvbiBtdWx0aWNhc3QgYnV0IHRoaXMg c2VlbXMgbGlrZSBhIGZlZWwtZ29vZCBzdGF0ZW1lbnQgd2l0aG91dCBhIHBvaW50LiBJIHN1Z2dl c3QgdG8gZHJvcCB0aGlzIHJlcXVpcmVtZW50IG9yIG1ha2UgYSBjbGVhcmVyIHN0YXRlbWVudCBs aWtlICJETU0gc2hvdWxkIGFsbG93IG11bHRpY2FzdCB0byBzdXJ2aXZlIElQIGxheWVyIG1vYmls aXR5IHdpdGhvdXQgcGFja2V0IGxvc3MiLCBvciBtb3JlIG1vZGVzdGx5LCAiRE1NIHNob3VsZCBu b3QgZm9yZWNsb3NlIG11bHRpY2FzdCBzdXBwb3J0IGR1cmluZyBJUCBsYXllciBtb2JpbGl0eS4i LCBldGMuLg0KPg0KPiA9PT09PT09PT09PT09PT09PT09PQ0KPiBDb21tZW50IDQ6DQo+DQo+IDUu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiAgICBEaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5h Z2VtZW50IChETU0pIHJlcXVpcmVzIHR3byBraW5kcyBvZiBzZWN1cml0eQ0KPiAgICBjb25zaWRl cmF0aW9uczogRmlyc3QsIGFjY2VzcyBuZXR3b3JrIHNlY3VyaXR5IHRoYXQgb25seSBhbGxvd3Mg YQ0KPiAgICBsZWdpdGltYXRlIG1vYmlsZSBob3N0L3JvdXRlciB0byBhY2Nlc3MgdGhlIERNTSBz ZXJ2aWNlOyBTZWNvbmQsIGVuZC0NCj4gICAgdG8tZW5kIHNlY3VyaXR5IHRoYXQgcHJvdGVjdHMg c2lnbmFsaW5nIG1lc3NhZ2VzIGZvciB0aGUgRE1NIHNlcnZpY2UuDQo+DQo+ID4+IFJlbGF0ZWQg dG8gbXkgQ29tbWVudCAyLCAiYWNjZXNzIG5ldHdvcmsgc2VjdXJpdHkiIGlzIGNvbmZ1c2luZyBo ZXJlLCBhcyBpdCBvZnRlbiBtZWFucyBhbGxvd2luZyBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsgdG8g YmVnaW4gd2l0aC4gRE1NIG11c3QgYXNzdW1lIHRoYXQgaXMgYWxyZWFkeSBkb25lIGF0IGxlYXN0 IGluIHRoZSBsb3dlciBsYXllciBvciBldmVuIElQIGxheWVyLiBJdCBtYXkgb3IgbWF5IG5vdCBv ZmZlciBETU0gc2VydmljZSB0byBhbnlvbmUgb3Igb25seSB0byBhdXRob3JpemVkIGRldmljZXMv dXNlcnMuIEkgdGhpbmsgRE1NIG11c3QgY292ZXIgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2Vy dmljZSBpcyBvZmZlcmVkIHRvIGFueXRoaW5nIHRoYXQgYXNrcyBmb3IgaXQsIHdoaWxlIGVuc3Vy aW5nIHRoZSBwYWNrZXRzIGFyZSBub3QgcmVkaXJlY3RlZCB0byB3cm9uZyBkaXJlY3Rpb25zLg0K Pg0KPiA9PT09PT09PT09PT09PT09PT09DQo+DQo+IEJlc3RzLg0KPg0KPiBCeW91bmctSm8gIkoi IEtpbQ0KPiBBVCZUIExhYnMgLSBSZXNlYXJjaA0KPiBodHRwczovL3NpdGVzLmdvb2dsZS5jb20v c2l0ZS9tYWNzYnVnLw0KPg0KPg0KPiBPbiBBcHIgMTAsIDIwMTMsIGF0IDM6MTkgQU0sIEpvdW5p IEtvcmhvbmVuIHdyb3RlOg0KPg0KPiA+IEZvbGtzLA0KPiA+DQo+ID4gVGhpcyBtYWlsIHN0YXJ0 cyBhIHR3byB3ZWVrIFdHTEMgIzIgZm9yIGRyYWZ0LWlldGYtZG1tLXJlcXVpcmVtZW50cy0wMy4N Cj4gPiBUaGUgaXNzdWVzLCBldmVuIGVkaXRvcmlhbHMsIG11c3QgYmUgcmVjb3JkZWQgaW50byB0 aGUgSXNzdWUNCj4gPiBUcmFja2VyLCBvdGhlcndpc2UgdGhleSBhcmUgbGlrZWx5IHRvIGJlIG5l Z2xlY3RlZC4gV2UgcmVxdWlyZQ0KPiA+IG1pbmltdW0gdGhyZWUgcmV2aWV3cyAodGhhdCBhcmUg bW9yZSB0aGFuIG9uZSBsaW5lcnMpLiBUaGUgbW9yZSB0aGUgYmV0dGVyLCB0aG91Z2guDQo+ID4N Cj4gPiBUaGUgV0dMQyBlbmRzIG9uIFdlZG5lc2RheSAyNHJkIEFwcmlsLg0KPiA+DQo+ID4gLSBK b3VuaSAmIEp1bGllbg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gZG1tIG1haWxpbmcgbGlzdA0KPiA+IGRtbUBpZXRmLm9yZzxtYWlsdG86 ZG1tQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IGRtbSBtYWlsaW5nIGxpc3QNCj4gZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+DQo+DQo+DQo+ IC0tDQo+IFJTTSBEZXBhcnRtZW50LCBURUxFQ09NIEJyZXRhZ25lLCBGcmFuY2UgSm9uZy1IeW91 ayBMZWUsIGxpdmluZw0KPiBzb21ld2hlcmUgYmV0d2VlbiAvZGV2L251bGwgYW5kIC9kZXYvcmFu ZG9tDQo+DQo+ICNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tDQo+ICN3ZWJw YWdlOiBodHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2h1cnJ5b24vDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVz DQo+DQo+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG1hdGVyaWFsIGZvcg0KPiB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24NCj4gYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KPg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBj b21wYW5pZXMNCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yDQp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24NCmJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuDQoNCg0KDQot LQ0KUlNNIERlcGFydG1lbnQsIFRFTEVDT00gQnJldGFnbmUsIEZyYW5jZQ0KSm9uZy1IeW91ayBM ZWUsIGxpdmluZyBzb21ld2hlcmUgYmV0d2VlbiAvZGV2L251bGwgYW5kIC9kZXYvcmFuZG9tDQoN CiNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tDQojd2VicGFnZTogaHR0cDov L3NpdGVzLmdvb2dsZS5jb20vc2l0ZS9odXJyeW9uLw0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_C5B6A9A3D7D5C941A08B34159DEFE902078A0DCBPEXCVZYM11corpo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDAwOTk7DQoJcG9zaXRpb246 cmVsYXRpdmU7DQoJdG9wOjBwdDsNCgltc28tdGV4dC1yYWlzZTowcHQ7DQoJbGV0dGVyLXNwYWNp bmc6MHB0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDk5Ij5UaGUgRE1NIGNoYXJ0ZXIgbWVudGlvbnM6 IOKApiBhbGxvdyBmb3Igc2V0dGluZyB1cCBJUCBuZXR3b3JrcyBzbyB0aGF0IHRyYWZmaWMgaXMg ZGlzdHJpYnV0ZWQgaW4gYW4g4oCcb3B0aW1hbCB3YXnigJ3igKY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwOTkiPlNvIEkgdGhp bmsgdGhhdCB5ZXMgaXTigJlzIGEgc3RhbmRhcmRpemF0aW9uIGlzc3VlIGFuZCBzdWNoIGNhc2Vz IHNob3VsZCBiZSBjb25zaWRlcmVkIGluIHRoZSBETU0gcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA5OSI+ QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDk5Ij5IYXNzYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw OTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkbW0tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Kb25nLUh5b3VrIExlZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAyMywgMjAx MyAxMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gTW9zZXMsIERhbm55PGJyPg0KPGI+Q2M6PC9iPiBk bW1AaWV0Zi5vcmc7IGRtbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtETU1dIFdHTEMgIzIgc3RhcnRzIGZvciBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVu dHMtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxv IE1vc2VzPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAyMiwgMjAxMyBhdCA1OjM0IFBNLCBNb3Nlcywg RGFubnkgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb20iIHRhcmdldD0i X2JsYW5rIj5kYW5ueS5tb3Nlc0BpbnRlbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uPGJy Pg0KPGJyPg0KWWVzLCB0aGVyZSB3YXMgYSBtaXN1bmRlcnN0YW5kaW5nIG9uIG15IHBhcnQuIEkg dGhvdWdodCB5b3Ugd2VyZSBpbXBseWluZyB0aGF0IHNvbWV0aW1lIGluIHRoZSBmdXR1cmUsIHdl IHNob3VsZCByZW1vdmUgdGhhdCByZXF1aXJlbWVudCAoaGVuY2UgbXkgcmVwbHkgYWJvdXQgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkpLjxicj4NCjxicj4NClNvIGFjdHVhbGx5IHdlIGhhdmUgdHdv IGlzc3VlcyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzIGhlcmUgd2UgaGF2ZSB0aGUgdHdvIGlzc3VlcywgYnV0IHdlIG5lZWQgdG8mbmJzcDtk aXN0aW5ndWlzaCB0aGVtOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBIb3cgbG9uZyBzaG91bGQgdHVubmVscyBiZSBtYWludGFp bmVkIGFzc3VtaW5nIGZsb3dzIGNhbiBsYXN0IGZvciBhIGxvbmcgdGltZSAoZm9yZXZlci4uLik8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IGlzIG5vdCB0aGUgc3RhbmRhcmRpemF0aW9uIGlzc3VlIGV2ZW4gaWYgd2UgbWF5IG1l bnRpb24gaXQgKCZxdW90O3Nlc3Npb24gZHVyYXRpb24mcXVvdDsgYW5kICZxdW90O3Nlc3Npb24g dHVubmVsaW5nIHJlcXVpcmVkJnF1b3Q7KSBpbiB0aGUgRE1NIHJlcXVpcmVtZW50IGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLiBIb3cgc3Ryb25nIGlzIHRoZSB0cmFuc3BhcmVuY3kgcmVxdWlyZW1lbnQgaW4gdGVy bXMgb2YgZmluZGluZyBzb2x1dGlvbnMgdGhhdCBtdXN0IG5vdCByZXF1aXJlIGFueSBJUCBtb2Jp bGl0eSByZXZlYWxpbmcgdG8gdXBwZXItbGF5ZXIgcHJvdG9jb2xzPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdHJhbnNwYXJl bmN5IHJlcXVpcmVtZW50IG11c3QgYmUgYWRkcmVzc2VkIGluIHRoZSBETU0gcmVxdWlyZW1lbnQg ZG9jdW1lbnQsIHN1cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNoZWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQXMgdG8gdGhlIGZpcnN0IGlzc3VlLCBJIHRo aW5rIHRoYXQgZG1tIHNob3VsZCBiZWhhdmUgaW4gdGhhdCBzZW5zZSBsaW5lIFBNSVAuIFdoZXRo ZXIgdGhlcmUgaXMgb25lIGNlbnRyYWxpemVkIE1BIG9yIHNldmVyYWwgZGlzdHJpYnV0ZWQgTUFz IHNob3VsZCBub3QgY2hhbmdlIHRoZSB0cmFmZmljIGZsb3cgKGhlbmNlLCBhbGFzLCB0aGUgdHVu bmVscyBtdXN0IGJlIG1haW50YWluZWQgYXMgbG9uZyBhcyB0aGVyZSBhcmUgZmxvd3MgdGhhdCBy ZXF1aXJlDQogdGhlbSkuPGJyPg0KPGJyPg0KQXMgdG8gdGhlIHNlY29uZCBpc3N1ZSwgYXMgSSBt ZW50aW9uZWQgaW4gbXkgcHJldmlvdXMgbm90ZSwgSSBiZWxpZXZlIHRoYXQgUkVRMiBzaG91bGQg YWxsb3cgdGhlIGFiaWxpdHkgb2YgdXBwZXItbGF5ZXJzIG5vdGlmaWNhdGlvbiBmb3Igb3B0aW1p emF0aW9uIHB1cnBvc2VzIG9ubHkuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgL0Rhbm55PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBLSU0sIEJZT1VORy1KTyBKIChCWU9V TkctSk8pIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hY3NidWdAcmVzZWFyY2guYXR0LmNvbSI+ bWFjc2J1Z0ByZXNlYXJjaC5hdHQuY29tPC9hPl08YnI+DQpTZW50OiBNb25kYXksIEFwcmlsIDIy LCAyMDEzIDE4OjEzPGJyPg0KVG86IE1vc2VzLCBEYW5ueTxicj4NCkNjOiA8YSBocmVmPSJtYWls dG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZG1tLWNo YWlyc0B0b29scy5pZXRmLm9yZyI+DQpkbW0tY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgSm9u Zy1IeW91ayBMZWU8YnI+DQpTdWJqZWN0OiBSZTogW0RNTV0gV0dMQyAjMiBzdGFydHMgZm9yIGRy YWZ0LWlldGYtZG1tLXJlcXVpcmVtZW50cy0wMzxicj4NCjxicj4NCkkgZ2V0IHRoZSBmZWVsaW5n IHdlIGFyZSBvZiBzaW1pbGFyIG9waW5pb24sIGJ1dCBJIGFtIGFmcmFpZCB0aGUgd29yZGluZyBp cyBub3Qgd29ya2luZyBmb3IgbWUuPGJyPg0KPGJyPg0KSSBvYnNlcnZlIG1hbnkgSVAgZmxvd3Mg bGFzdGluZyBtYW55IGRheXMgaW4gc29tZSBuZXR3b3Jrcy48YnI+DQpJIGRvbid0IHRoaW5rIHlv dSBhY3R1YWxseSB3YW50IHRvIG1haW50YWluIHRoZWlyIGNvbm5lY3Rpb25zIHZpYSB0dW5uZWxz IG9yIHdoYXQgbm90IGZvciB0aGF0IGxvbmcsIGlmIHRoZXkgaGF2ZSBiZWVuIG1vdmluZyBhYm91 dC48YnI+DQo8YnI+DQpJbiBmYWN0LCB0aGVzZSBhcmUgKG1vc3RseSkgZmxvd3MgdGhhdCBjYW4g aGFuZGxlIHN1Ym5ldCBjaGFuZ2VzIGJlaGluZCB0aGUgc2NlbmVzLCBzaW5jZSB0aGV5IGFyZSB1 c3VhbGx5IHB1c2ggbm90aWZpY2F0aW9uLCBTSVAgc2lnbmFsaW5nLCBvciBjaGF0IHNlcnZlciBw cmVzZW5jZSBjb25uZWN0aW9ucywgdGhhdCBtb25pdG9yIGFuZCByZWNvbm5lY3QgaWYgdW5kZXJs eWluZyBuZXR3b3JrIGNvbm5lY3Rpb25zIGFyZSBicm9rZW4uPGJyPg0KPGJyPg0KU28sIGl0J3Mg bm90IGluZmluaXR5LiBUaGVuIHRoZXJlIGlzIHNvbWUgbnVtYmVyLjxicj4NCjxicj4NCkRNTSBz aG91bGQgYmUgYSAmcXVvdDt0ZW1wb3JhcnkmcXVvdDsgaGVscCB0byBrZWVwIHBhY2tldCBsb3Nz ZXMgbG93IGFuZCBnaXZlIHRpbWUgZm9yIGFwcHMgdG8gcHJlcGFyZSBhIG5ldyBjb25uZWN0aW9u LCBvciBoaWRlIHJhcGlkIHN1Y2Nlc3Npb24gb2Ygc3VibmV0IGNoYW5nZXMgZm9yIGEgbGltaXRl ZCB0aW1lLjxicj4NCjxicj4NClRoYXQncyB3aGF0IEkgdGhpbmsgaXQgc2hvdWxkIG1lYW4gYnkg YmFja3dhcmQgY29tcGF0aWJpbGl0eS48YnI+DQo8YnI+DQpJZiB5b3UgbXVzdCBoaWRlIHN1Ym5l dCBjaGFuZ2VzIHRvIGFsbCBhcHBzIGZvcmV2ZXIsIHRoZW4gd2UgY2Fubm90IGhhdmUgRE1NLjxi cj4NClNvbWUgYXBwcyB3b3VsZCBicmVhaywgYnV0IEkgdGhpbmsgbW9zdCBvZiB0aGVtIGFyZSBu b3QgaW1wb3J0YW50IG5vdyBvciBpbiB0aGUgZnV0dXJlLCBhbmQgaWYgdGhleSB3aXNoIHRvIGJl IHVzZWQgaW4gbW9iaWxlIGVudmlyb25tZW50LCB0aGV5IG11c3QgYWRhcHQuIChhbmQvb3IgdGhl IE9TKTxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0aGUgcmVxdWlyZW1lbnQgdG8gc2F5IGl0Ljxi cj4NCjxicj4NCkouPGJyPg0KPGJyPg0KQnlvdW5nLUpvICZxdW90O0omcXVvdDsgS2ltPGJyPg0K QVQmYW1wO1QgTGFicyAtIFJlc2VhcmNoPGJyPg0KPGEgaHJlZj0iaHR0cDovL3NpdGVzLmdvb2ds ZS5jb20vc2l0ZS9tYWNzYnVnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zaXRlcy5nb29nbGUu Y29tL3NpdGUvbWFjc2J1Zy88L2E+PGJyPg0KPGJyPg0KPGJyPg0KT24gQXByIDIyLCAyMDEzLCBh dCA5OjM4IEFNLCBNb3NlcywgRGFubnkgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBIaSw8YnI+DQom Z3Q7PGJyPg0KJmd0OyBSZWdhcmRpbmcgdGhlIGZpcnN0IGNvbW1lbnQgYWJvdXQgdHJhbnNwYXJl bmN5IHRvIHVwcGVyIGxheWVycywgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSB2ZXJ5IGxpbWl0aW5n IHJlcXVpcmVtZW50IGJ1dCBhbHNvIHRoaW5rIGl0IGlzIGEgY3J1Y2lhbCBvbmUgZm9yIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5LiBTbyBJIGRvIG5vdCB0aGluayB3ZSBjYW4gbGlnaHRlbiBpdCBi eSBkZWZpbmluZyBhIHRpbWUgbGltaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG93ZXZlciwgd2Ug Y2FuIGFsbG93IG9wdGltaXphdGlvbiBmZWF0dXJlcyB0aGF0IHJlbHkgb24gdXBwZXItbGF5ZXIg cHJvdG9jb2xzIChvciBhcHBsaWNhdGlvbnMpIGJlaW5nIGF3YXJlIG9mIElQIGxheWVyIG1vYmls aXR5IGFzIGxvbmcgYXMgdGhlc2UgYXJlIGZvciBvcHRpbWl6YXRpb24gb25seS4gVGhpcyBtZWFu cyB0aGF0IHVwcGVyLWxheWVyIHByb3RvY29scy9hcHBsaWNhdGlvbnMgdGhhdCBhcmUgTk9UIGF3 YXJlIG9mIElQIG1vYmlsaXR5DQogd2lsbCBjb250aW51ZSB0byB3b3JrIGNvcnJlY3RseSBidXQg d2l0aG91dCBleHRyYSBvcHRpbWl6YXRpb24gdGhhdCAmbmJzcDt0aG9zZSB3aGljaCBBUkUgYXdh cmUgd2lsbCB1dGlsaXplLjxicj4NCiZndDs8YnI+DQomZ3Q7IEluIGZhY3QsIEkgYmVsaWV2ZSB0 aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIFJFUTIgdG8gYWxsb3cgZmVhdHVyZXMgdGhhdCBhcmUg bm90IHRyYW5zcGFyZW50IHRvIHVwcGVyIGxheWVycyBhcyBsb25nIGFzIGJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IGlzIG1haW50YWluZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgL0Rhbm55PGJyPg0KJmd0Ozxicj4NCiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmRt bS1ib3VuY2VzQGlldGYub3JnIj5kbW0tYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPmRtbS1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mPGJyPg0KJmd0OyBKb25nLUh5b3VrIExlZTxicj4NCiZndDsgU2VudDog RnJpZGF5LCBBcHJpbCAxOSwgMjAxMyAxMToxNDxicj4NCiZndDsgVG86IEtJTSwgQllPVU5HLUpP IEogKEJZT1VORy1KTyk8YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3Jn Ij5kbW1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZG1tLWNoYWlyc0B0b29scy5pZXRm Lm9yZyI+DQpkbW0tY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDog UmU6IFtETU1dIFdHTEMgIzIgc3RhcnRzIGZvciBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMt MDM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZWxsbywgQnlvdW5nLUpvPGJyPg0KJmd0Ozxicj4NCiZn dDsgUmVnYXJkaW5nIHlvdXIgY29tbWVudHMgb24gdGhlIHNlY3VyaXR5IHRleHQsIGZvciB5b3Vy IGNvbW1lbnQgMiwgSSBkbyBub3QgcXVpdGUgZ2V0IHlvdS4gUHJvdmlkZSBjbGVhciB0ZXh0IGV4 cHJlc3NpbmcgeW91ciBjb25jZXJuIHRoZW4gSSB3aWxsIHJldmlldyBhbmQgdHJ5IHRvIHJlZmxl Y3QgdG8gdGhlIGRyYWZ0LiBGb3IgeW91ciBjb21tZW50IDUsIGp1c3QgeW91IG5lZWQgdG8gYmUg c3VyZSB0aGF0IHRoZSBnaXZlbiB0ZXh0IGlzIGFib3V0DQogdGhlIGdlbmVyYWwgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnMuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFdlZCwgQXByIDE3LCAyMDEzIGF0IDk6NDQgUE0sIEtJTSwgQllP VU5HLUpPIEogKEJZT1VORy1KTykgJmx0OzxhIGhyZWY9Im1haWx0bzptYWNzYnVnQHJlc2VhcmNo LmF0dC5jb20iPm1hY3NidWdAcmVzZWFyY2guYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgSGkuPGJyPg0KJmd0Ozxicj4NCiZndDsgQmVsb3cgYXJlIG15IGNvbW1lbnRzIG9uIHRoZSBk cmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMtMDMuPGJyPg0KJmd0Ozxicj4NCiZndDsgT3ZlcmFs bCwgdGhlIGRyYWZ0IGhhcyBtdWNoIHRvIGFkbWlyZSBhbmQgYWdyZWVhYmxlIG9uIG1vc3QgcG9p bnRzLjxicj4NCiZndDsgS3Vkb3MgdG8gdGhlIGF1dGhvcnMuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IENvbW1lbnQgMTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBSRVEyOiAmbmJzcDtUcmFuc3BhcmVuY3kgdG8gVXBwZXIgTGF5ZXJzIHdo ZW4gbmVlZGVkPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSB3b3VsZCBsaWtlIHRvIHN1 Z2dlc3QgdGhhdCBETU0gbXVzdCBwcm92aWRlIHRyYW5zcGFyZW5jeSB0byB1cHBlciBsYXllcnMg Zm9yIGEgbGltaXRlZCB0aW1lIG9ubHkgd2hlbiBuZWVkZWQuIFVwcGVyIGxheWVyIHByb3RvY29s cyBvciBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgdW5hd2FyZSBvZiBJUCBsYXllciBtb2JpbGl0eSBh bmQgSVAgYWRkcmVzcyBjaGFuZ2VzIGNhbm5vdCBiZSBzdXBwb3J0ZWQgaW5kZWZpbml0ZWx5LCB3 aXRob3V0DQogY29tcHJvbWlzaW5nIHRoZSBwdXJwb3NlIG9mIERNTS4gSG93IG11Y2ggdGltZSBp cyBvZiBjb3Vyc2UgYW5vdGhlciBtYXR0ZXIsIGJ1dCB0aGF0IGNhbiBiZSBkaXNjdXNzZWQgZHVy aW5nIGRlc2lnbiBvciBldmVuIGR5bmFtaWMuPGJyPg0KJmd0OyBJbiB0aW1lLCBhcHBsaWNhdGlv bnMgYW5kIHVwcGVyIGxheWVyIHByb3RvY29scyB3aWxsIGhhdmUgdG8gYmUgdXBkYXRlZCB0byBo YW5kbGUgSVAgYWRkcmVzcyBjaGFuZ2VzIGJ5IHJlY29ubmVjdCBvciBvdGhlciBtZWFucywgYXMg bG9uZyBhcyBETU0gcHJvdmlkZXMgdGVtcG9yYXJ5IHNoaWVsZCBmcm9tIHBhY2tldCBsb3NzZXMg b3Igb3RoZXIgZGlzcnVwdGlvbnMgYW5kIGJ1eSB0aGVtIHRpbWUgdG8gbWFrZSBwcmVwYXJhdGlv bnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IENv bW1lbnQgMjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSRVE2OiAmbmJzcDtTZWN1cml0eSBjb25zaWRl cmF0aW9uczxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgdGhlIHJlcXVpcmVt ZW50cyBkZXNjcmliZWQgaGVyZSBtYXkgZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IERNTSBleGNs dWRlcyBlcGhlbWVyYWwgc2VjdXJpdHkgZm9yIHRoZSBwdXJwb3NlIG9mIHJvdXRpbmcgdG8gdGhl IGNvcnJlY3QgZW50aXRpZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgdGllZCB0byBzZXJ2aWNlIGF1 dGhvcml6YXRpb25zIG9yIGlkZW50aXRpZXMuIEFsc28sIHByb3RlY3Rpb24gcmVxdWlyZW1lbnRz IGJleW9uZA0KIHdoYXQgY3VycmVudCBJU1BzIGRlYWwgd2l0aCBmb3IgdGhlaXIgYWNjZXNzIHJv dXRlcnMgc2VlbSB1bm5lY2Vzc2FyeS4gRE1NJ3Mgb3duIHNlY3VyaXR5IHNob3VsZCBiZSBsaW1p dGVkIHRvIHJpc2tzIHRoYXQgRE1NIGFkZHMgdG8gdGhlIGFjY2VzcyBuZXR3b3JrLCBub3QgdGhl IHdob2xlIGFjY2VzcyBuZXR3b3JrIHNlY3VyaXR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7ID09PT09 PT09PT09PT09PT09PT09PTxicj4NCiZndDsgQ29tbWVudCAzOjxicj4NCiZndDsgUkVRNzogJm5i c3A7RE1NIHNob3VsZCBlbmFibGUgbXVsdGljYXN0IHNvbHV0aW9ucyBpbiBmbGV4aWJsZSBkaXN0 cmlidXRpb24gc2NlbmFyaW8uPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSBsYWNrIHRo ZSBuZWNlc3Nhcnkga25vd2xlZGdlIG9uIG11bHRpY2FzdCBidXQgdGhpcyBzZWVtcyBsaWtlIGEg ZmVlbC1nb29kIHN0YXRlbWVudCB3aXRob3V0IGEgcG9pbnQuIEkgc3VnZ2VzdCB0byBkcm9wIHRo aXMgcmVxdWlyZW1lbnQgb3IgbWFrZSBhIGNsZWFyZXIgc3RhdGVtZW50IGxpa2UgJnF1b3Q7RE1N IHNob3VsZCBhbGxvdyBtdWx0aWNhc3QgdG8gc3Vydml2ZSBJUCBsYXllciBtb2JpbGl0eSB3aXRo b3V0IHBhY2tldCBsb3NzJnF1b3Q7LCBvcg0KIG1vcmUgbW9kZXN0bHksICZxdW90O0RNTSBzaG91 bGQgbm90IGZvcmVjbG9zZSBtdWx0aWNhc3Qgc3VwcG9ydCBkdXJpbmcgSVAgbGF5ZXIgbW9iaWxp dHkuJnF1b3Q7LCBldGMuLjxicj4NCiZndDs8YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09 PGJyPg0KJmd0OyBDb21tZW50IDQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgNS4gJm5ic3A7U2VjdXJp dHkgQ29uc2lkZXJhdGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtEaXN0cmlidXRlZCBtb2Jp bGl0eSBtYW5hZ2VtZW50IChETU0pIHJlcXVpcmVzIHR3byBraW5kcyBvZiBzZWN1cml0eTxicj4N CiZndDsgJm5ic3A7ICZuYnNwO2NvbnNpZGVyYXRpb25zOiBGaXJzdCwgYWNjZXNzIG5ldHdvcmsg c2VjdXJpdHkgdGhhdCBvbmx5IGFsbG93cyBhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bGVnaXRp bWF0ZSBtb2JpbGUgaG9zdC9yb3V0ZXIgdG8gYWNjZXNzIHRoZSBETU0gc2VydmljZTsgU2Vjb25k LCBlbmQtPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dG8tZW5kIHNlY3VyaXR5IHRoYXQgcHJvdGVj dHMgc2lnbmFsaW5nIG1lc3NhZ2VzIGZvciB0aGUgRE1NIHNlcnZpY2UuPGJyPg0KJmd0Ozxicj4N CiZndDsgJmd0OyZndDsgUmVsYXRlZCB0byBteSBDb21tZW50IDIsICZxdW90O2FjY2VzcyBuZXR3 b3JrIHNlY3VyaXR5JnF1b3Q7IGlzIGNvbmZ1c2luZyBoZXJlLCBhcyBpdCBvZnRlbiBtZWFucyBh bGxvd2luZyBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsgdG8gYmVnaW4gd2l0aC4gRE1NIG11c3QgYXNz dW1lIHRoYXQgaXMgYWxyZWFkeSBkb25lIGF0IGxlYXN0IGluIHRoZSBsb3dlciBsYXllciBvciBl dmVuIElQIGxheWVyLiBJdCBtYXkgb3IgbWF5IG5vdCBvZmZlciBETU0gc2VydmljZQ0KIHRvIGFu eW9uZSBvciBvbmx5IHRvIGF1dGhvcml6ZWQgZGV2aWNlcy91c2Vycy4gSSB0aGluayBETU0gbXVz dCBjb3ZlciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2aWNlIGlzIG9mZmVyZWQgdG8gYW55 dGhpbmcgdGhhdCBhc2tzIGZvciBpdCwgd2hpbGUgZW5zdXJpbmcgdGhlIHBhY2tldHMgYXJlIG5v dCByZWRpcmVjdGVkIHRvIHdyb25nIGRpcmVjdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgPT09 PT09PT09PT09PT09PT09PTxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3RzLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEJ5b3VuZy1KbyAmcXVvdDtKJnF1b3Q7IEtpbTxicj4NCiZndDsgQVQmYW1wO1QgTGFi cyAtIFJlc2VhcmNoPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3NpdGVzLmdvb2dsZS5jb20v c2l0ZS9tYWNzYnVnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9z aXRlL21hY3NidWcvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBBcHIgMTAs IDIwMTMsIGF0IDM6MTkgQU0sIEpvdW5pIEtvcmhvbmVuIHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7ICZndDsgRm9sa3MsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgbWFpbCBz dGFydHMgYSB0d28gd2VlayBXR0xDICMyIGZvciBkcmFmdC1pZXRmLWRtbS1yZXF1aXJlbWVudHMt MDMuPGJyPg0KJmd0OyAmZ3Q7IFRoZSBpc3N1ZXMsIGV2ZW4gZWRpdG9yaWFscywgbXVzdCBiZSBy ZWNvcmRlZCBpbnRvIHRoZSBJc3N1ZTxicj4NCiZndDsgJmd0OyBUcmFja2VyLCBvdGhlcndpc2Ug dGhleSBhcmUgbGlrZWx5IHRvIGJlIG5lZ2xlY3RlZC4gV2UgcmVxdWlyZTxicj4NCiZndDsgJmd0 OyBtaW5pbXVtIHRocmVlIHJldmlld3MgKHRoYXQgYXJlIG1vcmUgdGhhbiBvbmUgbGluZXJzKS4g VGhlIG1vcmUgdGhlIGJldHRlciwgdGhvdWdoLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBUaGUgV0dMQyBlbmRzIG9uIFdlZG5lc2RheSAyNHJkIEFwcmlsLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAtIEpvdW5pICZhbXA7IEp1bGllbjxicj4NCiZndDsgJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBk bW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5v cmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg ZG1tIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ ZG1tQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBSU00gRGVwYXJ0bWVudCwgVEVMRUNPTSBCcmV0YWduZSwg RnJhbmNlIEpvbmctSHlvdWsgTGVlLCBsaXZpbmc8YnI+DQomZ3Q7IHNvbWV3aGVyZSBiZXR3ZWVu IC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5kb208YnI+DQomZ3Q7PGJyPg0KJmd0OyAjZW1haWw6IGpv bmdoeW91ayAoYXQpIGdtYWlsIChkb3QpIGNvbTxicj4NCiZndDsgI3dlYnBhZ2U6IDxhIGhyZWY9 Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlvbi8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2h1cnJ5b24vPC9hPjxicj4NCiZndDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyBBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAg b2YgY29tcGFuaWVzPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yPGJyPg0KJmd0OyB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBk aXN0cmlidXRpb248YnI+DQomZ3Q7IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuPGJyPg0KJmd0Ozxicj4NCjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBn cm91cCBvZiBjb21wYW5pZXM8YnI+DQo8YnI+DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+DQp0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRp b248YnI+DQpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgYWxsIGNvcGllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0i YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SU00gRGVwYXJ0bWVudCwgVEVM RUNPTSBCcmV0YWduZSwgRnJhbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Kb25nLUh5b3VrIExlZSwgbGl2aW5nIHNvbWV3aGVyZSBiZXR3ZWVu IC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5kb208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+I2VtYWlsOiZuYnNwO2pvbmdoeW91ayAoYXQpIGdtYWls IChkb3QpIGNvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+I3dlYnBhZ2U6IDxhIGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVy cnlvbi8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVy cnlvbi88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_C5B6A9A3D7D5C941A08B34159DEFE902078A0DCBPEXCVZYM11corpo_-- From k.pentikousis@huawei.com Wed Apr 24 10:17:34 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B745121F9679 for ; Wed, 24 Apr 2013 10:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSSVGKrQt8Al for ; Wed, 24 Apr 2013 10:17:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2F21F9638 for ; Wed, 24 Apr 2013 10:17:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASD68003; Wed, 24 Apr 2013 17:17:18 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 18:16:44 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Apr 2013 01:17:16 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.56]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 25 Apr 2013 01:17:08 +0800 From: Konstantinos Pentikousis To: "karagian@cs.utwente.nl" , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Thread-Index: AQHOPTB4vAXffZiMUkCB6lDkt5ZqEZjlo/fg Date: Wed, 24 Apr 2013 17:17:07 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 17:17:34 -0000 | I am happy with the current version of the DMM draft!=20 | So I think that the draft can proceed with the further IETF review proces= s! |=A0 | Best regards, | Georgios =A0 I second Georgios' assessment. I think that most of the comments related to= editorial aspects, and thus it's time to move this draft forward in the pr= ocess. Best regards, Kostas From charliep@computer.org Wed Apr 24 14:14:36 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2717221F856D for ; Wed, 24 Apr 2013 14:14:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYZfLUOBv+rS for ; Wed, 24 Apr 2013 14:14:35 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9F04821F8551 for ; Wed, 24 Apr 2013 14:14:35 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UV71O-0006oS-M7 for dmm@ietf.org; Wed, 24 Apr 2013 17:14:34 -0400 Message-ID: <51784B36.5090102@computer.org> Date: Wed, 24 Apr 2013 14:14:30 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dmm@ietf.org" References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866899a6731b330dcd2ebb414c82727d69350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 21:14:36 -0000 Hello folks, I have many editorial comments which I will submit later today. However, I think the draft has a major organizational problem. Namely, the "problem statements", instead of being properly collected together in an initial section, are sprinkled in along with various statements of requirements. I remember there was previously a problem statement draft that enumerated the PSs in the current requirements draft. I think it is O.K. (perhaps not optimal, but O.K.) for the problem statements to be in the requirements draft, but not as currently situated. This, along with the various other editorial clarifications that are needed, lead me to believe that the draft is not yet ready, but I do not think that there are major problems, and that the next draft probably could be ready for advancement. Regards, Charlie P. From charliep@computer.org Wed Apr 24 17:24:14 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDEE21F8976 for ; Wed, 24 Apr 2013 17:24:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSfWB9kxFIkm for ; Wed, 24 Apr 2013 17:24:14 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0105821F88FB for ; Wed, 24 Apr 2013 17:24:13 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UV9yu-00015Q-W7 for dmm@ietf.org; Wed, 24 Apr 2013 20:24:13 -0400 Message-ID: <517877AA.1070203@computer.org> Date: Wed, 24 Apr 2013 17:24:10 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dmm@ietf.org" References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> In-Reply-To: <51784B36.5090102@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ed12f0e57bb87e53762e70ebaa180a8d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 00:24:14 -0000 Hello again folks, I can't type in all the editorial suggestions right now, but at least I wanted to provide some overall comments that cause the document to seem quite inaccurate in many of its claims. Here are my general comments. - The requirements need to be distinguished from the desirable features. For instance, section 4.7 describes a desirable feature, not a requirement. Moreover, the desirable feature may be unattainable. This is important, because if feature is *required*, a solution not providing the *required* feature "must" be considered incomplete and rejected. - The problem statement clauses should be located in an initial section. Each problem statement should have a motivation. - There is no problem statement supporting sections 4.4 or 4.6 - There is no motivation for section 4.4 - There is nothing specific to DMM in sections 4.4 or 4.6 - Section 5 should cross-reference section 4.6, and they should both be rewritten to eliminate redundant extra verbiage of which there is too much. - PS7 claims that deployment (of "something": existing IETF solutions?) is too complicated. Compared to what??? 3GPP solutions?? Dozens of incompatible clunky slow portal authentication design botches? This point strikes me as basically wrong, but it can be rescued if a target level of deployment complexity is described. - REQ3 claims that we should target IPv6 because of tools available for IPv6 that are not available for IPv4. Please identify at least one. - Section 1 claims that user traffic patterns have shifted to become more localized. This is probably false, but I can imagine several ways to change it so that it becomes true. It is important for this purpose to clarify what is intended by "peer communications". - What is an "IP session"? Wasn't IP supposed to be connectionless? I strongly suggest not trying to define such a thing. Perhaps it was intended to indicate a "flow" instead. - It is claimed that a centralized architecture requires more resources than a distributed architecture. This is usually false. For instance, if a centralized node requires 100 units, and 100 distributed nodes each require 1.03 units, the distributed architecture requires 3 more units overall. Even so, the additional expense of the distributed architecture would often be a bargain for reasons of redundancy, resiliency, etc. I will do the editorial suggestions tomorrow. Also I can volunteer to rewrite various parts if extra effort is needed. Regards, Charlie P. On 4/24/2013 2:14 PM, Charles E. Perkins wrote: > Hello folks, > > I have many editorial comments which I will submit later today. > > However, I think the draft has a major organizational problem. Namely, > the "problem statements", instead of being properly collected together > in an initial section, are sprinkled in along with various statements of > requirements. > > I remember there was previously a problem statement draft that > enumerated the PSs in the current requirements draft. I think it is > O.K. (perhaps not optimal, but O.K.) for the problem statements to > be in the requirements draft, but not as currently situated. > > This, along with the various other editorial clarifications that are > needed, lead me to believe that the draft is not yet ready, but I do > not think that there are major problems, and that the next draft > probably could be ready for advancement. > > Regards, > Charlie P. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From alper.yegin@yegin.org Fri Apr 26 00:56:36 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7021F97C6 for ; Fri, 26 Apr 2013 00:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Y4pLv55Ols for ; Fri, 26 Apr 2013 00:56:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8410B21F979F for ; Fri, 26 Apr 2013 00:56:35 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LqBHE-1V0YUY14hU-00e4bo; Fri, 26 Apr 2013 03:56:34 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <517877AA.1070203@computer.org> Date: Fri, 26 Apr 2013 10:56:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7B113F52-9BBA-45E7-85C5-6F1379A28295@yegin.org> References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:GxZP8ILZk/sVRazNAkrZPaGpZKMNdArjBn66gq+wOdB gP6uuVZJAcjGkmcSdj3WM9GtclmDJszG6o4S+XpFCkmJ27QV6V GPMlJLo0/Etx7pCm120dDrxf3DZvGEJqoGfu7zvt7JbUrU59Dk ENCcXsEs6WbUncz4SPK/H1B1jZbaxKp5X1xyxiT5Y5ioBnNZct r8ZMLRG82HuE/iawCRl9r3c0ovSnSSErBT23n4PwW0jYcV36WQ ih+loM2kRDsVoIPk5O8epB/wKkf48oKeftsFRGVabp8BwQqe0/ /q99fLBD+8naWCFxaxcRFGkqytUwnsmEWtgkmqSa+RKpwSAC3Z gKeL8TI0hkHFb1N3jFI2XwSKitZJokuqD1VwevAkTbvbjwlIcV RbvU/sdID7amw== Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:56:36 -0000 Hi Charlie, > - It is claimed that a centralized architecture requires more = resources > than a distributed architecture. This is usually false. For = instance, > if a centralized node requires 100 units, and 100 distributed nodes = each > require 1.03 units, the distributed architecture requires 3 more = units > overall. =20 This would be true for tasks that can be performed either on the = distributed node or on the central node. But the essential task for DMM systems, IP forwarding, is not of that = nature. In centralized architecture, that task needs to be performed *both* at = the edge node and also at the central node (and in fact even in between) = before the packets hit the Internet/mobile device. > Even so, the additional expense of the distributed architecture > would often be a bargain for reasons of redundancy, resiliency, etc. Alper From seiljeon@av.it.pt Fri Apr 26 06:18:27 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8535721F97FB for ; Fri, 26 Apr 2013 06:18:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQZkugK7RuFQ for ; Fri, 26 Apr 2013 06:18:27 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id A423821F97F7 for ; Fri, 26 Apr 2013 06:18:26 -0700 (PDT) Received: from [193.136.93.128] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 68918731; Fri, 26 Apr 2013 14:18:25 +0100 From: "Seil Jeon" To: "'Charles E. Perkins'" References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> In-Reply-To: <517877AA.1070203@computer.org> Date: Fri, 26 Apr 2013 14:18:26 +0100 Message-ID: <000001ce4280$892fc760$9b8f5620$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvlJZLV6Y7YCDqKgL8PqnQBftCnQLAYhobAlHCCAYB6kxGrQIu5PZ9Af6LemaYTIMfwA== Content-Language: ko Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 13:18:27 -0000 Hi Charles, Actually, in realizing DMM-based mobility management, as you know, they may exist various ways or more requirements for DMM protocol deign tackling the issues raised from CMM. Given the requirements defined in the document is confining, in their ways, explicitly or implicitly the protocol design for further steps. It means that proposed solutions should satisfy or consider the requirements, or they will not be DMM solution in DMM WG at least. If you see the mail posted by Sergio a few days ago, the multicast part title was changed with 'Multicast Considerations' for right meaning. With the meaning, I think it would go together with the other requirements. Have a look, please. Regards, Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Thursday, April 25, 2013 1:24 AM To: dmm@ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello again folks, I can't type in all the editorial suggestions right now, but at least I wanted to provide some overall comments that cause the document to seem quite inaccurate in many of its claims. Here are my general comments. - The requirements need to be distinguished from the desirable features. For instance, section 4.7 describes a desirable feature, not a requirement. Moreover, the desirable feature may be unattainable. This is important, because if feature is *required*, a solution not providing the *required* feature "must" be considered incomplete and rejected. From charliep@computer.org Fri Apr 26 17:13:33 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8BF21F95D0 for ; Fri, 26 Apr 2013 17:13:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGeI8gG2lXQk for ; Fri, 26 Apr 2013 17:13:32 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id C511321F955A for ; Fri, 26 Apr 2013 17:13:32 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UVslf-0002O2-Tr; Fri, 26 Apr 2013 20:13:32 -0400 Message-ID: <517B1826.9070905@computer.org> Date: Fri, 26 Apr 2013 17:13:26 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Seil Jeon References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> <000001ce4280$892fc760$9b8f5620$@av.it.pt> In-Reply-To: <000001ce4280$892fc760$9b8f5620$@av.it.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8606b3c5c6ae9a4392330ad08eacf4bef2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 00:13:33 -0000 Hello Seil, You suggest that if a feature is not listed as a requirement, it cannot be considered during the evaluation of solution proposals. This is not true. Given the choice of two proposals, the one that meets the requirements and offers the best other features will invariably be chosen. The real danger is in disqualifying good proposals because they fail to offer some feature that should not have been made into a requirement. There is no harm in listing desirable features (like multicast) that would enhance the value of a solution that meets the requirements. Regards, Charlie P. On 4/26/2013 6:18 AM, Seil Jeon wrote: > Hi Charles, > > Actually, in realizing DMM-based mobility management, as you know, they may > exist various ways or more requirements for DMM protocol deign tackling the > issues raised from CMM. Given the requirements defined in the document is > confining, in their ways, explicitly or implicitly the protocol design for > further steps. > It means that proposed solutions should satisfy or consider the > requirements, or they will not be DMM solution in DMM WG at least. > > If you see the mail posted by Sergio a few days ago, the multicast part > title was changed with 'Multicast Considerations' for right meaning. With > the meaning, I think it would go together with the other requirements. Have > a look, please. > > > Regards, > Seil > > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Thursday, April 25, 2013 1:24 AM > To: dmm@ietf.org > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > Hello again folks, > > I can't type in all the editorial suggestions right now, but at least I > wanted to provide some overall comments that cause the document to seem > quite inaccurate in many of its claims. > Here are my general comments. > > - The requirements need to be distinguished from the desirable features. > For instance, section 4.7 describes a desirable feature, not a > requirement. > Moreover, the desirable feature may be unattainable. This is important, > because if feature is *required*, a solution not providing the *required* > feature "must" be considered incomplete and rejected. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From charliep@computer.org Fri Apr 26 17:19:28 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239621F9A03 for ; Fri, 26 Apr 2013 17:19:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUzRDqTtWguc for ; Fri, 26 Apr 2013 17:19:28 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FB21F99A5 for ; Fri, 26 Apr 2013 17:19:27 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UVsrP-0008Bi-8O for dmm@ietf.org; Fri, 26 Apr 2013 20:19:27 -0400 Message-ID: <517B198A.6020605@computer.org> Date: Fri, 26 Apr 2013 17:19:22 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864b312f0de4677b5c95e1a071770bd4c1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: [DMM] Editorial suggestions for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 00:19:28 -0000 Hello folks, Here are some editorial suggestions for the document. Check for missing articles. For instance: "Gateway selection mechanism" --> "A gateway selection mechanism" "is also taking the" --> "also takes" Delete "However" before "assigning". Delete "Issues such as" Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. "In particular, there is an increase in direct communications among peers in the same geographical area." --> there has always been such locality... in fact maybe less now than previously. Otherwise, please provide a citation. Delete "While deploying" "today's mobile networks, service providers face" --> "Today's mobile networks present service providers with" Delete "more often than not," Delete "Therefore it is not uncommon to observe that" "ever-increasing" --> "unnecessary" "provided" --> "managed" "non-optimal" --> "unnecessary" Delete "Given this motivational background in this section," "address these problems": at this point in the document, the problems have not been identified. As suggested earlier, there should be a section devoted to listing the problems, and then a cross reference to that section could go here. "changing IP address" --> "locator IP address" Insert "The" before "Gateway GPRS Support Node" "respectively, act" --> "all act" "SAE" --> "EPC" "closeby" --> "nearby" Center figure 2. (and might as well center figure 1 too) "future flat IP-based" --> "flat IP-based" (unwise to predict the future) "states the requirements as follows" --> "identifies the following requirements" "Distributed deployment" --> "Distributed processing" ... also in "REQ1" "of IP sessions" --> "of some flows" "an optimal manner" --> "to avoid known bottlenecks" "This requirement addresses problems PS1, PS2, PS3, and PS4 in the following." ... the following ?what? "each MN therein" .... the MNs are not "in" the tunnel, and they are not "in" the mobility anchor. "Centralized anchoring" --> "Centralized anchoring designs" "Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities can increase scalability." --> only when the signaling protocol is properly designed. "is to be inline" --> "conforms" "may need to interoperate with a network or mobile hosts/ routers that do not support DMM protocols." ... this is technically infeasible. Suggested replacement: "may need to co-exist with a network or mobile hosts/ routers that do not support DMM protocols." Delete "The motivations of this requirement are" -- Regards, Charlie P. From charliep@computer.org Fri Apr 26 17:44:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C506421F9D23 for ; Fri, 26 Apr 2013 17:44:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ8IvDW9YMEl for ; Fri, 26 Apr 2013 17:44:05 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8021F9953 for ; Fri, 26 Apr 2013 17:44:05 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UVtFE-0000jT-QD; Fri, 26 Apr 2013 20:44:04 -0400 Message-ID: <517B1F50.9090209@computer.org> Date: Fri, 26 Apr 2013 17:44:00 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Alper Yegin References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> <7B113F52-9BBA-45E7-85C5-6F1379A28295@yegin.org> In-Reply-To: <7B113F52-9BBA-45E7-85C5-6F1379A28295@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b5989c6c4309419f216e6304cd1ca411350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 00:44:06 -0000 Hello Alper, I agree with your point, but it means that the total cost of the distributed solution is even more expensive.... right? Regards, Charlie P. On 4/26/2013 12:56 AM, Alper Yegin wrote: > Hi Charlie, > >> - It is claimed that a centralized architecture requires more resources >> than a distributed architecture. This is usually false. For instance, >> if a centralized node requires 100 units, and 100 distributed nodes each >> require 1.03 units, the distributed architecture requires 3 more units >> overall. > This would be true for tasks that can be performed either on the distributed node or on the central node. > But the essential task for DMM systems, IP forwarding, is not of that nature. > In centralized architecture, that task needs to be performed *both* at the edge node and also at the central node (and in fact even in between) before the packets hit the Internet/mobile device. > > >> Even so, the additional expense of the distributed architecture >> would often be a bargain for reasons of redundancy, resiliency, etc. > > Alper > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From johnsonhammond2@hushmail.com Sat Apr 27 10:06:33 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2519321F983B for ; Sat, 27 Apr 2013 10:06:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIrQhzdr+NAo for ; Sat, 27 Apr 2013 10:06:33 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id EBCEB21F9837 for ; Sat, 27 Apr 2013 10:06:32 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id B11F83098C for ; Sat, 27 Apr 2013 17:06:32 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:06:32 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 64F4114DBDE; Sat, 27 Apr 2013 17:06:31 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:06:31 -0400 To: dmm@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170632.64F4114DBDE@smtp.hushmail.com> Subject: [DMM] Biggest Fake Conference in Computer Science X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:13:21 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From alper.yegin@yegin.org Mon Apr 29 05:29:35 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B7D21F9D88 for ; Mon, 29 Apr 2013 05:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feXhMSs1o4mO for ; Mon, 29 Apr 2013 05:29:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73721F9D86 for ; Mon, 29 Apr 2013 05:29:31 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lg1Ct-1UqRR22mfT-00pfhG; Mon, 29 Apr 2013 08:29:27 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <517B1F50.9090209@computer.org> Date: Mon, 29 Apr 2013 15:29:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> <7B113F52-9BBA-45E7-85C5-6F1379A28295@yegin.org> <517B1F50.9090209@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:1RhiL0NXOO1HcLJVtH98E/fXpMhQkyoZ41BlWw3RCMe tUMyDsqj2ZCzM9pCYTgmVqJv/ZAyGFYH0CHjwufbNXpth/oBV/ QVcgjvk1hnrEWLclrQXWfSZ2aQajTQ2bxLsEdZf4Rn4CkYgZqZ fghTVF/X1YTNIWHV82c9xnuZI2+yhRoApUNmukf+f6BZ+8Y4Ix j8y1pZ1XGuzwM3JQanO+UK1QTO89td3mpw7PO8AY/SaDwUhPDc lk8NCpkkHgSBF1slyaKsk4ZVCeI3mW262OrPNrXgo3SwjbR1b6 qis9mYeWOueS+bf12FKBoKD8l/D7qwBxvHgnqs6a8LPznynhfi KHF6757Wqpma0X+KUSqbnTzXuHVSa/20d8WvrcfeDq9dMCN71n pwKzTh0c4YtZA== Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 12:29:35 -0000 Hi Charlie, No, it should be less. Distributed solution: Take IP traffic directly from access router to the = Internet. Centralized solution: Take IP traffic from access router to a core = router to the Internet. The latter suggests more CAPEX and OPEX. Alper On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote: >=20 > Hello Alper, >=20 > I agree with your point, but it means that the total cost of > the distributed solution is even more expensive.... right? >=20 > Regards, > Charlie P. >=20 > On 4/26/2013 12:56 AM, Alper Yegin wrote: >> Hi Charlie, >>=20 >>> - It is claimed that a centralized architecture requires more = resources >>> than a distributed architecture. This is usually false. For = instance, >>> if a centralized node requires 100 units, and 100 distributed nodes = each >>> require 1.03 units, the distributed architecture requires 3 more = units >>> overall. >> This would be true for tasks that can be performed either on the = distributed node or on the central node. >> But the essential task for DMM systems, IP forwarding, is not of that = nature. >> In centralized architecture, that task needs to be performed *both* = at the edge node and also at the central node (and in fact even in = between) before the packets hit the Internet/mobile device. >>=20 >>=20 >>> Even so, the additional expense of the distributed architecture >>> would often be a bargain for reasons of redundancy, resiliency, = etc. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 From seiljeon@av.it.pt Tue Apr 30 03:52:22 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E3021F9AF0 for ; Tue, 30 Apr 2013 03:52:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4kJ1uAIoOwd for ; Tue, 30 Apr 2013 03:52:18 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9221F9B44 for ; Tue, 30 Apr 2013 03:52:16 -0700 (PDT) Received: from [193.136.93.128] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 68974324; Tue, 30 Apr 2013 11:52:15 +0100 From: "Seil Jeon" To: "'Charles E. Perkins'" References: , <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com> <51784B36.5090102@computer.org> <517877AA.1070203@computer.org> <000001ce4280$892fc760$9b8f5620$@av.it.pt> <517B1826.9070905@computer.org> In-Reply-To: <517B1826.9070905@computer.org> Date: Tue, 30 Apr 2013 11:52:15 +0100 Message-ID: <001c01ce4590$c6ea63e0$54bf2ba0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvlJZLV6Y7YCDqKgL8PqnQBftCnQLAYhobAlHCCAYB6kxGrQIu5PZ9Af6LemYCcMMSLAFl6jdPmDKaDNA= Content-Language: ko Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 10:52:22 -0000 Hi Charlie, Honestly, I don't know whether how it would be a feature or not. But I know that the current multicast part is one of the requirements/considerations the DMM should take into account. Actually, we need to think of the reason why it is important. Existing approaches were a "patching-up" style that first, base multicast support design has been made on the reference protocol, then optimizations and extensions have been followed, thus leading to the unnecessities to the reference protocol and the inefficiencies to the network. I think this approach has been O.K. until now because IP mobility support itself and enhancement for unicast has been first. But now I believe we're in the slightly different stage when contemplating the ultimate goals and expected effects by the DMM. So, I think we need to consider the requirement reflecting such a concern at the initial stage. And current multicast requirement does not prevent to appear 'good proposals' but only provides the minimum guidelines of IP multicast deployment in the DMM we want to define. Best Regards, Seil -----Original Message----- From: Charles E. Perkins [mailto:charliep@computer.org] Sent: Saturday, April 27, 2013 1:13 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello Seil, You suggest that if a feature is not listed as a requirement, it cannot be considered during the evaluation of solution proposals. This is not true. Given the choice of two proposals, the one that meets the requirements and offers the best other features will invariably be chosen. The real danger is in disqualifying good proposals because they fail to offer some feature that should not have been made into a requirement. There is no harm in listing desirable features (like multicast) that would enhance the value of a solution that meets the requirements. Regards, Charlie P. On 4/26/2013 6:18 AM, Seil Jeon wrote: > Hi Charles, > > Actually, in realizing DMM-based mobility management, as you know, > they may exist various ways or more requirements for DMM protocol > deign tackling the issues raised from CMM. Given the requirements > defined in the document is confining, in their ways, explicitly or > implicitly the protocol design for further steps. > It means that proposed solutions should satisfy or consider the > requirements, or they will not be DMM solution in DMM WG at least. > > If you see the mail posted by Sergio a few days ago, the multicast > part title was changed with 'Multicast Considerations' for right > meaning. With the meaning, I think it would go together with the other > requirements. Have a look, please. > > > Regards, > Seil > > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Thursday, April 25, 2013 1:24 AM > To: dmm@ietf.org > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > Hello again folks, > > I can't type in all the editorial suggestions right now, but at least > I wanted to provide some overall comments that cause the document to > seem quite inaccurate in many of its claims. > Here are my general comments. > > - The requirements need to be distinguished from the desirable features. > For instance, section 4.7 describes a desirable feature, not a > requirement. > Moreover, the desirable feature may be unattainable. This is important, > because if feature is *required*, a solution not providing the *required* > feature "must" be considered incomplete and rejected. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P.