From nemo-bounces@ietf.org Fri Jun 01 04:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2C6-0005uO-Co; Fri, 01 Jun 2007 04:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2C5-0005r2-EQ for nemo@ietf.org; Fri, 01 Jun 2007 04:09:09 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2C2-0000XE-RC for nemo@ietf.org; Fri, 01 Jun 2007 04:09:09 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DAE03200CABA; Fri, 1 Jun 2007 10:28:13 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1CgJP6vxZI5; Fri, 1 Jun 2007 10:28:13 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A9A9E200CAB7; Fri, 1 Jun 2007 10:27:58 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2007 10:08:49 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD696013CC163@mx1.office> In-Reply-To: <20070531131918.GA30387@grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-eddy-nemo-aero-reqs-00 Thread-Index: AcejifoYUrQT6BAgQnG9TetDrTiukwAloQQg From: "Roberto Baldessari" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: nemo@ietf.org, MPI@multicasttech.com Subject: [nemo] RE: Comments on draft-eddy-nemo-aero-reqs-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Wesley, See my comment inline=20 >=20 > > - Req4 (availability): in my opinion any RO scheme will=20 > alleviate the=20 > > problem of a single point of failure instead of creating=20 > it. Or do you=20 > > mean that RO should work even if the HA is not available? We also=20 > > pointed out this, but then I've realized that=20 > "internet-less" RO might=20 > > distract the WG and prevent it to come to (at least) a=20 > basic RO scheme=20 > > MIPv6-like. RO without infrastructure should better be the focus of=20 > > other WGs >=20 >=20 > Personally, I hadn't been thinking about the Internet-less=20 > case of not being able to reach any HA, but rather I was=20 > trying to say that it won't be acceptable for a solution to=20 > only work under the assumption that a single MR services a=20 > mobile network, or a single HA or access router services an=20 > MR (or set of MRs). >=20 > In other words, we need the solution to co-exist peacefully=20 > with both HA reliability mechanisms (e.g. the one MIP6 is=20 > working on), multihoming mechanisms, and with multiple MRs. >=20 > Do you think it would be more clear if I added a sentence=20 > that specifically excluded Internet-less operation from being=20 > required? >=20 Now it is clear. I don't think that you need to mention the = internet-less scenario. Maybe just a sentence about what you wrote here, = i.e. RO compatible with multiple MRs serving the same mobile network. I = did not immediately think about this case simply because in our scenario = we consider a single MR. > =20 > > - Req6 (scalability): it is hard to determine whether an RO=20 > scheme is=20 > > scalable in terms of signaling, as it depends on other variables=20 > > (network capacity, mobility,...). More than a absolute=20 > requirement, I=20 > > consider this as an important criterion in relative terms. I.e. a=20 > > solution with lower signaling will be preferred compared=20 > with one with=20 > > higher signaling >=20 >=20 > Agreed; this is an important metric, but one that's fairly=20 > scenario-dependent in measurement and evaluation. For=20 > aircraft, the mobility patterns are tough to guess at because=20 > they depend on the link technologies used. Since many of the=20 > current links are very low-rate, basing an analysis on them=20 > may not be particularly useful, although I gave some rough=20 > estimate of the time between changing VDL channels in the=20 > draft. I will check and see if the COCR document from the=20 > FAA/Eurocontrol Future Communications Study has any guidance=20 > on how we can specify scalability in greater detail for aeronautics. >=20 > =20 Actually I wanted to say that since giving details on scalability at = this stage is hard, maybe instead of as a requirement scalability could = be mentioned as more general recommendation (e.g. desirable = characteristic). But this is also questionable, because a solution that = does not scale simply based on the number of aircrafts will not be = considered at all. So, you could also leave it like this and mention = that at this stage you refer to scalability considering only number of = aircrafts and not other at the moment unknown variables (link capacity, = number and distribution of HAs, etc). > > - Req8 (security): I think it would be beneficial to=20 > specify whether=20 > > or not you require IPsec to be usable for LFN or only in the RO=20 > > signaling or in the tunnel MR-HA. We will also try to specify=20 > > something more about security in the automotive requirements. >=20 >=20 > I think it should be possible to use in both cases, although=20 > it must be understood that in some cases, the security=20 > mechanisms can undo the RO, as Will Ivancic is very good at=20 > explaining :). My goals for this requirement were to (1)=20 > ensure that the data used to make RO decisions can be=20 > authenticable, and (2) ensure that flows using transport-mode=20 > IPsec can use RO between the two end-points, and flows using=20 > tunnel-mode IPsec can get RO between the MR and the=20 > groundward side of the tunnel. > If I put some more explanation of this into the draft, would=20 > that help? Yes, it would definitely help. It's reasonably clear to me now. >=20 > I would be interested in reviewing the automotive=20 > requirements, if/when they are available. I'm not sure how=20 > similar they will be to the aero requirements, but it would=20 > be really neat if a common solution was acceptable for both. >=20 We produced and presented a -00 draft in Prague = http://tools.ietf.org/wg/nemo/draft-baldessari-c2ccc-nemo-req-00.txt. It does not say much specifically about RO requirements, yet. So, we'll try to be more specific in -01, for which I'd be really glad = to have your comments. Best regards, Roberto From nemo-bounces@ietf.org Fri Jun 01 04:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Wx-0003cQ-5u; Fri, 01 Jun 2007 04:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Ww-0003cF-Ca for nemo@ietf.org; Fri, 01 Jun 2007 04:30:42 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2Ws-000780-Tp for nemo@ietf.org; Fri, 01 Jun 2007 04:30:42 -0400 Received: from acorde (acorde.it.uc3m.es [163.117.139.72])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 022351A7AC; Fri, 1 Jun 2007 10:30:38 +0200 (CEST) Subject: Re: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00 From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: weddy@grc.nasa.gov In-Reply-To: <20070531131918.GA30387@grc.nasa.gov> References: <113091BD57179D4491C19DA7E10CD6960113890A@mx1.office> <20070531131918.GA30387@grc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Fri, 01 Jun 2007 10:30:38 +0200 Message-Id: <1180686638.4485.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-10.2460 TC:1F TRN:39 TV:3.6.1039(15210.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, MPI@multicasttech.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Wesley, I've not read your I-D in detail yet, but I have a question regarding the requirement of security (Roberto actually triggered that). When you say that are some security mechanisms that can undo the RO, do you mean that are several circumstances where a security mechanism can prevent an RO solution from taking place? would it be OK for an RO solution not to work for some IPsec configurations while work for others or is it necessary to support all? I'll try to provide more comments soon. Kind Regards, Carlos > =20 > > - Req8 (security): I think it would be beneficial to specify whether > > or not you require IPsec to be usable for LFN or only in the RO > > signaling or in the tunnel MR-HA. We will also try to specify somethi= ng > > more about security in the automotive requirements. >=20 >=20 > I think it should be possible to use in both cases, although it must be > understood that in some cases, the security mechanisms can undo the RO, > as Will Ivancic is very good at explaining :). My goals for this > requirement were to (1) ensure that the data used to make RO decisions > can be authenticable, and (2) ensure that flows using transport-mode > IPsec can use RO between the two end-points, and flows using tunnel-mod= e > IPsec can get RO between the MR and the groundward side of the tunnel. > If I put some more explanation of this into the draft, would that help? >=20 > I would be interested in reviewing the automotive requirements, if/when > they are available. I'm not sure how similar they will be to the aero > requirements, but it would be really neat if a common solution was > acceptable for both. >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From nemo-bounces@ietf.org Fri Jun 01 12:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9gs-00048Y-8D; Fri, 01 Jun 2007 12:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9gr-00048N-KM for nemo@ietf.org; Fri, 01 Jun 2007 12:09:25 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu9gp-0000sm-3Y for nemo@ietf.org; Fri, 01 Jun 2007 12:09:25 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 003CDC215 for ; Fri, 1 Jun 2007 12:09:21 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l51G9Lqb029518; Fri, 1 Jun 2007 12:09:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l51G9Irl020965; Fri, 1 Jun 2007 12:09:20 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id u9FyK5ghTa5s; Fri, 1 Jun 2007 12:09:18 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l51G9Hne020961;Fri, 1 Jun 2007 12:09:17 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 7C6EB4FEA4; Fri, 1 Jun 2007 12:07:43 -0400 (EDT) Date: Fri, 1 Jun 2007 12:07:43 -0400 From: Wesley Eddy To: Carlos =?iso-8859-1?Q?Jes=FAs?= Bernardos Cano Subject: Re: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00 Message-ID: <20070601160743.GH19321@grc.nasa.gov> References: <113091BD57179D4491C19DA7E10CD6960113890A@mx1.office> <20070531131918.GA30387@grc.nasa.gov> <1180686638.4485.19.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1180686638.4485.19.camel@localhost> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, MPI@multicasttech.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Fri, Jun 01, 2007 at 10:30:38AM +0200, Carlos Jes=FAs Bernardos Cano w= rote: > Hi Wesley, >=20 > I've not read your I-D in detail yet, but I have a question regarding > the requirement of security (Roberto actually triggered that). > When you say that are some security mechanisms that can undo the RO, do > you mean that are several circumstances where a security mechanism can > prevent an RO solution from taking place? would it be OK for an RO > solution not to work for some IPsec configurations while work for other= s > or is it necessary to support all? >=20 > I'll try to provide more comments soon. >=20 An easy way to explain this is that if tunnel-mode IPsec is used, the RO scheme can't possibly optimize the end-to-end packet flow, only the IPsec tunneled portion of it. Imagine the ground-side IPsec gateway is nearby the HA, and it's clear that RO bought very little. I don't believe this is a problem with the protocols, but rather with the way that people choose to apply them, or create policies without considering how they impact other parts of the system when combined. So, it's not really something that impacts RO requirements, just something to be aware of when building and deploying systems that use RO. --=20 Wesley M. Eddy Verizon Federal Network Systems From nemo-bounces@ietf.org Fri Jun 01 15:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuD5Q-0000IT-Qp; Fri, 01 Jun 2007 15:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuD5P-0000IK-0g; Fri, 01 Jun 2007 15:46:59 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuD5O-0002ht-GV; Fri, 01 Jun 2007 15:46:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51Jka6U005089; Fri, 1 Jun 2007 22:46:56 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 22:46:50 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 14:46:38 -0500 Received: from 10.241.58.171 ([10.241.58.171]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 19:46:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 14:46:40 -0500 From: Basavaraj Patil To: ext Basavaraj Patil , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 19:46:38.0225 (UTC) FILETIME=[91833810:01C7A485] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org So after an extensive discussion on this topic which spun off into a discussion about the need/use for GRE, I would like to summarize where we are with the options that we have. Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol header following the UDP header" is good enough. So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this issue are needed. It was pointed out that in the future if GRE was determined as a protocol that needs to be supported as well either for MIP6, NEMO or PMIP6 then it would be specified in the appropriate WG and a UDP port reserved for the same. In such a case it would essentially be the equivalent of option 2 in the choices list (below). At this time, the need for GRE especially in the scope of DS-MIP6 which is primarily MIP6 and NEMO is not proven. Hence we will move forward with Option 1 and close this issue. -Raj On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: > > Hello, > > The DS-MIP6 I-D still has > issue 93 open. This was discussed at IETF68. Vijay presented 4 options > to solve the issue. These are captured in: > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > We need to make a decision on this issue and move forward with the > I-D. At the meeting itself, I got the sense that option 3 was the one > that had the least impact and easy to implement. > > Please consider this email as a consensus call for issue 93. The > problem and choices are as follows (based on Vijay's slides): > > Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The > encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type of > protocol being encapsulated in the UDP header. > > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message > > Pros and cons of these choices are in the slides that were presented > at IETF68 (see URL above). > > Please provide your opinions and comments by May 15th, 07 on the MIP6 > mailing list. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Fri Jun 01 16:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuE7C-0002FC-Gu; Fri, 01 Jun 2007 16:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuE7A-0002Eo-Fq; Fri, 01 Jun 2007 16:52:52 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuE78-0003OL-Ps; Fri, 01 Jun 2007 16:52:52 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuE77-0005QQ-OZ; Fri, 01 Jun 2007 22:52:49 +0200 Message-ID: <46608721.1030902@levkowetz.com> Date: Fri, 01 Jun 2007 22:52:49 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, mip6@ietf.org, nemo@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, On 2007-06-01 21:46 Basavaraj Patil said the following: > So after an extensive discussion on this topic which spun off into a > discussion about the need/use for GRE, I would like to summarize where we > are with the options that we have. > > Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol > header following the UDP header" is good enough. Could you give us an indication of who preferred which option? You seem to be very clear about the outcome, while it was far from obvious to me that the counts turned out to support above conclusion... Henrik > So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this > issue are needed. > > > It was pointed out that in the future if GRE was determined as a protocol > that needs to be supported as well either for MIP6, NEMO or PMIP6 then it > would be specified in the appropriate WG and a UDP port reserved for the > same. In such a case it would essentially be the equivalent of option 2 in > the choices list (below). > > At this time, the need for GRE especially in the scope of DS-MIP6 which is > primarily MIP6 and NEMO is not proven. Hence we will move forward with > Option 1 and close this issue. > > -Raj > > > > On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: > >> Hello, >> >> The DS-MIP6 I-D still has >> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >> to solve the issue. These are captured in: >> >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >> >> We need to make a decision on this issue and move forward with the >> I-D. At the meeting itself, I got the sense that option 3 was the one >> that had the least impact and easy to implement. >> >> Please consider this email as a consensus call for issue 93. The >> problem and choices are as follows (based on Vijay's slides): >> >> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >> encapculations are either: >> - IPv6-in-UDP-over-IPv4 >> - IPv4-in-UDP-over-IPv4 >> There is a need (or I guess desirable) to indicate the type of >> protocol being encapsulated in the UDP header. >> >> Choices are: >> 1. Parse the protocol header following the UDP header >> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >> 4. Encapsulated protocol header type is indicated in the BU message >> >> Pros and cons of these choices are in the slides that were presented >> at IETF68 (see URL above). >> >> Please provide your opinions and comments by May 15th, 07 on the MIP6 >> mailing list. >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > From nemo-bounces@ietf.org Fri Jun 01 17:18:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEVj-0004lR-V4; Fri, 01 Jun 2007 17:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEVj-0004lI-1n; Fri, 01 Jun 2007 17:18:15 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuEVi-0003Nu-GC; Fri, 01 Jun 2007 17:18:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51LI3mv014621; Sat, 2 Jun 2007 00:18:12 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 00:18:07 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 16:18:02 -0500 Received: from 10.241.59.35 ([10.241.59.35]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 21:18:02 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 16:18:05 -0500 Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AcekklfilimLPBCFEdyx6wARJNUNiA== In-Reply-To: <46608721.1030902@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 21:18:02.0807 (UTC) FILETIME=[56940470:01C7A492] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, Rough consensus is what I am going by here. But I will send the count or who chose what if it helps anyway. -Raj On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > Hi Raj, > > On 2007-06-01 21:46 Basavaraj Patil said the following: >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >> header following the UDP header" is good enough. > > Could you give us an indication of who preferred which option? You seem > to be very clear about the outcome, while it was far from obvious to me > that the counts turned out to support above conclusion... > > > Henrik > >> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined as a protocol >> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >> would be specified in the appropriate WG and a UDP port reserved for the >> same. In such a case it would essentially be the equivalent of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >> >>> Hello, >>> >>> The DS-MIP6 I-D still has >>> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >>> to solve the issue. These are captured in: >>> >>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>> >>> We need to make a decision on this issue and move forward with the >>> I-D. At the meeting itself, I got the sense that option 3 was the one >>> that had the least impact and easy to implement. >>> >>> Please consider this email as a consensus call for issue 93. The >>> problem and choices are as follows (based on Vijay's slides): >>> >>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>> encapculations are either: >>> - IPv6-in-UDP-over-IPv4 >>> - IPv4-in-UDP-over-IPv4 >>> There is a need (or I guess desirable) to indicate the type of >>> protocol being encapsulated in the UDP header. >>> >>> Choices are: >>> 1. Parse the protocol header following the UDP header >>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>> 4. Encapsulated protocol header type is indicated in the BU message >>> >>> Pros and cons of these choices are in the slides that were presented >>> at IETF68 (see URL above). >>> >>> Please provide your opinions and comments by May 15th, 07 on the MIP6 >>> mailing list. >>> >>> -Raj >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> From nemo-bounces@ietf.org Fri Jun 01 17:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEoW-00014s-8F; Fri, 01 Jun 2007 17:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEoV-00014k-9Z; Fri, 01 Jun 2007 17:37:39 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuEoT-0002XC-O4; Fri, 01 Jun 2007 17:37:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51LbJSA006619; Sat, 2 Jun 2007 00:37:35 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 00:36:47 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 16:36:25 -0500 Received: from 10.241.59.35 ([10.241.59.35]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 21:36:25 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 16:36:27 -0500 Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiA== In-Reply-To: <46608721.1030902@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 21:36:25.0525 (UTC) FILETIME=[E7D96E50:01C7A494] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay D. - Option 4 originally and then changed to Option 2 Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - Option 1 (Interpreted) So we have a sort of a tie if you strictly go by count. If I were to express my own opinion (non-chair-hat), I would go with option 1 as well for the current DS-MIP6 proposal (aligned with my earlier email that if and when GRE is planned for use, another UDP port can be reserved... But for now option 1). That would break any deadlock issues. Or the other way is to let the chairs decide what is the sense of the discussion on the ML and from the perspective of the charter/scope and urgency of this protocol. And from this angle as well, I would stick by my conclusion, i.e option 1. -Raj On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > Hi Raj, > > On 2007-06-01 21:46 Basavaraj Patil said the following: >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >> header following the UDP header" is good enough. > > Could you give us an indication of who preferred which option? You seem > to be very clear about the outcome, while it was far from obvious to me > that the counts turned out to support above conclusion... > > > Henrik > >> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined as a protocol >> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >> would be specified in the appropriate WG and a UDP port reserved for the >> same. In such a case it would essentially be the equivalent of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >> >>> Hello, >>> >>> The DS-MIP6 I-D still has >>> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >>> to solve the issue. These are captured in: >>> >>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>> >>> We need to make a decision on this issue and move forward with the >>> I-D. At the meeting itself, I got the sense that option 3 was the one >>> that had the least impact and easy to implement. >>> >>> Please consider this email as a consensus call for issue 93. The >>> problem and choices are as follows (based on Vijay's slides): >>> >>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>> encapculations are either: >>> - IPv6-in-UDP-over-IPv4 >>> - IPv4-in-UDP-over-IPv4 >>> There is a need (or I guess desirable) to indicate the type of >>> protocol being encapsulated in the UDP header. >>> >>> Choices are: >>> 1. Parse the protocol header following the UDP header >>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>> 4. Encapsulated protocol header type is indicated in the BU message >>> >>> Pros and cons of these choices are in the slides that were presented >>> at IETF68 (see URL above). >>> >>> Please provide your opinions and comments by May 15th, 07 on the MIP6 >>> mailing list. >>> >>> -Raj >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> From nemo-bounces@ietf.org Fri Jun 01 18:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFMx-0008FO-07; Fri, 01 Jun 2007 18:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFMv-0007yR-8C; Fri, 01 Jun 2007 18:13:13 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFMu-0005dK-MM; Fri, 01 Jun 2007 18:13:13 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l51MDAxH002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 15:13:11 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l51MDA5e029026; Fri, 1 Jun 2007 15:13:10 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:13:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Fri, 1 Jun 2007 15:13:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAABRPsw References: <46608721.1030902@levkowetz.com> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Levkowetz" X-OriginalArrivalTime: 01 Jun 2007 22:13:10.0314 (UTC) FILETIME=[0A0188A0:01C7A49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org FWIW, I had also supported going with Option 1 for DS-MIP6.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 2:36 PM > To: Levkowetz > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > - Consensus call to close issue 93 >=20 >=20 >=20 > Vijay D. - Option 4 originally and then changed to Option 2=20 > Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > Option 1 (Interpreted) >=20 > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would=20 > go with option 1 as well for the current DS-MIP6 proposal=20 > (aligned with my earlier email that if and when GRE is=20 > planned for use, another UDP port can be reserved... But for=20 > now option 1). That would break any deadlock issues. >=20 > Or the other way is to let the chairs decide what is the=20 > sense of the discussion on the ML and from the perspective of=20 > the charter/scope and urgency of this protocol. And from this=20 > angle as well, I would stick by my conclusion, i.e option 1. >=20 > -Raj >=20 >=20 > On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > > Hi Raj, > >=20 > > On 2007-06-01 21:46 Basavaraj Patil said the following: > >> So after an extensive discussion on this topic which spun=20 > off into a=20 > >> discussion about the need/use for GRE, I would like to summarize=20 > >> where we are with the options that we have. > >>=20 > >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 > >> protocol header following the UDP header" is good enough. > >=20 > > Could you give us an indication of who preferred which option? You=20 > > seem to be very clear about the outcome, while it was far=20 > from obvious=20 > > to me that the counts turned out to support above conclusion... > >=20 > >=20 > > Henrik > >=20 > >> So it implies no changes to the current text in the=20 > DS-MIP6 I-D w.r.t=20 > >> this issue are needed. > >>=20 > >>=20 > >> It was pointed out that in the future if GRE was determined as a=20 > >> protocol that needs to be supported as well either for=20 > MIP6, NEMO or=20 > >> PMIP6 then it would be specified in the appropriate WG and=20 > a UDP port=20 > >> reserved for the same. In such a case it would essentially be the=20 > >> equivalent of option 2 in the choices list (below). > >>=20 > >> At this time, the need for GRE especially in the scope of DS-MIP6=20 > >> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 > >> forward with Option 1 and close this issue. > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: > >>=20 > >>> Hello, > >>>=20 > >>> The DS-MIP6 I-D =20 > still has=20 > >>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 > >>> options to solve the issue. These are captured in: > >>>=20 > >>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>>=20 > >>> We need to make a decision on this issue and move forward=20 > with the=20 > >>> I-D. At the meeting itself, I got the sense that option 3 was the=20 > >>> one that had the least impact and easy to implement. > >>>=20 > >>> Please consider this email as a consensus call for issue 93. The=20 > >>> problem and choices are as follows (based on Vijay's slides): > >>>=20 > >>> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The=20 > >>> encapculations are either: > >>> - IPv6-in-UDP-over-IPv4 > >>> - IPv4-in-UDP-over-IPv4 > >>> There is a need (or I guess desirable) to indicate the type of=20 > >>> protocol being encapsulated in the UDP header. > >>>=20 > >>> Choices are: > >>> 1. Parse the protocol header following the UDP header 2.=20 > Reserve a=20 > >>> UDP port for each protocol header (i.e one UDP port for > >>> IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.)=20 > >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>> 4. Encapsulated protocol header type is indicated in the=20 > BU message > >>>=20 > >>> Pros and cons of these choices are in the slides that=20 > were presented=20 > >>> at IETF68 (see URL above). > >>>=20 > >>> Please provide your opinions and comments by May 15th, 07 on the=20 > >>> MIP6 mailing list. > >>>=20 > >>> -Raj > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >>=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri Jun 01 18:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFNW-0000y3-4I; Fri, 01 Jun 2007 18:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFNU-0000xv-Cx; Fri, 01 Jun 2007 18:13:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFNT-00069K-Tr; Fri, 01 Jun 2007 18:13:48 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l51MDAxH002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 15:13:11 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l51MDA5e029026; Fri, 1 Jun 2007 15:13:10 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:13:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Fri, 1 Jun 2007 15:13:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAABRPsw References: <46608721.1030902@levkowetz.com> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Levkowetz" X-OriginalArrivalTime: 01 Jun 2007 22:13:10.0314 (UTC) FILETIME=[0A0188A0:01C7A49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org FWIW, I had also supported going with Option 1 for DS-MIP6.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 2:36 PM > To: Levkowetz > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > - Consensus call to close issue 93 >=20 >=20 >=20 > Vijay D. - Option 4 originally and then changed to Option 2=20 > Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > Option 1 (Interpreted) >=20 > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would=20 > go with option 1 as well for the current DS-MIP6 proposal=20 > (aligned with my earlier email that if and when GRE is=20 > planned for use, another UDP port can be reserved... But for=20 > now option 1). That would break any deadlock issues. >=20 > Or the other way is to let the chairs decide what is the=20 > sense of the discussion on the ML and from the perspective of=20 > the charter/scope and urgency of this protocol. And from this=20 > angle as well, I would stick by my conclusion, i.e option 1. >=20 > -Raj >=20 >=20 > On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > > Hi Raj, > >=20 > > On 2007-06-01 21:46 Basavaraj Patil said the following: > >> So after an extensive discussion on this topic which spun=20 > off into a=20 > >> discussion about the need/use for GRE, I would like to summarize=20 > >> where we are with the options that we have. > >>=20 > >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 > >> protocol header following the UDP header" is good enough. > >=20 > > Could you give us an indication of who preferred which option? You=20 > > seem to be very clear about the outcome, while it was far=20 > from obvious=20 > > to me that the counts turned out to support above conclusion... > >=20 > >=20 > > Henrik > >=20 > >> So it implies no changes to the current text in the=20 > DS-MIP6 I-D w.r.t=20 > >> this issue are needed. > >>=20 > >>=20 > >> It was pointed out that in the future if GRE was determined as a=20 > >> protocol that needs to be supported as well either for=20 > MIP6, NEMO or=20 > >> PMIP6 then it would be specified in the appropriate WG and=20 > a UDP port=20 > >> reserved for the same. In such a case it would essentially be the=20 > >> equivalent of option 2 in the choices list (below). > >>=20 > >> At this time, the need for GRE especially in the scope of DS-MIP6=20 > >> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 > >> forward with Option 1 and close this issue. > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: > >>=20 > >>> Hello, > >>>=20 > >>> The DS-MIP6 I-D =20 > still has=20 > >>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 > >>> options to solve the issue. These are captured in: > >>>=20 > >>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>>=20 > >>> We need to make a decision on this issue and move forward=20 > with the=20 > >>> I-D. At the meeting itself, I got the sense that option 3 was the=20 > >>> one that had the least impact and easy to implement. > >>>=20 > >>> Please consider this email as a consensus call for issue 93. The=20 > >>> problem and choices are as follows (based on Vijay's slides): > >>>=20 > >>> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The=20 > >>> encapculations are either: > >>> - IPv6-in-UDP-over-IPv4 > >>> - IPv4-in-UDP-over-IPv4 > >>> There is a need (or I guess desirable) to indicate the type of=20 > >>> protocol being encapsulated in the UDP header. > >>>=20 > >>> Choices are: > >>> 1. Parse the protocol header following the UDP header 2.=20 > Reserve a=20 > >>> UDP port for each protocol header (i.e one UDP port for > >>> IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.)=20 > >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>> 4. Encapsulated protocol header type is indicated in the=20 > BU message > >>>=20 > >>> Pros and cons of these choices are in the slides that=20 > were presented=20 > >>> at IETF68 (see URL above). > >>>=20 > >>> Please provide your opinions and comments by May 15th, 07 on the=20 > >>> MIP6 mailing list. > >>>=20 > >>> -Raj > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >>=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri Jun 01 19:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGWw-00050j-1E; Fri, 01 Jun 2007 19:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGWt-0004lw-Jv for nemo@ietf.org; Fri, 01 Jun 2007 19:27:35 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuGWs-0007i0-29 for nemo@ietf.org; Fri, 01 Jun 2007 19:27:35 -0400 Received: (qmail 5458 invoked for bounce); 2 Jun 2007 01:29:46 -0000 Received: from unknown (HELO ?192.168.3.7?) (lorchat@unknown) by unknown with SMTP; 2 Jun 2007 01:29:46 -0000 Message-ID: <4660AB63.3010608@sfc.wide.ad.jp> Date: Sat, 02 Jun 2007 08:27:31 +0900 From: Jean Lorchat User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, In the Nautilus6 project, we are working on a Linux implementation of the DS-MIP6 draft and as such, we currently provide option 1. It seems satisfactory enough for us and we have no issues to report with that, as of yet. Implicitly, I'd say we support option 1 as implementors. Also, I personally feel that it is important for the DS-MIP6 specification to move forward quickly. Regards, Jean Basavaraj Patil wrote: > > Vijay D. - Option 4 originally and then changed to Option 2 > Hesham - Option 1 > Sri Gundavelli - Option 3 > Kent - Option 3 > Ahmad Muhanna - Option 3 > Alex Petrescu - Option 1 (Interpreted) > George T. - Option 1 > Mohamed Khalil - Option 3 > Markku Ala-V - Option 2 > Henrik L. - Option 3 > Pascal T. - Option 1 (Interpreted) > > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would go with > option 1 as well for the current DS-MIP6 proposal (aligned with my > earlier email that if and when GRE is planned for use, another UDP > port can be reserved... But for now option 1). That would break any > deadlock issues. > > Or the other way is to let the chairs decide what is the sense of the > discussion on the ML and from the perspective of the charter/scope and > urgency of this protocol. And from this angle as well, I would stick > by my conclusion, i.e option 1. > > -Raj > > > On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >> >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun off into a >>> discussion about the need/use for GRE, I would like to summarize where we >>> are with the options that we have. >>> >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>> header following the UDP header" is good enough. >> Could you give us an indication of who preferred which option? You seem >> to be very clear about the outcome, while it was far from obvious to me >> that the counts turned out to support above conclusion... >> >> >> Henrik >> >>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>> issue are needed. >>> >>> >>> It was pointed out that in the future if GRE was determined as a protocol >>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>> would be specified in the appropriate WG and a UDP port reserved for the >>> same. In such a case it would essentially be the equivalent of option 2 in >>> the choices list (below). >>> >>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>> Option 1 and close this issue. >>> >>> -Raj >>> >>> >>> >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>> >>>> Hello, >>>> >>>> The DS-MIP6 I-D still has >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >>>> to solve the issue. These are captured in: >>>> >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>> >>>> We need to make a decision on this issue and move forward with the >>>> I-D. At the meeting itself, I got the sense that option 3 was the one >>>> that had the least impact and easy to implement. >>>> >>>> Please consider this email as a consensus call for issue 93. The >>>> problem and choices are as follows (based on Vijay's slides): >>>> >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of >>>> protocol being encapsulated in the UDP header. >>>> >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header >>>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>> >>>> Pros and cons of these choices are in the slides that were presented >>>> at IETF68 (see URL above). >>>> >>>> Please provide your opinions and comments by May 15th, 07 on the MIP6 >>>> mailing list. >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> > > From nemo-bounces@ietf.org Fri Jun 01 19:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXH-0006NI-2A; Fri, 01 Jun 2007 19:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXE-0006LJ-OS; Fri, 01 Jun 2007 19:27:56 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGXC-0007is-TX; Fri, 01 Jun 2007 19:27:56 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuGXC-000606-3z; Sat, 02 Jun 2007 01:27:54 +0200 Message-ID: <4660AB79.3050204@levkowetz.com> Date: Sat, 02 Jun 2007 01:27:53 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, mip6@ietf.org, nemo@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2007-06-01 23:36 Basavaraj Patil said the following: > > Vijay D. - Option 4 originally and then changed to Option 2 > Hesham - Option 1 > Sri Gundavelli - Option 3 > Kent - Option 3 > Ahmad Muhanna - Option 3 > Alex Petrescu - Option 1 (Interpreted) > George T. - Option 1 > Mohamed Khalil - Option 3 > Markku Ala-V - Option 2 > Henrik L. - Option 3 > Pascal T. - Option 1 (Interpreted) > > So we have a sort of a tie if you strictly go by count. No, if we strictly go by the above count, there's no tie: Option 3 5 counts Option 1 4 counts Option 2 2 counts > If I were to express my own opinion (non-chair-hat), I would go with > option 1 as well for the current DS-MIP6 proposal (aligned with my > earlier email that if and when GRE is planned for use, another UDP > port can be reserved... But for now option 1). That would break any > deadlock issues. That would be credible if you'd said that before pronouncing a consensus for option 1. Now it doesn't. > Or the other way is to let the chairs decide what is the sense of the > discussion on the ML and from the perspective of the charter/scope and > urgency of this protocol. And from this angle as well, I would stick > by my conclusion, i.e option 1. That was my original reason for asking for the count -- having followed the discussion, my perception was *very* different, and there wasn't a consensus for 1 in the sense of the discussion. Henrik > -Raj > > > On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >> >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun off into a >>> discussion about the need/use for GRE, I would like to summarize where we >>> are with the options that we have. >>> >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>> header following the UDP header" is good enough. >> Could you give us an indication of who preferred which option? You seem >> to be very clear about the outcome, while it was far from obvious to me >> that the counts turned out to support above conclusion... >> >> >> Henrik >> >>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>> issue are needed. >>> >>> >>> It was pointed out that in the future if GRE was determined as a protocol >>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>> would be specified in the appropriate WG and a UDP port reserved for the >>> same. In such a case it would essentially be the equivalent of option 2 in >>> the choices list (below). >>> >>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>> Option 1 and close this issue. >>> >>> -Raj >>> >>> >>> >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>> >>>> Hello, >>>> >>>> The DS-MIP6 I-D still has >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >>>> to solve the issue. These are captured in: >>>> >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>> >>>> We need to make a decision on this issue and move forward with the >>>> I-D. At the meeting itself, I got the sense that option 3 was the one >>>> that had the least impact and easy to implement. >>>> >>>> Please consider this email as a consensus call for issue 93. The >>>> problem and choices are as follows (based on Vijay's slides): >>>> >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of >>>> protocol being encapsulated in the UDP header. >>>> >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header >>>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>> >>>> Pros and cons of these choices are in the slides that were presented >>>> at IETF68 (see URL above). >>>> >>>> Please provide your opinions and comments by May 15th, 07 on the MIP6 >>>> mailing list. >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> > > From nemo-bounces@ietf.org Fri Jun 01 19:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXr-0006cO-1H; Fri, 01 Jun 2007 19:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXp-0006c9-V7; Fri, 01 Jun 2007 19:28:33 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGXp-0007nI-E3; Fri, 01 Jun 2007 19:28:33 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuGXl-00061e-Qz; Sat, 02 Jun 2007 01:28:29 +0200 Message-ID: <4660AB9D.3040809@levkowetz.com> Date: Sat, 02 Jun 2007 01:28:29 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: <46608721.1030902@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: vidyan@qualcomm.com, basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nemo@ietf.org, Mobile IPv6 Mailing List , Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vidya, Rai, On 2007-06-02 00:13 Narayanan, Vidya said the following: > FWIW, I had also supported going with Option 1 for DS-MIP6. Of course that matters, Vidya, but the more important thing here is that it's pretty clear to me that there is *no* rough consensus present. Please don't manufacture one when there isn't one; if there really isn't one, do another call for discussion and/or show of hands, and if the group is deadlocked, use 3929. I can't accept this pronouncement of a consensus, rough or not, in the group, neither from my observation of the discussion or from the count. Henrik > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, June 01, 2007 2:36 PM >> To: Levkowetz >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >> - Consensus call to close issue 93 >> >> >> >> Vijay D. - Option 4 originally and then changed to Option 2 >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >> Option 1 (Interpreted) >> >> So we have a sort of a tie if you strictly go by count. >> If I were to express my own opinion (non-chair-hat), I would >> go with option 1 as well for the current DS-MIP6 proposal >> (aligned with my earlier email that if and when GRE is >> planned for use, another UDP port can be reserved... But for >> now option 1). That would break any deadlock issues. >> >> Or the other way is to let the chairs decide what is the >> sense of the discussion on the ML and from the perspective of >> the charter/scope and urgency of this protocol. And from this >> angle as well, I would stick by my conclusion, i.e option 1. >> >> -Raj >> >> >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >> wrote: >> >>> Hi Raj, >>> >>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>> So after an extensive discussion on this topic which spun >> off into a >>>> discussion about the need/use for GRE, I would like to summarize >>>> where we are with the options that we have. >>>> >>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>> protocol header following the UDP header" is good enough. >>> Could you give us an indication of who preferred which option? You >>> seem to be very clear about the outcome, while it was far >> from obvious >>> to me that the counts turned out to support above conclusion... >>> >>> >>> Henrik >>> >>>> So it implies no changes to the current text in the >> DS-MIP6 I-D w.r.t >>>> this issue are needed. >>>> >>>> >>>> It was pointed out that in the future if GRE was determined as a >>>> protocol that needs to be supported as well either for >> MIP6, NEMO or >>>> PMIP6 then it would be specified in the appropriate WG and >> a UDP port >>>> reserved for the same. In such a case it would essentially be the >>>> equivalent of option 2 in the choices list (below). >>>> >>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>> forward with Option 1 and close this issue. >>>> >>>> -Raj >>>> >>>> >>>> >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> wrote: >>>>> Hello, >>>>> >>>>> The DS-MIP6 I-D >> still has >>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>>> options to solve the issue. These are captured in: >>>>> >>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>> >>>>> We need to make a decision on this issue and move forward >> with the >>>>> I-D. At the meeting itself, I got the sense that option 3 was the >>>>> one that had the least impact and easy to implement. >>>>> >>>>> Please consider this email as a consensus call for issue 93. The >>>>> problem and choices are as follows (based on Vijay's slides): >>>>> >>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> traversal. The >>>>> encapculations are either: >>>>> - IPv6-in-UDP-over-IPv4 >>>>> - IPv4-in-UDP-over-IPv4 >>>>> There is a need (or I guess desirable) to indicate the type of >>>>> protocol being encapsulated in the UDP header. >>>>> >>>>> Choices are: >>>>> 1. Parse the protocol header following the UDP header 2. >> Reserve a >>>>> UDP port for each protocol header (i.e one UDP port for >>>>> IPv6-in-UDP-over-IPv4 and another for >> IPv4-in-UDP-over-IPv4 etc.) >>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>>> 4. Encapsulated protocol header type is indicated in the >> BU message >>>>> Pros and cons of these choices are in the slides that >> were presented >>>>> at IETF68 (see URL above). >>>>> >>>>> Please provide your opinions and comments by May 15th, 07 on the >>>>> MIP6 mailing list. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > From nemo-bounces@ietf.org Fri Jun 01 19:44:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGmz-0008Ql-UL; Fri, 01 Jun 2007 19:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGmy-0008Qd-5K; Fri, 01 Jun 2007 19:44:12 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGmx-0002bu-7T; Fri, 01 Jun 2007 19:44:12 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51Ni2tD007749; Sat, 2 Jun 2007 02:44:09 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 02:44:07 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 18:44:05 -0500 Received: from 10.241.58.165 ([10.241.58.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 23:44:05 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 18:44:06 -0500 Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: Acekpr3Z/Kv7EBCZEdyx6wARJNUNiA== In-Reply-To: <4660AB79.3050204@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 23:44:05.0382 (UTC) FILETIME=[BD7ADA60:01C7A4A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, On 6/1/07 6:27 PM, "ext Henrik Levkowetz" wrote: > > > On 2007-06-01 23:36 Basavaraj Patil said the following: >> >> Vijay D. - Option 4 originally and then changed to Option 2 >> Hesham - Option 1 >> Sri Gundavelli - Option 3 >> Kent - Option 3 >> Ahmad Muhanna - Option 3 >> Alex Petrescu - Option 1 (Interpreted) >> George T. - Option 1 >> Mohamed Khalil - Option 3 >> Markku Ala-V - Option 2 >> Henrik L. - Option 3 >> Pascal T. - Option 1 (Interpreted) >> >> So we have a sort of a tie if you strictly go by count. > > No, if we strictly go by the above count, there's no tie: > > Option 3 5 counts > Option 1 4 counts > Option 2 2 counts Guess I need to count better. Sorry, my mistake. Yes based on the above that is true. But I missed Vidya in this count (which she indicated following the email). So if I were to include Vidya in the count and myself, it would be very rough consensus. -Raj > >> If I were to express my own opinion (non-chair-hat), I would go with >> option 1 as well for the current DS-MIP6 proposal (aligned with my >> earlier email that if and when GRE is planned for use, another UDP >> port can be reserved... But for now option 1). That would break any >> deadlock issues. > > That would be credible if you'd said that before pronouncing a consensus > for option 1. Now it doesn't. > >> Or the other way is to let the chairs decide what is the sense of the >> discussion on the ML and from the perspective of the charter/scope and >> urgency of this protocol. And from this angle as well, I would stick >> by my conclusion, i.e option 1. > > That was my original reason for asking for the count -- having followed > the discussion, my perception was *very* different, and there wasn't a > consensus for 1 in the sense of the discussion. > > > Henrik > > >> -Raj >> >> >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: >> >>> Hi Raj, >>> >>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>> So after an extensive discussion on this topic which spun off into a >>>> discussion about the need/use for GRE, I would like to summarize where we >>>> are with the options that we have. >>>> >>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>>> header following the UDP header" is good enough. >>> Could you give us an indication of who preferred which option? You seem >>> to be very clear about the outcome, while it was far from obvious to me >>> that the counts turned out to support above conclusion... >>> >>> >>> Henrik >>> >>>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>>> issue are needed. >>>> >>>> >>>> It was pointed out that in the future if GRE was determined as a protocol >>>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>>> would be specified in the appropriate WG and a UDP port reserved for the >>>> same. In such a case it would essentially be the equivalent of option 2 in >>>> the choices list (below). >>>> >>>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>>> Option 1 and close this issue. >>>> >>>> -Raj >>>> >>>> >>>> >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>>> >>>>> Hello, >>>>> >>>>> The DS-MIP6 I-D still has >>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 options >>>>> to solve the issue. These are captured in: >>>>> >>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>> >>>>> We need to make a decision on this issue and move forward with the >>>>> I-D. At the meeting itself, I got the sense that option 3 was the one >>>>> that had the least impact and easy to implement. >>>>> >>>>> Please consider this email as a consensus call for issue 93. The >>>>> problem and choices are as follows (based on Vijay's slides): >>>>> >>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>>>> encapculations are either: >>>>> - IPv6-in-UDP-over-IPv4 >>>>> - IPv4-in-UDP-over-IPv4 >>>>> There is a need (or I guess desirable) to indicate the type of >>>>> protocol being encapsulated in the UDP header. >>>>> >>>>> Choices are: >>>>> 1. Parse the protocol header following the UDP header >>>>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>>>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>>> 4. Encapsulated protocol header type is indicated in the BU message >>>>> >>>>> Pros and cons of these choices are in the slides that were presented >>>>> at IETF68 (see URL above). >>>>> >>>>> Please provide your opinions and comments by May 15th, 07 on the MIP6 >>>>> mailing list. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> >> >> From nemo-bounces@ietf.org Fri Jun 01 19:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGut-0006Xy-EM; Fri, 01 Jun 2007 19:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGuq-0006N8-PD; Fri, 01 Jun 2007 19:52:20 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGuq-0003dM-2H; Fri, 01 Jun 2007 19:52:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51Nq8G8014602; Sat, 2 Jun 2007 02:52:18 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 02:52:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 18:52:13 -0500 Received: from 10.241.58.165 ([10.241.58.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 23:52:13 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 18:52:15 -0500 Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Levkowetz , "Narayanan, Vidya" Message-ID: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: Acekp+FQH7aIcRCbEdyx6wARJNUNiA== In-Reply-To: <4660AB9D.3040809@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 23:52:13.0654 (UTC) FILETIME=[E0833F60:01C7A4A7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, Rough consensus is what we have from my perspective on this issue. It is not being fabricated. Apparently you differ. I can ask Jari (AD) for his recommendation on whether: 1. To do a new consensus call 2. Use any of the RFC 3929 alternatives -Raj On 6/1/07 6:28 PM, "ext Henrik Levkowetz" wrote: > Hi Vidya, Rai, > > On 2007-06-02 00:13 Narayanan, Vidya said the following: >> FWIW, I had also supported going with Option 1 for DS-MIP6. > > Of course that matters, Vidya, but the more important thing here > is that it's pretty clear to me that there is *no* rough consensus > present. > > Please don't manufacture one when there isn't one; if there > really isn't one, do another call for discussion and/or show > of hands, and if the group is deadlocked, use 3929. > > I can't accept this pronouncement of a consensus, rough or not, > in the group, neither from my observation of the discussion or > from the count. > > > Henrik > > >> Vidya >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> Sent: Friday, June 01, 2007 2:36 PM >>> To: Levkowetz >>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>> - Consensus call to close issue 93 >>> >>> >>> >>> Vijay D. - Option 4 originally and then changed to Option 2 >>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>> Option 1 (Interpreted) >>> >>> So we have a sort of a tie if you strictly go by count. >>> If I were to express my own opinion (non-chair-hat), I would >>> go with option 1 as well for the current DS-MIP6 proposal >>> (aligned with my earlier email that if and when GRE is >>> planned for use, another UDP port can be reserved... But for >>> now option 1). That would break any deadlock issues. >>> >>> Or the other way is to let the chairs decide what is the >>> sense of the discussion on the ML and from the perspective of >>> the charter/scope and urgency of this protocol. And from this >>> angle as well, I would stick by my conclusion, i.e option 1. >>> >>> -Raj >>> >>> >>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>> wrote: >>> >>>> Hi Raj, >>>> >>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>> So after an extensive discussion on this topic which spun >>> off into a >>>>> discussion about the need/use for GRE, I would like to summarize >>>>> where we are with the options that we have. >>>>> >>>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>>> protocol header following the UDP header" is good enough. >>>> Could you give us an indication of who preferred which option? You >>>> seem to be very clear about the outcome, while it was far >>> from obvious >>>> to me that the counts turned out to support above conclusion... >>>> >>>> >>>> Henrik >>>> >>>>> So it implies no changes to the current text in the >>> DS-MIP6 I-D w.r.t >>>>> this issue are needed. >>>>> >>>>> >>>>> It was pointed out that in the future if GRE was determined as a >>>>> protocol that needs to be supported as well either for >>> MIP6, NEMO or >>>>> PMIP6 then it would be specified in the appropriate WG and >>> a UDP port >>>>> reserved for the same. In such a case it would essentially be the >>>>> equivalent of option 2 in the choices list (below). >>>>> >>>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>>> forward with Option 1 and close this issue. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> >>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>> wrote: >>>>>> Hello, >>>>>> >>>>>> The DS-MIP6 I-D >>> still has >>>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>>>> options to solve the issue. These are captured in: >>>>>> >>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>>> >>>>>> We need to make a decision on this issue and move forward >>> with the >>>>>> I-D. At the meeting itself, I got the sense that option 3 was the >>>>>> one that had the least impact and easy to implement. >>>>>> >>>>>> Please consider this email as a consensus call for issue 93. The >>>>>> problem and choices are as follows (based on Vijay's slides): >>>>>> >>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >>> traversal. The >>>>>> encapculations are either: >>>>>> - IPv6-in-UDP-over-IPv4 >>>>>> - IPv4-in-UDP-over-IPv4 >>>>>> There is a need (or I guess desirable) to indicate the type of >>>>>> protocol being encapsulated in the UDP header. >>>>>> >>>>>> Choices are: >>>>>> 1. Parse the protocol header following the UDP header 2. >>> Reserve a >>>>>> UDP port for each protocol header (i.e one UDP port for >>>>>> IPv6-in-UDP-over-IPv4 and another for >>> IPv4-in-UDP-over-IPv4 etc.) >>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>>>> 4. Encapsulated protocol header type is indicated in the >>> BU message >>>>>> Pros and cons of these choices are in the slides that >>> were presented >>>>>> at IETF68 (see URL above). >>>>>> >>>>>> Please provide your opinions and comments by May 15th, 07 on the >>>>>> MIP6 mailing list. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mip6 mailing list >>>>>> Mip6@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> From nemo-bounces@ietf.org Fri Jun 01 21:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuId0-00027d-CM; Fri, 01 Jun 2007 21:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuIcy-000278-T8; Fri, 01 Jun 2007 21:42:00 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuIcx-0007ji-0Z; Fri, 01 Jun 2007 21:42:00 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602014156.HTRS25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 01:41:56 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 01:41:55 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" , "'Narayanan, Vidya'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:41:51 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4660AB9D.3040809@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekpJQfzhZgBsfQR2CLJyxXoLmIUAAElTHQ Message-Id: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, You seem to be looking for a vote. We've always asked for concencus to change anything in the draft. The numbers that Raj sent clearly indicate that there is no concensus to change the draft. 5:4 is not concensus. Therefore, I think Raj's decision is correct. I hope we don't turn the IETF into a voting organisation, if we do then the whole process of providing a vote would be different from what we do today. Hesham > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Saturday, June 02, 2007 9:28 AM > To: Narayanan, Vidya > Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 - Consensuscall to close issue 93 > > Hi Vidya, Rai, > > On 2007-06-02 00:13 Narayanan, Vidya said the following: > > FWIW, I had also supported going with Option 1 for DS-MIP6. > > Of course that matters, Vidya, but the more important thing here > is that it's pretty clear to me that there is *no* rough consensus > present. > > Please don't manufacture one when there isn't one; if there > really isn't one, do another call for discussion and/or show > of hands, and if the group is deadlocked, use 3929. > > I can't accept this pronouncement of a consensus, rough or not, > in the group, neither from my observation of the discussion or > from the count. > > > Henrik > > > > Vidya > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Friday, June 01, 2007 2:36 PM > >> To: Levkowetz > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > >> - Consensus call to close issue 93 > >> > >> > >> > >> Vijay D. - Option 4 originally and then changed to Option 2 > >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > >> Option 1 (Interpreted) > >> > >> So we have a sort of a tie if you strictly go by count. > >> If I were to express my own opinion (non-chair-hat), I would > >> go with option 1 as well for the current DS-MIP6 proposal > >> (aligned with my earlier email that if and when GRE is > >> planned for use, another UDP port can be reserved... But for > >> now option 1). That would break any deadlock issues. > >> > >> Or the other way is to let the chairs decide what is the > >> sense of the discussion on the ML and from the perspective of > >> the charter/scope and urgency of this protocol. And from this > >> angle as well, I would stick by my conclusion, i.e option 1. > >> > >> -Raj > >> > >> > >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > >> wrote: > >> > >>> Hi Raj, > >>> > >>> On 2007-06-01 21:46 Basavaraj Patil said the following: > >>>> So after an extensive discussion on this topic which spun > >> off into a > >>>> discussion about the need/use for GRE, I would like to > summarize > >>>> where we are with the options that we have. > >>>> > >>>> Conclusion was that for DS-MIP6, Option 1 which is : " > Parse the > >>>> protocol header following the UDP header" is good enough. > >>> Could you give us an indication of who preferred which > option? You > >>> seem to be very clear about the outcome, while it was far > >> from obvious > >>> to me that the counts turned out to support above conclusion... > >>> > >>> > >>> Henrik > >>> > >>>> So it implies no changes to the current text in the > >> DS-MIP6 I-D w.r.t > >>>> this issue are needed. > >>>> > >>>> > >>>> It was pointed out that in the future if GRE was > determined as a > >>>> protocol that needs to be supported as well either for > >> MIP6, NEMO or > >>>> PMIP6 then it would be specified in the appropriate WG and > >> a UDP port > >>>> reserved for the same. In such a case it would > essentially be the > >>>> equivalent of option 2 in the choices list (below). > >>>> > >>>> At this time, the need for GRE especially in the scope > of DS-MIP6 > >>>> which is primarily MIP6 and NEMO is not proven. Hence > we will move > >>>> forward with Option 1 and close this issue. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > >> wrote: > >>>>> Hello, > >>>>> > >>>>> The DS-MIP6 I-D > >> still has > >>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 > >>>>> options to solve the issue. These are captured in: > >>>>> > >>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>>>> > >>>>> We need to make a decision on this issue and move forward > >> with the > >>>>> I-D. At the meeting itself, I got the sense that > option 3 was the > >>>>> one that had the least impact and easy to implement. > >>>>> > >>>>> Please consider this email as a consensus call for > issue 93. The > >>>>> problem and choices are as follows (based on Vijay's slides): > >>>>> > >>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > >> traversal. The > >>>>> encapculations are either: > >>>>> - IPv6-in-UDP-over-IPv4 > >>>>> - IPv4-in-UDP-over-IPv4 > >>>>> There is a need (or I guess desirable) to indicate the type of > >>>>> protocol being encapsulated in the UDP header. > >>>>> > >>>>> Choices are: > >>>>> 1. Parse the protocol header following the UDP header 2. > >> Reserve a > >>>>> UDP port for each protocol header (i.e one UDP port for > >>>>> IPv6-in-UDP-over-IPv4 and another for > >> IPv4-in-UDP-over-IPv4 etc.) > >>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>>>> 4. Encapsulated protocol header type is indicated in the > >> BU message > >>>>> Pros and cons of these choices are in the slides that > >> were presented > >>>>> at IETF68 (see URL above). > >>>>> > >>>>> Please provide your opinions and comments by May 15th, > 07 on the > >>>>> MIP6 mailing list. > >>>>> > >>>>> -Raj > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Mip6 mailing list > >>>>> Mip6@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >>>> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > From nemo-bounces@ietf.org Fri Jun 01 21:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuIti-0004b0-34; Fri, 01 Jun 2007 21:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuItg-0004aI-0r; Fri, 01 Jun 2007 21:59:16 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuIte-0002tM-4k; Fri, 01 Jun 2007 21:59:16 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602015912.IFOD25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 01:59:12 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602015911.UCFD4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 01:59:11 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" , "'Narayanan, Vidya'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:59:07 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekpJQfzhZgBsfQR2CLJyxXoLmIUAAElTHQAACiGBA= Message-Id: <20070602015911.UCFD4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org incidentally it is apparently 6:5 in favour of option 1. If the draft contained option 2 today then I would say that 6:5 is not concensus to change the draft. Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 11:42 AM > To: 'Henrik Levkowetz'; 'Narayanan, Vidya' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 -Consensuscall to close issue 93 > > Henrik, > > You seem to be looking for a vote. We've always asked for > concencus to > change anything > in the draft. The numbers that Raj sent clearly indicate > that there is no > concensus to change the draft. 5:4 is not concensus. > Therefore, I think > Raj's decision is correct. I hope we don't turn the IETF > into a voting > organisation, if we do then the whole process of providing a > vote would be > different from what we do today. > > Hesham > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Saturday, June 02, 2007 9:28 AM > > To: Narayanan, Vidya > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6 - Consensuscall to close issue 93 > > > > Hi Vidya, Rai, > > > > On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > FWIW, I had also supported going with Option 1 for DS-MIP6. > > > > Of course that matters, Vidya, but the more important thing here > > is that it's pretty clear to me that there is *no* rough consensus > > present. > > > > Please don't manufacture one when there isn't one; if there > > really isn't one, do another call for discussion and/or show > > of hands, and if the group is deadlocked, use 3929. > > > > I can't accept this pronouncement of a consensus, rough or not, > > in the group, neither from my observation of the discussion or > > from the count. > > > > > > Henrik > > > > > > > Vidya > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Friday, June 01, 2007 2:36 PM > > >> To: Levkowetz > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > > >> - Consensus call to close issue 93 > > >> > > >> > > >> > > >> Vijay D. - Option 4 originally and then changed to Option 2 > > >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > > >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > > >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > >> Option 1 (Interpreted) > > >> > > >> So we have a sort of a tie if you strictly go by count. > > >> If I were to express my own opinion (non-chair-hat), I would > > >> go with option 1 as well for the current DS-MIP6 proposal > > >> (aligned with my earlier email that if and when GRE is > > >> planned for use, another UDP port can be reserved... But for > > >> now option 1). That would break any deadlock issues. > > >> > > >> Or the other way is to let the chairs decide what is the > > >> sense of the discussion on the ML and from the perspective of > > >> the charter/scope and urgency of this protocol. And from this > > >> angle as well, I would stick by my conclusion, i.e option 1. > > >> > > >> -Raj > > >> > > >> > > >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > >> wrote: > > >> > > >>> Hi Raj, > > >>> > > >>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>> So after an extensive discussion on this topic which spun > > >> off into a > > >>>> discussion about the need/use for GRE, I would like to > > summarize > > >>>> where we are with the options that we have. > > >>>> > > >>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > Parse the > > >>>> protocol header following the UDP header" is good enough. > > >>> Could you give us an indication of who preferred which > > option? You > > >>> seem to be very clear about the outcome, while it was far > > >> from obvious > > >>> to me that the counts turned out to support above > conclusion... > > >>> > > >>> > > >>> Henrik > > >>> > > >>>> So it implies no changes to the current text in the > > >> DS-MIP6 I-D w.r.t > > >>>> this issue are needed. > > >>>> > > >>>> > > >>>> It was pointed out that in the future if GRE was > > determined as a > > >>>> protocol that needs to be supported as well either for > > >> MIP6, NEMO or > > >>>> PMIP6 then it would be specified in the appropriate WG and > > >> a UDP port > > >>>> reserved for the same. In such a case it would > > essentially be the > > >>>> equivalent of option 2 in the choices list (below). > > >>>> > > >>>> At this time, the need for GRE especially in the scope > > of DS-MIP6 > > >>>> which is primarily MIP6 and NEMO is not proven. Hence > > we will move > > >>>> forward with Option 1 and close this issue. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> > > >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > >> wrote: > > >>>>> Hello, > > >>>>> > > >>>>> The DS-MIP6 I-D > > >> still has > > >>>>> issue 93 open. This was discussed at IETF68. Vijay > presented 4 > > >>>>> options to solve the issue. These are captured in: > > >>>>> > > >>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >>>>> > > >>>>> We need to make a decision on this issue and move forward > > >> with the > > >>>>> I-D. At the meeting itself, I got the sense that > > option 3 was the > > >>>>> one that had the least impact and easy to implement. > > >>>>> > > >>>>> Please consider this email as a consensus call for > > issue 93. The > > >>>>> problem and choices are as follows (based on > Vijay's slides): > > >>>>> > > >>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > >> traversal. The > > >>>>> encapculations are either: > > >>>>> - IPv6-in-UDP-over-IPv4 > > >>>>> - IPv4-in-UDP-over-IPv4 > > >>>>> There is a need (or I guess desirable) to indicate > the type of > > >>>>> protocol being encapsulated in the UDP header. > > >>>>> > > >>>>> Choices are: > > >>>>> 1. Parse the protocol header following the UDP header 2. > > >> Reserve a > > >>>>> UDP port for each protocol header (i.e one UDP port for > > >>>>> IPv6-in-UDP-over-IPv4 and another for > > >> IPv4-in-UDP-over-IPv4 etc.) > > >>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > >>>>> 4. Encapsulated protocol header type is indicated in the > > >> BU message > > >>>>> Pros and cons of these choices are in the slides that > > >> were presented > > >>>>> at IETF68 (see URL above). > > >>>>> > > >>>>> Please provide your opinions and comments by May 15th, > > 07 on the > > >>>>> MIP6 mailing list. > > >>>>> > > >>>>> -Raj > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Mip6 mailing list > > >>>>> Mip6@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >>>> > > >> > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sat Jun 02 06:14:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQdE-0000La-AU; Sat, 02 Jun 2007 06:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQdC-00008n-Fr; Sat, 02 Jun 2007 06:14:46 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuQdA-0005DV-Fl; Sat, 02 Jun 2007 06:14:46 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuQd9-00025N-KQ; Sat, 02 Jun 2007 12:14:43 +0200 Message-ID: <46614313.2050302@levkowetz.com> Date: Sat, 02 Jun 2007 12:14:43 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2007-06-02 01:52 Basavaraj Patil said the following: > Henrik, > > Rough consensus is what we have from my perspective on this issue. It is not > being fabricated. Then you use a very different definition of rough consensus than I do. I see no consensus at all in this question yet. > Apparently you differ. I can ask Jari (AD) for his recommendation on > whether: > 1. To do a new consensus call > 2. Use any of the RFC 3929 alternatives Yes, please do so. Henrik > -Raj > > On 6/1/07 6:28 PM, "ext Henrik Levkowetz" wrote: > >> Hi Vidya, Rai, >> >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> Of course that matters, Vidya, but the more important thing here >> is that it's pretty clear to me that there is *no* rough consensus >> present. >> >> Please don't manufacture one when there isn't one; if there >> really isn't one, do another call for discussion and/or show >> of hands, and if the group is deadlocked, use 3929. >> >> I can't accept this pronouncement of a consensus, rough or not, >> in the group, neither from my observation of the discussion or >> from the count. >> >> >> Henrik >> >> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Friday, June 01, 2007 2:36 PM >>>> To: Levkowetz >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>>> - Consensus call to close issue 93 >>>> >>>> >>>> >>>> Vijay D. - Option 4 originally and then changed to Option 2 >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>>> Option 1 (Interpreted) >>>> >>>> So we have a sort of a tie if you strictly go by count. >>>> If I were to express my own opinion (non-chair-hat), I would >>>> go with option 1 as well for the current DS-MIP6 proposal >>>> (aligned with my earlier email that if and when GRE is >>>> planned for use, another UDP port can be reserved... But for >>>> now option 1). That would break any deadlock issues. >>>> >>>> Or the other way is to let the chairs decide what is the >>>> sense of the discussion on the ML and from the perspective of >>>> the charter/scope and urgency of this protocol. And from this >>>> angle as well, I would stick by my conclusion, i.e option 1. >>>> >>>> -Raj >>>> >>>> >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>>> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>>> So after an extensive discussion on this topic which spun >>>> off into a >>>>>> discussion about the need/use for GRE, I would like to summarize >>>>>> where we are with the options that we have. >>>>>> >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>>>> protocol header following the UDP header" is good enough. >>>>> Could you give us an indication of who preferred which option? You >>>>> seem to be very clear about the outcome, while it was far >>>> from obvious >>>>> to me that the counts turned out to support above conclusion... >>>>> >>>>> >>>>> Henrik >>>>> >>>>>> So it implies no changes to the current text in the >>>> DS-MIP6 I-D w.r.t >>>>>> this issue are needed. >>>>>> >>>>>> >>>>>> It was pointed out that in the future if GRE was determined as a >>>>>> protocol that needs to be supported as well either for >>>> MIP6, NEMO or >>>>>> PMIP6 then it would be specified in the appropriate WG and >>>> a UDP port >>>>>> reserved for the same. In such a case it would essentially be the >>>>>> equivalent of option 2 in the choices list (below). >>>>>> >>>>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>>>> forward with Option 1 and close this issue. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>>> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> The DS-MIP6 I-D >>>> still has >>>>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>>>>> options to solve the issue. These are captured in: >>>>>>> >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>>>> >>>>>>> We need to make a decision on this issue and move forward >>>> with the >>>>>>> I-D. At the meeting itself, I got the sense that option 3 was the >>>>>>> one that had the least impact and easy to implement. >>>>>>> >>>>>>> Please consider this email as a consensus call for issue 93. The >>>>>>> problem and choices are as follows (based on Vijay's slides): >>>>>>> >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >>>> traversal. The >>>>>>> encapculations are either: >>>>>>> - IPv6-in-UDP-over-IPv4 >>>>>>> - IPv4-in-UDP-over-IPv4 >>>>>>> There is a need (or I guess desirable) to indicate the type of >>>>>>> protocol being encapsulated in the UDP header. >>>>>>> >>>>>>> Choices are: >>>>>>> 1. Parse the protocol header following the UDP header 2. >>>> Reserve a >>>>>>> UDP port for each protocol header (i.e one UDP port for >>>>>>> IPv6-in-UDP-over-IPv4 and another for >>>> IPv4-in-UDP-over-IPv4 etc.) >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>>>>> 4. Encapsulated protocol header type is indicated in the >>>> BU message >>>>>>> Pros and cons of these choices are in the slides that >>>> were presented >>>>>>> at IETF68 (see URL above). >>>>>>> >>>>>>> Please provide your opinions and comments by May 15th, 07 on the >>>>>>> MIP6 mailing list. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mip6 mailing list >>>>>>> Mip6@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> > > From nemo-bounces@ietf.org Sat Jun 02 06:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQeM-000287-Tc; Sat, 02 Jun 2007 06:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQeL-00027y-80; Sat, 02 Jun 2007 06:15:57 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuQeK-0005Z4-Iq; Sat, 02 Jun 2007 06:15:57 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuQeI-00067B-MX; Sat, 02 Jun 2007 12:15:54 +0200 Message-ID: <4661435A.2040505@levkowetz.com> Date: Sat, 02 Jun 2007 12:15:54 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, On 2007-06-02 03:41 Hesham Soliman said the following: > Henrik, > > You seem to be looking for a vote. No, I'm not looking for a vote. I'm looking for consensus on how to handle the issue. And I don't see any consensus on how to handle the issue here. Henrik > We've always asked for concencus to > change anything > in the draft. The numbers that Raj sent clearly indicate that there is no > concensus to change the draft. 5:4 is not concensus. Therefore, I think > Raj's decision is correct. I hope we don't turn the IETF into a voting > organisation, if we do then the whole process of providing a vote would be > different from what we do today. > > Hesham > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Saturday, June 02, 2007 9:28 AM >> To: Narayanan, Vidya >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >> DS-MIP6 - Consensuscall to close issue 93 >> >> Hi Vidya, Rai, >> >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> Of course that matters, Vidya, but the more important thing here >> is that it's pretty clear to me that there is *no* rough consensus >> present. >> >> Please don't manufacture one when there isn't one; if there >> really isn't one, do another call for discussion and/or show >> of hands, and if the group is deadlocked, use 3929. >> >> I can't accept this pronouncement of a consensus, rough or not, >> in the group, neither from my observation of the discussion or >> from the count. >> >> >> Henrik >> >> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Friday, June 01, 2007 2:36 PM >>>> To: Levkowetz >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>>> - Consensus call to close issue 93 >>>> >>>> >>>> >>>> Vijay D. - Option 4 originally and then changed to Option 2 >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>>> Option 1 (Interpreted) >>>> >>>> So we have a sort of a tie if you strictly go by count. >>>> If I were to express my own opinion (non-chair-hat), I would >>>> go with option 1 as well for the current DS-MIP6 proposal >>>> (aligned with my earlier email that if and when GRE is >>>> planned for use, another UDP port can be reserved... But for >>>> now option 1). That would break any deadlock issues. >>>> >>>> Or the other way is to let the chairs decide what is the >>>> sense of the discussion on the ML and from the perspective of >>>> the charter/scope and urgency of this protocol. And from this >>>> angle as well, I would stick by my conclusion, i.e option 1. >>>> >>>> -Raj >>>> >>>> >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>>> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>>> So after an extensive discussion on this topic which spun >>>> off into a >>>>>> discussion about the need/use for GRE, I would like to >> summarize >>>>>> where we are with the options that we have. >>>>>> >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >> Parse the >>>>>> protocol header following the UDP header" is good enough. >>>>> Could you give us an indication of who preferred which >> option? You >>>>> seem to be very clear about the outcome, while it was far >>>> from obvious >>>>> to me that the counts turned out to support above conclusion... >>>>> >>>>> >>>>> Henrik >>>>> >>>>>> So it implies no changes to the current text in the >>>> DS-MIP6 I-D w.r.t >>>>>> this issue are needed. >>>>>> >>>>>> >>>>>> It was pointed out that in the future if GRE was >> determined as a >>>>>> protocol that needs to be supported as well either for >>>> MIP6, NEMO or >>>>>> PMIP6 then it would be specified in the appropriate WG and >>>> a UDP port >>>>>> reserved for the same. In such a case it would >> essentially be the >>>>>> equivalent of option 2 in the choices list (below). >>>>>> >>>>>> At this time, the need for GRE especially in the scope >> of DS-MIP6 >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >> we will move >>>>>> forward with Option 1 and close this issue. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>>> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> The DS-MIP6 I-D >>>> still has >>>>>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>>>>> options to solve the issue. These are captured in: >>>>>>> >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>>>> >>>>>>> We need to make a decision on this issue and move forward >>>> with the >>>>>>> I-D. At the meeting itself, I got the sense that >> option 3 was the >>>>>>> one that had the least impact and easy to implement. >>>>>>> >>>>>>> Please consider this email as a consensus call for >> issue 93. The >>>>>>> problem and choices are as follows (based on Vijay's slides): >>>>>>> >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >>>> traversal. The >>>>>>> encapculations are either: >>>>>>> - IPv6-in-UDP-over-IPv4 >>>>>>> - IPv4-in-UDP-over-IPv4 >>>>>>> There is a need (or I guess desirable) to indicate the type of >>>>>>> protocol being encapsulated in the UDP header. >>>>>>> >>>>>>> Choices are: >>>>>>> 1. Parse the protocol header following the UDP header 2. >>>> Reserve a >>>>>>> UDP port for each protocol header (i.e one UDP port for >>>>>>> IPv6-in-UDP-over-IPv4 and another for >>>> IPv4-in-UDP-over-IPv4 etc.) >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>>>>> 4. Encapsulated protocol header type is indicated in the >>>> BU message >>>>>>> Pros and cons of these choices are in the slides that >>>> were presented >>>>>>> at IETF68 (see URL above). >>>>>>> >>>>>>> Please provide your opinions and comments by May 15th, >> 07 on the >>>>>>> MIP6 mailing list. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mip6 mailing list >>>>>>> Mip6@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >> > > > From nemo-bounces@ietf.org Sat Jun 02 07:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRPi-0006nt-0X; Sat, 02 Jun 2007 07:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRPf-0006V0-IF; Sat, 02 Jun 2007 07:04:51 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuRPe-00047f-Mr; Sat, 02 Jun 2007 07:04:51 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602110447.UJUG25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 11:04:47 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 11:04:47 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 21:04:42 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4661435A.2040505@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NA Message-Id: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > No, I'm not looking for a vote. I'm looking for consensus on how to > handle the issue. And I don't see any consensus on how to handle the > issue here. => The issue was raised against an existing solution, if there is no support in the WG (6 people against and 5 for it) then clearly there is no agreement that there is an issue to begin with. What are you suggesting we do? If there is no support for the perceived issue then naturally it's rejected. I don't think anyone is changing their mind if we ask the same question again in the space of two weeks... If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you accepted the same numbers as concensus on other issues, like the mapped address one or issue 93. Should we repeat all those questions again? Hesham > > > Henrik > > > We've always asked for concencus to > > change anything > > in the draft. The numbers that Raj sent clearly indicate > that there is no > > concensus to change the draft. 5:4 is not concensus. > Therefore, I think > > Raj's decision is correct. I hope we don't turn the IETF > into a voting > > organisation, if we do then the whole process of providing > a vote would be > > different from what we do today. > > > > Hesham > > > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > >> Sent: Saturday, June 02, 2007 9:28 AM > >> To: Narayanan, Vidya > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > >> DS-MIP6 - Consensuscall to close issue 93 > >> > >> Hi Vidya, Rai, > >> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > >> Of course that matters, Vidya, but the more important thing here > >> is that it's pretty clear to me that there is *no* rough consensus > >> present. > >> > >> Please don't manufacture one when there isn't one; if there > >> really isn't one, do another call for discussion and/or show > >> of hands, and if the group is deadlocked, use 3929. > >> > >> I can't accept this pronouncement of a consensus, rough or not, > >> in the group, neither from my observation of the discussion or > >> from the count. > >> > >> > >> Henrik > >> > >> > >>> Vidya > >>> > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Friday, June 01, 2007 2:36 PM > >>>> To: Levkowetz > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > >>>> - Consensus call to close issue 93 > >>>> > >>>> > >>>> > >>>> Vijay D. - Option 4 originally and then changed to Option 2 > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > >>>> Option 1 (Interpreted) > >>>> > >>>> So we have a sort of a tie if you strictly go by count. > >>>> If I were to express my own opinion (non-chair-hat), I would > >>>> go with option 1 as well for the current DS-MIP6 proposal > >>>> (aligned with my earlier email that if and when GRE is > >>>> planned for use, another UDP port can be reserved... But for > >>>> now option 1). That would break any deadlock issues. > >>>> > >>>> Or the other way is to let the chairs decide what is the > >>>> sense of the discussion on the ML and from the perspective of > >>>> the charter/scope and urgency of this protocol. And from this > >>>> angle as well, I would stick by my conclusion, i.e option 1. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > >>>> wrote: > >>>> > >>>>> Hi Raj, > >>>>> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > >>>>>> So after an extensive discussion on this topic which spun > >>>> off into a > >>>>>> discussion about the need/use for GRE, I would like to > >> summarize > >>>>>> where we are with the options that we have. > >>>>>> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > >> Parse the > >>>>>> protocol header following the UDP header" is good enough. > >>>>> Could you give us an indication of who preferred which > >> option? You > >>>>> seem to be very clear about the outcome, while it was far > >>>> from obvious > >>>>> to me that the counts turned out to support above conclusion... > >>>>> > >>>>> > >>>>> Henrik > >>>>> > >>>>>> So it implies no changes to the current text in the > >>>> DS-MIP6 I-D w.r.t > >>>>>> this issue are needed. > >>>>>> > >>>>>> > >>>>>> It was pointed out that in the future if GRE was > >> determined as a > >>>>>> protocol that needs to be supported as well either for > >>>> MIP6, NEMO or > >>>>>> PMIP6 then it would be specified in the appropriate WG and > >>>> a UDP port > >>>>>> reserved for the same. In such a case it would > >> essentially be the > >>>>>> equivalent of option 2 in the choices list (below). > >>>>>> > >>>>>> At this time, the need for GRE especially in the scope > >> of DS-MIP6 > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > >> we will move > >>>>>> forward with Option 1 and close this issue. > >>>>>> > >>>>>> -Raj > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > >>>> wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> The DS-MIP6 I-D > >>>> still has > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > presented 4 > >>>>>>> options to solve the issue. These are captured in: > >>>>>>> > >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>>>>>> > >>>>>>> We need to make a decision on this issue and move forward > >>>> with the > >>>>>>> I-D. At the meeting itself, I got the sense that > >> option 3 was the > >>>>>>> one that had the least impact and easy to implement. > >>>>>>> > >>>>>>> Please consider this email as a consensus call for > >> issue 93. The > >>>>>>> problem and choices are as follows (based on Vijay's slides): > >>>>>>> > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > >>>> traversal. The > >>>>>>> encapculations are either: > >>>>>>> - IPv6-in-UDP-over-IPv4 > >>>>>>> - IPv4-in-UDP-over-IPv4 > >>>>>>> There is a need (or I guess desirable) to indicate > the type of > >>>>>>> protocol being encapsulated in the UDP header. > >>>>>>> > >>>>>>> Choices are: > >>>>>>> 1. Parse the protocol header following the UDP header 2. > >>>> Reserve a > >>>>>>> UDP port for each protocol header (i.e one UDP port for > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > >>>> IPv4-in-UDP-over-IPv4 etc.) > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>>>>>> 4. Encapsulated protocol header type is indicated in the > >>>> BU message > >>>>>>> Pros and cons of these choices are in the slides that > >>>> were presented > >>>>>>> at IETF68 (see URL above). > >>>>>>> > >>>>>>> Please provide your opinions and comments by May 15th, > >> 07 on the > >>>>>>> MIP6 mailing list. > >>>>>>> > >>>>>>> -Raj > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Mip6 mailing list > >>>>>>> Mip6@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>> > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >> > > > > > > > From nemo-bounces@ietf.org Sat Jun 02 08:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuT9g-0001Wn-Bx; Sat, 02 Jun 2007 08:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuT9f-0001We-RV; Sat, 02 Jun 2007 08:56:27 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuT9d-0002V2-Kq; Sat, 02 Jun 2007 08:56:27 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuT9a-0005rO-TV; Sat, 02 Jun 2007 14:56:22 +0200 Message-ID: <466168F4.6030006@levkowetz.com> Date: Sat, 02 Jun 2007 14:56:20 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60DA3BA4127C81A830F7DE97" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.com, jari.arkko@piuha.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60DA3BA4127C81A830F7DE97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2007-06-02 13:04 Hesham Soliman said the following: >> No, I'm not looking for a vote. I'm looking for consensus on how to >> handle the issue. And I don't see any consensus on how to handle the >> issue here. >=20 > The issue was raised against an existing solution, if there is no suppo= rt > in the WG (6 people against and 5 for it) then clearly there is no agre= ement > that there is an issue to begin with. I think this is incorrect; that we don't agree on a solution doesn't mean there isn't an issue. But if you want to ask the list if they think this is a non-issue, go right ahead. > What are you suggesting we do? If > there is no support for the perceived issue then naturally it's rejecte= d. I > don't think anyone is changing their mind if we ask the same question a= gain > in the space of two weeks... I saw several people change position during the discussion, which is of course the benefit of having a discussion in the first place -- as various aspects of a question is illuminated, people get a clearer view of the tradeofs, and hopefully align in a rough consensus. > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like the mapped= > address one or issue 93. Should we repeat all those questions again?=20 If you have counts of those issues that indicate that there was no consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can tell) then I think that would be the right thing to do. However, my memory of the other discussions isn't that they were as inconclusive as this one. Henrik --------------enig60DA3BA4127C81A830F7DE97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFGYWj1eVhrtTJkXCMRAsChAJ0RLZkJbDPdwvMbgJhnIdXay+zLpACg03se YAFXrJav4gEmhEQvoBQGnKg= =Qg+R -----END PGP SIGNATURE----- --------------enig60DA3BA4127C81A830F7DE97-- From nemo-bounces@ietf.org Sat Jun 02 09:50:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuTzh-00035A-TO; Sat, 02 Jun 2007 09:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuTzf-00032u-FQ; Sat, 02 Jun 2007 09:50:11 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuTzb-0004Fw-0H; Sat, 02 Jun 2007 09:50:11 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070602135003.CADD10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Sat, 2 Jun 2007 13:50:03 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 13:50:03 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 23:49:58 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <466168F4.6030006@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelFkpunItFNvAiTm+yh3L/+AxHTwABbZgw Message-Id: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > The issue was raised against an existing solution, if > there is no support > > in the WG (6 people against and 5 for it) then clearly > there is no agreement > > that there is an issue to begin with. > > I think this is incorrect; that we don't agree on a solution doesn't > mean there isn't an issue. But if you want to ask the list if they > think this is a non-issue, go right ahead. => We already did that, it's implicit in the question for a choice between keeping things as they are (i.e. it's not an issue that we need to solve) Vs 3 other options (or 2 workable options because option 4 doesn't work). > > I saw several people change position during the discussion, which is > of course the benefit of having a discussion in the first place -- as > various aspects of a question is illuminated, people get a clearer > view of the tradeofs, and hopefully align in a rough consensus. => Several people? I saw one. > > > If a 6:5 or 5:4 means no concensus to you, then I'm > surprised that you > > accepted the same numbers as concensus on other issues, > like the mapped > > address one or issue 93. Should we repeat all those > questions again? > > If you have counts of those issues that indicate that there was no > consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can > tell) then I think that would be the right thing to do. => I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there is no concensus to change the draft. Of course the figures for the mapped address were sent to the list, it was 5:4 for the change, you have those figures too. So if we re-open an issue for this reason then we have to be consistent and re-open all issues. However, my > memory of the other discussions isn't that they were as inconclusive > as this one. => You can check Raj's email on the mapped address issue yourself, it was another 5:4. I don't remember the exact number on issue 93. I assume you're not considering that a valid concensus either, we would agree on that. Hesham > > > Henrik > > > From nemo-bounces@ietf.org Sat Jun 02 14:31:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuYNb-0007Wr-SL; Sat, 02 Jun 2007 14:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuYNa-0007We-GF; Sat, 02 Jun 2007 14:31:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuYNZ-0004yQ-Mj; Sat, 02 Jun 2007 14:31:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2007 11:31:09 -0700 X-IronPort-AV: i="4.16,376,1175497200"; d="scan'208"; a="158001314:sNHT62434512" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l52IV9FD027924; Sat, 2 Jun 2007 11:31:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l52IUx20001398; Sat, 2 Jun 2007 18:31:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 11:30:59 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 11:30:58 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" References: <4661435A.2040505@levkowetz.com> <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:30:58 -0700 Message-ID: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6A= In-Reply-To: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 02 Jun 2007 18:30:58.0947 (UTC) FILETIME=[2A4E1D30:01C7A544] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10499; t=1180809069; x=1181673069; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6=20-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=ZX95+1EJN2ReVbiehUtwKNP51Q+oywffF2Ho65TL8U8=; b=Avc1g8S/IzGLh0nagHrQteLCtnyouanvQudM0GKEIftc7oRNpm4FWlEHjLrLpmgnD+eo6UdV q6ALVufJJWgkcfEo8hsxQJYZkJ9VE79dxzr58cyDwdM8COHXHZ/fr3JQ; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I understand the need to complete the DSMIP6 as early as possible and I appreciate the Chair's position to close this issue soon. I really like to see that as well. I also believe, IMO, that there is a proper justification in asking for Option#3. Its for a simple TLV header, qualifier in UDP for the payload packet. Many reasons, examples, protocol conventions including 3519's way of dealing with the exact same issue, lack of resaved port numbers, opening multiple port numbers if we were to extend it later, and many other reasons were mentioned and against the one solid reason of extra-4 byte overhead. We don't have turn this to a voting machine, if we see the need for this request with certain flexibility. Now, w.r.t the voting, I though Pascal did mention the need for a supporting new encapsulation mode and off course he also wanted this work to close ASAP and that leaves it in a ambiguous vote. And if I interpret Vijay's emails correctly, his preference is for Option#4 and his second preference is for option#3. He can speak up. And, we missed Alessio Casati's preference on this issue, he did support option#3. So with Jouni Korhonen, he did state that "I prefer more future proof extensibility over slight performance hit thus I prefer the 4 bytes header like in 3519". I also interpret Yoshi Tsuda's vote in favour of option#3. If this is not rough consensus, atleast, there is sufficient interest to discuss this issue further and proper conclude. My 2c. Regards Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 4:05 AM > To: 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 -Consensuscall to close issue 93 > > > > No, I'm not looking for a vote. I'm looking for consensus > on how to > > handle the issue. And I don't see any consensus on how to > handle the > > issue here. > > => The issue was raised against an existing solution, if > there is no support > in the WG (6 people against and 5 for it) then clearly there > is no agreement > that there is an issue to begin with. What are you suggesting > we do? If > there is no support for the perceived issue then naturally > it's rejected. I > don't think anyone is changing their mind if we ask the same > question again > in the space of two weeks... > > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like > the mapped > address one or issue 93. Should we repeat all those questions again? > > Hesham > > > > > > > Henrik > > > > > We've always asked for concencus to > > > change anything > > > in the draft. The numbers that Raj sent clearly indicate > > that there is no > > > concensus to change the draft. 5:4 is not concensus. > > Therefore, I think > > > Raj's decision is correct. I hope we don't turn the IETF > > into a voting > > > organisation, if we do then the whole process of providing > > a vote would be > > > different from what we do today. > > > > > > Hesham > > > > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > >> Sent: Saturday, June 02, 2007 9:28 AM > > >> To: Narayanan, Vidya > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > >> DS-MIP6 - Consensuscall to close issue 93 > > >> > > >> Hi Vidya, Rai, > > >> > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > >> Of course that matters, Vidya, but the more important thing here > > >> is that it's pretty clear to me that there is *no* > rough consensus > > >> present. > > >> > > >> Please don't manufacture one when there isn't one; if there > > >> really isn't one, do another call for discussion and/or show > > >> of hands, and if the group is deadlocked, use 3929. > > >> > > >> I can't accept this pronouncement of a consensus, rough or not, > > >> in the group, neither from my observation of the discussion or > > >> from the count. > > >> > > >> > > >> Henrik > > >> > > >> > > >>> Vidya > > >>> > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > >>>> To: Levkowetz > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > > >>>> - Consensus call to close issue 93 > > >>>> > > >>>> > > >>>> > > >>>> Vijay D. - Option 4 originally and then changed to Option 2 > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > >>>> Option 1 (Interpreted) > > >>>> > > >>>> So we have a sort of a tie if you strictly go by count. > > >>>> If I were to express my own opinion (non-chair-hat), I would > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > >>>> (aligned with my earlier email that if and when GRE is > > >>>> planned for use, another UDP port can be reserved... But for > > >>>> now option 1). That would break any deadlock issues. > > >>>> > > >>>> Or the other way is to let the chairs decide what is the > > >>>> sense of the discussion on the ML and from the perspective of > > >>>> the charter/scope and urgency of this protocol. And from this > > >>>> angle as well, I would stick by my conclusion, i.e option 1. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > >>>> wrote: > > >>>> > > >>>>> Hi Raj, > > >>>>> > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>>>> So after an extensive discussion on this topic which spun > > >>>> off into a > > >>>>>> discussion about the need/use for GRE, I would like to > > >> summarize > > >>>>>> where we are with the options that we have. > > >>>>>> > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > >> Parse the > > >>>>>> protocol header following the UDP header" is good enough. > > >>>>> Could you give us an indication of who preferred which > > >> option? You > > >>>>> seem to be very clear about the outcome, while it was far > > >>>> from obvious > > >>>>> to me that the counts turned out to support above > conclusion... > > >>>>> > > >>>>> > > >>>>> Henrik > > >>>>> > > >>>>>> So it implies no changes to the current text in the > > >>>> DS-MIP6 I-D w.r.t > > >>>>>> this issue are needed. > > >>>>>> > > >>>>>> > > >>>>>> It was pointed out that in the future if GRE was > > >> determined as a > > >>>>>> protocol that needs to be supported as well either for > > >>>> MIP6, NEMO or > > >>>>>> PMIP6 then it would be specified in the appropriate WG and > > >>>> a UDP port > > >>>>>> reserved for the same. In such a case it would > > >> essentially be the > > >>>>>> equivalent of option 2 in the choices list (below). > > >>>>>> > > >>>>>> At this time, the need for GRE especially in the scope > > >> of DS-MIP6 > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > >> we will move > > >>>>>> forward with Option 1 and close this issue. > > >>>>>> > > >>>>>> -Raj > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > >>>> wrote: > > >>>>>>> Hello, > > >>>>>>> > > >>>>>>> The DS-MIP6 I-D > > >>>> still has > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > > presented 4 > > >>>>>>> options to solve the issue. These are captured in: > > >>>>>>> > > >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >>>>>>> > > >>>>>>> We need to make a decision on this issue and move forward > > >>>> with the > > >>>>>>> I-D. At the meeting itself, I got the sense that > > >> option 3 was the > > >>>>>>> one that had the least impact and easy to implement. > > >>>>>>> > > >>>>>>> Please consider this email as a consensus call for > > >> issue 93. The > > >>>>>>> problem and choices are as follows (based on > Vijay's slides): > > >>>>>>> > > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > >>>> traversal. The > > >>>>>>> encapculations are either: > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > >>>>>>> There is a need (or I guess desirable) to indicate > > the type of > > >>>>>>> protocol being encapsulated in the UDP header. > > >>>>>>> > > >>>>>>> Choices are: > > >>>>>>> 1. Parse the protocol header following the UDP header 2. > > >>>> Reserve a > > >>>>>>> UDP port for each protocol header (i.e one UDP port for > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > > >>>> IPv4-in-UDP-over-IPv4 etc.) > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel > type message" > > >>>>>>> 4. Encapsulated protocol header type is indicated in the > > >>>> BU message > > >>>>>>> Pros and cons of these choices are in the slides that > > >>>> were presented > > >>>>>>> at IETF68 (see URL above). > > >>>>>>> > > >>>>>>> Please provide your opinions and comments by May 15th, > > >> 07 on the > > >>>>>>> MIP6 mailing list. > > >>>>>>> > > >>>>>>> -Raj > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> Mip6 mailing list > > >>>>>>> Mip6@ietf.org > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>> > > >>>> _______________________________________________ > > >>>> Mip6 mailing list > > >>>> Mip6@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >> > > > > > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Sat Jun 02 18:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huc7I-000462-5Z; Sat, 02 Jun 2007 18:30:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huc7G-00045u-7y; Sat, 02 Jun 2007 18:30:34 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huc7E-0000zK-F6; Sat, 02 Jun 2007 18:30:34 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Huc7B-0003sI-Ka; Sun, 03 Jun 2007 00:30:29 +0200 Message-ID: <4661EF82.90605@levkowetz.com> Date: Sun, 03 Jun 2007 00:30:26 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD4DC49EE93C846EF069B92D" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.com, jari.arkko@piuha.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD4DC49EE93C846EF069B92D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2007-06-02 15:49 Hesham Soliman said the following: >>> The issue was raised against an existing solution, if=20 >> there is no support >>> in the WG (6 people against and 5 for it) then clearly=20 >> there is no agreement >>> that there is an issue to begin with. >> I think this is incorrect; that we don't agree on a solution doesn't >> mean there isn't an issue. But if you want to ask the list if they >> think this is a non-issue, go right ahead. >=20 > We already did that, it's implicit in the question for a choice between= > keeping things as they are (i.e. it's not an issue that we need to solv= e) Vs > 3 other options (or 2 workable options because option 4 doesn't work). I think here we have a fundamental disagrement. If I understand your reasoning right, then you are saying that in a case when the WG doesn't have consensus on an issue, whatever is written in a document is going to be the resolution. I'm saying that if the working group doesn't have consensus on an issue, it doesn't matter what the document says; the document cannot go forward with either of the discussed solutions if the WG doesn't have rough consensus for one of them. Maybe you're focussing more on what is going to be changed in the document right now, rather on closing the issue; while I'm focussing on resolving the issue, and the text of the document at the point when it can be sent for publication, rather than focussing on what happens to the document text right now? >> I saw several people change position during the discussion, which is >> of course the benefit of having a discussion in the first place -- as >> various aspects of a question is illuminated, people get a clearer >> view of the tradeofs, and hopefully align in a rough consensus. >=20 > Several people? I saw one. And I saw several. Does arguing about this lead anywhere? >>> If a 6:5 or 5:4 means no concensus to you, then I'm=20 >> surprised that you >>> accepted the same numbers as concensus on other issues,=20 >> like the mapped >>> address one or issue 93. Should we repeat all those=20 >> questions again?=20 >> >> If you have counts of those issues that indicate that there was no >> consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can >> tell) then I think that would be the right thing to do. =20 >=20 > I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there= > is no concensus to change the draft. Of course the figures for the mapp= ed > address were sent to the list, it was 5:4 for the change, you have thos= e > figures too. So if we re-open an issue for this reason then we have to = be > consistent and re-open all issues.=20 >=20 > However, my >> memory of the other discussions isn't that they were as inconclusive >> as this one. >=20 > You can check Raj's email on the mapped address issue yourself, it was > another 5:4. I don't remember the exact number on issue 93. I assume yo= u're > not considering that a valid concensus either, we would agree on that. >=20 > Hesham >=20 >=20 >=20 >> >> Henrik >> >> >> >=20 >=20 >=20 --------------enigBD4DC49EE93C846EF069B92D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFGYe+DeVhrtTJkXCMRAtpvAJ4xVKO0JM+Syataeg/jzYRGnE50fQCfWdQh J9DwnPJs15VIYKhgfFKJrlo= =AjRj -----END PGP SIGNATURE----- --------------enigBD4DC49EE93C846EF069B92D-- From nemo-bounces@ietf.org Sat Jun 02 18:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HucNG-0004r3-1x; Sat, 02 Jun 2007 18:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HucNE-0004qv-W2; Sat, 02 Jun 2007 18:47:04 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HucND-000506-69; Sat, 02 Jun 2007 18:47:04 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HucNB-0004Wm-1G; Sun, 03 Jun 2007 00:47:01 +0200 Message-ID: <4661F364.9000200@levkowetz.com> Date: Sun, 03 Jun 2007 00:47:00 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 References: <4661435A.2040505@levkowetz.com> <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> In-Reply-To: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: sgundave@cisco.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2007-06-02 20:30 Sri Gundavelli said the following: ... > Now, w.r.t the voting, I though Pascal did mention the need > for a supporting new encapsulation mode and off course he > also wanted this work to close ASAP and that leaves it in > a ambiguous vote. And if I interpret Vijay's emails correctly, > his preference is for Option#4 and his second preference is > for option#3. He can speak up. And, we missed Alessio Casati's > preference on this issue, he did support option#3. So with > Jouni Korhonen, he did state that "I prefer more future proof > extensibility over slight performance hit thus I prefer the > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > vote in favour of option#3. So if I count this correctly, we have Option 3 9 counts (+ Vijay's 2nd pref) Option 1 5 counts Option 2 2 counts Option 4 1 count > If this is not rough consensus, atleast, there is sufficient > interest to discuss this issue further and proper conclude. I agree. Henrik > My 2c. > > Regards > Sri > > > > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Saturday, June 02, 2007 4:05 AM >> To: 'Henrik Levkowetz' >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: >> DS-MIP6 -Consensuscall to close issue 93 >> >> >> > No, I'm not looking for a vote. I'm looking for consensus >> on how to >> > handle the issue. And I don't see any consensus on how to >> handle the >> > issue here. >> >> => The issue was raised against an existing solution, if >> there is no support >> in the WG (6 people against and 5 for it) then clearly there >> is no agreement >> that there is an issue to begin with. What are you suggesting >> we do? If >> there is no support for the perceived issue then naturally >> it's rejected. I >> don't think anyone is changing their mind if we ask the same >> question again >> in the space of two weeks... >> >> If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you >> accepted the same numbers as concensus on other issues, like >> the mapped >> address one or issue 93. Should we repeat all those questions again? >> >> Hesham >> >> > >> > >> > Henrik >> > >> > > We've always asked for concencus to >> > > change anything >> > > in the draft. The numbers that Raj sent clearly indicate >> > that there is no >> > > concensus to change the draft. 5:4 is not concensus. >> > Therefore, I think >> > > Raj's decision is correct. I hope we don't turn the IETF >> > into a voting >> > > organisation, if we do then the whole process of providing >> > a vote would be >> > > different from what we do today. >> > > >> > > Hesham >> > > >> > >> -----Original Message----- >> > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> > >> Sent: Saturday, June 02, 2007 9:28 AM >> > >> To: Narayanan, Vidya >> > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >> > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >> > >> DS-MIP6 - Consensuscall to close issue 93 >> > >> >> > >> Hi Vidya, Rai, >> > >> >> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >> > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> > >> Of course that matters, Vidya, but the more important thing here >> > >> is that it's pretty clear to me that there is *no* >> rough consensus >> > >> present. >> > >> >> > >> Please don't manufacture one when there isn't one; if there >> > >> really isn't one, do another call for discussion and/or show >> > >> of hands, and if the group is deadlocked, use 3929. >> > >> >> > >> I can't accept this pronouncement of a consensus, rough or not, >> > >> in the group, neither from my observation of the discussion or >> > >> from the count. >> > >> >> > >> >> > >> Henrik >> > >> >> > >> >> > >>> Vidya >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> > >>>> Sent: Friday, June 01, 2007 2:36 PM >> > >>>> To: Levkowetz >> > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >> > >>>> - Consensus call to close issue 93 >> > >>>> >> > >>>> >> > >>>> >> > >>>> Vijay D. - Option 4 originally and then changed to Option 2 >> > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >> > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >> > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >> > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >> > >>>> Option 1 (Interpreted) >> > >>>> >> > >>>> So we have a sort of a tie if you strictly go by count. >> > >>>> If I were to express my own opinion (non-chair-hat), I would >> > >>>> go with option 1 as well for the current DS-MIP6 proposal >> > >>>> (aligned with my earlier email that if and when GRE is >> > >>>> planned for use, another UDP port can be reserved... But for >> > >>>> now option 1). That would break any deadlock issues. >> > >>>> >> > >>>> Or the other way is to let the chairs decide what is the >> > >>>> sense of the discussion on the ML and from the perspective of >> > >>>> the charter/scope and urgency of this protocol. And from this >> > >>>> angle as well, I would stick by my conclusion, i.e option 1. >> > >>>> >> > >>>> -Raj >> > >>>> >> > >>>> >> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >> > >>>> wrote: >> > >>>> >> > >>>>> Hi Raj, >> > >>>>> >> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >> > >>>>>> So after an extensive discussion on this topic which spun >> > >>>> off into a >> > >>>>>> discussion about the need/use for GRE, I would like to >> > >> summarize >> > >>>>>> where we are with the options that we have. >> > >>>>>> >> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >> > >> Parse the >> > >>>>>> protocol header following the UDP header" is good enough. >> > >>>>> Could you give us an indication of who preferred which >> > >> option? You >> > >>>>> seem to be very clear about the outcome, while it was far >> > >>>> from obvious >> > >>>>> to me that the counts turned out to support above >> conclusion... >> > >>>>> >> > >>>>> >> > >>>>> Henrik >> > >>>>> >> > >>>>>> So it implies no changes to the current text in the >> > >>>> DS-MIP6 I-D w.r.t >> > >>>>>> this issue are needed. >> > >>>>>> >> > >>>>>> >> > >>>>>> It was pointed out that in the future if GRE was >> > >> determined as a >> > >>>>>> protocol that needs to be supported as well either for >> > >>>> MIP6, NEMO or >> > >>>>>> PMIP6 then it would be specified in the appropriate WG and >> > >>>> a UDP port >> > >>>>>> reserved for the same. In such a case it would >> > >> essentially be the >> > >>>>>> equivalent of option 2 in the choices list (below). >> > >>>>>> >> > >>>>>> At this time, the need for GRE especially in the scope >> > >> of DS-MIP6 >> > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >> > >> we will move >> > >>>>>> forward with Option 1 and close this issue. >> > >>>>>> >> > >>>>>> -Raj >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> > >>>> wrote: >> > >>>>>>> Hello, >> > >>>>>>> >> > >>>>>>> The DS-MIP6 I-D >> > >>>> still has >> > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay >> > presented 4 >> > >>>>>>> options to solve the issue. These are captured in: >> > >>>>>>> >> > >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >> > >>>>>>> >> > >>>>>>> We need to make a decision on this issue and move forward >> > >>>> with the >> > >>>>>>> I-D. At the meeting itself, I got the sense that >> > >> option 3 was the >> > >>>>>>> one that had the least impact and easy to implement. >> > >>>>>>> >> > >>>>>>> Please consider this email as a consensus call for >> > >> issue 93. The >> > >>>>>>> problem and choices are as follows (based on >> Vijay's slides): >> > >>>>>>> >> > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> > >>>> traversal. The >> > >>>>>>> encapculations are either: >> > >>>>>>> - IPv6-in-UDP-over-IPv4 >> > >>>>>>> - IPv4-in-UDP-over-IPv4 >> > >>>>>>> There is a need (or I guess desirable) to indicate >> > the type of >> > >>>>>>> protocol being encapsulated in the UDP header. >> > >>>>>>> >> > >>>>>>> Choices are: >> > >>>>>>> 1. Parse the protocol header following the UDP header 2. >> > >>>> Reserve a >> > >>>>>>> UDP port for each protocol header (i.e one UDP port for >> > >>>>>>> IPv6-in-UDP-over-IPv4 and another for >> > >>>> IPv4-in-UDP-over-IPv4 etc.) >> > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel >> type message" >> > >>>>>>> 4. Encapsulated protocol header type is indicated in the >> > >>>> BU message >> > >>>>>>> Pros and cons of these choices are in the slides that >> > >>>> were presented >> > >>>>>>> at IETF68 (see URL above). >> > >>>>>>> >> > >>>>>>> Please provide your opinions and comments by May 15th, >> > >> 07 on the >> > >>>>>>> MIP6 mailing list. >> > >>>>>>> >> > >>>>>>> -Raj >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> _______________________________________________ >> > >>>>>>> Mip6 mailing list >> > >>>>>>> Mip6@ietf.org >> > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >> > >>>>>> >> > >>>> _______________________________________________ >> > >>>> Mip6 mailing list >> > >>>> Mip6@ietf.org >> > >>>> https://www1.ietf.org/mailman/listinfo/mip6 >> > >>>> >> > >> >> > > >> > > >> > > >> > >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sat Jun 02 22:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HufyG-0004RD-Mf; Sat, 02 Jun 2007 22:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HufyF-0004R0-GV; Sat, 02 Jun 2007 22:37:31 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HufyE-00008M-IP; Sat, 02 Jun 2007 22:37:31 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070603023727.EALO28583.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sun, 3 Jun 2007 02:37:27 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 02:37:26 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 12:37:21 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkA== Message-Id: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, Pascal's email was not sent in private and we don't need an interpretation. He's alive and well and he didn't object to Raj's conclusion. He clearly said that we should let the draft move as is. I believe other people who are also alive and well can speak for themselves if they were misrepresented..... I look forward to people expressing that they were misrepresnted by the chairs. I don't think it's useful for you or Henrik to recount on their behalf. Hesham > I understand the need to complete the DSMIP6 as early as > possible and I appreciate the Chair's position to close > this issue soon. I really like to see that as well. I also > believe, IMO, that there is a proper justification in asking > for Option#3. Its for a simple TLV header, qualifier in UDP > for the payload packet. Many reasons, examples, protocol > conventions including 3519's way of dealing with the exact > same issue, lack of resaved port numbers, opening multiple > port numbers if we were to extend it later, and many other > reasons were mentioned and against the one solid reason of > extra-4 byte overhead. We don't have turn this to a voting > machine, if we see the need for this request with certain > flexibility. > > Now, w.r.t the voting, I though Pascal did mention the need > for a supporting new encapsulation mode and off course he > also wanted this work to close ASAP and that leaves it in > a ambiguous vote. And if I interpret Vijay's emails correctly, > his preference is for Option#4 and his second preference is > for option#3. He can speak up. And, we missed Alessio Casati's > preference on this issue, he did support option#3. So with > Jouni Korhonen, he did state that "I prefer more future proof > extensibility over slight performance hit thus I prefer the > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > vote in favour of option#3. > > If this is not rough consensus, atleast, there is sufficient > interest to discuss this issue further and proper conclude. > My 2c. > > Regards > Sri > > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Saturday, June 02, 2007 4:05 AM > > To: 'Henrik Levkowetz' > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > on how to > > > handle the issue. And I don't see any consensus on how to > > handle the > > > issue here. > > > > => The issue was raised against an existing solution, if > > there is no support > > in the WG (6 people against and 5 for it) then clearly there > > is no agreement > > that there is an issue to begin with. What are you suggesting > > we do? If > > there is no support for the perceived issue then naturally > > it's rejected. I > > don't think anyone is changing their mind if we ask the same > > question again > > in the space of two weeks... > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > surprised that you > > accepted the same numbers as concensus on other issues, like > > the mapped > > address one or issue 93. Should we repeat all those > questions again? > > > > Hesham > > > > > > > > > > > Henrik > > > > > > > We've always asked for concencus to > > > > change anything > > > > in the draft. The numbers that Raj sent clearly indicate > > > that there is no > > > > concensus to change the draft. 5:4 is not concensus. > > > Therefore, I think > > > > Raj's decision is correct. I hope we don't turn the IETF > > > into a voting > > > > organisation, if we do then the whole process of providing > > > a vote would be > > > > different from what we do today. > > > > > > > > Hesham > > > > > > > >> -----Original Message----- > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > >> To: Narayanan, Vidya > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > >> > > > >> Hi Vidya, Rai, > > > >> > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > > >> Of course that matters, Vidya, but the more > important thing here > > > >> is that it's pretty clear to me that there is *no* > > rough consensus > > > >> present. > > > >> > > > >> Please don't manufacture one when there isn't one; if there > > > >> really isn't one, do another call for discussion and/or show > > > >> of hands, and if the group is deadlocked, use 3929. > > > >> > > > >> I can't accept this pronouncement of a consensus, > rough or not, > > > >> in the group, neither from my observation of the > discussion or > > > >> from the count. > > > >> > > > >> > > > >> Henrik > > > >> > > > >> > > > >>> Vidya > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > >>>> To: Levkowetz > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > of: DS-MIP6 > > > >>>> - Consensus call to close issue 93 > > > >>>> > > > >>>> > > > >>>> > > > >>>> Vijay D. - Option 4 originally and then changed to > Option 2 > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > Option 3 > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > - Option 3 > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > >>>> Option 1 (Interpreted) > > > >>>> > > > >>>> So we have a sort of a tie if you strictly go by count. > > > >>>> If I were to express my own opinion > (non-chair-hat), I would > > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > > >>>> (aligned with my earlier email that if and when GRE is > > > >>>> planned for use, another UDP port can be > reserved... But for > > > >>>> now option 1). That would break any deadlock issues. > > > >>>> > > > >>>> Or the other way is to let the chairs decide what is the > > > >>>> sense of the discussion on the ML and from the > perspective of > > > >>>> the charter/scope and urgency of this protocol. > And from this > > > >>>> angle as well, I would stick by my conclusion, i.e > option 1. > > > >>>> > > > >>>> -Raj > > > >>>> > > > >>>> > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > >>>> wrote: > > > >>>> > > > >>>>> Hi Raj, > > > >>>>> > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > >>>>>> So after an extensive discussion on this topic > which spun > > > >>>> off into a > > > >>>>>> discussion about the need/use for GRE, I would like to > > > >> summarize > > > >>>>>> where we are with the options that we have. > > > >>>>>> > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > >> Parse the > > > >>>>>> protocol header following the UDP header" is good enough. > > > >>>>> Could you give us an indication of who preferred which > > > >> option? You > > > >>>>> seem to be very clear about the outcome, while it was far > > > >>>> from obvious > > > >>>>> to me that the counts turned out to support above > > conclusion... > > > >>>>> > > > >>>>> > > > >>>>> Henrik > > > >>>>> > > > >>>>>> So it implies no changes to the current text in the > > > >>>> DS-MIP6 I-D w.r.t > > > >>>>>> this issue are needed. > > > >>>>>> > > > >>>>>> > > > >>>>>> It was pointed out that in the future if GRE was > > > >> determined as a > > > >>>>>> protocol that needs to be supported as well either for > > > >>>> MIP6, NEMO or > > > >>>>>> PMIP6 then it would be specified in the > appropriate WG and > > > >>>> a UDP port > > > >>>>>> reserved for the same. In such a case it would > > > >> essentially be the > > > >>>>>> equivalent of option 2 in the choices list (below). > > > >>>>>> > > > >>>>>> At this time, the need for GRE especially in the scope > > > >> of DS-MIP6 > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > >> we will move > > > >>>>>> forward with Option 1 and close this issue. > > > >>>>>> > > > >>>>>> -Raj > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > >>>> wrote: > > > >>>>>>> Hello, > > > >>>>>>> > > > >>>>>>> The DS-MIP6 I-D > > > > >>>> still has > > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > > > presented 4 > > > >>>>>>> options to solve the issue. These are captured in: > > > >>>>>>> > > > >>>>>>> > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > >>>>>>> > > > >>>>>>> We need to make a decision on this issue and > move forward > > > >>>> with the > > > >>>>>>> I-D. At the meeting itself, I got the sense that > > > >> option 3 was the > > > >>>>>>> one that had the least impact and easy to implement. > > > >>>>>>> > > > >>>>>>> Please consider this email as a consensus call for > > > >> issue 93. The > > > >>>>>>> problem and choices are as follows (based on > > Vijay's slides): > > > >>>>>>> > > > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > >>>> traversal. The > > > >>>>>>> encapculations are either: > > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > > >>>>>>> There is a need (or I guess desirable) to indicate > > > the type of > > > >>>>>>> protocol being encapsulated in the UDP header. > > > >>>>>>> > > > >>>>>>> Choices are: > > > >>>>>>> 1. Parse the protocol header following the UDP > header 2. > > > >>>> Reserve a > > > >>>>>>> UDP port for each protocol header (i.e one UDP port for > > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > > > >>>> IPv4-in-UDP-over-IPv4 etc.) > > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel > > type message" > > > >>>>>>> 4. Encapsulated protocol header type is > indicated in the > > > >>>> BU message > > > >>>>>>> Pros and cons of these choices are in the slides that > > > >>>> were presented > > > >>>>>>> at IETF68 (see URL above). > > > >>>>>>> > > > >>>>>>> Please provide your opinions and comments by May 15th, > > > >> 07 on the > > > >>>>>>> MIP6 mailing list. > > > >>>>>>> > > > >>>>>>> -Raj > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> _______________________________________________ > > > >>>>>>> Mip6 mailing list > > > >>>>>>> Mip6@ietf.org > > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > >>>>>> > > > >>>> _______________________________________________ > > > >>>> Mip6 mailing list > > > >>>> Mip6@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > >>>> > > > >> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sat Jun 02 22:39:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hug0L-0004kN-4e; Sat, 02 Jun 2007 22:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hug0I-0004jH-GH; Sat, 02 Jun 2007 22:39:38 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hug0I-0000Au-1S; Sat, 02 Jun 2007 22:39:38 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070603023931.HJFZ14178.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Sun, 3 Jun 2007 02:39:31 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 02:39:27 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 12:39:22 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4661EF82.90605@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelZaMZ1GjnMAPeR8CP2YMuCQnO2wAIoR4Q Message-Id: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, Like I said, if you want to go by your interepretation then I'll ask the chairs to reopen the other issues. I won't accept selectivity on where to apply those rules. I'll wait for the chairs/AD's decision on this. Hesham > > We already did that, it's implicit in the question for a > choice between > > keeping things as they are (i.e. it's not an issue that we > need to solve) Vs > > 3 other options (or 2 workable options because option 4 > doesn't work). > > I think here we have a fundamental disagrement. > > If I understand your reasoning right, then you are saying that in a > case when the WG doesn't have consensus on an issue, whatever is > written in a document is going to be the resolution. > > I'm saying that if the working group doesn't have consensus > on an issue, > it doesn't matter what the document says; the document > cannot go forward > with either of the discussed solutions if the WG doesn't have rough > consensus for one of them. > > Maybe you're focussing more on what is going to be changed in the > document right now, rather on closing the issue; while I'm > focussing on > resolving the issue, and the text of the document at the > point when it > can be sent for publication, rather than focussing on what happens to > the document text right now? > > >> I saw several people change position during the > discussion, which is > >> of course the benefit of having a discussion in the first > place -- as > >> various aspects of a question is illuminated, people get a clearer > >> view of the tradeofs, and hopefully align in a rough consensus. > > > > Several people? I saw one. > > And I saw several. Does arguing about this lead anywhere? > > >>> If a 6:5 or 5:4 means no concensus to you, then I'm > >> surprised that you > >>> accepted the same numbers as concensus on other issues, > >> like the mapped > >>> address one or issue 93. Should we repeat all those > >> questions again? > >> > >> If you have counts of those issues that indicate that there was no > >> consensus (and 6:5 or 5:4 isn't even rough consensus as > far as I can > >> tell) then I think that would be the right thing to do. > > > > I agree that 6:5, 5:4 or 4:3 is not a concensus. To me > that means there > > is no concensus to change the draft. Of course the figures > for the mapped > > address were sent to the list, it was 5:4 for the change, > you have those > > figures too. So if we re-open an issue for this reason > then we have to be > > consistent and re-open all issues. > > > > However, my > >> memory of the other discussions isn't that they were as > inconclusive > >> as this one. > > > > You can check Raj's email on the mapped address issue > yourself, it was > > another 5:4. I don't remember the exact number on issue > 93. I assume you're > > not considering that a valid concensus either, we would > agree on that. > > > > Hesham > > > > > > > >> > >> Henrik > >> > >> > >> > > > > > > > > From nemo-bounces@ietf.org Sun Jun 03 01:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huiis-0008HF-4L; Sun, 03 Jun 2007 01:33:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huiiq-0008Gz-3C; Sun, 03 Jun 2007 01:33:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huiip-0006x0-83; Sun, 03 Jun 2007 01:33:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2007 22:33:42 -0700 X-IronPort-AV: i="4.16,377,1175497200"; d="scan'208"; a="158088286:sNHT74196198" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l535XgMa005748; Sat, 2 Jun 2007 22:33:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l535XgaI024812; Sun, 3 Jun 2007 05:33:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 22:33:41 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 22:33:40 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" References: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 22:33:39 -0700 Message-ID: <03d301c7a5a0$bddc4bb0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAAGMOxQ In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 03 Jun 2007 05:33:41.0019 (UTC) FILETIME=[BE58CEB0:01C7A5A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13357; t=1180848822; x=1181712822; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=jNJQLgPTRGT/UU9rID0tre1ZyUs1sqPVxLDvEfzs8Io=; b=Am0+ykkaknRAeX1R/lQfIMnXE2ay/N32/GkQC2FTLCgOpj0sGfBMnsi5PRXQV4jfrJnqeo6E nKvfY13jPgPZwt5Ch2CQ+d1wxsXxCcXK6TQ2Aviwhn3FqEtV0zq7aRc1; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, Fine. Let them speak out. I will just say, there is sufficient interest to close this issue properly. Rest, I will leave it to the chairs and to the authors of this draft to ensure the draft reflects the WG consensus, in the right spirit. Regards Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 7:37 PM > To: 'Sri Gundavelli'; 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6-Consensuscall to close issue 93 > > Sri, > > Pascal's email was not sent in private and we don't need an > interpretation. > He's alive and well and he didn't object to Raj's conclusion. > He clearly > said that we should let the draft move as is. I believe other > people who are > also alive and well can speak for themselves if they were > misrepresented..... > > I look forward to people expressing that they were > misrepresnted by the > chairs. I don't think it's useful for you or Henrik to > recount on their > behalf. > > Hesham > > > I understand the need to complete the DSMIP6 as early as > > possible and I appreciate the Chair's position to close > > this issue soon. I really like to see that as well. I also > > believe, IMO, that there is a proper justification in asking > > for Option#3. Its for a simple TLV header, qualifier in UDP > > for the payload packet. Many reasons, examples, protocol > > conventions including 3519's way of dealing with the exact > > same issue, lack of resaved port numbers, opening multiple > > port numbers if we were to extend it later, and many other > > reasons were mentioned and against the one solid reason of > > extra-4 byte overhead. We don't have turn this to a voting > > machine, if we see the need for this request with certain > > flexibility. > > > > Now, w.r.t the voting, I though Pascal did mention the need > > for a supporting new encapsulation mode and off course he > > also wanted this work to close ASAP and that leaves it in > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > his preference is for Option#4 and his second preference is > > for option#3. He can speak up. And, we missed Alessio Casati's > > preference on this issue, he did support option#3. So with > > Jouni Korhonen, he did state that "I prefer more future proof > > extensibility over slight performance hit thus I prefer the > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > vote in favour of option#3. > > > > If this is not rough consensus, atleast, there is sufficient > > interest to discuss this issue further and proper conclude. > > My 2c. > > > > Regards > > Sri > > > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Saturday, June 02, 2007 4:05 AM > > > To: 'Henrik Levkowetz' > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > on how to > > > > handle the issue. And I don't see any consensus on how to > > > handle the > > > > issue here. > > > > > > => The issue was raised against an existing solution, if > > > there is no support > > > in the WG (6 people against and 5 for it) then clearly there > > > is no agreement > > > that there is an issue to begin with. What are you suggesting > > > we do? If > > > there is no support for the perceived issue then naturally > > > it's rejected. I > > > don't think anyone is changing their mind if we ask the same > > > question again > > > in the space of two weeks... > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > surprised that you > > > accepted the same numbers as concensus on other issues, like > > > the mapped > > > address one or issue 93. Should we repeat all those > > questions again? > > > > > > Hesham > > > > > > > > > > > > > > > Henrik > > > > > > > > > We've always asked for concencus to > > > > > change anything > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > that there is no > > > > > concensus to change the draft. 5:4 is not concensus. > > > > Therefore, I think > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > into a voting > > > > > organisation, if we do then the whole process of providing > > > > a vote would be > > > > > different from what we do today. > > > > > > > > > > Hesham > > > > > > > > > >> -----Original Message----- > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > >> To: Narayanan, Vidya > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; > Basavaraj Patil > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > >> > > > > >> Hi Vidya, Rai, > > > > >> > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > >>> FWIW, I had also supported going with Option 1 > for DS-MIP6. > > > > >> Of course that matters, Vidya, but the more > > important thing here > > > > >> is that it's pretty clear to me that there is *no* > > > rough consensus > > > > >> present. > > > > >> > > > > >> Please don't manufacture one when there isn't one; if there > > > > >> really isn't one, do another call for discussion > and/or show > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > >> > > > > >> I can't accept this pronouncement of a consensus, > > rough or not, > > > > >> in the group, neither from my observation of the > > discussion or > > > > >> from the count. > > > > >> > > > > >> > > > > >> Henrik > > > > >> > > > > >> > > > > >>> Vidya > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > >>>> To: Levkowetz > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > of: DS-MIP6 > > > > >>>> - Consensus call to close issue 93 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Vijay D. - Option 4 originally and then changed to > > Option 2 > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > Option 3 > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > - Option 3 > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > > >>>> Option 1 (Interpreted) > > > > >>>> > > > > >>>> So we have a sort of a tie if you strictly go by count. > > > > >>>> If I were to express my own opinion > > (non-chair-hat), I would > > > > >>>> go with option 1 as well for the current DS-MIP6 > proposal > > > > >>>> (aligned with my earlier email that if and when GRE is > > > > >>>> planned for use, another UDP port can be > > reserved... But for > > > > >>>> now option 1). That would break any deadlock issues. > > > > >>>> > > > > >>>> Or the other way is to let the chairs decide what is the > > > > >>>> sense of the discussion on the ML and from the > > perspective of > > > > >>>> the charter/scope and urgency of this protocol. > > And from this > > > > >>>> angle as well, I would stick by my conclusion, i.e > > option 1. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Hi Raj, > > > > >>>>> > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > > >>>>>> So after an extensive discussion on this topic > > which spun > > > > >>>> off into a > > > > >>>>>> discussion about the need/use for GRE, I would like to > > > > >> summarize > > > > >>>>>> where we are with the options that we have. > > > > >>>>>> > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > > >> Parse the > > > > >>>>>> protocol header following the UDP header" is > good enough. > > > > >>>>> Could you give us an indication of who preferred which > > > > >> option? You > > > > >>>>> seem to be very clear about the outcome, while > it was far > > > > >>>> from obvious > > > > >>>>> to me that the counts turned out to support above > > > conclusion... > > > > >>>>> > > > > >>>>> > > > > >>>>> Henrik > > > > >>>>> > > > > >>>>>> So it implies no changes to the current text in the > > > > >>>> DS-MIP6 I-D w.r.t > > > > >>>>>> this issue are needed. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> It was pointed out that in the future if GRE was > > > > >> determined as a > > > > >>>>>> protocol that needs to be supported as well either for > > > > >>>> MIP6, NEMO or > > > > >>>>>> PMIP6 then it would be specified in the > > appropriate WG and > > > > >>>> a UDP port > > > > >>>>>> reserved for the same. In such a case it would > > > > >> essentially be the > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > >>>>>> > > > > >>>>>> At this time, the need for GRE especially in the scope > > > > >> of DS-MIP6 > > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > > >> we will move > > > > >>>>>> forward with Option 1 and close this issue. > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > >>>> wrote: > > > > >>>>>>> Hello, > > > > >>>>>>> > > > > >>>>>>> The DS-MIP6 I-D > > > > > > >>>> still has > > > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > > > > presented 4 > > > > >>>>>>> options to solve the issue. These are captured in: > > > > >>>>>>> > > > > >>>>>>> > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > >>>>>>> > > > > >>>>>>> We need to make a decision on this issue and > > move forward > > > > >>>> with the > > > > >>>>>>> I-D. At the meeting itself, I got the sense that > > > > >> option 3 was the > > > > >>>>>>> one that had the least impact and easy to implement. > > > > >>>>>>> > > > > >>>>>>> Please consider this email as a consensus call for > > > > >> issue 93. The > > > > >>>>>>> problem and choices are as follows (based on > > > Vijay's slides): > > > > >>>>>>> > > > > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > >>>> traversal. The > > > > >>>>>>> encapculations are either: > > > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > > > >>>>>>> There is a need (or I guess desirable) to indicate > > > > the type of > > > > >>>>>>> protocol being encapsulated in the UDP header. > > > > >>>>>>> > > > > >>>>>>> Choices are: > > > > >>>>>>> 1. Parse the protocol header following the UDP > > header 2. > > > > >>>> Reserve a > > > > >>>>>>> UDP port for each protocol header (i.e one > UDP port for > > > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > > > > >>>> IPv4-in-UDP-over-IPv4 etc.) > > > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel > > > type message" > > > > >>>>>>> 4. Encapsulated protocol header type is > > indicated in the > > > > >>>> BU message > > > > >>>>>>> Pros and cons of these choices are in the slides that > > > > >>>> were presented > > > > >>>>>>> at IETF68 (see URL above). > > > > >>>>>>> > > > > >>>>>>> Please provide your opinions and comments by > May 15th, > > > > >> 07 on the > > > > >>>>>>> MIP6 mailing list. > > > > >>>>>>> > > > > >>>>>>> -Raj > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> _______________________________________________ > > > > >>>>>>> Mip6 mailing list > > > > >>>>>>> Mip6@ietf.org > > > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>>>> > > > > >>>> _______________________________________________ > > > > >>>> Mip6 mailing list > > > > >>>> Mip6@ietf.org > > > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Sun Jun 03 02:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HujiU-0005vh-Qz; Sun, 03 Jun 2007 02:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HujiT-0005vR-BQ; Sun, 03 Jun 2007 02:37:29 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HujiS-0002am-Bm; Sun, 03 Jun 2007 02:37:29 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070603063725.JLNX10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Sun, 3 Jun 2007 06:37:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070603063724.WTKD7229.oaamta02sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 06:37:24 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 16:37:18 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <03d301c7a5a0$bddc4bb0$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAAGMOxQAAJXzCA= Message-Id: <20070603063724.WTKD7229.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org That's fine with me. Hesham > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Sunday, June 03, 2007 3:34 PM > To: 'Hesham Soliman'; 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6-Consensuscall to close issue 93 > > Hesham, > > Fine. Let them speak out. I will just say, there is sufficient > interest to close this issue properly. Rest, I will leave it to > the chairs and to the authors of this draft to ensure the draft > reflects the WG consensus, in the right spirit. > > Regards > Sri > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Saturday, June 02, 2007 7:37 PM > > To: 'Sri Gundavelli'; 'Henrik Levkowetz' > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6-Consensuscall to close issue 93 > > > > Sri, > > > > Pascal's email was not sent in private and we don't need an > > interpretation. > > He's alive and well and he didn't object to Raj's conclusion. > > He clearly > > said that we should let the draft move as is. I believe other > > people who are > > also alive and well can speak for themselves if they were > > misrepresented..... > > > > I look forward to people expressing that they were > > misrepresnted by the > > chairs. I don't think it's useful for you or Henrik to > > recount on their > > behalf. > > > > Hesham > > > > > I understand the need to complete the DSMIP6 as early as > > > possible and I appreciate the Chair's position to close > > > this issue soon. I really like to see that as well. I also > > > believe, IMO, that there is a proper justification in asking > > > for Option#3. Its for a simple TLV header, qualifier in UDP > > > for the payload packet. Many reasons, examples, protocol > > > conventions including 3519's way of dealing with the exact > > > same issue, lack of resaved port numbers, opening multiple > > > port numbers if we were to extend it later, and many other > > > reasons were mentioned and against the one solid reason of > > > extra-4 byte overhead. We don't have turn this to a voting > > > machine, if we see the need for this request with certain > > > flexibility. > > > > > > Now, w.r.t the voting, I though Pascal did mention the need > > > for a supporting new encapsulation mode and off course he > > > also wanted this work to close ASAP and that leaves it in > > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > > his preference is for Option#4 and his second preference is > > > for option#3. He can speak up. And, we missed Alessio Casati's > > > preference on this issue, he did support option#3. So with > > > Jouni Korhonen, he did state that "I prefer more future proof > > > extensibility over slight performance hit thus I prefer the > > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > > vote in favour of option#3. > > > > > > If this is not rough consensus, atleast, there is sufficient > > > interest to discuss this issue further and proper conclude. > > > My 2c. > > > > > > Regards > > > Sri > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > > Sent: Saturday, June 02, 2007 4:05 AM > > > > To: 'Henrik Levkowetz' > > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > > on how to > > > > > handle the issue. And I don't see any consensus on how to > > > > handle the > > > > > issue here. > > > > > > > > => The issue was raised against an existing solution, if > > > > there is no support > > > > in the WG (6 people against and 5 for it) then clearly there > > > > is no agreement > > > > that there is an issue to begin with. What are you suggesting > > > > we do? If > > > > there is no support for the perceived issue then naturally > > > > it's rejected. I > > > > don't think anyone is changing their mind if we ask the same > > > > question again > > > > in the space of two weeks... > > > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > > surprised that you > > > > accepted the same numbers as concensus on other issues, like > > > > the mapped > > > > address one or issue 93. Should we repeat all those > > > questions again? > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > Henrik > > > > > > > > > > > We've always asked for concencus to > > > > > > change anything > > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > > that there is no > > > > > > concensus to change the draft. 5:4 is not concensus. > > > > > Therefore, I think > > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > > into a voting > > > > > > organisation, if we do then the whole process of > providing > > > > > a vote would be > > > > > > different from what we do today. > > > > > > > > > > > > Hesham > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > > >> To: Narayanan, Vidya > > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; > > Basavaraj Patil > > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and > conclusion of: > > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > > >> > > > > > >> Hi Vidya, Rai, > > > > > >> > > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > > >>> FWIW, I had also supported going with Option 1 > > for DS-MIP6. > > > > > >> Of course that matters, Vidya, but the more > > > important thing here > > > > > >> is that it's pretty clear to me that there is *no* > > > > rough consensus > > > > > >> present. > > > > > >> > > > > > >> Please don't manufacture one when there isn't > one; if there > > > > > >> really isn't one, do another call for discussion > > and/or show > > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > > >> > > > > > >> I can't accept this pronouncement of a consensus, > > > rough or not, > > > > > >> in the group, neither from my observation of the > > > discussion or > > > > > >> from the count. > > > > > >> > > > > > >> > > > > > >> Henrik > > > > > >> > > > > > >> > > > > > >>> Vidya > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Basavaraj Patil > [mailto:basavaraj.patil@nsn.com] > > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > > >>>> To: Levkowetz > > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > > of: DS-MIP6 > > > > > >>>> - Consensus call to close issue 93 > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> Vijay D. - Option 4 originally and then changed to > > > Option 2 > > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > > Option 3 > > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > > - Option 3 > > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 > Pascal T. - > > > > > >>>> Option 1 (Interpreted) > > > > > >>>> > > > > > >>>> So we have a sort of a tie if you strictly go > by count. > > > > > >>>> If I were to express my own opinion > > > (non-chair-hat), I would > > > > > >>>> go with option 1 as well for the current DS-MIP6 > > proposal > > > > > >>>> (aligned with my earlier email that if and > when GRE is > > > > > >>>> planned for use, another UDP port can be > > > reserved... But for > > > > > >>>> now option 1). That would break any deadlock issues. > > > > > >>>> > > > > > >>>> Or the other way is to let the chairs decide > what is the > > > > > >>>> sense of the discussion on the ML and from the > > > perspective of > > > > > >>>> the charter/scope and urgency of this protocol. > > > And from this > > > > > >>>> angle as well, I would stick by my conclusion, i.e > > > option 1. > > > > > >>>> > > > > > >>>> -Raj > > > > > >>>> > > > > > >>>> > > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> Hi Raj, > > > > > >>>>> > > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the > following: > > > > > >>>>>> So after an extensive discussion on this topic > > > which spun > > > > > >>>> off into a > > > > > >>>>>> discussion about the need/use for GRE, I > would like to > > > > > >> summarize > > > > > >>>>>> where we are with the options that we have. > > > > > >>>>>> > > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 > which is : " > > > > > >> Parse the > > > > > >>>>>> protocol header following the UDP header" is > > good enough. > > > > > >>>>> Could you give us an indication of who > preferred which > > > > > >> option? You > > > > > >>>>> seem to be very clear about the outcome, while > > it was far > > > > > >>>> from obvious > > > > > >>>>> to me that the counts turned out to support above > > > > conclusion... > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> Henrik > > > > > >>>>> > > > > > >>>>>> So it implies no changes to the current text in the > > > > > >>>> DS-MIP6 I-D w.r.t > > > > > >>>>>> this issue are needed. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> It was pointed out that in the future if GRE was > > > > > >> determined as a > > > > > >>>>>> protocol that needs to be supported as well > either for > > > > > >>>> MIP6, NEMO or > > > > > >>>>>> PMIP6 then it would be specified in the > > > appropriate WG and > > > > > >>>> a UDP port > > > > > >>>>>> reserved for the same. In such a case it would > > > > > >> essentially be the > > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > > >>>>>> > > > > > >>>>>> At this time, the need for GRE especially > in the scope > > > > > >> of DS-MIP6 > > > > > >>>>>> which is primarily MIP6 and NEMO is not > proven. Hence > > > > > >> we will move > > > > > >>>>>> forward with Option 1 and close this issue. > > > > > >>>>>> > > > > > >>>>>> -Raj > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > > >>>> wrote: > > > > > >>>>>>> Hello, > > > > > >>>>>>> > > > > > >>>>>>> The DS-MIP6 I-D > > > > > > > > >>>> still has > > > > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > > > > > presented 4 > > > > > >>>>>>> options to solve the issue. These are captured in: > > > > > >>>>>>> > > > > > >>>>>>> > > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > > >>>>>>> > > > > > >>>>>>> We need to make a decision on this issue and > > > move forward > > > > > >>>> with the > > > > > >>>>>>> I-D. At the meeting itself, I got the sense that > > > > > >> option 3 was the > > > > > >>>>>>> one that had the least impact and easy to > implement. > > > > > >>>>>>> > > > > > >>>>>>> Please consider this email as a consensus call for > > > > > >> issue 93. The > > > > > >>>>>>> problem and choices are as follows (based on > > > > Vijay's slides): > > > > > >>>>>>> > > > > > >>>>>>> Problem: UDP encapsulation is used in > DS-MIP6 for NAT > > > > > >>>> traversal. The > > > > > >>>>>>> encapculations are either: > > > > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > > > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > > > > >>>>>>> There is a need (or I guess desirable) to indicate > > > > > the type of > > > > > >>>>>>> protocol being encapsulated in the UDP header. > > > > > >>>>>>> > > > > > >>>>>>> Choices are: > > > > > >>>>>>> 1. Parse the protocol header following the UDP > > > header 2. > > > > > >>>> Reserve a > > > > > >>>>>>> UDP port for each protocol header (i.e one > > UDP port for > > > > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > > > > > >>>> IPv4-in-UDP-over-IPv4 etc.) > > > > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel > > > > type message" > > > > > >>>>>>> 4. Encapsulated protocol header type is > > > indicated in the > > > > > >>>> BU message > > > > > >>>>>>> Pros and cons of these choices are in the > slides that > > > > > >>>> were presented > > > > > >>>>>>> at IETF68 (see URL above). > > > > > >>>>>>> > > > > > >>>>>>> Please provide your opinions and comments by > > May 15th, > > > > > >> 07 on the > > > > > >>>>>>> MIP6 mailing list. > > > > > >>>>>>> > > > > > >>>>>>> -Raj > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> _______________________________________________ > > > > > >>>>>>> Mip6 mailing list > > > > > >>>>>>> Mip6@ietf.org > > > > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >>>>>> > > > > > >>>> _______________________________________________ > > > > > >>>> Mip6 mailing list > > > > > >>>> Mip6@ietf.org > > > > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >>>> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sun Jun 03 04:48:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hull8-00019B-5X; Sun, 03 Jun 2007 04:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hull6-000190-OS; Sun, 03 Jun 2007 04:48:20 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hull5-0007YV-GR; Sun, 03 Jun 2007 04:48:20 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hull0-00029M-Vp; Sun, 03 Jun 2007 10:48:15 +0200 Message-ID: <4662804D.6010708@levkowetz.com> Date: Sun, 03 Jun 2007 10:48:13 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 References: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, sgundave@cisco.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Sri Gundavelli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, On 2007-06-03 04:37 Hesham Soliman said the following: > Sri, > > Pascal's email was not sent in private and we don't need an interpretation. > He's alive and well and he didn't object to Raj's conclusion. He clearly > said that we should let the draft move as is. I believe other people who are > also alive and well can speak for themselves if they were > misrepresented..... > > I look forward to people expressing that they were misrepresnted by the > chairs. I don't think it's useful for you or Henrik to recount on their > behalf. As you said about Pascal's email, the mails were sent to the list, not in private. If a review of the list shows substantially more expressions of preference than were noticed by the chairs, this seems to me to be a matter which I *do* think it's useful to point out by showing a strawman recount. I don't think you want the chair to misrepresent what people have expressed on the list? Henrik > Hesham > >> I understand the need to complete the DSMIP6 as early as >> possible and I appreciate the Chair's position to close >> this issue soon. I really like to see that as well. I also >> believe, IMO, that there is a proper justification in asking >> for Option#3. Its for a simple TLV header, qualifier in UDP >> for the payload packet. Many reasons, examples, protocol >> conventions including 3519's way of dealing with the exact >> same issue, lack of resaved port numbers, opening multiple >> port numbers if we were to extend it later, and many other >> reasons were mentioned and against the one solid reason of >> extra-4 byte overhead. We don't have turn this to a voting >> machine, if we see the need for this request with certain >> flexibility. >> >> Now, w.r.t the voting, I though Pascal did mention the need >> for a supporting new encapsulation mode and off course he >> also wanted this work to close ASAP and that leaves it in >> a ambiguous vote. And if I interpret Vijay's emails correctly, >> his preference is for Option#4 and his second preference is >> for option#3. He can speak up. And, we missed Alessio Casati's >> preference on this issue, he did support option#3. So with >> Jouni Korhonen, he did state that "I prefer more future proof >> extensibility over slight performance hit thus I prefer the >> 4 bytes header like in 3519". I also interpret Yoshi Tsuda's >> vote in favour of option#3. >> >> If this is not rough consensus, atleast, there is sufficient >> interest to discuss this issue further and proper conclude. >> My 2c. >> >> Regards >> Sri >> >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Saturday, June 02, 2007 4:05 AM >>> To: 'Henrik Levkowetz' >>> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >>> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: >>> DS-MIP6 -Consensuscall to close issue 93 >>> >>> >>> > No, I'm not looking for a vote. I'm looking for consensus >>> on how to >>> > handle the issue. And I don't see any consensus on how to >>> handle the >>> > issue here. >>> >>> => The issue was raised against an existing solution, if >>> there is no support >>> in the WG (6 people against and 5 for it) then clearly there >>> is no agreement >>> that there is an issue to begin with. What are you suggesting >>> we do? If >>> there is no support for the perceived issue then naturally >>> it's rejected. I >>> don't think anyone is changing their mind if we ask the same >>> question again >>> in the space of two weeks... >>> >>> If a 6:5 or 5:4 means no concensus to you, then I'm >> surprised that you >>> accepted the same numbers as concensus on other issues, like >>> the mapped >>> address one or issue 93. Should we repeat all those >> questions again? >>> Hesham >>> >>> > >>> > >>> > Henrik >>> > >>> > > We've always asked for concencus to >>> > > change anything >>> > > in the draft. The numbers that Raj sent clearly indicate >>> > that there is no >>> > > concensus to change the draft. 5:4 is not concensus. >>> > Therefore, I think >>> > > Raj's decision is correct. I hope we don't turn the IETF >>> > into a voting >>> > > organisation, if we do then the whole process of providing >>> > a vote would be >>> > > different from what we do today. >>> > > >>> > > Hesham >>> > > >>> > >> -----Original Message----- >>> > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >>> > >> Sent: Saturday, June 02, 2007 9:28 AM >>> > >> To: Narayanan, Vidya >>> > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >>> > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >>> > >> DS-MIP6 - Consensuscall to close issue 93 >>> > >> >>> > >> Hi Vidya, Rai, >>> > >> >>> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >>> > >> Of course that matters, Vidya, but the more >> important thing here >>> > >> is that it's pretty clear to me that there is *no* >>> rough consensus >>> > >> present. >>> > >> >>> > >> Please don't manufacture one when there isn't one; if there >>> > >> really isn't one, do another call for discussion and/or show >>> > >> of hands, and if the group is deadlocked, use 3929. >>> > >> >>> > >> I can't accept this pronouncement of a consensus, >> rough or not, >>> > >> in the group, neither from my observation of the >> discussion or >>> > >> from the count. >>> > >> >>> > >> >>> > >> Henrik >>> > >> >>> > >> >>> > >>> Vidya >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> > >>>> Sent: Friday, June 01, 2007 2:36 PM >>> > >>>> To: Levkowetz >>> > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>> > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion >> of: DS-MIP6 >>> > >>>> - Consensus call to close issue 93 >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> Vijay D. - Option 4 originally and then changed to >> Option 2 >>> > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - >> Option 3 >>> > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>> > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil >> - Option 3 >>> > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>> > >>>> Option 1 (Interpreted) >>> > >>>> >>> > >>>> So we have a sort of a tie if you strictly go by count. >>> > >>>> If I were to express my own opinion >> (non-chair-hat), I would >>> > >>>> go with option 1 as well for the current DS-MIP6 proposal >>> > >>>> (aligned with my earlier email that if and when GRE is >>> > >>>> planned for use, another UDP port can be >> reserved... But for >>> > >>>> now option 1). That would break any deadlock issues. >>> > >>>> >>> > >>>> Or the other way is to let the chairs decide what is the >>> > >>>> sense of the discussion on the ML and from the >> perspective of >>> > >>>> the charter/scope and urgency of this protocol. >> And from this >>> > >>>> angle as well, I would stick by my conclusion, i.e >> option 1. >>> > >>>> >>> > >>>> -Raj >>> > >>>> >>> > >>>> >>> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>> > >>>> wrote: >>> > >>>> >>> > >>>>> Hi Raj, >>> > >>>>> >>> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> > >>>>>> So after an extensive discussion on this topic >> which spun >>> > >>>> off into a >>> > >>>>>> discussion about the need/use for GRE, I would like to >>> > >> summarize >>> > >>>>>> where we are with the options that we have. >>> > >>>>>> >>> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >>> > >> Parse the >>> > >>>>>> protocol header following the UDP header" is good enough. >>> > >>>>> Could you give us an indication of who preferred which >>> > >> option? You >>> > >>>>> seem to be very clear about the outcome, while it was far >>> > >>>> from obvious >>> > >>>>> to me that the counts turned out to support above >>> conclusion... >>> > >>>>> >>> > >>>>> >>> > >>>>> Henrik >>> > >>>>> >>> > >>>>>> So it implies no changes to the current text in the >>> > >>>> DS-MIP6 I-D w.r.t >>> > >>>>>> this issue are needed. >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> It was pointed out that in the future if GRE was >>> > >> determined as a >>> > >>>>>> protocol that needs to be supported as well either for >>> > >>>> MIP6, NEMO or >>> > >>>>>> PMIP6 then it would be specified in the >> appropriate WG and >>> > >>>> a UDP port >>> > >>>>>> reserved for the same. In such a case it would >>> > >> essentially be the >>> > >>>>>> equivalent of option 2 in the choices list (below). >>> > >>>>>> >>> > >>>>>> At this time, the need for GRE especially in the scope >>> > >> of DS-MIP6 >>> > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >>> > >> we will move >>> > >>>>>> forward with Option 1 and close this issue. >>> > >>>>>> >>> > >>>>>> -Raj >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>> > >>>> wrote: >>> > >>>>>>> Hello, >>> > >>>>>>> >>> > >>>>>>> The DS-MIP6 I-D >> >>> > >>>> still has >>> > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay >>> > presented 4 >>> > >>>>>>> options to solve the issue. These are captured in: >>> > >>>>>>> >>> > >>>>>>> >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>> > >>>>>>> >>> > >>>>>>> We need to make a decision on this issue and >> move forward >>> > >>>> with the >>> > >>>>>>> I-D. At the meeting itself, I got the sense that >>> > >> option 3 was the >>> > >>>>>>> one that had the least impact and easy to implement. >>> > >>>>>>> >>> > >>>>>>> Please consider this email as a consensus call for >>> > >> issue 93. The >>> > >>>>>>> problem and choices are as follows (based on >>> Vijay's slides): >>> > >>>>>>> >>> > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >>> > >>>> traversal. The >>> > >>>>>>> encapculations are either: >>> > >>>>>>> - IPv6-in-UDP-over-IPv4 >>> > >>>>>>> - IPv4-in-UDP-over-IPv4 >>> > >>>>>>> There is a need (or I guess desirable) to indicate >>> > the type of >>> > >>>>>>> protocol being encapsulated in the UDP header. >>> > >>>>>>> >>> > >>>>>>> Choices are: >>> > >>>>>>> 1. Parse the protocol header following the UDP >> header 2. >>> > >>>> Reserve a >>> > >>>>>>> UDP port for each protocol header (i.e one UDP port for >>> > >>>>>>> IPv6-in-UDP-over-IPv4 and another for >>> > >>>> IPv4-in-UDP-over-IPv4 etc.) >>> > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel >>> type message" >>> > >>>>>>> 4. Encapsulated protocol header type is >> indicated in the >>> > >>>> BU message >>> > >>>>>>> Pros and cons of these choices are in the slides that >>> > >>>> were presented >>> > >>>>>>> at IETF68 (see URL above). >>> > >>>>>>> >>> > >>>>>>> Please provide your opinions and comments by May 15th, >>> > >> 07 on the >>> > >>>>>>> MIP6 mailing list. >>> > >>>>>>> >>> > >>>>>>> -Raj >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> _______________________________________________ >>> > >>>>>>> Mip6 mailing list >>> > >>>>>>> Mip6@ietf.org >>> > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> > >>>>>> >>> > >>>> _______________________________________________ >>> > >>>> Mip6 mailing list >>> > >>>> Mip6@ietf.org >>> > >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> > >>>> >>> > >> >>> > > >>> > > >>> > > >>> > >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sun Jun 03 04:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hulov-0003cp-Oe; Sun, 03 Jun 2007 04:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hulou-0003cc-Ph; Sun, 03 Jun 2007 04:52:16 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hulou-0007uQ-A7; Sun, 03 Jun 2007 04:52:16 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hulos-0002T1-JV; Sun, 03 Jun 2007 10:52:14 +0200 Message-ID: <4662813D.4070301@levkowetz.com> Date: Sun, 03 Jun 2007 10:52:13 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, On 2007-06-03 04:39 Hesham Soliman said the following: > Henrik, > > Like I said, if you want to go by your interepretation then I'll ask the > chairs to reopen the other issues. I won't accept selectivity on where to > apply those rules. Certainly. But we should also have indications of preference which reasonably well match what has been sent to the list. With the mis-tally of people's expressed preference in the latest case, the first thing to do would maybe be to go over the list material in the other cases, and see if maybe the list showed a consensus even if the chair's tally didn't show one? Henrik > I'll wait for the chairs/AD's decision on this. > > Hesham > >>> We already did that, it's implicit in the question for a >> choice between >>> keeping things as they are (i.e. it's not an issue that we >> need to solve) Vs >>> 3 other options (or 2 workable options because option 4 >> doesn't work). >> >> I think here we have a fundamental disagrement. >> >> If I understand your reasoning right, then you are saying that in a >> case when the WG doesn't have consensus on an issue, whatever is >> written in a document is going to be the resolution. >> >> I'm saying that if the working group doesn't have consensus >> on an issue, >> it doesn't matter what the document says; the document >> cannot go forward >> with either of the discussed solutions if the WG doesn't have rough >> consensus for one of them. >> >> Maybe you're focussing more on what is going to be changed in the >> document right now, rather on closing the issue; while I'm >> focussing on >> resolving the issue, and the text of the document at the >> point when it >> can be sent for publication, rather than focussing on what happens to >> the document text right now? >> >>>> I saw several people change position during the >> discussion, which is >>>> of course the benefit of having a discussion in the first >> place -- as >>>> various aspects of a question is illuminated, people get a clearer >>>> view of the tradeofs, and hopefully align in a rough consensus. >>> Several people? I saw one. >> And I saw several. Does arguing about this lead anywhere? >> >>>>> If a 6:5 or 5:4 means no concensus to you, then I'm >>>> surprised that you >>>>> accepted the same numbers as concensus on other issues, >>>> like the mapped >>>>> address one or issue 93. Should we repeat all those >>>> questions again? >>>> >>>> If you have counts of those issues that indicate that there was no >>>> consensus (and 6:5 or 5:4 isn't even rough consensus as >> far as I can >>>> tell) then I think that would be the right thing to do. >>> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me >> that means there >>> is no concensus to change the draft. Of course the figures >> for the mapped >>> address were sent to the list, it was 5:4 for the change, >> you have those >>> figures too. So if we re-open an issue for this reason >> then we have to be >>> consistent and re-open all issues. >>> >>> However, my >>>> memory of the other discussions isn't that they were as >> inconclusive >>>> as this one. >>> You can check Raj's email on the mapped address issue >> yourself, it was >>> another 5:4. I don't remember the exact number on issue >> 93. I assume you're >>> not considering that a valid concensus either, we would >> agree on that. >>> Hesham >>> >>> >>> >>>> Henrik >>>> >>>> >>>> >>> >>> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Sun Jun 03 05:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumSc-0000DT-T9; Sun, 03 Jun 2007 05:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumSa-0000D1-MH; Sun, 03 Jun 2007 05:33:16 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HumSZ-0006HF-80; Sun, 03 Jun 2007 05:33:16 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070603093312.RUDZ14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Sun, 3 Jun 2007 09:33:12 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070603093311.TXWH28187.oaamta06sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 09:33:11 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 19:33:07 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4662804D.6010708@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acelu/AolsNYhhfvQaSiQvxKe5aVagABdvjw Message-Id: <20070603093311.TXWH28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Sri Gundavelli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > > Pascal's email was not sent in private and we don't need > an interpretation. > > He's alive and well and he didn't object to Raj's > conclusion. He clearly > > said that we should let the draft move as is. I believe > other people who are > > also alive and well can speak for themselves if they were > > misrepresented..... > > > > I look forward to people expressing that they were > misrepresnted by the > > chairs. I don't think it's useful for you or Henrik to > recount on their > > behalf. > > As you said about Pascal's email, the mails were sent to the list, > not in private. If a review of the list shows substantially more > expressions of preference than were noticed by the chairs, this > seems to me to be a matter which I *do* think it's useful to point > out by showing a strawman recount. I don't think you want the chair > to misrepresent what people have expressed on the list? => No of course I don't want that, hence my statement above. But these people are on the list and they know whether they were misrepresented or not. For the last few weeks (and since Raj sent his last email a couple of days ago) no one seemed to complain, so let them speak for themselves. Hesham From nemo-bounces@ietf.org Sun Jun 03 05:46:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumfO-00022W-Bu; Sun, 03 Jun 2007 05:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumfM-000203-0f; Sun, 03 Jun 2007 05:46:28 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HumfL-00081V-7Z; Sun, 03 Jun 2007 05:46:27 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070603094620.QIID28583.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Sun, 3 Jun 2007 09:46:20 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 09:46:20 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 19:46:15 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4662813D.4070301@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelvH1r/tKr49MiROSAHTzsPD3LRAABc3jw Message-Id: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > Like I said, if you want to go by your interepretation > then I'll ask the > > chairs to reopen the other issues. I won't accept > selectivity on where to > > apply those rules. > > Certainly. > > But we should also have indications of preference which > reasonably well > match what has been sent to the list. With the mis-tally of people's > expressed preference in the latest case, the first thing to do would > maybe be to go over the list material in the other cases, and see if > maybe the list showed a consensus even if the chair's tally didn't > show one? => I'm not sure what you mean by "going over the list material in the other cases" but I'm more than happy for the chair or AD to review the concensus threads for all those issues and include known opionions from the DT people. Actually, some people were counted despite not sending a peep about the issue to the list (not only during the concensus call but in general). So, yes a review is fine with me as long as we're consistent; regardless of the outcome. I was ok with things as is because at least it was consistent. The question is whether we want to keep delaying things to do this or just go with the decisions that were already made. Personally, I prefer less delays and going with the decisions already made (and you know too well that I didn't agree with some of the outcomes), but if you're objecting to the way all these decisions are made and the chairs grant a review of all those issues then I'm fine with that too. As I said earlier, the only thing that doesn't make sense is to change the rules for one issue. Hesham > > > Henrik > > > I'll wait for the chairs/AD's decision on this. > > > > Hesham > > > >>> We already did that, it's implicit in the question for a > >> choice between > >>> keeping things as they are (i.e. it's not an issue that we > >> need to solve) Vs > >>> 3 other options (or 2 workable options because option 4 > >> doesn't work). > >> > >> I think here we have a fundamental disagrement. > >> > >> If I understand your reasoning right, then you are saying > that in a > >> case when the WG doesn't have consensus on an issue, whatever is > >> written in a document is going to be the resolution. > >> > >> I'm saying that if the working group doesn't have consensus > >> on an issue, > >> it doesn't matter what the document says; the document > >> cannot go forward > >> with either of the discussed solutions if the WG doesn't > have rough > >> consensus for one of them. > >> > >> Maybe you're focussing more on what is going to be changed in the > >> document right now, rather on closing the issue; while I'm > >> focussing on > >> resolving the issue, and the text of the document at the > >> point when it > >> can be sent for publication, rather than focussing on > what happens to > >> the document text right now? > >> > >>>> I saw several people change position during the > >> discussion, which is > >>>> of course the benefit of having a discussion in the first > >> place -- as > >>>> various aspects of a question is illuminated, people > get a clearer > >>>> view of the tradeofs, and hopefully align in a rough consensus. > >>> Several people? I saw one. > >> And I saw several. Does arguing about this lead anywhere? > >> > >>>>> If a 6:5 or 5:4 means no concensus to you, then I'm > >>>> surprised that you > >>>>> accepted the same numbers as concensus on other issues, > >>>> like the mapped > >>>>> address one or issue 93. Should we repeat all those > >>>> questions again? > >>>> > >>>> If you have counts of those issues that indicate that > there was no > >>>> consensus (and 6:5 or 5:4 isn't even rough consensus as > >> far as I can > >>>> tell) then I think that would be the right thing to do. > >>> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me > >> that means there > >>> is no concensus to change the draft. Of course the figures > >> for the mapped > >>> address were sent to the list, it was 5:4 for the change, > >> you have those > >>> figures too. So if we re-open an issue for this reason > >> then we have to be > >>> consistent and re-open all issues. > >>> > >>> However, my > >>>> memory of the other discussions isn't that they were as > >> inconclusive > >>>> as this one. > >>> You can check Raj's email on the mapped address issue > >> yourself, it was > >>> another 5:4. I don't remember the exact number on issue > >> 93. I assume you're > >>> not considering that a valid concensus either, we would > >> agree on that. > >>> Hesham > >>> > >>> > >>> > >>>> Henrik > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > From nemo-bounces@ietf.org Sun Jun 03 11:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusQs-0006Ep-Sc; Sun, 03 Jun 2007 11:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusQr-0006Eh-70; Sun, 03 Jun 2007 11:55:53 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HusQp-0007Io-Ic; Sun, 03 Jun 2007 11:55:53 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HusQh-0000rw-C4; Sun, 03 Jun 2007 17:55:43 +0200 Message-ID: <4662E47D.4000509@levkowetz.com> Date: Sun, 03 Jun 2007 17:55:41 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, On 2007-06-03 11:46 Hesham Soliman said the following: > >>> Like I said, if you want to go by your interepretation >> then I'll ask the >>> chairs to reopen the other issues. I won't accept >> selectivity on where to >>> apply those rules. >> Certainly. >> >> But we should also have indications of preference which >> reasonably well >> match what has been sent to the list. With the mis-tally of people's >> expressed preference in the latest case, the first thing to do would >> maybe be to go over the list material in the other cases, and see if >> maybe the list showed a consensus even if the chair's tally didn't >> show one? > > I'm not sure what you mean by "going over the list material in the other > cases" but I'm more than happy for the chair or AD to review the concensus > threads for all those issues and include known opionions from the DT people. Right. > Actually, some people were counted despite not sending a peep about the > issue to the list (not only during the concensus call but in general). So, > yes a review is fine with me as long as we're consistent; regardless of the > outcome. I was ok with things as is because at least it was consistent. The > question is whether we want to keep delaying things to do this or just go > with the decisions that were already made. I don't particularly want to delay things, but swiftly producing a document which doesn't reflect the lists viewpoint on how the issues should be resolved doesn't seem like a good idea either -- in the worst case, it would lead to a requirement to do a -bis document immediately, which I would see as a rather larger delay... > Personally, I prefer less delays and going with the decisions already made > (and you know too well that I didn't agree with some of the outcomes), but > if you're objecting to the way all these decisions are made and the chairs > grant a review of all those issues then I'm fine with that too. As I said > earlier, the only thing that doesn't make sense is to change the rules for > one issue. I agree with this. Henrik From nemo-bounces@ietf.org Sun Jun 03 14:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huv2H-0002ou-II; Sun, 03 Jun 2007 14:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huv2G-0002op-Fw for nemo@ietf.org; Sun, 03 Jun 2007 14:42:40 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huv2E-0003SU-1H for nemo@ietf.org; Sun, 03 Jun 2007 14:42:40 -0400 Received: from [192.168.1.133] (unknown [87.218.127.87])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id A916E41EDB; Sun, 3 Jun 2007 20:42:36 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Sun, 03 Jun 2007 20:42:32 +0200 Message-Id: <1180896152.4812.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-9.9802 TC:1F TRN:50 TV:3.6.1039(15212.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF NEMO WG , MPI@multicasttech.com Subject: [nemo] Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Wesley, I've read your draft and I've found it very interesting and clear. I'm talking from the perspective of a person working on NEMO RO mechanisms, and sometimes I find myself not knowing which are the most important metrics/requirements of a practical NEMO RO solution to be deployed in real scenarios. Thanks for the draft! After the reading, I have some comments/questions: - There are some requirements, such as Req2 (multihoming) that seem to me more related to the general NEMO solution required for aeronautical environments than to a NEMO RO particular solution. I agree that a NEMO RO solution should work when multiple MRs/HAs are used, but IMHO the multihoming support itself should be provided by multihoming mechanisms, rather than by the NEMO RO solution (although the RO mechanism should be compatible to these solutions). I think it would be useful to clarify that in the text. - I miss one requirement saying that the NEMO RO solution must be secure. Req8 says that IPsec must be usable, but I think that's a different issue (e.g., a particular NEMO RO solution must allow IPsec to be used while enabling new attacks). Therefore, I'd add a requirement specifically stating that the NEMO RO solution must be secure, and I'd describe to which kind of attacks it should be secure and which are the assumptions about the existing infrastructure (something similar to what is said in RFC 4225). - I also miss a requirement about which are the types of MNNs that should be supported by the NEMO RO solution. From the reading of the draft, it seems to me that all kinds of MNNs should be supported (i.e., LFNs, LMNs and VMNs). This requirement is important, because many solutions proposed so far only deal with the optimisation of certain MNNs/configurations (e.g., nested networks, VMNs, etc). Kind Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From nemo-bounces@ietf.org Mon Jun 04 04:11:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7f6-0004pP-Qj; Mon, 04 Jun 2007 04:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7f5-0004oy-AG; Mon, 04 Jun 2007 04:11:35 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv7ew-0003LO-U1; Mon, 04 Jun 2007 04:11:35 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l548BCd9032495; Mon, 4 Jun 2007 11:11:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 11:11:05 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 11:11:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call toclose issue 93 Date: Mon, 4 Jun 2007 11:11:04 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D059F8A78@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call toclose issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAB6oiUw References: <46608721.1030902@levkowetz.com> From: To: , X-OriginalArrivalTime: 04 Jun 2007 08:11:05.0066 (UTC) FILETIME=[E5D9C4A0:01C7A67F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, Just to clarify my position on this issue, my preference was option 1 for now but reserve option 2 for extending the protocol to support e.g. GRE later if seen necessary. Cheers, Markku=20 >-----Original Message----- >From: ext Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 >Sent: 02 June, 2007 00:36 >To: Levkowetz >Cc: nemo@ietf.org; Mobile IPv6 Mailing List >Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 -=20 >Consensus call toclose issue 93 > > > >Vijay D. - Option 4 originally and then changed to Option 2=20 >Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 >Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 >(Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 >Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 >Option 1 (Interpreted) > >So we have a sort of a tie if you strictly go by count. >If I were to express my own opinion (non-chair-hat), I would=20 >go with option 1 as well for the current DS-MIP6 proposal=20 >(aligned with my earlier email that if and when GRE is planned=20 >for use, another UDP port can be reserved... But for now=20 >option 1). That would break any deadlock issues. > >Or the other way is to let the chairs decide what is the sense=20 >of the discussion on the ML and from the perspective of the=20 >charter/scope and urgency of this protocol. And from this=20 >angle as well, I would stick by my conclusion, i.e option 1. > >-Raj > > >On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >>=20 >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun=20 >off into a=20 >>> discussion about the need/use for GRE, I would like to summarize=20 >>> where we are with the options that we have. >>>=20 >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 >>> protocol header following the UDP header" is good enough. >>=20 >> Could you give us an indication of who preferred which option? You=20 >> seem to be very clear about the outcome, while it was far=20 >from obvious=20 >> to me that the counts turned out to support above conclusion... >>=20 >>=20 >> Henrik >>=20 >>> So it implies no changes to the current text in the DS-MIP6=20 >I-D w.r.t=20 >>> this issue are needed. >>>=20 >>>=20 >>> It was pointed out that in the future if GRE was determined as a=20 >>> protocol that needs to be supported as well either for=20 >MIP6, NEMO or=20 >>> PMIP6 then it would be specified in the appropriate WG and=20 >a UDP port=20 >>> reserved for the same. In such a case it would essentially be the=20 >>> equivalent of option 2 in the choices list (below). >>>=20 >>> At this time, the need for GRE especially in the scope of DS-MIP6=20 >>> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 >>> forward with Option 1 and close this issue. >>>=20 >>> -Raj >>>=20 >>>=20 >>>=20 >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: >>>=20 >>>> Hello, >>>>=20 >>>> The DS-MIP6 I-D =20 >still has=20 >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 >>>> options to solve the issue. These are captured in: >>>>=20 >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>>=20 >>>> We need to make a decision on this issue and move forward with the=20 >>>> I-D. At the meeting itself, I got the sense that option 3 was the=20 >>>> one that had the least impact and easy to implement. >>>>=20 >>>> Please consider this email as a consensus call for issue 93. The=20 >>>> problem and choices are as follows (based on Vijay's slides): >>>>=20 >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 >traversal. The=20 >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of=20 >>>> protocol being encapsulated in the UDP header. >>>>=20 >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header 2. Reserve a=20 >>>> UDP port for each protocol header (i.e one UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for=20 >IPv4-in-UDP-over-IPv4 etc.)=20 >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>>=20 >>>> Pros and cons of these choices are in the slides that were=20 >presented=20 >>>> at IETF68 (see URL above). >>>>=20 >>>> Please provide your opinions and comments by May 15th, 07 on the=20 >>>> MIP6 mailing list. >>>>=20 >>>> -Raj >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>=20 >>>=20 >>>=20 > > > From nemo-bounces@ietf.org Mon Jun 04 16:59:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJe9-0002XB-G5; Mon, 04 Jun 2007 16:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJe8-0002X3-Bv; Mon, 04 Jun 2007 16:59:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJe7-0006v2-Or; Mon, 04 Jun 2007 16:59:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Mon, 4 Jun 2007 13:59:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 thread-index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAHlQ1DA= References: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, =20 > =3D> The issue was raised against an existing solution, if=20 > there is no support > in the WG (6 people against and 5 for it) then clearly there=20 > is no agreement > that there is an issue to begin with. What are you suggesting=20 > we do?=20 I disagree with this. It is an open issue. Just because it is already there in the draft does not mean it gets to stay in the draft. 6:5 means we don't have a good way forward. It does not mean that there is no issue and the existing solution should stay in the draft. Vijay If > there is no support for the perceived issue then naturally=20 > it's rejected. I > don't think anyone is changing their mind if we ask the same=20 > question again > in the space of two weeks... >=20 > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like=20 > the mapped > address one or issue 93. Should we repeat all those questions again?=20 >=20 > Hesham >=20 > >=20 > >=20 > > Henrik > >=20 > > > We've always asked for concencus to > > > change anything=20 > > > in the draft. The numbers that Raj sent clearly indicate=20 > > that there is no > > > concensus to change the draft. 5:4 is not concensus.=20 > > Therefore, I think > > > Raj's decision is correct. I hope we don't turn the IETF=20 > > into a voting > > > organisation, if we do then the whole process of providing=20 > > a vote would be > > > different from what we do today.=20 > > >=20 > > > Hesham=20 > > >=20 > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > > >> Sent: Saturday, June 02, 2007 9:28 AM > > >> To: Narayanan, Vidya > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of:=20 > > >> DS-MIP6 - Consensuscall to close issue 93 > > >> > > >> Hi Vidya, Rai, > > >> > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6.=20 > > >> Of course that matters, Vidya, but the more important thing here > > >> is that it's pretty clear to me that there is *no*=20 > rough consensus > > >> present. > > >> > > >> Please don't manufacture one when there isn't one; if there > > >> really isn't one, do another call for discussion and/or show > > >> of hands, and if the group is deadlocked, use 3929. > > >> > > >> I can't accept this pronouncement of a consensus, rough or not, > > >> in the group, neither from my observation of the discussion or > > >> from the count. > > >> > > >> > > >> Henrik > > >> > > >> > > >>> Vidya=20 > > >>> > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > >>>> To: Levkowetz > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > > >>>> - Consensus call to close issue 93 > > >>>> > > >>>> > > >>>> > > >>>> Vijay D. - Option 4 originally and then changed to Option 2=20 > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > > >>>> Option 1 (Interpreted) > > >>>> > > >>>> So we have a sort of a tie if you strictly go by count. > > >>>> If I were to express my own opinion (non-chair-hat), I would=20 > > >>>> go with option 1 as well for the current DS-MIP6 proposal=20 > > >>>> (aligned with my earlier email that if and when GRE is=20 > > >>>> planned for use, another UDP port can be reserved... But for=20 > > >>>> now option 1). That would break any deadlock issues. > > >>>> > > >>>> Or the other way is to let the chairs decide what is the=20 > > >>>> sense of the discussion on the ML and from the perspective of=20 > > >>>> the charter/scope and urgency of this protocol. And from this=20 > > >>>> angle as well, I would stick by my conclusion, i.e option 1. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > > >>>> wrote: > > >>>> > > >>>>> Hi Raj, > > >>>>> > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>>>> So after an extensive discussion on this topic which spun=20 > > >>>> off into a=20 > > >>>>>> discussion about the need/use for GRE, I would like to=20 > > >> summarize=20 > > >>>>>> where we are with the options that we have. > > >>>>>> > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : "=20 > > >> Parse the=20 > > >>>>>> protocol header following the UDP header" is good enough. > > >>>>> Could you give us an indication of who preferred which=20 > > >> option? You=20 > > >>>>> seem to be very clear about the outcome, while it was far=20 > > >>>> from obvious=20 > > >>>>> to me that the counts turned out to support above=20 > conclusion... > > >>>>> > > >>>>> > > >>>>> Henrik > > >>>>> > > >>>>>> So it implies no changes to the current text in the=20 > > >>>> DS-MIP6 I-D w.r.t=20 > > >>>>>> this issue are needed. > > >>>>>> > > >>>>>> > > >>>>>> It was pointed out that in the future if GRE was=20 > > >> determined as a=20 > > >>>>>> protocol that needs to be supported as well either for=20 > > >>>> MIP6, NEMO or=20 > > >>>>>> PMIP6 then it would be specified in the appropriate WG and=20 > > >>>> a UDP port=20 > > >>>>>> reserved for the same. In such a case it would=20 > > >> essentially be the=20 > > >>>>>> equivalent of option 2 in the choices list (below). > > >>>>>> > > >>>>>> At this time, the need for GRE especially in the scope=20 > > >> of DS-MIP6=20 > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence=20 > > >> we will move=20 > > >>>>>> forward with Option 1 and close this issue. > > >>>>>> > > >>>>>> -Raj > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > > >>>> wrote: > > >>>>>>> Hello, > > >>>>>>> > > >>>>>>> The DS-MIP6 I-D =20 > > >>>> still has=20 > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay=20 > > presented 4=20 > > >>>>>>> options to solve the issue. These are captured in: > > >>>>>>> > > >>>>>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >>>>>>> > > >>>>>>> We need to make a decision on this issue and move forward=20 > > >>>> with the=20 > > >>>>>>> I-D. At the meeting itself, I got the sense that=20 > > >> option 3 was the=20 > > >>>>>>> one that had the least impact and easy to implement. > > >>>>>>> > > >>>>>>> Please consider this email as a consensus call for=20 > > >> issue 93. The=20 > > >>>>>>> problem and choices are as follows (based on=20 > Vijay's slides): > > >>>>>>> > > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > > >>>> traversal. The=20 > > >>>>>>> encapculations are either: > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > >>>>>>> There is a need (or I guess desirable) to indicate=20 > > the type of=20 > > >>>>>>> protocol being encapsulated in the UDP header. > > >>>>>>> > > >>>>>>> Choices are: > > >>>>>>> 1. Parse the protocol header following the UDP header 2.=20 > > >>>> Reserve a=20 > > >>>>>>> UDP port for each protocol header (i.e one UDP port for > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for=20 > > >>>> IPv4-in-UDP-over-IPv4 etc.)=20 > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel=20 > type message" > > >>>>>>> 4. Encapsulated protocol header type is indicated in the=20 > > >>>> BU message > > >>>>>>> Pros and cons of these choices are in the slides that=20 > > >>>> were presented=20 > > >>>>>>> at IETF68 (see URL above). > > >>>>>>> > > >>>>>>> Please provide your opinions and comments by May 15th,=20 > > >> 07 on the=20 > > >>>>>>> MIP6 mailing list. > > >>>>>>> > > >>>>>>> -Raj > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> Mip6 mailing list > > >>>>>>> Mip6@ietf.org > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>> > > >>>> _______________________________________________ > > >>>> Mip6 mailing list > > >>>> Mip6@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >> > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Mon Jun 04 17:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJju-0007wh-Ps; Mon, 04 Jun 2007 17:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjs-0007qa-Rj; Mon, 04 Jun 2007 17:05:20 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJjs-0007gl-Fp; Mon, 04 Jun 2007 17:05:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2007 14:05:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QA= References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Raj, This is fine with me. But today we already have option 2. One reserved UDP port for IPv4/v6 and another for ESP encapsulation of DS-MIPv6 tunneled packets.=20 Vijay > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 12:47 PM > To: ext Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] Summary and conclusion of: DS-MIP6 -=20 > Consensus call to close issue 93 >=20 >=20 > So after an extensive discussion on this topic which spun off into a > discussion about the need/use for GRE, I would like to=20 > summarize where we > are with the options that we have. >=20 > Conclusion was that for DS-MIP6, Option 1 which is : " Parse=20 > the protocol > header following the UDP header" is good enough. >=20 > So it implies no changes to the current text in the DS-MIP6=20 > I-D w.r.t this > issue are needed. >=20 >=20 > It was pointed out that in the future if GRE was determined=20 > as a protocol > that needs to be supported as well either for MIP6, NEMO or=20 > PMIP6 then it > would be specified in the appropriate WG and a UDP port=20 > reserved for the > same. In such a case it would essentially be the equivalent=20 > of option 2 in > the choices list (below). >=20 > At this time, the need for GRE especially in the scope of=20 > DS-MIP6 which is > primarily MIP6 and NEMO is not proven. Hence we will move forward with > Option 1 and close this issue. >=20 > -Raj >=20 >=20 >=20 > On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: >=20 > >=20 > > Hello, > >=20 > > The DS-MIP6 I-D still has > > issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options > > to solve the issue. These are captured in: > >=20 > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >=20 > > We need to make a decision on this issue and move forward with the > > I-D. At the meeting itself, I got the sense that option 3=20 > was the one > > that had the least impact and easy to implement. > >=20 > > Please consider this email as a consensus call for issue 93. The > > problem and choices are as follows (based on Vijay's slides): > >=20 > > Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The > > encapculations are either: > > - IPv6-in-UDP-over-IPv4 > > - IPv4-in-UDP-over-IPv4 > > There is a need (or I guess desirable) to indicate the type of > > protocol being encapsulated in the UDP header. > >=20 > > Choices are: > > 1. Parse the protocol header following the UDP header > > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > 4. Encapsulated protocol header type is indicated in the BU message > >=20 > > Pros and cons of these choices are in the slides that were presented > > at IETF68 (see URL above). > >=20 > > Please provide your opinions and comments by May 15th, 07=20 > on the MIP6 > > mailing list. > >=20 > > -Raj > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Tue Jun 05 11:32:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb0z-0002Du-OZ; Tue, 05 Jun 2007 11:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb0y-0002Dp-FL for nemo@ietf.org; Tue, 05 Jun 2007 11:32:08 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvb0w-0003tt-RJ for nemo@ietf.org; Tue, 05 Jun 2007 11:32:08 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 73260C283 for ; Tue, 5 Jun 2007 11:31:59 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l55FVwV7003512; Tue, 5 Jun 2007 11:31:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l55FVwE4014276; Tue, 5 Jun 2007 11:31:58 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id P-7par5FTbz4; Tue, 5 Jun 2007 11:31:57 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l55FVtsl014262;Tue, 5 Jun 2007 11:31:55 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 457224FE4C; Tue, 5 Jun 2007 11:30:16 -0400 (EDT) Date: Tue, 5 Jun 2007 11:30:16 -0400 From: Wesley Eddy To: Carlos =?iso-8859-1?Q?Jes=FAs?= Bernardos Cano Message-ID: <20070605153016.GA441@grc.nasa.gov> References: <1180896152.4812.18.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1180896152.4812.18.camel@localhost> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF NEMO WG , MPI@multicasttech.com Subject: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Sun, Jun 03, 2007 at 08:42:32PM +0200, Carlos Jes=FAs Bernardos Cano w= rote: >=20 > I've read your draft and I've found it very interesting and clear. I'm > talking from the perspective of a person working on NEMO RO mechanisms, > and sometimes I find myself not knowing which are the most important > metrics/requirements of a practical NEMO RO solution to be deployed in > real scenarios. Thanks for the draft! Excellent, I'm glad it is helpful. =20 =20 > - There are some requirements, such as Req2 (multihoming) that seem to > me more related to the general NEMO solution required for aeronautical > environments than to a NEMO RO particular solution. I agree that a NEMO > RO solution should work when multiple MRs/HAs are used, but IMHO the > multihoming support itself should be provided by multihoming mechanisms= , > rather than by the NEMO RO solution (although the RO mechanism should b= e > compatible to these solutions). I think it would be useful to clarify > that in the text. Yes, I think you're right. The text should be more clear here in saying that providing multihoming is not itself a requirement, but "MUST NOT preclude multihoming" *is* a requirement. We'll try to fix this. =20 > - I miss one requirement saying that the NEMO RO solution must be > secure. Req8 says that IPsec must be usable, but I think that's a > different issue (e.g., a particular NEMO RO solution must allow IPsec t= o > be used while enabling new attacks). Therefore, I'd add a requirement > specifically stating that the NEMO RO solution must be secure, and I'd > describe to which kind of attacks it should be secure and which are the > assumptions about the existing infrastructure (something similar to wha= t > is said in RFC 4225). I'm not quite sure about this "must be secure" is rather vague and could be too loose in that it permits sort-of homebrew schemes that look secure at first, but after a few years turn out to not be. I prefer to require the securability to be vai IPsec, since it is well understood and maintained by the IETF, whereas other ways to "secure" RO schemes may not be. > - I also miss a requirement about which are the types of MNNs that > should be supported by the NEMO RO solution. From the reading of the > draft, it seems to me that all kinds of MNNs should be supported (i.e., > LFNs, LMNs and VMNs). This requirement is important, because many > solutions proposed so far only deal with the optimisation of certain > MNNs/configurations (e.g., nested networks, VMNs, etc). At least LFNs and LMNs MUST be supported by the RO solution in our case, and it would be very desirable for deployment purposes to support VMNs as well (SHOULD?). --=20 Wesley M. Eddy Verizon Federal Network Systems From nemo-bounces@ietf.org Tue Jun 05 11:58:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbQG-0004Yv-Ly; Tue, 05 Jun 2007 11:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbQF-0004Yk-RN; Tue, 05 Jun 2007 11:58:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbQE-0002WE-Ps; Tue, 05 Jun 2007 11:58:15 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Jun 2007 17:58:13 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l55FwDG4012385; Tue, 5 Jun 2007 17:58:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l55Fw9DR023805; Tue, 5 Jun 2007 15:58:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:58:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Tue, 5 Jun 2007 17:58:05 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC040D0263@xmb-ams-337.emea.cisco.com> In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAB/8CMA References: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> From: "Pascal Thubert \(pthubert\)" To: "Hesham Soliman" , "Sri Gundavelli \(sgundave\)" , "Henrik Levkowetz" X-OriginalArrivalTime: 05 Jun 2007 15:58:09.0895 (UTC) FILETIME=[505D0F70:01C7A78A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13748; t=1181059093; x=1181923093; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=9X+5z4K2vNbPUv+N2nNEhPD5p+Ak6x8x/DuahHJHeG0=; b=fd0KzWcIdPwvjViPlmirPww8OqZywx9v4JimoTt2Ep2V8R4Z0l1Z8GSF50vXqUBag+rnQyOQ XrEIerN76WWoWw47U3+O2n0d5c7ZpgYE/XGVg4E5zUO/EPewwYeJOlvP; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > >Pascal's email was not sent in private and we don't need an interpretation. >He's alive and well and he didn't object to Raj's conclusion. He clearly >said that we should let the draft move as is. I believe other people who are >also alive and well can speak for themselves if they were >misrepresented..... [Pascal] Thanks Hesham :) :)=20 I might have preferred 3 to be honest, just like I might have preferred to include the RR test for IPv4 traversal and a number of other things like HA in an IPv6 dominant network, etc... But realistically I think the draft is good enough for the purpose and should not be delayed. I voted to keep the mapped address for the same reasons. So my proposal was: 1) publish the current draft ASAP with minimum (editorial) change. 2) promote rapidly a separate I-D on enabling option 3.=20 The PS for that new I-D is almost done thanks to Sri's work and the discussions over this issue 93. There were needs listed, I just added a mobile pseudo-wire. The fact that IPv6 comes straight after the UDP header pre exists to the IPv4 traversal work, so issue 93 is a problem that should be addressed, but can be addressed separately, with backward compatibility to both MIP and MIPTRANS (it's not much harder anyway). I believe it's hard to close the issue cleanly without a commitment to do that work. IMHO, exact same goes for the security issue we discuss over the validity of the CoA: It's generally very hard for a MR to check that it is actually reachable from the HA at the CoA unless RR test is performed. Then again, the problem preexists to MIPTRANS, even if MIPTRANS makes it worse with IPv4 and NATs. There also, I think a small paper proposing a new optional mechanism could be a useful RFC. I hope I made myself clearer now... >I look forward to people expressing that they were misrepresnted by the >chairs. I don't think it's useful for you or Henrik to recount on their >behalf. > >Hesham > > > I understand the need to complete the DSMIP6 as early as > > possible and I appreciate the Chair's position to close > > this issue soon. I really like to see that as well. I also > > believe, IMO, that there is a proper justification in asking > > for Option#3. Its for a simple TLV header, qualifier in UDP > > for the payload packet. Many reasons, examples, protocol > > conventions including 3519's way of dealing with the exact > > same issue, lack of resaved port numbers, opening multiple > > port numbers if we were to extend it later, and many other > > reasons were mentioned and against the one solid reason of > > extra-4 byte overhead. We don't have turn this to a voting > > machine, if we see the need for this request with certain > > flexibility. > > > > Now, w.r.t the voting, I though Pascal did mention the need > > for a supporting new encapsulation mode and off course he > > also wanted this work to close ASAP and that leaves it in > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > his preference is for Option#4 and his second preference is > > for option#3. He can speak up. And, we missed Alessio Casati's > > preference on this issue, he did support option#3. So with > > Jouni Korhonen, he did state that "I prefer more future proof > > extensibility over slight performance hit thus I prefer the > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > vote in favour of option#3. > > > > If this is not rough consensus, atleast, there is sufficient > > interest to discuss this issue further and proper conclude. > > My 2c. > > > > Regards > > Sri > > > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Saturday, June 02, 2007 4:05 AM > > > To: 'Henrik Levkowetz' > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > on how to > > > > handle the issue. And I don't see any consensus on how to > > > handle the > > > > issue here. > > > > > > =3D> The issue was raised against an existing solution, if > > > there is no support > > > in the WG (6 people against and 5 for it) then clearly there > > > is no agreement > > > that there is an issue to begin with. What are you suggesting > > > we do? If > > > there is no support for the perceived issue then naturally > > > it's rejected. I > > > don't think anyone is changing their mind if we ask the same > > > question again > > > in the space of two weeks... > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > surprised that you > > > accepted the same numbers as concensus on other issues, like > > > the mapped > > > address one or issue 93. Should we repeat all those > > questions again? > > > > > > Hesham > > > > > > > > > > > > > > > Henrik > > > > > > > > > We've always asked for concencus to > > > > > change anything > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > that there is no > > > > > concensus to change the draft. 5:4 is not concensus. > > > > Therefore, I think > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > into a voting > > > > > organisation, if we do then the whole process of providing > > > > a vote would be > > > > > different from what we do today. > > > > > > > > > > Hesham > > > > > > > > > >> -----Original Message----- > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > >> To: Narayanan, Vidya > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > >> > > > > >> Hi Vidya, Rai, > > > > >> > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > > > >> Of course that matters, Vidya, but the more > > important thing here > > > > >> is that it's pretty clear to me that there is *no* > > > rough consensus > > > > >> present. > > > > >> > > > > >> Please don't manufacture one when there isn't one; if there > > > > >> really isn't one, do another call for discussion and/or show > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > >> > > > > >> I can't accept this pronouncement of a consensus, > > rough or not, > > > > >> in the group, neither from my observation of the > > discussion or > > > > >> from the count. > > > > >> > > > > >> > > > > >> Henrik > > > > >> > > > > >> > > > > >>> Vidya > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > >>>> To: Levkowetz > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > of: DS-MIP6 > > > > >>>> - Consensus call to close issue 93 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Vijay D. - Option 4 originally and then changed to > > Option 2 > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > Option 3 > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > - Option 3 > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > > >>>> Option 1 (Interpreted) > > > > >>>> > > > > >>>> So we have a sort of a tie if you strictly go by count. > > > > >>>> If I were to express my own opinion > > (non-chair-hat), I would > > > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > > > >>>> (aligned with my earlier email that if and when GRE is > > > > >>>> planned for use, another UDP port can be > > reserved... But for > > > > >>>> now option 1). That would break any deadlock issues. > > > > >>>> > > > > >>>> Or the other way is to let the chairs decide what is the > > > > >>>> sense of the discussion on the ML and from the > > perspective of > > > > >>>> the charter/scope and urgency of this protocol. > > And from this > > > > >>>> angle as well, I would stick by my conclusion, i.e > > option 1. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Hi Raj, > > > > >>>>> > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > > >>>>>> So after an extensive discussion on this topic > > which spun > > > > >>>> off into a > > > > >>>>>> discussion about the need/use for GRE, I would like to > > > > >> summarize > > > > >>>>>> where we are with the options that we have. > > > > >>>>>> > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > > >> Parse the > > > > >>>>>> protocol header following the UDP header" is good enough. > > > > >>>>> Could you give us an indication of who preferred which > > > > >> option? You > > > > >>>>> seem to be very clear about the outcome, while it was far > > > > >>>> from obvious > > > > >>>>> to me that the counts turned out to support above > > > conclusion... > > > > >>>>> > > > > >>>>> > > > > >>>>> Henrik > > > > >>>>> > > > > >>>>>> So it implies no changes to the current text in the > > > > >>>> DS-MIP6 I-D w.r.t > > > > >>>>>> this issue are needed. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> It was pointed out that in the future if GRE was > > > > >> determined as a > > > > >>>>>> protocol that needs to be supported as well either for > > > > >>>> MIP6, NEMO or > > > > >>>>>> PMIP6 then it would be specified in the > > appropriate WG and > > > > >>>> a UDP port > > > > >>>>>> reserved for the same. In such a case it would > > > > >> essentially be the > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > >>>>>> > > > > >>>>>> At this time, the need for GRE especially in the scope > > > > >> of DS-MIP6 > > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > > >> we will move > > > > >>>>>> forward with Option 1 and close this issue. > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > >>>> wrote: > > > > >>>>>>> Hello, > > > > >>>>>>> > > > > >>>>>>> The DS-MIP6 I-D > > > > > > >>>> still has > > > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay > > > > presented 4 > > > > >>>>>>> options to solve the issue. These are captured in: > > > > >>>>>>> > > > > >>>>>>> > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > >>>>>>> > > > > >>>>>>> We need to make a decision on this issue and > > move forward > > > > >>>> with the > > > > >>>>>>> I-D. At the meeting itself, I got the sense that > > > > >> option 3 was the > > > > >>>>>>> one that had the least impact and easy to implement. > > > > >>>>>>> > > > > >>>>>>> Please consider this email as a consensus call for > > > > >> issue 93. The > > > > >>>>>>> problem and choices are as follows (based on > > > Vijay's slides): > > > > >>>>>>> > > > > >>>>>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > >>>> traversal. The > > > > >>>>>>> encapculations are either: > > > > >>>>>>> - IPv6-in-UDP-over-IPv4 > > > > >>>>>>> - IPv4-in-UDP-over-IPv4 > > > > >>>>>>> There is a need (or I guess desirable) to indicate > > > > the type of > > > > >>>>>>> protocol being encapsulated in the UDP header. > > > > >>>>>>> > > > > >>>>>>> Choices are: > > > > >>>>>>> 1. Parse the protocol header following the UDP > > header 2. > > > > >>>> Reserve a > > > > >>>>>>> UDP port for each protocol header (i.e one UDP port for > > > > >>>>>>> IPv6-in-UDP-over-IPv4 and another for > > > > >>>> IPv4-in-UDP-over-IPv4 etc.) > > > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel > > > type message" > > > > >>>>>>> 4. Encapsulated protocol header type is > > indicated in the > > > > >>>> BU message > > > > >>>>>>> Pros and cons of these choices are in the slides that > > > > >>>> were presented > > > > >>>>>>> at IETF68 (see URL above). > > > > >>>>>>> > > > > >>>>>>> Please provide your opinions and comments by May 15th, > > > > >> 07 on the > > > > >>>>>>> MIP6 mailing list. > > > > >>>>>>> > > > > >>>>>>> -Raj > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> _______________________________________________ > > > > >>>>>>> Mip6 mailing list > > > > >>>>>>> Mip6@ietf.org > > > > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>>>> > > > > >>>> _______________________________________________ > > > > >>>> Mip6 mailing list > > > > >>>> Mip6@ietf.org > > > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Tue Jun 05 12:17:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbiO-00072X-JB; Tue, 05 Jun 2007 12:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbiN-00072S-Cf for nemo@ietf.org; Tue, 05 Jun 2007 12:16:59 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbiK-0006RO-SP for nemo@ietf.org; Tue, 05 Jun 2007 12:16:59 -0400 Received: from acorde (acorde.it.uc3m.es [163.117.139.72])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 0383D1CFF1; Tue, 5 Jun 2007 18:16:56 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: weddy@grc.nasa.gov In-Reply-To: <20070605153016.GA441@grc.nasa.gov> References: <1180896152.4812.18.camel@localhost> <20070605153016.GA441@grc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Tue, 05 Jun 2007 18:17:02 +0200 Message-Id: <1181060222.14265.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-15.8028 TC:1F TRN:76 TV:3.6.1039(15220.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: IETF NEMO WG , MPI@multicasttech.com Subject: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Wesley, El mar, 05-06-2007 a las 11:30 -0400, Wesley Eddy escribi=F3: > On Sun, Jun 03, 2007 at 08:42:32PM +0200, Carlos Jes=FAs Bernardos Cano= wrote: > >=20 > > I've read your draft and I've found it very interesting and clear. I= 'm > > talking from the perspective of a person working on NEMO RO mechanism= s, > > and sometimes I find myself not knowing which are the most important > > metrics/requirements of a practical NEMO RO solution to be deployed i= n > > real scenarios. Thanks for the draft! >=20 >=20 > Excellent, I'm glad it is helpful. > =20 >=20 > > - There are some requirements, such as Req2 (multihoming) that seem t= o > > me more related to the general NEMO solution required for aeronautica= l > > environments than to a NEMO RO particular solution. I agree that a NE= MO > > RO solution should work when multiple MRs/HAs are used, but IMHO the > > multihoming support itself should be provided by multihoming mechanis= ms, > > rather than by the NEMO RO solution (although the RO mechanism should= be > > compatible to these solutions). I think it would be useful to clarify > > that in the text. >=20 >=20 > Yes, I think you're right. The text should be more clear here in sayin= g > that providing multihoming is not itself a requirement, but "MUST NOT > preclude multihoming" *is* a requirement. We'll try to fix this. >=20 > =20 > > - I miss one requirement saying that the NEMO RO solution must be > > secure. Req8 says that IPsec must be usable, but I think that's a > > different issue (e.g., a particular NEMO RO solution must allow IPsec= to > > be used while enabling new attacks). Therefore, I'd add a requirement > > specifically stating that the NEMO RO solution must be secure, and I'= d > > describe to which kind of attacks it should be secure and which are t= he > > assumptions about the existing infrastructure (something similar to w= hat > > is said in RFC 4225). >=20 >=20 > I'm not quite sure about this "must be secure" is rather vague and coul= d > be too loose in that it permits sort-of homebrew schemes that look > secure at first, but after a few years turn out to not be. I prefer to > require the securability to be vai IPsec, since it is well understood a= nd > maintained by the IETF, whereas other ways to "secure" RO schemes may n= ot > be. I think I'm not explained myself clearly. I'm referring to the security of the RO mechanism itself. As far as I understand, one issue is to allow end to end traffic to be secured by using IPsec and another issue is how secure the NEMO RO solution (security was the key issue in the RO solution adopted by MIPv6, and this security is not provided by IPsec). Do you see my point? >=20 >=20 > > - I also miss a requirement about which are the types of MNNs that > > should be supported by the NEMO RO solution. From the reading of the > > draft, it seems to me that all kinds of MNNs should be supported (i.e= ., > > LFNs, LMNs and VMNs). This requirement is important, because many > > solutions proposed so far only deal with the optimisation of certain > > MNNs/configurations (e.g., nested networks, VMNs, etc). >=20 >=20 > At least LFNs and LMNs MUST be supported by the RO solution in our case= , > and it would be very desirable for deployment purposes to support VMNs = as > well (SHOULD?). OK. Kind Regards, Carlos >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From nemo-bounces@ietf.org Wed Jun 06 10:55:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvwv7-0008Qy-H8; Wed, 06 Jun 2007 10:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvwv6-0008Qq-0i; Wed, 06 Jun 2007 10:55:32 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvwv5-00020G-Fo; Wed, 06 Jun 2007 10:55:32 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56Et8ih026879; Wed, 6 Jun 2007 17:55:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 17:55:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:55:12 -0500 Received: from 10.241.58.179 ([10.241.58.179]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jun 2007 14:55:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 06 Jun 2007 09:55:19 -0500 From: Basavaraj Patil To: Vijay Devarapalli , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QAAV7s87g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 14:55:12.0478 (UTC) FILETIME=[AF42B7E0:01C7A84A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, Sure... So I guess you are okay with not having to add the 4 byte header (Option 3). -Raj On 6/4/07 4:05 PM, "ext Vijay Devarapalli" wrote: > Raj, > > This is fine with me. But today we already have option 2. One > reserved UDP port for IPv4/v6 and another for ESP encapsulation > of DS-MIPv6 tunneled packets. > > Vijay > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, June 01, 2007 12:47 PM >> To: ext Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org >> Subject: [Mip6] Summary and conclusion of: DS-MIP6 - >> Consensus call to close issue 93 >> >> >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to >> summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse >> the protocol >> header following the UDP header" is good enough. >> >> So it implies no changes to the current text in the DS-MIP6 >> I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined >> as a protocol >> that needs to be supported as well either for MIP6, NEMO or >> PMIP6 then it >> would be specified in the appropriate WG and a UDP port >> reserved for the >> same. In such a case it would essentially be the equivalent >> of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of >> DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> wrote: >> >>> >>> Hello, >>> >>> The DS-MIP6 I-D still has >>> issue 93 open. This was discussed at IETF68. Vijay >> presented 4 options >>> to solve the issue. These are captured in: >>> >>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>> >>> We need to make a decision on this issue and move forward with the >>> I-D. At the meeting itself, I got the sense that option 3 >> was the one >>> that had the least impact and easy to implement. >>> >>> Please consider this email as a consensus call for issue 93. The >>> problem and choices are as follows (based on Vijay's slides): >>> >>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >>> encapculations are either: >>> - IPv6-in-UDP-over-IPv4 >>> - IPv4-in-UDP-over-IPv4 >>> There is a need (or I guess desirable) to indicate the type of >>> protocol being encapsulated in the UDP header. >>> >>> Choices are: >>> 1. Parse the protocol header following the UDP header >>> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >>> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>> 4. Encapsulated protocol header type is indicated in the BU message >>> >>> Pros and cons of these choices are in the slides that were presented >>> at IETF68 (see URL above). >>> >>> Please provide your opinions and comments by May 15th, 07 >> on the MIP6 >>> mailing list. >>> >>> -Raj >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Wed Jun 06 11:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx1e-0006QL-Ip; Wed, 06 Jun 2007 11:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx1e-0006QD-4k; Wed, 06 Jun 2007 11:02:18 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvx1c-0003OL-MH; Wed, 06 Jun 2007 11:02:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56F1xNj024983; Wed, 6 Jun 2007 18:02:14 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 18:02:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 10:01:29 -0500 Received: from 10.241.58.179 ([10.241.58.179]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jun 2007 15:01:29 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 06 Jun 2007 10:01:37 -0500 From: Basavaraj Patil To: ext Basavaraj Patil , Mobile IPv6 Mailing List , , ext Jari Arkko Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QAAV7s87gAAOFNq In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 15:01:29.0936 (UTC) FILETIME=[903E3D00:01C7A84B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Since concerns about rough consensus, process followed and who said what w.r.t the various options seem to be dragging on, I have requested Jari Arkko (AD) to review the discussion and the thread and provide a recommendtion on next steps. -Raj From nemo-bounces@ietf.org Wed Jun 06 17:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3Em-00017p-Gs; Wed, 06 Jun 2007 17:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3El-00017c-6l; Wed, 06 Jun 2007 17:40:15 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3Ek-0002Db-OZ; Wed, 06 Jun 2007 17:40:15 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2EECF19868A; Thu, 7 Jun 2007 00:40:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D654019867C; Thu, 7 Jun 2007 00:40:12 +0300 (EEST) Message-ID: <466729AE.3000707@piuha.net> Date: Thu, 07 Jun 2007 00:39:58 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org All, (Sorry for not responding to this sooner -- I was traveling. But I have now reviewed the list discussion and talked to some of you as well.) First, it should be obvious that if we need to worry about the difference of one or two persons, then we don't have consensus. I appreciate the fact that we sometimes end up in a controversial situation where there is no clear consensus. But we should aim to run the working groups by consensus rather than move forward when a slim margin shows that some resolution "wins". That is, if the opinions are so diverse then more discussion is probably needed. Also, it would be better if people who post opinions actually state why they believe what they believe ("Approach A is already in my implementation" or "Approach B makes X very hard"). We also need to listen to what the others are saying, and be able to change our opinion when we learn new things. Everyone on this WG needs to work harder towards consensus. The other observation I would make is that in any case the conclusions sent by the chairs need to be accurate. I realize that in some cases a response is unclear or may change/come late. But the counts need to be right, and contain people who have sent their opinions to the list. Basavaraj has already admitted he made a mistake here, and has promised to get this right in the future. A datapoint from my discussion with the people involved in this: I did not hear any extreme opinions about the technical matter itself. None of the main alternatives were seen to cause significant problems, even if everyone had their favorite alternative. With that in mind, I do not believe we should make this process a long one. An almost perfect solution now is better than a perfect solution later... Hesham and Henrik talked about the nature of the consensus call and that is actually an interesting issue. One opinion was that lack of consensus means we can not move forward until the issue is resolved. Another opinion was that lack of consensus means the issue was rejected and we move forward without changing the document. I'd say which approach to use is a judgment call. The former approach is the usual IETF one. We really need to solve issues that we know exist in the specification. But in some cases, particularly with new features someone suggests to adopt, it may make sense to employ the other approach. Then lack of consensus to adopt/not adopt the feature means the document progresses anyway, assuming of course there was earlier consensus about the current document. Issue 93 is perhaps a borderline case, as you could argue its either a new feature or an issue in the current document. How do we move forward? I would like to extend the consensus call for a short period (a week) and see if we can reach a better conclusion. In addition to the preferred alternative (1-4) and rationale, I think it would also be useful to understand how the group feels about the text in the current document. Does it adequately describe the operation with regards to this issue (irrespective of whether you prefer the used approach or not)? If no, some change will be needed. Hesham has also raised a concern about one earlier issue (73). I will take a look at the discussion to see if we need to revisit that. Note that we will not revisit old issues lightly, only in case of when substantial new information comes to light. Jari From nemo-bounces@ietf.org Wed Jun 06 20:54:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw6GM-0006Te-CR; Wed, 06 Jun 2007 20:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw6GK-0006TR-TN; Wed, 06 Jun 2007 20:54:04 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw6GI-0003kq-Qb; Wed, 06 Jun 2007 20:54:04 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070607005359.TBHF25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Thu, 7 Jun 2007 00:53:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 00:53:58 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" , "'Basavaraj Patil'" Date: Thu, 7 Jun 2007 10:53:49 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQ In-Reply-To: <466729AE.3000707@piuha.net> Message-Id: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call toclose issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks Jari, This is the perfect answer to our discussion. I hope we can move on within the extended week to resolve this. Folks, please feel free to express more opinions, change opinions ...etc Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, June 07, 2007 7:40 AM > To: Basavaraj Patil > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus call toclose issue 93 > > All, > > (Sorry for not responding to this sooner -- I was traveling. > But I have now reviewed the list discussion and talked > to some of you as well.) > > First, it should be obvious that if we need to worry about > the difference of one or two persons, then we don't have > consensus. I appreciate the fact that we sometimes end > up in a controversial situation where there is no clear > consensus. But we should aim to run the working groups > by consensus rather than move forward when a slim > margin shows that some resolution "wins". That is, if > the opinions are so diverse then more discussion is > probably needed. Also, it would be better if people > who post opinions actually state why they believe > what they believe ("Approach A is already in my > implementation" or "Approach B makes X very > hard"). We also need to listen to what the others > are saying, and be able to change our opinion when > we learn new things. Everyone on this WG needs > to work harder towards consensus. > > The other observation I would make is that in any > case the conclusions sent by the chairs need to > be accurate. I realize that in some cases a response > is unclear or may change/come late. But the counts > need to be right, and contain people who have > sent their opinions to the list. Basavaraj has already > admitted he made a mistake here, and has promised > to get this right in the future. > > A datapoint from my discussion with the people > involved in this: I did not hear any extreme opinions > about the technical matter itself. None of the main > alternatives were seen to cause significant problems, > even if everyone had their favorite alternative. With > that in mind, I do not believe we should make this > process a long one. An almost perfect solution > now is better than a perfect solution later... > > Hesham and Henrik talked about the nature of the > consensus call and that is actually an interesting > issue. One opinion was that lack of consensus > means we can not move forward until the issue > is resolved. Another opinion was that lack of > consensus means the issue was rejected and we > move forward without changing the document. > I'd say which approach to use is a judgment call. > The former approach is the usual IETF one. We really > need to solve issues that we know exist in the > specification. But in some cases, particularly with > new features someone suggests to adopt, it may > make sense to employ the other approach. Then > lack of consensus to adopt/not adopt the feature > means the document progresses anyway, assuming > of course there was earlier consensus about the > current document. Issue 93 is perhaps a borderline > case, as you could argue its either a new feature > or an issue in the current document. > > How do we move forward? I would like to extend > the consensus call for a short period (a week) > and see if we can reach a better conclusion. > In addition to the preferred alternative (1-4) and > rationale, I think it would also be useful to understand > how the group feels about the text in the current > document. Does it adequately describe the operation > with regards to this issue (irrespective of whether you > prefer the used approach or not)? If no, some change > will be needed. > > Hesham has also raised a concern about one > earlier issue (73). I will take a look at the discussion > to see if we need to revisit that. Note that we > will not revisit old issues lightly, only in case > of when substantial new information comes to > light. > > Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Wed Jun 06 22:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw88h-0001Go-3E; Wed, 06 Jun 2007 22:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw88f-0001GZ-VP; Wed, 06 Jun 2007 22:54:17 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw88f-00011x-Fr; Wed, 06 Jun 2007 22:54:17 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070607025415.BRBC25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Thu, 7 Jun 2007 02:54:15 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 02:54:14 +0000 From: "Hesham Soliman" To: , Date: Thu, 7 Jun 2007 12:54:07 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvA== Message-Id: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [nemo] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In light of the discussions that went on I thought it would be useful to summarise the issue and discussions so far to give people who haven't kept up an insight into what this is all about. First the issue text discussed the need for a "TLV" type encoding between the outer IP header and the inner UDP header. The reason specified in the issue was that the upper layer parsing the packet can't tell what information follows UDP unless it is explicitly encoded. Upon further discussion it was clear that this rationale is not true because the upper layer can always parse the version field in the IP header following UDP. However, the following question was "what if the information following UDP was not an IP header?". One could encode messages (at least in theory) that follow UDP and that are not IP. But to save space and reading time, the main (probably only) example for such information is the use of GRE encapsulation. Some people don't see the need for the use of GRE and some people do. I suggested that GRE can be used before UDP and not after, but that was seen as unhelpful for cases where a NAT is present. Since I, after substantial effort, still couldn't find out what the deployment scenario that needs this might be, I won't try to invent a scenario for GRE on behalf of people who are calling for it and I'll leave the floor open for that discussion. The point I wanted to highlight here that practically this is the only reason left for adding TLV encoding. Finally, there are 3 options available for us to move forward and I'll use the same numbers that Raj use to avoid confusing people: 1. Do nothing, keep the draft as is. 2. Specify a different port number for the different format suggested. 3. Add the TLV encoding suggested in the issue. 1) above implies that should there be agreement in future that the format suggested in this issue is necessary, it can be achieved using option 2 (i.e. specify a new port that carries that format). This can be used if, for example, GRE is needed for NETLMM. A MAG can use a different port from the one used by the MN. The main reasons expressed by people for choosing 1 were: a) Adding 4 bytes on every packet is not needed. b) GRE is not needed. 2) above is pretty clear to everyone I think but Karen Nielsen raised some questions that people should read. 3) I believe 3 is also clear for everyone. Going to 3 will not require a move to 2) later. Of course this comes at the cost mentioned above. I believe the main reason expressed by people for this option was "future proof". So, hopefully this gives a summary of the discussion so far. I think there are basically two ways of finding concensus: 1. Discuss the rationale a lot more to make either side move. For instance, discuss the deployment scenarios that require GRE, what is "future proof", why the extra 4 bytes are an issue for those who chose 1) ...etc 2. Due to current threads more people might express their opionions. I'm not too hopeful with 2) above because most of the people that are actively involved have commented. Plus it would actually be nice to see 1) being achieved once in a while! So let's try to do that. Hesham From nemo-bounces@ietf.org Wed Jun 06 23:53:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw94M-0000gE-2b; Wed, 06 Jun 2007 23:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw94K-0000XW-T1; Wed, 06 Jun 2007 23:53:52 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw93i-0001d5-1g; Wed, 06 Jun 2007 23:53:17 -0400 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 07 Jun 2007 22:19:25 +0530 X-IronPort-AV: i="4.16,392,1175452200"; d="scan'208"; a="81614982:sNHT71267386" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l573r99K016748; Thu, 7 Jun 2007 11:53:09 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l573qaqU022428; Thu, 7 Jun 2007 03:53:00 GMT Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:52:36 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 11:52:34 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> In-Reply-To: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6A= From: "Yoshi Tsuda \(yotsuda\)" To: "Hesham Soliman" , "Jari Arkko" , "Basavaraj Patil" , "Henrik Levkowetz" , "Sri Gundavelli \(sgundave\)" X-OriginalArrivalTime: 07 Jun 2007 03:52:36.0928 (UTC) FILETIME=[4984F400:01C7A8B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5960; t=1181188390; x=1182052390; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=yotsuda@cisco.com; z=From:=20=22Yoshi=20Tsuda=20\(yotsuda\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=DAqIv9j1ayDqnWH6hREaggbM80iVRB94oSvaZezGVek=; b=n64dNmQLG6uNDJe+th0CiuJEvJ+Ubfyjk3dF5CAoev/x6ZOwITb6ekoxSFxHRCzzIAbRxAv9 Dqf3zM1YybIu8h1M2chgnyhH3fJrM8mzWiBn7t5MSERrvWudZjFDgjuxlIhTHV7wMp1y/HCtCz C1p1Gg+1uH+TIReIwyze2IEtI=; Authentication-Results: hkg-dkim-2; header.From=yotsuda@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello Jari, Hesham, Sri and all: Thank you for your works! If possible, and if you have time, I prefer the option#3. I'm sorry for my late response. Does anyone have any time constraint to publish the current draft now? If not, I deeply agree with Henrik; it would be sad to see many emails about a -bis document just after publishing the current draft... Personally, I don't care too much for GRE; if there are any other better mechanisms than GRE, it would be fine. I agree with Hesham, if we got a port number, it would be wonderful. But, if not, it would be still great to have some encapsulation mechanisms as a second option. GRE is just available in MIPv4 so far. :) Have a nice day! Cheers. -Yoshi > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, June 07, 2007 9:54 AM > To: 'Jari Arkko'; 'Basavaraj Patil' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 -=20 > Consensus calltoclose issue 93 >=20 > Thanks Jari, This is the perfect answer to our discussion. I=20 > hope we can move on within the extended week to resolve this.=20 > Folks, please feel free to express more opinions, change=20 > opinions ...etc >=20 > Hesham=20 >=20 > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent:=20 > Thursday, June 07, 2007 7:40 AM > To: Basavaraj Patil > Cc:=20 > nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re:=20 > [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus call=20 > toclose issue 93 > > All, > > (Sorry for not responding=20 > to this sooner -- I was traveling. > > But I have now reviewed the list discussion and talked >=20 > to some of you as well.) > > First, it should be obvious=20 > that if we need to worry about > the difference of one or=20 > two persons, then we don't have > consensus. I appreciate=20 > the fact that we sometimes end > up in a controversial=20 > situation where there is no clear > consensus. But we should=20 > aim to run the working groups > by consensus rather than=20 > move forward when a slim > margin shows that some resolution=20 > "wins". That is, if > the opinions are so diverse then more=20 > discussion is > probably needed. Also, it would be better if=20 > people > who post opinions actually state why they believe =20 > > what they believe ("Approach A is already in my >=20 > implementation" or "Approach B makes X very > hard"). We=20 > also need to listen to what the others > are saying, and be=20 > able to change our opinion when > we learn new things.=20 > Everyone on this WG needs > to work harder towards consensus. > > > > The other observation I would make is that in any > case=20 > the conclusions sent by the chairs need to > be accurate. I=20 > realize that in some cases a response > is unclear or may=20 > change/come late. But the counts > need to be right, and=20 > contain people who have > sent their opinions to the list.=20 > Basavaraj has already > admitted he made a mistake here, and=20 > has promised > to get this right in the future. > > > > A datapoint from my discussion with the people > involved=20 > in this: I did not hear any extreme opinions > about the=20 > technical matter itself. None of the main > alternatives=20 > were seen to cause significant problems, > even if everyone=20 > had their favorite alternative. With > that in mind, I do=20 > not believe we should make this > process a long one. An=20 > almost perfect solution > now is better than a perfect=20 > solution later... > > > > Hesham and Henrik talked about the nature of the >=20 > consensus call and that is actually an interesting > issue.=20 > One opinion was that lack of consensus > means we can not=20 > move forward until the issue > is resolved. Another opinion=20 > was that lack of > consensus means the issue was rejected=20 > and we > move forward without changing the document. > > I'd say which approach to use is a judgment call. > > The former approach is the usual IETF one. We really >=20 > need to solve issues that we know exist in the >=20 > specification. But in some cases, particularly with > new=20 > features someone suggests to adopt, it may > make sense to=20 > employ the other approach. Then > lack of consensus to=20 > adopt/not adopt the feature > means the document progresses=20 > anyway, assuming > of course there was earlier consensus=20 > about the > current document. Issue 93 is perhaps a=20 > borderline > case, as you could argue its either a new=20 > feature > or an issue in the current document. > > > > How do we move forward? I would like to extend > the=20 > consensus call for a short period (a week) > and see if we=20 > can reach a better conclusion. > > In addition to the preferred alternative (1-4) and >=20 > rationale, I think it would also be useful to understand >=20 > how the group feels about the text in the current >=20 > document. Does it adequately describe the operation > with=20 > regards to this issue (irrespective of whether you > prefer=20 > the used approach or not)? If no, some change > will be needed. > > > > Hesham has also raised a concern about one > earlier=20 > issue (73). I will take a look at the discussion > to see if=20 > we need to revisit that. Note that we > will not revisit old=20 > issues lightly, only in case > of when substantial new=20 > information comes to > light. > > > > Jari > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Thu Jun 07 00:20:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9U6-0002hm-Mb; Thu, 07 Jun 2007 00:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9U4-0002WT-Cz; Thu, 07 Jun 2007 00:20:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw9U1-0007d7-U4; Thu, 07 Jun 2007 00:20:28 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 21:20:21 -0700 X-IronPort-AV: i="4.16,392,1175497200"; d="scan'208"; a="161437969:sNHT50325849" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l574KLfH026313; Wed, 6 Jun 2007 21:20:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l574KKaI011322; Thu, 7 Jun 2007 04:20:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 21:20:20 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 21:20:20 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> Date: Wed, 6 Jun 2007 21:20:19 -0700 Message-ID: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsA== In-Reply-To: <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> X-OriginalArrivalTime: 07 Jun 2007 04:20:20.0585 (UTC) FILETIME=[2922DD90:01C7A8BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3729; t=1181190021; x=1182054021; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=JFDCwvvGjzlg0bjqmqtJ3bDA/RBLlJPZ2PVe5Me/SiM=; b=rpVc+Eo53OJm6vuWon+QCy/RstbAxABn6a+aVW6D5f59KRkaWOsfk9CNPXPgjZG2kw/0kjGn rm8luyrYIto12xRWQgWofLUSsAD/mgn/mZr68z29wYTDvtFCwyErbmu8; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org A question was asked, why do we need a 4-byte header when we carry IPv4/IPv6 packets in a IPv4-UDP tunnel header ? Reasons were stated as why we don't need it and why there is no next IP version in our lifetimes. This is the other side of the coin as why we would need it. I'm sure, we can converge and decide on one solution, what ever that is. Summary of the comments captured favoring option#3. Lets close this thread ASAP. 1. Protocol Design Convention Looking at IP header, Ethernet header or IPv6 options, always the prev header qualifies the payload that follows. No protocol is looking at the payload to determine the type. 2. How 3519 handles the exact same scenario When a packet is carried in a UDP transport, its important that the payload is classified by a prior header. Designers of 3519 chose that option. Please see the 4 byte TLV header in RFC-3519, Section 3.1. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Extensibility and Future proof We cannot say, we will only carry raw IPv4 or IPv6 payloads and so the 1st byte IPv4 version lookup is sufficient. Lets learn some thing from the IPv6 address space design, from the Y2K problem or the millennium bug. Allow the provision for carrying other types of messages. Example: - GRE Header (Explained below in item#6) - Other encapsulation headers 4. Tunnel Keep Alive message When DSMIP chose IPv4 UDP transport for NAT traversal, the need for keepalive messaging between the tunnel peers for keeping the NAT bindings came up. The authors of the draft chose to use MIP6 signaling messages BU/BA as a way to refresh the keepalive messages. IMO, having a simple keepalive messages is lot more useful than an expensive BU/BA. Most 3519 implementation today optimize on this, by eliminating the keepalives when there is traffic. We cant do such optimizations with BU/BA. 5. Lack of Reserved ports for allocation The comment was made, we can always extend DSMIP for supporting GRE or other encapsulation modes. Then the issue of backward compatibility came up. The tunnel end points cannot demux the encapsulated packets, when some packets are encapsulated with a thin header and some with out a thin header. So, the only alternative would be to allocate two ports numbers and the end points have to listen on both the port numbers. But, as Henrik mentioned, there is also an issue with the available reserved ports for standard network services. 6. Why do we need GRE Header ? We need GRE tunnel header for various reasons, when ever we carry multiple streams within a tunnel, the GRE header for its mature header semantics, the key field and the sequence number field is useful. We have some NEMO use cases where we use the GRE key to tag certain MNP flows, and the tunnel peers use these keys as a form of a selector for differential treatment. Its a color code. Use cases: a.) Overlapping private IPv4 addressing support on the MAGs (PMIP6 Usage) b.) GRE tunnel header for NEMO usecase c.) Carrying other protocol packets (Lets say, IPX packets) in a MIP tunnel. d.) MIP4 supports it for a reason e.) Industry direction and related work, these are the active drafts: http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-00.tx t http://www.ietf.org/internet-drafts/draft-yegani-gre-key-extension-02.txt http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt From nemo-bounces@ietf.org Thu Jun 07 00:35:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9j2-00030A-0y; Thu, 07 Jun 2007 00:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9j0-0002ze-9o; Thu, 07 Jun 2007 00:35:54 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw9iy-0002Kl-QY; Thu, 07 Jun 2007 00:35:54 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070607043550.TAYZ14178.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Thu, 7 Jun 2007 04:35:50 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 04:35:45 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" Date: Thu, 7 Jun 2007 14:35:38 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBw In-Reply-To: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> Message-Id: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, This is a good start for discussion. In the spirit of listening, I'll address some of those comments. > 4. Tunnel Keep Alive message > > When DSMIP chose IPv4 UDP transport for NAT traversal, > the need for keepalive messaging between the tunnel > peers for keeping the NAT bindings came up. The authors > of the draft chose to use MIP6 signaling messages BU/BA > as a way to refresh the keepalive messages. IMO, having > a simple keepalive messages is lot more useful than an > expensive BU/BA. Most 3519 implementation today optimize > on this, by eliminating the keepalives when there is > traffic. We cant do such optimizations with BU/BA. => We discussed this already no? We said that you could encapsulate a ping in IP or use a dst option if you want to save bytes. So there are many ways of doing this, I don't see this as a Y2K equivalent. > 5. Lack of Reserved ports for allocation > > The comment was made, we can always extend DSMIP for supporting > GRE or other encapsulation modes. Then the issue of backward > compatibility came up. The tunnel end points cannot demux the > encapsulated packets, when some packets are encapsulated with > a thin header and some with out a thin header. So, the only > alternative would be to allocate two ports numbers and the end > points have to listen on both the port numbers. But, as Henrik > mentioned, there is also an issue with the available reserved > ports for standard network services. => I'd appreciate some pointers to this problem. About 18 months ago I asked for 6 ports and got them almost instantly. > > > 6. Why do we need GRE Header ? > > We need GRE tunnel header for various reasons, "when ever we > carry multiple streams within a tunnel, the GRE header for its > mature header semantics, the key field and the sequence number > field is useful." => I've added quotes around the area that I'm responding to above Are you seriously saying that whenever multiple flows are encapsulated in a packet GRE is needed? If you are then I think this is flat wrong, factually it's wrong. I hope you can either qualify that or change it or explain it better. I'll leave it with those comments for now to focus the discussion, I have other comments on the rest of the text but let's do it piecemeal. Hesham From nemo-bounces@ietf.org Thu Jun 07 01:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwAZj-00030O-Dt; Thu, 07 Jun 2007 01:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwAZh-00030D-P6; Thu, 07 Jun 2007 01:30:21 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwAZf-0000no-Bn; Thu, 07 Jun 2007 01:30:21 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l575UGY22149; Thu, 7 Jun 2007 05:30:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 00:30:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjg References: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, If I understand Jari comments correctly, I think at one point, he mentioned that we need to revisit/revaluate the existing text in the draft. I looked into the draft but the only thing that I found w.r.t option (1) is the following text: LOCATION NO. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.3.2.1 Visited network supports IPv4 only (private addresses) In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled UDP and IPv4. The UDP port used to send the IPv6 packet is TBD. Basically there is no text included in the draft to explain how to identify the type of payload that is encapsulated in UDP. In other words and strictly speaking, if we take the draft most relevant text above, this "TBD" reserved UDP port will always indicate that the payload is an IPv6!=20 LOCATION NO. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 8. IANA considerations: " 8. IANA considerations The specification requires the following allocations from IANA: - A UDP port is needed for the NAT traversal mechanism described in section 4.1. " Well, looking under section 4.1, I found the following sentence which suggest that an IPv4 packet may be encapsulated in UDP in IPv4. " ......... All tunneled IPv4 packets will contain the mobile node's IPv4 home address in the source address field of the inner IPv4 packet and the correspondent node's IPv4 address in the destination address field. The outer IPv4 header is the same whether the inner packet is IPv4 or IPv6. ..... " The least that I may say about the existing text, it is inadequate. IMO, it needs serious update to identify the mechanism needed by the receiving node to identify the type of packet that is encapsulated in UDP then in IPv4. Finally, I still favor option 3 considering that the 4 bytes can be compressed to much less than 4 bytes reducing the overhead on the wireless link. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Wednesday, June 06, 2007 9:54 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] issue 93 summary >=20 >=20 >=20 > In light of the discussions that went on I thought it would=20 > be useful to summarise the issue and discussions so far to=20 > give people who haven't kept up an insight into what this is=20 > all about.=20 >=20 > First the issue text discussed the need for a "TLV" type=20 > encoding between the outer IP header and the inner UDP=20 > header. The reason specified in the issue was that the upper=20 > layer parsing the packet can't tell what information follows=20 > UDP unless it is explicitly encoded. Upon further discussion=20 > it was clear that this rationale is not true because the=20 > upper layer can always parse the version field in the IP=20 > header following UDP.=20 >=20 > However, the following question was "what if the information=20 > following UDP was not an IP header?". One could encode=20 > messages (at least in theory) that follow UDP and that are=20 > not IP. But to save space and reading time, the main=20 > (probably only) example for such information is the use of=20 > GRE encapsulation. Some people don't see the need for the use=20 > of GRE and some people do. I suggested that GRE can be used=20 > before UDP and not after, but that was seen as unhelpful for=20 > cases where a NAT is present.=20 >=20 > Since I, after substantial effort, still couldn't find out=20 > what the deployment scenario that needs this might be, I=20 > won't try to invent a scenario for GRE on behalf of people=20 > who are calling for it and I'll leave the floor open for that=20 > discussion. The point I wanted to highlight here that=20 > practically this is the only reason left for adding TLV encoding.=20 >=20 > Finally, there are 3 options available for us to move forward=20 > and I'll use the same numbers that Raj use to avoid confusing people: >=20 > 1. Do nothing, keep the draft as is.=20 >=20 > 2. Specify a different port number for the different format suggested. >=20 > 3. Add the TLV encoding suggested in the issue.=20 >=20 >=20 > 1) above implies that should there be agreement in future=20 > that the format suggested in this issue is necessary, it can=20 > be achieved using option 2 (i.e. specify a new port that=20 > carries that format). This can be used if, for example, GRE=20 > is needed for NETLMM. A MAG can use a different port from the=20 > one used by the MN. The main reasons expressed by people for=20 > choosing 1 > were: > a) Adding 4 bytes on every packet is not needed.=20 > b) GRE is not needed.=20 >=20 > 2) above is pretty clear to everyone I think but Karen=20 > Nielsen raised some questions that people should read.=20 >=20 > 3) I believe 3 is also clear for everyone. Going to 3 will=20 > not require a move to 2) later. Of course this comes at the=20 > cost mentioned above. I believe the main reason expressed by=20 > people for this option was "future proof".=20 >=20 > So, hopefully this gives a summary of the discussion so far.=20 > I think there are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move.=20 > For instance, discuss the deployment scenarios that require=20 > GRE, what is "future proof", why the extra 4 bytes are an=20 > issue for those who chose 1) ...etc 2. Due to current threads=20 > more people might express their opionions.=20 >=20 > I'm not too hopeful with 2) above because most of the people=20 > that are actively involved have commented. Plus it would=20 > actually be nice to see 1) being achieved once in a while! So=20 > let's try to do that.=20 >=20 > Hesham >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Thu Jun 07 03:03:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwC1d-0005gl-BY; Thu, 07 Jun 2007 03:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwC1a-0005gV-Qb; Thu, 07 Jun 2007 03:03:14 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwC1Z-0005lj-CW; Thu, 07 Jun 2007 03:03:14 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070607070308.GDCN23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Thu, 7 Jun 2007 07:03:08 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 07:03:08 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , , Date: Thu, 7 Jun 2007 17:03:01 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjgAARjEMA= Message-Id: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > If I understand Jari comments correctly, I think at one point, he > mentioned that we need to revisit/revaluate the existing text in the > draft. I looked into the draft but the only thing that I found w.r.t > option (1) is the following text: > > LOCATION NO. 1: > =============== > 2.3.2.1 Visited network supports IPv4 only (private addresses) > > In this scenario the mobile node will need to tunnel IPv6 packets > containing the binding update to the home agent's IPv4 address. In > order to traverse the NAT device, IPv6 packets are > tunneled UDP and > IPv4. The UDP port used to send the IPv6 packet is TBD. > > Basically there is no text included in the draft to explain how to > identify the type of payload that is encapsulated in UDP. In > other words > and strictly speaking, if we take the draft most relevant text above, > this "TBD" reserved UDP port will always indicate that the > payload is an > IPv6! => No that's not true at all. There is an IP version field in the IP header that tells you what the header is. The fact that the IP header fields (for v4 or v6) are not revisited in this draft does not in any shape or form suggest that we have no way of parsing header. I suggest that we get off the header parsing argument because frankly, it's a waste of time. Everyone knows (including people who want option 3) that you can do this with the version field. Let's not debate facts here, it's pointless. Hesham From nemo-bounces@ietf.org Thu Jun 07 04:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDQo-00064E-F2; Thu, 07 Jun 2007 04:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDQm-00063X-HX; Thu, 07 Jun 2007 04:33:20 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwDQj-0006r5-N7; Thu, 07 Jun 2007 04:33:20 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070607083314.VYQJ8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com>; Thu, 7 Jun 2007 08:33:14 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 08:33:14 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , , Date: Thu, 7 Jun 2007 18:33:09 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAIjFBgAAM2IUA= Message-Id: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Karen, Good question. I don't know actually. Transport ESP on the outer header is obviously not a good idea. Transport ESP on the inner header is obviously possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. Anyone else has a comment on this? Hesham > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) > [mailto:karen.e.nielsen@ericsson.com] > Sent: Thursday, June 07, 2007 6:11 PM > To: Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary > > Hi Hesham, All > > For completeness it would be good to understand the implications > vis-a-vis IPSec in the three options. > > I assume that we are speaking about UDP encapsulated ESP (3948) in > option 1 and option 2, > whether for payload and optionally also for BU/BACK. > But what is the intended approach with option 3 ? > > Thanks, > Karen > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: 7. juni 2007 04:54 > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] issue 93 summary > > > > > > > > In light of the discussions that went on I thought it would > > be useful to summarise the issue and discussions so far to > > give people who haven't kept up an insight into what this is > > all about. > > > > First the issue text discussed the need for a "TLV" type > > encoding between the outer IP header and the inner UDP > > header. The reason specified in the issue was that the upper > > layer parsing the packet can't tell what information follows > > UDP unless it is explicitly encoded. Upon further discussion > > it was clear that this rationale is not true because the > > upper layer can always parse the version field in the IP > > header following UDP. > > > > However, the following question was "what if the information > > following UDP was not an IP header?". One could encode > > messages (at least in theory) that follow UDP and that are > > not IP. But to save space and reading time, the main > > (probably only) example for such information is the use of > > GRE encapsulation. Some people don't see the need for the use > > of GRE and some people do. I suggested that GRE can be used > > before UDP and not after, but that was seen as unhelpful for > > cases where a NAT is present. > > > > Since I, after substantial effort, still couldn't find out > > what the deployment scenario that needs this might be, I > > won't try to invent a scenario for GRE on behalf of people > > who are calling for it and I'll leave the floor open for that > > discussion. The point I wanted to highlight here that > > practically this is the only reason left for adding TLV encoding. > > > > Finally, there are 3 options available for us to move forward > > and I'll use the same numbers that Raj use to avoid > confusing people: > > > > 1. Do nothing, keep the draft as is. > > > > 2. Specify a different port number for the different > format suggested. > > > > 3. Add the TLV encoding suggested in the issue. > > > > > > 1) above implies that should there be agreement in future > > that the format suggested in this issue is necessary, it can > > be achieved using option 2 (i.e. specify a new port that > > carries that format). This can be used if, for example, GRE > > is needed for NETLMM. A MAG can use a different port from the > > one used by the MN. The main reasons expressed by people for > > choosing 1 > > were: > > a) Adding 4 bytes on every packet is not needed. > > b) GRE is not needed. > > > > 2) above is pretty clear to everyone I think but Karen > > Nielsen raised some questions that people should read. > > > > 3) I believe 3 is also clear for everyone. Going to 3 will > > not require a move to 2) later. Of course this comes at the > > cost mentioned above. I believe the main reason expressed by > > people for this option was "future proof". > > > > So, hopefully this gives a summary of the discussion so far. > > I think there are basically two ways of finding concensus: > > 1. Discuss the rationale a lot more to make either side move. > > For instance, discuss the deployment scenarios that require > > GRE, what is "future proof", why the extra 4 bytes are an > > issue for those who chose 1) ...etc 2. Due to current threads > > more people might express their opionions. > > > > I'm not too hopeful with 2) above because most of the people > > that are actively involved have commented. Plus it would > > actually be nice to see 1) being achieved once in a while! So > > let's try to do that. > > > > Hesham > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > From nemo-bounces@ietf.org Thu Jun 07 05:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEc7-0001ZL-VQ; Thu, 07 Jun 2007 05:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEc5-0001Z5-Ol; Thu, 07 Jun 2007 05:49:06 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwEc4-000387-H0; Thu, 07 Jun 2007 05:49:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1181209743!17594856!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15992 invoked from network); 7 Jun 2007 09:49:03 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-8.tower-119.messagelabs.com with SMTP; 7 Jun 2007 09:49:03 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l579msVD023620; Thu, 7 Jun 2007 02:48:59 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l579msx2014558; Thu, 7 Jun 2007 04:48:54 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l579mpG2014493; Thu, 7 Jun 2007 04:48:52 -0500 (CDT) Message-ID: <4667D47D.7060909@gmail.com> Date: Thu, 07 Jun 2007 11:48:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, mip6@ietf.org, "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > Hi Karen, > > Good question. I don't know actually. Transport ESP on the outer header is > obviously not a good idea. Transport ESP on the inner header is obviously > possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. > Anyone else has a comment on this? YEs. I don't think implementations of DS-MIPv6 do what rfc3948 says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 operations are mainly about re-computing checksums in UDP header. Doesn't mean it should be ignored. I think the differences between RFC3948 (UDP-ESP) and DS-MIPv6 use of ESP lie in the style of approach of using ESP. It's not only the typical tunnel vs transport mode. It is about which style of ESP? IPv4-style or IPv6-style ESP? The ESP as usually used by UDP in IPv4 (ESP is after the UDP header, RFC3948)? Or the ESP as used by the inner typical IPv6 packet (IPv6baseheader-ESPheader-MobilityHEader). The exact placing of the ESP header (with respect to UDP and IPv6 headers) obviously has an impact of the level of protection afforded. I believe for maximum protection there may be two ESP headers. I think what DS-MIPv6 assumes is this: IPv4-header UDP IPv6-baseheader ESP IPv6-MobilityHeader I think what RFC3948 suggests is this: IPv4-header IPv4-header UDP or UDP ESP ESP IPv6-MobilityHeader IPv6-baseheader IPv6-MobilityHeader Two ESP headers - one IPv4 style and the other IPv6 style - would look like this: IPv4-header UDP ESP IPv6-baseheader ESP IPv6-MobilityHeader But that has two ESP headers and UDP is still exposed. So better would be: IPv4-header ESP IPv4-header UDP ESP IPv6-header But that doesn't traverse NATs because UDP is not seen by NAT :-( (I think this was already discussed recently). Maybe a shorter-packet alternative is this: IPv4-header UDP ESP IPv6-MobilityHeader. I think in practice the implementer will prefer to either use IPsec code from that s/he usually uses for IPv4 or for IPv6. But packets surely look different. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu Jun 07 06:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEw1-0000Ek-21; Thu, 07 Jun 2007 06:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEvy-0000EG-V5; Thu, 07 Jun 2007 06:09:38 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwEvy-0007oX-Jn; Thu, 07 Jun 2007 06:09:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1181210977!1314935!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10139 invoked from network); 7 Jun 2007 10:09:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 7 Jun 2007 10:09:37 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57A9OUM002317; Thu, 7 Jun 2007 03:09:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l57A9N6f021308; Thu, 7 Jun 2007 05:09:23 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l57A9JxQ021225; Thu, 7 Jun 2007 05:09:20 -0500 (CDT) Message-ID: <4667D94A.5050806@gmail.com> Date: Thu, 07 Jun 2007 12:09:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: GRE, L2TP and no intermediary header (was: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93) References: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> In-Reply-To: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, 'Sri Gundavelli' , 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' , 'Henrik Levkowetz' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: [...] >> 5. Lack of Reserved ports for allocation >> >> The comment was made, we can always extend DSMIP for supporting GRE >> or other encapsulation modes. Then the issue of backward >> compatibility came up. The tunnel end points cannot demux the >> encapsulated packets, when some packets are encapsulated with a >> thin header and some with out a thin header. So, the only >> alternative would be to allocate two ports numbers and the end >> points have to listen on both the port numbers. But, as Henrik >> mentioned, there is also an issue with the available reserved ports >> for standard network services. > > => I'd appreciate some pointers to this problem. About 18 months ago > I asked for 6 ports and got them almost instantly. >> >> 6. Why do we need GRE Header ? >> >> We need GRE tunnel header for various reasons, "when ever we carry >> multiple streams within a tunnel, the GRE header for its mature >> header semantics, the key field and the sequence number field is >> useful." > > => I've added quotes around the area that I'm responding to above Are > you seriously saying that whenever multiple flows are encapsulated in > a packet GRE is needed? If you are then I think this is flat wrong, > factually it's wrong. I hope you can either qualify that or change it > or explain it better. Another comment that was made is that _if_ the problem is to transport link-layer messages (something else than IP) over IP then GRE is not the only solution - L2TP does approximately that too; if I understand the comment correctly. Thus _if_ we know the problem then we still have to choose between several solutions (muxing based on other things than the intermediary tagging header, GRE and L2TP). But I'm not sure I understand very well the problem in the first place. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu Jun 07 06:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFCX-0003HS-3f; Thu, 07 Jun 2007 06:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFCV-0003HK-Nv; Thu, 07 Jun 2007 06:26:43 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwFCU-0004NC-CJ; Thu, 07 Jun 2007 06:26:43 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1181212001!12285776!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9257 invoked from network); 7 Jun 2007 10:26:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 7 Jun 2007 10:26:41 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57AQaZr006008; Thu, 7 Jun 2007 03:26:36 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l57AQaFr013782; Thu, 7 Jun 2007 05:26:36 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l57AQYUC013727; Thu, 7 Jun 2007 05:26:35 -0500 (CDT) Message-ID: <4667DD55.10300@gmail.com> Date: Thu, 07 Jun 2007 12:26:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> <4667D47D.7060909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen E. Nielsen (AH/LMD) wrote: > Hi, > > I agree that DS-MIP model for BU ESP protection is: > >> IPv4-header >> UDP >> IPv6-baseheader >> ESP >> IPv6-MobilityHeader > > But what about ESP tunnel payload protection (and optional way of BU > protection - read: Section 3 of 4877). Here it could be appropriate > to use UDP ESP 3948 to obtain > > IPv4-header > UDP > ESP > IPv6/4-header > Payload/BU Looks meaningful to me (just don't call MobilityHeader 'payload' :-) > but, then the question for me is - is that also the intention in case > of option 3 - or is a different way of ESP tunnel envisaged here. It's a question. I show the Chair's call below. I don't know what Raj means by a DS-MIP6 'tunnel type message'. Is that an intermediary header between UDP and ESP (in the figure above)? Is that intermediary header a MobileIPv4-header? Is that the rfc3012 Generalized MIP Auth Extension replacing ESP? Is that GRE? I think your figure above looks good. Alex Raj originally posted 'issue 93 summary': [...] > Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The > encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type of > protocol being encapsulated in the UDP header. > > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message > > Pros and cons of these choices are in the slides that were presented > at IETF68 (see URL above). > > Please provide your opinions and comments by May 15th, 07 on the MIP6 > mailing list. > > -Raj ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu Jun 07 08:02:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwGgm-00055O-Cw; Thu, 07 Jun 2007 08:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwGgi-00053x-KJ; Thu, 07 Jun 2007 08:02:00 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwGgh-0008Md-3p; Thu, 07 Jun 2007 08:02:00 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070607120155.ZNSL19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Thu, 7 Jun 2007 12:01:55 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 12:01:55 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Date: Thu, 7 Jun 2007 22:01:48 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqA= Message-Id: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > I agree that DS-MIP model for BU ESP protection is: => Perhaps the draft needs clarification because there is no reason why this should be the only model. > > > IPv4-header > > UDP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > But what about ESP tunnel payload protection (and optional way of BU > protection - read: Section 3 of 4877). > Here it could be appropriate to use UDP ESP 3948 to obtain > > IPv4-header > UDP > ESP > IPv6/4-header > Payload/BU > => Right, which we do support today. > but, then the question for me is - is that also the > intention in case of > option 3 - or > is a different way of ESP tunnel envisaged here. => That's how I understood your original question, it's not a general question, it's specific to the option 3 case. Unless I'm missing something I don't think the latter format (3948) would work in this case due to the additional TLV. Hesham > > Karen > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: 7. juni 2007 11:49 > > To: Hesham Soliman > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > Subject: Re: [Mip6] issue 93 summary > > > > Hesham Soliman wrote: > > > Hi Karen, > > > > > > Good question. I don't know actually. Transport ESP on the outer > > > header is obviously not a good idea. Transport ESP on the > > inner header > > > is obviously possible. It doesn't seem like UDP > > encapsulated ESP as per 3948 is possible. > > > Anyone else has a comment on this? > > > > YEs. > > > > I don't think implementations of DS-MIPv6 do what rfc3948 > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 > > operations are mainly about re-computing checksums in UDP > > header. Doesn't mean it should be ignored. > > > > I think the differences between RFC3948 (UDP-ESP) and > > DS-MIPv6 use of ESP lie in the style of approach of using > > ESP. It's not only the typical tunnel vs transport mode. > > > > It is about which style of ESP? IPv4-style or IPv6-style > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after > > the UDP header, RFC3948)? > > Or the ESP as used by the inner typical IPv6 packet > > (IPv6baseheader-ESPheader-MobilityHEader). > > > > The exact placing of the ESP header (with respect to UDP and IPv6 > > headers) obviously has an impact of the level of protection > > afforded. I believe for maximum protection there may be two > > ESP headers. > > > > I think what DS-MIPv6 assumes is this: > > > > IPv4-header > > UDP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > > > I think what RFC3948 suggests is this: > > > > IPv4-header IPv4-header > > UDP or UDP > > ESP ESP > > IPv6-MobilityHeader IPv6-baseheader > > IPv6-MobilityHeader > > > > Two ESP headers - one IPv4 style and the other IPv6 style - > > would look like this: > > > > IPv4-header > > UDP > > ESP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > > > But that has two ESP headers and UDP is still exposed. So > > better would be: > > > > IPv4-header > > ESP > > IPv4-header > > UDP > > ESP > > IPv6-header > > > > But that doesn't traverse NATs because UDP is not seen by > > NAT :-( (I think this was already discussed recently). > > > > Maybe a shorter-packet alternative is this: > > > > IPv4-header > > UDP > > ESP > > IPv6-MobilityHeader. > > > > I think in practice the implementer will prefer to either use > > IPsec code from that s/he usually uses for IPv4 or for IPv6. > > But packets surely look different. > > > > Alex > > > > > _____________________________________________________________ > _________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit > > http://www.messagelabs.com/email > > > _____________________________________________________________ > _________ > > > From nemo-bounces@ietf.org Thu Jun 07 08:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH2j-0000h8-Sw; Thu, 07 Jun 2007 08:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH1l-0008Ne-Fd; Thu, 07 Jun 2007 08:23:45 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwH0V-0004cp-Ea; Thu, 07 Jun 2007 08:22:28 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1181218946!1064795!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4539 invoked from network); 7 Jun 2007 12:22:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 7 Jun 2007 12:22:26 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57CMP3s003942; Thu, 7 Jun 2007 05:22:25 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l57CMO2D024839; Thu, 7 Jun 2007 07:22:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l57CMMje024760; Thu, 7 Jun 2007 07:22:22 -0500 (CDT) Message-ID: <4667F876.9030109@gmail.com> Date: Thu, 07 Jun 2007 14:22:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: nemo@ietf.org, mip6@ietf.org, "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > > > I agree that DS-MIP model for BU ESP protection is: > > => Perhaps the draft needs clarification because there is no reason why this > should be the only model. > > > > > > IPv4-header > > > UDP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > But what about ESP tunnel payload protection (and optional way of BU > > protection - read: Section 3 of 4877). > > Here it could be appropriate to use UDP ESP 3948 to obtain > > > > IPv4-header > > UDP > > ESP > > IPv6/4-header > > Payload/BU > > > > => Right, which we do support today. > > > but, then the question for me is - is that also the > > intention in case of > > option 3 - or > > is a different way of ESP tunnel envisaged here. > > => That's how I understood your original question, it's not a general > question, it's specific to the option 3 case. Unless I'm missing something I > don't think the latter format (3948) would work in this case due to the > additional TLV. I don't think either. If the additional TLV is after ESP then we the existing ESP spec may not say how to calculate ESP fields across that TLV: IPv4-header UDP ESP TLV-tunneltypemessage IPv6-baseheader IPv6-MobilityHeader If the additional TLV is before the ESP then it is obviously insecure: IPv4-header UDP TLV-tunneltypemessage ESP IPv6-baseheader IPv6-MobilityHeader Alex > > Hesham > > > > > Karen > > > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: 7. juni 2007 11:49 > > > To: Hesham Soliman > > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > > Subject: Re: [Mip6] issue 93 summary > > > > > > Hesham Soliman wrote: > > > > Hi Karen, > > > > > > > > Good question. I don't know actually. Transport ESP on the outer > > > > header is obviously not a good idea. Transport ESP on the > > > inner header > > > > is obviously possible. It doesn't seem like UDP > > > encapsulated ESP as per 3948 is possible. > > > > Anyone else has a comment on this? > > > > > > YEs. > > > > > > I don't think implementations of DS-MIPv6 do what rfc3948 > > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 > > > operations are mainly about re-computing checksums in UDP > > > header. Doesn't mean it should be ignored. > > > > > > I think the differences between RFC3948 (UDP-ESP) and > > > DS-MIPv6 use of ESP lie in the style of approach of using > > > ESP. It's not only the typical tunnel vs transport mode. > > > > > > It is about which style of ESP? IPv4-style or IPv6-style > > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after > > > the UDP header, RFC3948)? > > > Or the ESP as used by the inner typical IPv6 packet > > > (IPv6baseheader-ESPheader-MobilityHEader). > > > > > > The exact placing of the ESP header (with respect to UDP and IPv6 > > > headers) obviously has an impact of the level of protection > > > afforded. I believe for maximum protection there may be two > > > ESP headers. > > > > > > I think what DS-MIPv6 assumes is this: > > > > > > IPv4-header > > > UDP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > > > I think what RFC3948 suggests is this: > > > > > > IPv4-header IPv4-header > > > UDP or UDP > > > ESP ESP > > > IPv6-MobilityHeader IPv6-baseheader > > > IPv6-MobilityHeader > > > > > > Two ESP headers - one IPv4 style and the other IPv6 style - > > > would look like this: > > > > > > IPv4-header > > > UDP > > > ESP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > > > But that has two ESP headers and UDP is still exposed. So > > > better would be: > > > > > > IPv4-header > > > ESP > > > IPv4-header > > > UDP > > > ESP > > > IPv6-header > > > > > > But that doesn't traverse NATs because UDP is not seen by > > > NAT :-( (I think this was already discussed recently). > > > > > > Maybe a shorter-packet alternative is this: > > > > > > IPv4-header > > > UDP > > > ESP > > > IPv6-MobilityHeader. > > > > > > I think in practice the implementer will prefer to either use > > > IPsec code from that s/he usually uses for IPv4 or for IPv6. > > > But packets surely look different. > > > > > > Alex > > > > > > > > _____________________________________________________________ > > _________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit > > > http://www.messagelabs.com/email > > > > > _____________________________________________________________ > > _________ > > > > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu Jun 07 10:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJST-0003iZ-Ik; Thu, 07 Jun 2007 10:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJSR-0003iO-VY; Thu, 07 Jun 2007 10:59:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJSP-0005vH-EH; Thu, 07 Jun 2007 10:59:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 07:59:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary thread-index: Aceo/tmNS8cVk6UjSGeFqBKAzz3nIAAFSW4g References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> <4667F876.9030109@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" , "Hesham Soliman" , "Karen E. Nielsen \(AH/LMD\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This discussion is creating confusion. Obviously if we have the TLV that comes after the UDP header, we are not really using RFC 3948 (UDP encapsulation for ESP). It would still work fine. The port number in UDP header would not point to ESP. It would point this new TLV (MIP tunnel data message header). The TLV's port/protocol field will then point to ESP.=20 There is *no* problem in encryption or calculating the MAC in the ESP header. It would work fine with the TLV header. =20 Vijay=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, June 07, 2007 5:22 AM > To: Hesham Soliman > Cc: nemo@ietf.org; mip6@ietf.org > Subject: Re: [Mip6] issue 93 summary >=20 > Hesham Soliman wrote: > >=20 > > > I agree that DS-MIP model for BU ESP protection is:=20 > >=20 > > =3D> Perhaps the draft needs clarification because there is=20 > no reason why this > > should be the only model. > >=20 > > >=20 > > > > IPv4-header > > > > UDP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > >=20 > > > But what about ESP tunnel payload protection (and=20 > optional way of BU > > > protection - read: Section 3 of 4877). > > > Here it could be appropriate to use UDP ESP 3948 to obtain > > >=20 > > > IPv4-header > > > UDP > > > ESP =20 > > > IPv6/4-header > > > Payload/BU > > >=20 > >=20 > > =3D> Right, which we do support today. > >=20 > > > but, then the question for me is - is that also the=20 > > > intention in case of > > > option 3 - or > > > is a different way of ESP tunnel envisaged here. > >=20 > > =3D> That's how I understood your original question, it's not=20 > a general > > question, it's specific to the option 3 case. Unless I'm=20 > missing something I > > don't think the latter format (3948) would work in this=20 > case due to the > > additional TLV. >=20 > I don't think either. >=20 > If the additional TLV is after ESP then we the existing ESP=20 > spec may not=20 > say how to calculate ESP fields across that TLV: >=20 > IPv4-header > UDP > ESP > TLV-tunneltypemessage > IPv6-baseheader > IPv6-MobilityHeader >=20 > If the additional TLV is before the ESP then it is obviously insecure: >=20 > IPv4-header > UDP > TLV-tunneltypemessage > ESP > IPv6-baseheader > IPv6-MobilityHeader >=20 > Alex >=20 > >=20 > > Hesham > >=20 > > >=20 > > > Karen > > >=20 > > > > -----Original Message----- > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > > > > Sent: 7. juni 2007 11:49 > > > > To: Hesham Soliman > > > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > > > Subject: Re: [Mip6] issue 93 summary > > > >=20 > > > > Hesham Soliman wrote: > > > > > Hi Karen, > > > > >=20 > > > > > Good question. I don't know actually. Transport ESP=20 > on the outer=20 > > > > > header is obviously not a good idea. Transport ESP on the=20 > > > > inner header=20 > > > > > is obviously possible. It doesn't seem like UDP=20 > > > > encapsulated ESP as per 3948 is possible. > > > > > Anyone else has a comment on this? > > > >=20 > > > > YEs. > > > >=20 > > > > I don't think implementations of DS-MIPv6 do what rfc3948=20 > > > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948=20 > > > > operations are mainly about re-computing checksums in UDP=20 > > > > header. Doesn't mean it should be ignored. > > > >=20 > > > > I think the differences between RFC3948 (UDP-ESP) and=20 > > > > DS-MIPv6 use of ESP lie in the style of approach of using=20 > > > > ESP. It's not only the typical tunnel vs transport mode. > > > >=20 > > > > It is about which style of ESP? IPv4-style or IPv6-style=20 > > > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after=20 > > > > the UDP header, RFC3948)?=20 > > > > Or the ESP as used by the inner typical IPv6 packet=20 > > > > (IPv6baseheader-ESPheader-MobilityHEader). > > > >=20 > > > > The exact placing of the ESP header (with respect to=20 > UDP and IPv6 > > > > headers) obviously has an impact of the level of protection=20 > > > > afforded. I believe for maximum protection there may be two=20 > > > > ESP headers. > > > >=20 > > > > I think what DS-MIPv6 assumes is this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > > >=20 > > > > I think what RFC3948 suggests is this: > > > >=20 > > > > IPv4-header IPv4-header > > > > UDP or UDP > > > > ESP ESP > > > > IPv6-MobilityHeader IPv6-baseheader > > > > IPv6-MobilityHeader > > > >=20 > > > > Two ESP headers - one IPv4 style and the other IPv6 style -=20 > > > > would look like this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > > >=20 > > > > But that has two ESP headers and UDP is still exposed. So=20 > > > > better would be: > > > >=20 > > > > IPv4-header > > > > ESP > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-header > > > >=20 > > > > But that doesn't traverse NATs because UDP is not seen by=20 > > > > NAT :-( (I think this was already discussed recently). > > > >=20 > > > > Maybe a shorter-packet alternative is this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-MobilityHeader. > > > >=20 > > > > I think in practice the implementer will prefer to either use=20 > > > > IPsec code from that s/he usually uses for IPv4 or for IPv6. =20 > > > > But packets surely look different. > > > >=20 > > > > Alex > > > >=20 > > > >=20 > > > _____________________________________________________________ > > > _________ > > > > This email has been scanned by the MessageLabs Email=20 > > > Security System. > > > > For more information please visit=20 > > > > http://www.messagelabs.com/email=20 > > > >=20 > > > _____________________________________________________________ > > > _________ > > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Thu Jun 07 11:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJW7-0005pJ-9a; Thu, 07 Jun 2007 11:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJW6-0005pB-6m; Thu, 07 Jun 2007 11:03:14 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJW5-0007DQ-O3; Thu, 07 Jun 2007 11:03:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l57F3AA25179; Thu, 7 Jun 2007 15:03:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 10:03:03 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A912@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary (Text Adequacy) Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjgAARjEMAADGzLYA== References: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: Subject: [nemo] RE: [Mip6] issue 93 summary (Text Adequacy) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks Hesham. Understood! However, the comment was not regarding a technical issue (in the sense right vs. wrong) here, but about adequacy of the text. It may ,very well, be straight forward in your mind, however, we are not writing a standard for the editor to read and understand! Right? On the other hand, since we are addressing adequacy of the draft text, let me point out a couple of places that you may need to fix in order to reduce the reader's confusion. CASE No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section: 2.3.2.1 Visited network supports IPv4 only (private addresses) " In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled UDP and IPv4. The UDP port used to send the IPv6 packet is TBD. " Here, it is clear that the MN needs to use UDP whenever using a Private IPv4 address, i.e. a NAT is assumed. However, I assume that the MN probably does not know if it is using a private IPv4 address or to be more accurate, if there is a NAT in path or not. Reading further down under the same section when it talks about what the HA does after receiving a BU with IPv4 HAO, it reads the following: " After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option were included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv6 packet and represented as an IPv4-mapped IPv6 address. In addition, the tunnel used MUST indicate UDP encapsulation for NAT traversal. .... " Here it is assumed that there is a NAT and HA marked the tunnel with UDP encapsulation for NAT traversal. Right? There is a lot of assumptions can go in the mind of the reader why this is true, however, the straight forward one is we are talking about private IP addresses anyway. Ok, let us move on. " .......... Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in UDP then encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care- of address in the destination address field. " Please tell me, which scenario we are talking about now?! If we assume that we are talking about private IP addresses, then How in the world, the HA will be able to send packet destined to the MN IPv4 care-of address, which is a private address. OK here is one needs to be adequately clarified. [1] CASE No. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let us continue reading under the same section, the same comments above applies on how the HA sends the BA as per the text below: " ... ............... The binding acknowledgement is encapsulated in UDP then IPv4 with the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination field. The inner IPv6 packet will contain the home agent's IPv6 address as a source address and the mobile node's IPv4 care-of address in the destination address field. The latter is represented as an IPv4-mapped IPv6 address. " Are we still talking about private IPv4 addresses in this scenario? I assume yes, because that is the title of the section and what the previous text indicates. Then the same comment above applies here and an adequate clarification is needed. [2] Finally the section ends the discussion as below, which gives the impression that this whole section assumes that NAT is always in path but does not talk how the MN would know that to start with. " The mobile node needs to maintain the NAT bindings for its current IPv4 care-of address. This is done through sending the binding update regularly to the home agent. " May be it is a good idea to up front highlight the assumption that this section is based on to eliminate a lot of confusion, what is the assumption behind the text of this section? Is it: 1. The IPv4 is a private IP address and there is a NAT on path all the time, or 2. The IPv4 address is a private but not necessary there is a NAT, or 3. There is a NAT regardless of the type of IPv4 address allocated to the MN. Case No. 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 4.1. NAT detection and traversal, it reads: " NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv4 care-of address represented in IPv4-mapped IPv6 format. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field. " This is a clear assumption that the MN uses UDP encapsulation (for sending BU) any time when it is located in an IPv4 only foreign network. Which I assume is the intent here. Let us move on and continue to read under the same section. Now, the below text MAY give an impression that UDP encapsulation is done only when HA detects NAT in the path. Correct? " ......... If the two addresses match, no NAT device was in the path. Otherwise, a NAT device was in the path and the NAT detection option is included in the binding acknowledgement. The binding acknowledgement, and all future packets, are then encapsulated in UDP and IPv4. The source address in the IPv4 header is the IPv4 address of the home agent. The destination address is the IPv4 address received in the IPv4 header encapsulating the binding update (this address will be different from the IPv4 care-of address when a NAT is in the path). " May be another place that clarification is needed. [3] However, here, the dst. IP address is specified correctly:) Reading the below text, I would suggest that an example for, at least, data packets UDP encapsulation like the one for BU and BA is very useful and probably needed. It makes things much cleaner. Instead of just have an indirect reference as in the below paragraph. [3+.5=3D3.5] " If no NAT device was detected in the path between the mobile node and the home agent then IPv6 packets are tunneled in an IPv4 header, unless the home agent forces UDP encapsulation using the F flag. The content of the inner and outer headers are identical to the **** UDP encapsulation case.***=20 " CASE NO. 4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A. Binding update received by the home agent: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, dst=3DHAADDR) DST-OPT HAO (IPv6 home address) Mobility header BU [IPv4 HAO] Where V4ADDR is either the IPv4 care-of address or the address provided by the NAT device. V4COA is the IPv4 care-of address of the mobile node. HAO is the home address option and BU is the binding update, which MAY contain the IPv4 home address option. I believe the definition of V4ADDR is very useful and SHOULD be global. This can be used whenever the text addresses HA functionality where NAT vs. NO NAT is not clearly identified. It eliminates confusion. [3.5 + 0.5=3D4] CASE NO. 5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section: 4.3.1 Sending packets from a visited network. " When the mobile node is located in an IPv4 only network, it will send IPv6 packets to its home agent according to the following format: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) [UDP header] IPv6 header (src=3DV6HoA, dst=3DCN) Upper layer protocols Where the UDP header is only used if a NAT were detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. " Now, the use of the V4ADDR in this context is wrong. We are talking about the MN sending an IPv6 packet in an IPv4 only network. MN will always set the src addr of the outer header to MN's IPv4 Care-of Address. Right? The above format would be perfect if we are talking about the HA receiving an IPv6 packet that the MN sent from an IPv4 only network. Right? The same comment applies to the following case: " Similarly, IPv4 packets are sent according to the following format: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) [UDP header] IPv4 header (src=3DV4HoA, dst=3DV4CN) Upper layer protocols " An adequate clarification is needed. [4+1=3D5] SUGGESTION: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Finally, probably this suggestion is a little too late in the game and have been discussed earlier, but since the MN is roaming in an IPv4 only foreign network, SHOULD not we make it optional to the MN to request that only an IPv4 HoA to be allocated. This would save resources at the HA. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, June 07, 2007 2:03 AM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary >=20 >=20 > > If I understand Jari comments correctly, I think at one=20 > point, he > mentioned that we need to revisit/revaluate the=20 > existing text in the > draft. I looked into the draft but=20 > the only thing that I found w.r.t > option (1) is the following text: > > > > LOCATION NO. 1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 2.3.2.1 Visited network supports IPv4 only (private addresses) >=20 > > In this scenario the mobile node will need to tunnel=20 > IPv6 packets > > containing the binding update to the home agent's IPv4=20 > address. In > > order to traverse the NAT device, IPv6 packets are=20 > > tunneled UDP and > > IPv4. The UDP port used to send the IPv6 packet is TBD. > > > > Basically there is no text included in the draft to=20 > explain how to > identify the type of payload that is=20 > encapsulated in UDP. In > other words > and strictly=20 > speaking, if we take the draft most relevant text above, >=20 > this "TBD" reserved UDP port will always indicate that the >=20 > payload is an > IPv6!=20 >=20 > =3D> No that's not true at all. There is an IP version field in=20 > the IP header that tells you what the header is. The fact=20 > that the IP header fields (for > v4 or v6) are not revisited in this draft does not in any=20 > shape or form suggest that we have no way of parsing header.=20 > I suggest that we get off the header parsing argument because=20 > frankly, it's a waste of time. Everyone knows (including=20 > people who want option 3) that you can do this with the=20 > version field. Let's not debate facts here, it's pointless.=20 >=20 > Hesham >=20 >=20 >=20 From nemo-bounces@ietf.org Thu Jun 07 11:10:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJcd-0004aC-Bj; Thu, 07 Jun 2007 11:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJcb-0004SB-Sl; Thu, 07 Jun 2007 11:09:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJXD-0007rm-R2; Thu, 07 Jun 2007 11:04:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2007 08:04:23 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="491499355:sNHT52356230" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57F4NdJ016892; Thu, 7 Jun 2007 08:04:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57F4C2A020403; Thu, 7 Jun 2007 15:04:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:04:20 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:04:20 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 08:04:20 -0700 Message-ID: <003201c7a915$20437e50$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QA== In-Reply-To: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:04:20.0568 (UTC) FILETIME=[205C5D80:01C7A915] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=555; t=1181228663; x=1182092663; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=msYuQq9yaeNry8d9G99OO6364h3wrwt3gGNJ6Ym3eK4=; b=lfvxmbz9cdJaJZ2EQHPvG4AVmeWvG4Zxr/rdNWWnlpboas8PWRH6bG+9ZL3hfjzDVCzHH6gS fhK4nnj12Wv1QPQBYSkF6d4qcMuT0latLgrauE3wgui8aLNHGROprlvv; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => That's how I understood your original question, it's not a general > question, it's specific to the option 3 case. Unless I'm > missing something I > don't think the latter format (3948) would work in this case > due to the > additional TLV. > If ESP over UDP is negotiated, then the port number will be UDP 4500. We cannot use the DSMIP UDP tunnel port number for this. The packets have to be handled by IPSec process and not MIP process. So, the IPSec issue Karen raised is common for both option#1 and option#3, IMO. Sri From nemo-bounces@ietf.org Thu Jun 07 11:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJlA-0000i8-3l; Thu, 07 Jun 2007 11:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJl8-0000hL-Uh; Thu, 07 Jun 2007 11:18:46 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJl7-00056Q-GD; Thu, 07 Jun 2007 11:18:46 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070607151842.NDV15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:18:42 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:18:42 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Date: Fri, 8 Jun 2007 01:18:37 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <003201c7a915$20437e50$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHw Message-Id: <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => That's how I understood your original question, it's > not a general > > question, it's specific to the option 3 case. Unless I'm > > missing something I > > don't think the latter format (3948) would work in this case > > due to the > > additional TLV. > > > > If ESP over UDP is negotiated, then the port number will be UDP 4500. => Agreed. > We cannot use the DSMIP UDP tunnel port number for this. The packets > have to be handled by IPSec process and not MIP process. So, > the IPSec > issue Karen raised is common for both option#1 and option#3, IMO. => I don't understand this part. If we're using port 4500 and following 3948, how would the IPsec implementation add that TLV or process it at the receiving end? Assume that a packet (v4 or v6) is passed to IPsec for sending, are you saying that the TLV is added to that packet before passing it to IPsec? If so, are you asking that this TLV gets treated as a protocol? It might be too late at night for me here but I don't follow. I don't see this issue in option 1 or 2 because there is no confusion about adding the TLV. Assuming that you answer the above issue, how does a packet that contains the TLV after ESP get processed at the receiving end? I mean, after it's decapsulated how do you parse the packet? you don't necessarily know that it's a TLV, it could be an IP packet as described in 3498. Hesham > > Sri > From nemo-bounces@ietf.org Thu Jun 07 11:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJmU-0003hp-4T; Thu, 07 Jun 2007 11:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJmQ-0003U6-VA; Thu, 07 Jun 2007 11:20:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJmO-0005K5-Q9; Thu, 07 Jun 2007 11:20:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 08:20:04 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="4489113:sNHT23373330" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l57FK3Rb013590; Thu, 7 Jun 2007 08:20:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l57FJoai017148; Thu, 7 Jun 2007 15:20:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:20:00 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:20:00 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" References: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 08:19:59 -0700 Message-ID: <003301c7a917$50538020$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBwABZUbaA= In-Reply-To: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:20:00.0204 (UTC) FILETIME=[506D70C0:01C7A917] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2304; t=1181229604; x=1182093604; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltocloseissue=2093 |Sender:=20; bh=hLmozkhPpoaNrwFAFSTupcQhrP0dBb559v2iRRXWj1I=; b=Ka6eWAhh+z5MZW/egap5a1UCicnOmGrcR30XejEb9K5rFBj55PqYRY3g5UyX8Rmyt9z69mi7 yP0yGjNhjlc2iEj0ip1PClLLFwA5/33tpD2AQeGQ2r8zKqJ3oNQcxM8p; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, > => We discussed this already no? We said that you could > encapsulate a ping > in IP or use a dst option if you want to save bytes. So there > are many ways > of doing this, I don't see this as a Y2K equivalent. > Yes. Your suggestion will work ! A *minor* side affect is that, if a user does a manual ping to the HA, the HA will not be able to differentiate between the user ping to the DSMIP ping, always DSMIP process gets all the packets. > => I'd appreciate some pointers to this problem. About 18 > months ago I asked > for 6 ports and got them almost instantly. > I will let Henrik answer the port number issue. As I mentioned, this was noted by Henrik. > > > > > > 6. Why do we need GRE Header ? > > > > > > We need GRE tunnel header for various reasons, "when ever we > > carry multiple streams within a tunnel, the GRE header for its > > mature header semantics, the key field and the sequence number > > field is useful." > > => I've added quotes around the area that I'm responding to above > Are you seriously saying that whenever multiple flows are > encapsulated in a > packet GRE is needed? > If you are then I think this is flat wrong, factually it's > wrong. I hope you > can either qualify that or change it or explain it better. > > I'll leave it with those comments for now to focus the > discussion, I have > other comments on the rest of the text but let's do it piecemeal. > When a tunnel carries multiple flows from different nodes, the semantics of the outer GRE header are useful. That was my intended comment. Now, I've cleary given the pointers as where its useful. - In Proxy Mobile IPv6, when the MAG is supporting mobile nodes with overlapping private IPv4 addresses, we need a selector that can be used by the tunnel peers for differentiating the flows. - I've given pointers to the three active drafts, using GRE and all are mobility related drafts, leveraging GRE header. George's draft uses GRE key as a way to identify the mobile flows inside. My text above may not be convincing to you, but, the use of GRE is much more than what we think, IMHO. Just these 3 draft and the support for GRE in MIP4, reflect the same. Thanks Sri From nemo-bounces@ietf.org Thu Jun 07 11:25:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJrJ-0000DW-5I; Thu, 07 Jun 2007 11:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJrI-0000D2-3e; Thu, 07 Jun 2007 11:25:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJrG-0006Mx-OS; Thu, 07 Jun 2007 11:25:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 08:25:05 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="160526860:sNHT45326889" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57FP5fR022909; Thu, 7 Jun 2007 08:25:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l57FOt0Y015164; Thu, 7 Jun 2007 15:25:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:25:05 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:25:04 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003201c7a915$20437e50$1220fea9@amer.cisco.com> <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 08:25:04 -0700 Message-ID: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aA= In-Reply-To: <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:25:04.0685 (UTC) FILETIME=[05E98DD0:01C7A918] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1436; t=1181229905; x=1182093905; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=A4rJ+UP8nYAL8+31LrW0/0zAokuRXIU+91bIqFxjhEs=; b=iMkpnjWTJzJqHeDjRmHj61uiSt7JCmWw/MpGzmzXRDTtRJ+IwoT/kJFfb8OtJH9hzjjlr5si exiP+nqN+1GTsyYRtl0ZQl9gXKGVMHIIbnwGyC8QF5agBD3lfPD3zeFU; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > > > We cannot use the DSMIP UDP tunnel port number for this. > The packets > > have to be handled by IPSec process and not MIP process. So, > > the IPSec > > issue Karen raised is common for both option#1 and option#3, IMO. > > => I don't understand this part. If we're using port 4500 and > following > 3948, how would the IPsec implementation add that TLV or > process it at the > receiving end? > Assume that a packet (v4 or v6) is passed to IPsec for > sending, are you > saying that the TLV is added to that packet before passing it > to IPsec? If > so, are you asking that this TLV gets treated as a protocol? > It might be too > late at night for me here but I don't follow. > I don't see this issue in option 1 or 2 because there is no > confusion about > adding the TLV. > > Assuming that you answer the above issue, how does a packet > that contains > the TLV after ESP get processed at the receiving end? I mean, > after it's > decapsulated how do you parse the packet? you don't > necessarily know that > it's a TLV, it could be an IP packet as described in 3498. > > Hesham Ok. If there is no TLV header, how does the IPSec process after decap, demux the packets ? Will it look in the version field as DSMIP ? How does it know, if it needs to feed the packet to the IPv4 forwarding engine or IPv6 forwarding engine ? Sri From nemo-bounces@ietf.org Thu Jun 07 11:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3J-0007ut-Ex; Thu, 07 Jun 2007 11:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3H-0007sv-TF; Thu, 07 Jun 2007 11:37:31 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwK37-0002FK-60; Thu, 07 Jun 2007 11:37:22 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070607153719.QDO15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:37:19 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:37:19 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Date: Fri, 8 Jun 2007 01:37:14 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAA== Message-Id: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > -----Original Message----- > > > > > We cannot use the DSMIP UDP tunnel port number for this. > > The packets > > > have to be handled by IPSec process and not MIP process. So, > > > the IPSec > > > issue Karen raised is common for both option#1 and > option#3, IMO. > > > > => I don't understand this part. If we're using port 4500 and > > following > > 3948, how would the IPsec implementation add that TLV or > > process it at the > > receiving end? > > Assume that a packet (v4 or v6) is passed to IPsec for > > sending, are you > > saying that the TLV is added to that packet before passing it > > to IPsec? If > > so, are you asking that this TLV gets treated as a protocol? > > It might be too > > late at night for me here but I don't follow. > > I don't see this issue in option 1 or 2 because there is no > > confusion about > > adding the TLV. > > > > Assuming that you answer the above issue, how does a packet > > that contains > > the TLV after ESP get processed at the receiving end? I mean, > > after it's > > decapsulated how do you parse the packet? you don't > > necessarily know that > > it's a TLV, it could be an IP packet as described in 3498. > > > > Hesham > > Ok. If there is no TLV header, how does the IPSec process after > decap, demux the packets ? Will it look in the version field > as DSMIP ? How does it know, if it needs to feed the packet > to the IPv4 forwarding engine or IPv6 forwarding engine ? => There is not much listening going on here obviously, my questions reamin unanswered.... To answer your questions, it processes them like any other packet received using 3948, it assumes it's an IP packet and sends it to the stack for normal processing. You get a packet, check with version and send it to ip_input or ip6_input. What's the problem? Incidentally, RFC 3948 says that it works whether the inner packet is v4 or v6. Hesham > > Sri > > From nemo-bounces@ietf.org Thu Jun 07 11:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3R-0008G4-LG; Thu, 07 Jun 2007 11:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3L-0007u8-8N; Thu, 07 Jun 2007 11:37:35 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJzV-00011b-Do; Thu, 07 Jun 2007 11:33:37 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070607153334.DIEC19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:33:34 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070607153333.XWIH6690.oaamta06ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:33:33 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" Date: Fri, 8 Jun 2007 01:33:28 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <003301c7a917$50538020$1220fea9@amer.cisco.com> Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBwABZUbaAAALVYMA== Message-Id: <20070607153333.XWIH6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => We discussed this already no? We said that you could > > encapsulate a ping > > in IP or use a dst option if you want to save bytes. So there > > are many ways > > of doing this, I don't see this as a Y2K equivalent. > > > > Yes. Your suggestion will work ! A *minor* side affect is that, > if a user does a manual ping to the HA, the HA will not be > able to differentiate between the user ping to the DSMIP > ping, always DSMIP process gets all the packets. => Well, sure, and it should. Just like a user ping in plain MIP might get tunnelled unless you force the use of the CoA. > > > We need GRE tunnel header for various reasons, "when ever we > > > carry multiple streams within a tunnel, the GRE header for its > > > mature header semantics, the key field and the sequence number > > > field is useful." > > > > => I've added quotes around the area that I'm responding to above > > Are you seriously saying that whenever multiple flows are > > encapsulated in a > > packet GRE is needed? > > If you are then I think this is flat wrong, factually it's > > wrong. I hope you > > can either qualify that or change it or explain it better. > > > > I'll leave it with those comments for now to focus the > > discussion, I have > > other comments on the rest of the text but let's do it piecemeal. > > > > When a tunnel carries multiple flows from different nodes, the > semantics of the outer GRE header are useful. That was my intended > comment. Now, I've cleary given the pointers as where its useful. > > - In Proxy Mobile IPv6, when the MAG is supporting mobile nodes > with overlapping private IPv4 addresses, we need a selector that > can be used by the tunnel peers for differentiating the flows. > > - I've given pointers to the three active drafts, using GRE and > all are mobility related drafts, leveraging GRE header. George's > draft uses GRE key as a way to identify the mobile flows inside. => Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed for IPv4 networks with overlapping IP addresses and we discussed that before (and it's typically used by the infrastructure not the host). None of that applies here. I already said that if for some reason you need it in PMIP then you can use it before the UDP header. Plus, why are we standardising PMIP extensions in this WG? > > My text above may not be convincing to you, but, the use of GRE is > much more than what we think, IMHO. Just these 3 draft and the > support for GRE in MIP4, reflect the same. => I know GRE is used but the use cases do not apply to our scenarios here. Of course you can create a scenario where you use it from a host if you really want to, my point is that we don't *need* it, as your earlier text seemed to imply in no uncertain terms. How many hosts use GRE today? Hesham > > Thanks > Sri > > > From nemo-bounces@ietf.org Thu Jun 07 11:40:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK5n-0002Np-PP; Thu, 07 Jun 2007 11:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK5l-0002MO-3M; Thu, 07 Jun 2007 11:40:05 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwK5k-0003d1-Mj; Thu, 07 Jun 2007 11:40:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1181230803!22511504!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25588 invoked from network); 7 Jun 2007 15:40:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 7 Jun 2007 15:40:04 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57Fe3rA008882; Thu, 7 Jun 2007 08:40:03 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l57Fe3gG002708; Thu, 7 Jun 2007 10:40:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l57Fe1lq002611; Thu, 7 Jun 2007 10:40:01 -0500 (CDT) Message-ID: <466826CB.10405@gmail.com> Date: Thu, 07 Jun 2007 17:39:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> <4667F876.9030109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: nemo@ietf.org, mip6@ietf.org, "Karen E. Nielsen \(AH/LMD\)" Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > This discussion is creating confusion. Obviously if we have > the TLV that comes after the UDP header, we are not really > using RFC 3948 (UDP encapsulation for ESP). It would still > work fine. The port number in UDP header would not point > to ESP. It would point this new TLV (MIP tunnel data message > header). The TLV's port/protocol field will then point to ESP. Mostly yes. > There is *no* problem in encryption or calculating the MAC > in the ESP header. It would work fine with the TLV header. ??? One doesn't know to encrypt any other thing than an IP packet or the payload of an IP packet... and that TLV is neither. Alex > > Vijay > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, June 07, 2007 5:22 AM >> To: Hesham Soliman >> Cc: nemo@ietf.org; mip6@ietf.org >> Subject: Re: [Mip6] issue 93 summary >> >> Hesham Soliman wrote: >>> > I agree that DS-MIP model for BU ESP protection is: >>> >>> => Perhaps the draft needs clarification because there is >> no reason why this >>> should be the only model. >>> >>> > >>> > > IPv4-header >>> > > UDP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > >>> > But what about ESP tunnel payload protection (and >> optional way of BU >>> > protection - read: Section 3 of 4877). >>> > Here it could be appropriate to use UDP ESP 3948 to obtain >>> > >>> > IPv4-header >>> > UDP >>> > ESP >>> > IPv6/4-header >>> > Payload/BU >>> > >>> >>> => Right, which we do support today. >>> >>> > but, then the question for me is - is that also the >>> > intention in case of >>> > option 3 - or >>> > is a different way of ESP tunnel envisaged here. >>> >>> => That's how I understood your original question, it's not >> a general >>> question, it's specific to the option 3 case. Unless I'm >> missing something I >>> don't think the latter format (3948) would work in this >> case due to the >>> additional TLV. >> I don't think either. >> >> If the additional TLV is after ESP then we the existing ESP >> spec may not >> say how to calculate ESP fields across that TLV: >> >> IPv4-header >> UDP >> ESP >> TLV-tunneltypemessage >> IPv6-baseheader >> IPv6-MobilityHeader >> >> If the additional TLV is before the ESP then it is obviously insecure: >> >> IPv4-header >> UDP >> TLV-tunneltypemessage >> ESP >> IPv6-baseheader >> IPv6-MobilityHeader >> >> Alex >> >>> Hesham >>> >>> > >>> > Karen >>> > >>> > > -----Original Message----- >>> > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> > > Sent: 7. juni 2007 11:49 >>> > > To: Hesham Soliman >>> > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org >>> > > Subject: Re: [Mip6] issue 93 summary >>> > > >>> > > Hesham Soliman wrote: >>> > > > Hi Karen, >>> > > > >>> > > > Good question. I don't know actually. Transport ESP >> on the outer >>> > > > header is obviously not a good idea. Transport ESP on the >>> > > inner header >>> > > > is obviously possible. It doesn't seem like UDP >>> > > encapsulated ESP as per 3948 is possible. >>> > > > Anyone else has a comment on this? >>> > > >>> > > YEs. >>> > > >>> > > I don't think implementations of DS-MIPv6 do what rfc3948 >>> > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 >>> > > operations are mainly about re-computing checksums in UDP >>> > > header. Doesn't mean it should be ignored. >>> > > >>> > > I think the differences between RFC3948 (UDP-ESP) and >>> > > DS-MIPv6 use of ESP lie in the style of approach of using >>> > > ESP. It's not only the typical tunnel vs transport mode. >>> > > >>> > > It is about which style of ESP? IPv4-style or IPv6-style >>> > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after >>> > > the UDP header, RFC3948)? >>> > > Or the ESP as used by the inner typical IPv6 packet >>> > > (IPv6baseheader-ESPheader-MobilityHEader). >>> > > >>> > > The exact placing of the ESP header (with respect to >> UDP and IPv6 >>> > > headers) obviously has an impact of the level of protection >>> > > afforded. I believe for maximum protection there may be two >>> > > ESP headers. >>> > > >>> > > I think what DS-MIPv6 assumes is this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > > >>> > > I think what RFC3948 suggests is this: >>> > > >>> > > IPv4-header IPv4-header >>> > > UDP or UDP >>> > > ESP ESP >>> > > IPv6-MobilityHeader IPv6-baseheader >>> > > IPv6-MobilityHeader >>> > > >>> > > Two ESP headers - one IPv4 style and the other IPv6 style - >>> > > would look like this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > > >>> > > But that has two ESP headers and UDP is still exposed. So >>> > > better would be: >>> > > >>> > > IPv4-header >>> > > ESP >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-header >>> > > >>> > > But that doesn't traverse NATs because UDP is not seen by >>> > > NAT :-( (I think this was already discussed recently). >>> > > >>> > > Maybe a shorter-packet alternative is this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-MobilityHeader. >>> > > >>> > > I think in practice the implementer will prefer to either use >>> > > IPsec code from that s/he usually uses for IPv4 or for IPv6. >>> > > But packets surely look different. >>> > > >>> > > Alex >>> > > >>> > > >>> > _____________________________________________________________ >>> > _________ >>> > > This email has been scanned by the MessageLabs Email >>> > Security System. >>> > > For more information please visit >>> > > http://www.messagelabs.com/email >>> > > >>> > _____________________________________________________________ >>> > _________ >>> > > >>> > >>> >>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu Jun 07 11:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKIk-0006Hr-9j; Thu, 07 Jun 2007 11:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKIj-0006HV-Cw; Thu, 07 Jun 2007 11:53:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKIi-0007t0-2V; Thu, 07 Jun 2007 11:53:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2007 08:53:27 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="2131424:sNHT21429792" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l57FrRht013210; Thu, 7 Jun 2007 08:53:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l57FnM0e021554; Thu, 7 Jun 2007 15:53:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:53:26 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:53:26 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 08:53:25 -0700 Message-ID: <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAAPb+g In-Reply-To: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:53:26.0509 (UTC) FILETIME=[FC4749D0:01C7A91B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1595; t=1181231607; x=1182095607; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=g0bGQQMgvu/HwRcfondDgqBQQRhfpo+ArsqLx3RZoY4=; b=KJHDzkDk0N9eRsRGAePfOcXlJBgVKrjPmT8aBUWcl0rbcmrCL0qx39VxVXAtHwlsFb7Yd+5U 6l919jqIAxCf0voHjTeSzUOoey70FUjrStgFsQmTSbm7DXZiI+hEzvLosCtFYXy67etoFzq8rj zNW88RGMWkzPx74WbOf6iB/XY=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > > Ok. If there is no TLV header, how does the IPSec process after > > decap, demux the packets ? Will it look in the version field > > as DSMIP ? How does it know, if it needs to feed the packet > > to the IPv4 forwarding engine or IPv6 forwarding engine ? > > => There is not much listening going on here obviously, my > questions reamin > unanswered.... No. I'm :) My comment is that, the issue is the same for both. The issue exists and I already agreed to it. Either case, the IPSec process has to parse either the version field of the packet or the TLV header and I dont believe any implementations do either of them today. > To answer your questions, it processes them like any other > packet received > using 3948, it assumes it's an IP packet and sends it to the stack for > normal processing. You get a packet, check with version and send it to > ip_input or ip6_input. What's the problem? Incidentally, RFC > 3948 says that > it works whether the inner packet is v4 or v6. > >From what I interpret from 3948, the mechanism of UDP transport can be used when the outer header and the contained header are both either IPv4 or IPv6. It did not state that the IPSec process has to look in the version field and do the demux to ip_input or ipv6_input. So, it did not talk about a scenario where the payload is IPv6 and the transport is IPv4. If we can get this clarified from the IPSec guys, that will be good. If 3948 can support IPv4, IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not applicable to option #1. Sri From nemo-bounces@ietf.org Thu Jun 07 11:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNq-0001Kw-6j; Thu, 07 Jun 2007 11:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNo-0001KM-LO; Thu, 07 Jun 2007 11:58:44 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKNn-00025X-SC; Thu, 07 Jun 2007 11:58:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57FwFFJ031432; Thu, 7 Jun 2007 18:58:37 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:58:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:58:15 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 15:58:15 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 10:58:24 -0500 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAbY/7M In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:58:15.0294 (UTC) FILETIME=[A86861E0:01C7A91C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In the context of DS-MIP6 and the scope or usage of this functionality by MIP6 or NEMO, I do believe that option 1 is sufficient. The type of packets encapsulated in the UDP tunnel are either IPv4 or IPv6. And as the discussion has shown, parising of these packets is not really a problem. There is no need for an explicit indication of the encapsulated packet type via a header. The 4 byte header as proposed by option 3 adds to the overhead since every packet between the MN and HA will now include it. It could be argued that 4 byte overhead in the overall scope of the headers of the tunnelled packets is not a significant percentage but it still is an overhead that can be avoided. Additionally HC schemes that may be applied to the normal IP/UDP headers will need to be updated or will have to consider this 4 byte header as well. So I do not believe option 3 from an efficiency perspective is a good choice for MIP6. It has been mentioned (by Vijay) that we already support option 2 since we have a separate port for the ESP encapsulated packets and we have this port for packets tunnelled over UDP. If GRE or other packets are in the future determined as being essential to be tunnelled over UDP between the MN and HA another port could be reserved as well. I am of the opinion that when the need for carrying GRE or other packet types is demonstrated either in the MIP6 or NEMO WGs or elsewhere and there is agreement on it, a draft could be written that updates the current DS-MIP6 document and proposes a new port that would enable the MN and HA to process those packets. I do not believe this is being short-sighted because the need for GRE in the context of MIP6 and NEMO has not really been proven inspite of the numerous discussions on the ML. Having felxibility in a protocol is also not a good reason (kitchen sink theory). -Raj On 6/6/07 9:54 PM, "ext Hesham Soliman" wrote: > > > In light of the discussions that went on I thought it would be useful to > summarise the issue and discussions so far to give people who haven't kept > up an insight into what this is all about. > > First the issue text discussed the need for a "TLV" type encoding between > the outer IP header and the inner UDP header. The reason specified in the > issue was that the upper layer parsing the packet can't tell what > information follows UDP unless it is explicitly encoded. Upon further > discussion it was clear that this rationale is not true because the upper > layer can always parse the version field in the IP header following UDP. > > However, the following question was "what if the information following UDP > was not an IP header?". One could encode messages (at least in theory) that > follow UDP and that are not IP. But to save space and reading time, the main > (probably only) example for such information is the use of GRE > encapsulation. Some people don't see the need for the use of GRE and some > people do. I suggested that GRE can be used before UDP and not after, but > that was seen as unhelpful for cases where a NAT is present. > > Since I, after substantial effort, still couldn't find out what the > deployment scenario that needs this might be, I won't try to invent a > scenario for GRE on behalf of people who are calling for it and I'll leave > the floor open for that discussion. The point I wanted to highlight here > that practically this is the only reason left for adding TLV encoding. > > Finally, there are 3 options available for us to move forward and I'll use > the same numbers that Raj use to avoid confusing people: > > 1. Do nothing, keep the draft as is. > > 2. Specify a different port number for the different format suggested. > > 3. Add the TLV encoding suggested in the issue. > > > 1) above implies that should there be agreement in future that the format > suggested in this issue is necessary, it can be achieved using option 2 > (i.e. specify a new port that carries that format). This can be used if, for > example, GRE is needed for NETLMM. A MAG can use a different port from the > one used by the MN. The main reasons expressed by people for choosing 1 > were: > a) Adding 4 bytes on every packet is not needed. > b) GRE is not needed. > > 2) above is pretty clear to everyone I think but Karen Nielsen raised some > questions that people should read. > > 3) I believe 3 is also clear for everyone. Going to 3 will not require a > move to 2) later. Of course this comes at the cost mentioned above. I > believe the main reason expressed by people for this option was "future > proof". > > So, hopefully this gives a summary of the discussion so far. I think there > are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move. For instance, > discuss the deployment scenarios that require GRE, what is "future proof", > why the extra 4 bytes are an issue for those who chose 1) ...etc > 2. Due to current threads more people might express their opionions. > > I'm not too hopeful with 2) above because most of the people that are > actively involved have commented. Plus it would actually be nice to see 1) > being achieved once in a while! So let's try to do that. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Thu Jun 07 11:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNp-0001KY-Sz; Thu, 07 Jun 2007 11:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNo-0001KH-J9; Thu, 07 Jun 2007 11:58:44 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKNn-00025Y-Vi; Thu, 07 Jun 2007 11:58:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57FwFDj023596; Thu, 7 Jun 2007 18:58:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:58:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:58:16 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 15:58:16 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 10:58:25 -0500 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] issue 93 summary (Please review and comment) Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAbZCQp In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:58:16.0819 (UTC) FILETIME=[A9511430:01C7A91C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [nemo] Re: [Mip6] issue 93 summary (Please review and comment) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello, In order to get a better sense of consensus, I would encourage more people who are on the MIP6 ML to express their opinion on this issue (summarized below by Hesham). -Raj On 6/6/07 9:54 PM, "ext Hesham Soliman" wrote: > > > In light of the discussions that went on I thought it would be useful to > summarise the issue and discussions so far to give people who haven't kept > up an insight into what this is all about. > > First the issue text discussed the need for a "TLV" type encoding between > the outer IP header and the inner UDP header. The reason specified in the > issue was that the upper layer parsing the packet can't tell what > information follows UDP unless it is explicitly encoded. Upon further > discussion it was clear that this rationale is not true because the upper > layer can always parse the version field in the IP header following UDP. > > However, the following question was "what if the information following UDP > was not an IP header?". One could encode messages (at least in theory) that > follow UDP and that are not IP. But to save space and reading time, the main > (probably only) example for such information is the use of GRE > encapsulation. Some people don't see the need for the use of GRE and some > people do. I suggested that GRE can be used before UDP and not after, but > that was seen as unhelpful for cases where a NAT is present. > > Since I, after substantial effort, still couldn't find out what the > deployment scenario that needs this might be, I won't try to invent a > scenario for GRE on behalf of people who are calling for it and I'll leave > the floor open for that discussion. The point I wanted to highlight here > that practically this is the only reason left for adding TLV encoding. > > Finally, there are 3 options available for us to move forward and I'll use > the same numbers that Raj use to avoid confusing people: > > 1. Do nothing, keep the draft as is. > > 2. Specify a different port number for the different format suggested. > > 3. Add the TLV encoding suggested in the issue. > > > 1) above implies that should there be agreement in future that the format > suggested in this issue is necessary, it can be achieved using option 2 > (i.e. specify a new port that carries that format). This can be used if, for > example, GRE is needed for NETLMM. A MAG can use a different port from the > one used by the MN. The main reasons expressed by people for choosing 1 > were: > a) Adding 4 bytes on every packet is not needed. > b) GRE is not needed. > > 2) above is pretty clear to everyone I think but Karen Nielsen raised some > questions that people should read. > > 3) I believe 3 is also clear for everyone. Going to 3 will not require a > move to 2) later. Of course this comes at the cost mentioned above. I > believe the main reason expressed by people for this option was "future > proof". > > So, hopefully this gives a summary of the discussion so far. I think there > are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move. For instance, > discuss the deployment scenarios that require GRE, what is "future proof", > why the extra 4 bytes are an issue for those who chose 1) ...etc > 2. Due to current threads more people might express their opionions. > > I'm not too hopeful with 2) above because most of the people that are > actively involved have commented. Plus it would actually be nice to see 1) > being achieved once in a while! So let's try to do that. > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From ubx@bmc.com Thu Jun 07 12:59:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLKy-0000CO-7U for nemo-archive@lists.ietf.org; Thu, 07 Jun 2007 12:59:52 -0400 Received: from [85.105.79.100] (helo=dsl.static.85-105-20324.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwLKx-000642-DU for nemo-archive@lists.ietf.org; Thu, 07 Jun 2007 12:59:52 -0400 Received: from zzp ([126.104.209.137]) by dsl.static.85-105-20324.ttnet.net.tr (8.13.4/8.13.4) with SMTP id l57GxSR0073525; Thu, 7 Jun 2007 19:59:28 +0300 Message-ID: <000b01c7a925$027514a0$89d1687e@zzp> From: "Elmer Bridges" To: Subject: Along the same lines, there is this quote from B. Date: Thu, 7 Jun 2007 19:58:02 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7A93E.27BC3220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Antivirus: avast! (VPS 0624-2, 15.06.2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.4 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 ------=_NextPart_000_0007_01C7A93E.27BC3220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C7A93E.27BDB8C0" ------=_NextPart_001_0008_01C7A93E.27BDB8C0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable So why is a beta release in my top five? This problem is not going away. There is always an implementation out there that is straining against = the limits of what can be done today - and managed today. In Predicting = the Future? Heck, my wife is a professional organization and time management = consultant. More on corporate responsibility: shouldn't the details of = my credit card records be only between me and the credit card company? I think he is on to something here. This is where I regularly store up those treasures that I think I might = want to refer to again, but usually never do. I think most people would = agree that a code of ethics would be helpful, but we need to set some = guidelines on what those ethics would cover. Modern organizations are = going to have to come up with better methods of protecting "their" data. = But what does that mean at the detailed level. The main point of the article seems to be that IT pay is improving. So, skepticism is a virtue, but sometimes analytical "guesses" can be = helpful. These proved to be quite amusing. Some analyst's suggest that such activity is more pervasive and = potentially damaging to data than external attacks. ------=_NextPart_001_0008_01C7A93E.27BDB8C0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"doorman"
So why is a beta release in my top=20 five?
This problem is not going = away.
There is always an implementation out = there that is=20 straining against the limits of what can be done today - and managed = today. In=20 Predicting the Future?
Heck, my wife is a professional = organization and=20 time management consultant. More on corporate responsibility: shouldn't = the details=20 of my credit card records be only between me and the credit card=20 company?
I think he is on to something = here.
This is where I regularly store up = those treasures=20 that I think I might want to refer to again, but usually never do. I = think most=20 people would agree that a code of ethics would be helpful, but we need = to set some=20 guidelines on what those ethics would cover. Modern organizations are = going to have=20 to come up with better methods of protecting "their" data. But what does = that mean=20 at the detailed level.
The main point of the article seems to = be that IT=20 pay is improving.
So, skepticism is a virtue, but = sometimes=20 analytical "guesses" can be helpful.
These proved to be quite = amusing.
Some analyst's suggest that such = activity is more=20 pervasive and potentially damaging to data than external=20 attacks.
------=_NextPart_001_0008_01C7A93E.27BDB8C0-- ------=_NextPart_000_0007_01C7A93E.27BC3220-- From nemo-bounces@ietf.org Thu Jun 07 13:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLLz-0000pC-Nm; Thu, 07 Jun 2007 13:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLLx-0000ov-G1; Thu, 07 Jun 2007 13:00:53 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLLt-0006ZH-V6; Thu, 07 Jun 2007 13:00:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57H0Son028355; Thu, 7 Jun 2007 20:00:48 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 20:00:34 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:00:32 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 17:00:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 12:00:41 -0500 From: Basavaraj Patil To: ext Jari Arkko Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AcepJWEFn1v9MBUYEdyT2wARJNUNiA== In-Reply-To: <466729AE.3000707@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 17:00:32.0217 (UTC) FILETIME=[5BC99490:01C7A925] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, My apologies for the error in the count as well as having missed several people from the count itself. -Raj On 6/6/07 4:39 PM, "ext Jari Arkko" wrote: > All, > The other observation I would make is that in any > case the conclusions sent by the chairs need to > be accurate. I realize that in some cases a response > is unclear or may change/come late. But the counts > need to be right, and contain people who have > sent their opinions to the list. Basavaraj has already > admitted he made a mistake here, and has promised > to get this right in the future. > > > Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Thu Jun 07 14:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwMTG-0004fr-L9; Thu, 07 Jun 2007 14:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwMTF-0004ff-Es for nemo@ietf.org; Thu, 07 Jun 2007 14:12:29 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwMTF-000313-39 for nemo@ietf.org; Thu, 07 Jun 2007 14:12:29 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id B7E78C2F3 for ; Thu, 7 Jun 2007 14:12:27 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l57ICPCx005821; Thu, 7 Jun 2007 14:12:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l57ICMwG006413; Thu, 7 Jun 2007 14:12:25 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id So7Mhw7uCFaf; Thu, 7 Jun 2007 14:12:22 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l57ICJ0b006390;Thu, 7 Jun 2007 14:12:19 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id CF7764FE4C; Thu, 7 Jun 2007 14:10:37 -0400 (EDT) Date: Thu, 7 Jun 2007 14:10:37 -0400 From: Wesley Eddy To: Carlos =?iso-8859-1?Q?Jes=FAs?= Bernardos Cano Message-ID: <20070607181037.GA17616@grc.nasa.gov> References: <1180896152.4812.18.camel@localhost> <20070605153016.GA441@grc.nasa.gov> <1181060222.14265.52.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1181060222.14265.52.camel@localhost> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF NEMO WG , MPI@multicasttech.com Subject: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Tue, Jun 05, 2007 at 06:17:02PM +0200, Carlos Jes=FAs Bernardos Cano w= rote: > >=20 > > I'm not quite sure about this "must be secure" is rather vague and co= uld > > be too loose in that it permits sort-of homebrew schemes that look > > secure at first, but after a few years turn out to not be. I prefer = to > > require the securability to be vai IPsec, since it is well understood= and > > maintained by the IETF, whereas other ways to "secure" RO schemes may= not > > be. >=20 > I think I'm not explained myself clearly. I'm referring to the securit= y > of the RO mechanism itself. As far as I understand, one issue is to > allow end to end traffic to be secured by using IPsec and another issue > is how secure the NEMO RO solution (security was the key issue in the R= O > solution adopted by MIPv6, and this security is not provided by IPsec). > Do you see my point? >=20 I think I understood/understand your question, but I'm still of the opinion that IPsec should be relied on. I don't feel incredibly strongly about this, and could be convinced otherwise though. I understand that the MIPv6 basic RO security isn't IPsec based, but I don't see this as a good reason not to require the NEMO RO to be securable through IPsec. The MIPv6 RO security wasn't built on IPsec because it was felt that the needed PKI structure didn't exist. With recent work like BTNS, I believe this concern could be revisited. RO security based on BTNS seems reasonable to me (for both MIPv6 and NEMO), since it could ensure that communications through the HA are with identical parties as those over the RO path, and it leverages the existing IPsec mechanisms. I would like to hear other opinions about this. Particularly, answers to the questions "Why *not* require securability via IPsec?" would be helpful. --=20 Wesley M. Eddy Verizon Federal Network Systems From nemo-bounces@ietf.org Thu Jun 07 15:53:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwO2X-0005sM-KH; Thu, 07 Jun 2007 15:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwO2V-0005i5-CM; Thu, 07 Jun 2007 15:52:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwO2O-0002ri-CJ; Thu, 07 Jun 2007 15:52:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 12:52:15 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="4504428:sNHT23699466" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57JqFBq017477; Thu, 7 Jun 2007 12:52:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l57Jpwtx012295; Thu, 7 Jun 2007 19:52:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:52:04 -0700 Received: from sgundavewxp ([10.21.80.17]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:52:03 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 12:52:03 -0700 Message-ID: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tA In-Reply-To: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 19:52:03.0725 (UTC) FILETIME=[520113D0:01C7A93D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2728; t=1181245935; x=1182109935; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=G+vkiojpMf2bbnuxXzlerprLipmgs2QXV6y8yUFDFrw=; b=PbKpu1i6MrmLeQVIkwyVemZYtEOA+dDoyTycZVCEwF6dx/DG9ioQNwR2vosdRzRwlfo5Jigo 36TjeBm6bqeJr6/bLuNArc+zK8zQ/cE3a1l9K6BaIhg/Hr7joeKrOALF; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham: > -----Original Message----- > To answer your questions, it processes them like any other > packet received > using 3948, it assumes it's an IP packet and sends it to the stack for > normal processing. You get a packet, check with version and send it to > ip_input or ip6_input. What's the problem? Incidentally, RFC > 3948 says that > it works whether the inner packet is v4 or v6. Clarification to my earlier email on 3948 about the payload identification. The "next header" field in the ESP header identifies the payload. So, there is a proper payload qualifier in ESP header. The packet inside can be IPv4, IPv6 or GRE protocol types. So, when using ESP header, we dont need the additional 4-byte TLV header, as the protocol type qualifier is present. We need the same qualifier when there is no ESP header, when riding on UDP. So, the point to emphasize is that we are asking for a payload qualifier when using UDP, so that we can send GRE packets. We need this: IPv4-UDP-ESP-GRE-(IPv4, IPv6) (This works) IPv4-UDP-TLV-GRE-(IPv4, IPv6) FYI, Cisco's IPSec implementation supports IPv4-UDP-ESP-GRE-IPv6 and not IPv4-UDP-ESP-IPv6, as of now. Just informational. GRE as a generic transport is supported for IPSec in many implementations today. The mode is very popular, IMO. Comments to your other email: > > Yes. Your suggestion will work ! A *minor* side affect is that, > > if a user does a manual ping to the HA, the HA will not be > > able to differentiate between the user ping to the DSMIP > > ping, always DSMIP process gets all the packets. > > => Well, sure, and it should. Just like a user ping in plain > MIP might get > tunnelled unless you force the use of the CoA. So, the user doing a simple ping to the HA, will never pass. The MIP stack on both the ends will capture that and consider that as a keepalive message. Simple side affect, its ok. No big deal, as long as the user understands why his pings to the HA will never pass. => Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed > for IPv4 networks with overlapping IP addresses and we discussed that before > (and it's typically used by the infrastructure not the host). None of that > applies here. I already said that if for some reason you need it in PMIP > then you can use it before the UDP header. Plus, why are we standardizing > PMIP extensions in this WG? DSMIP must be leveraged by PMIP6, that's Jari's direction, as I understand. So, IMO, we need to make sure, what we design here can serve the general MIP6, NEMO and PMIP6 requirements. But, I agree, GRE may not be required for a normal MIP6 tunnel. Regards Sri From nemo-bounces@ietf.org Thu Jun 07 16:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP0n-0003EC-9A; Thu, 07 Jun 2007 16:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP0m-0003E6-Cy for nemo@ietf.org; Thu, 07 Jun 2007 16:55:16 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwP0i-0006sr-TR for nemo@ietf.org; Thu, 07 Jun 2007 16:55:16 -0400 Received: from acorde (acorde.it.uc3m.es [163.117.139.72])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id C009C45C9A; Thu, 7 Jun 2007 22:55:11 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: weddy@grc.nasa.gov In-Reply-To: <20070607181037.GA17616@grc.nasa.gov> References: <1180896152.4812.18.camel@localhost> <20070605153016.GA441@grc.nasa.gov> <1181060222.14265.52.camel@localhost> <20070607181037.GA17616@grc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Thu, 07 Jun 2007 22:55:14 +0200 Message-Id: <1181249714.4614.122.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-6.8075 TC:1F TRN:46 TV:3.6.1039(15224.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF NEMO WG , MPI@multicasttech.com Subject: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Wesley, > I think I understood/understand your question, but I'm still of the > opinion that IPsec should be relied on. I don't feel incredibly > strongly about this, and could be convinced otherwise though. >=20 > I understand that the MIPv6 basic RO security isn't IPsec based, but I > don't see this as a good reason not to require the NEMO RO to be > securable through IPsec. The MIPv6 RO security wasn't built on IPsec > because it was felt that the needed PKI structure didn't exist. With > recent work like BTNS, I believe this concern could be revisited. RO > security based on BTNS seems reasonable to me (for both MIPv6 and NEMO)= , > since it could ensure that communications through the HA are with > identical parties as those over the RO path, and it leverages the > existing IPsec mechanisms. >=20 > I would like to hear other opinions about this. Particularly, answers > to the questions "Why *not* require securability via IPsec?" would be > helpful. >=20 I'm not familiar to the work done in the BTNS WG, although I'll take a look to it (it seems very interesting). Without knowing the details of that on-going work (I'll provide more comments after looking at it), I'd say that IMHO main advantages of using a not IPsec-based RO solution are: no need to change CNs (to support the mechanisms defined by BTNS) and no high additional delay in the handover. Besides that, it might be important to analyse the threat model of a NEMO RO solution and evaluate if a BTNS-based approach is effective at mitigating these threats, compared with a standard MIPv6-based approach. Kind Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From nemo-bounces@ietf.org Thu Jun 07 20:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwSJp-0004QY-K9; Thu, 07 Jun 2007 20:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwSJo-0004Q6-DI; Thu, 07 Jun 2007 20:27:08 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwSJn-0003Sf-UL; Thu, 07 Jun 2007 20:27:08 -0400 Received: from oaamta04ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070608002700.MZES15631.omta04ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Fri, 8 Jun 2007 00:27:00 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04ps.mx.bigpond.com with ESMTP id <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 00:26:59 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Date: Fri, 8 Jun 2007 10:26:55 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OA= Message-Id: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > Clarification to my earlier email on 3948 about the payload > identification. > > The "next header" field in the ESP header identifies the payload. => Ok, so we can't have TLV following that. > So, there is a proper payload qualifier in ESP header. The packet > inside can be IPv4, IPv6 or GRE protocol types. So, when using > ESP header, we dont need the additional 4-byte TLV header, as > the protocol type qualifier is present. => Right, we don't need it and we can't have it anyway. > Comments to your other email: > > > > Yes. Your suggestion will work ! A *minor* side affect is that, > > > if a user does a manual ping to the HA, the HA will not be > > > able to differentiate between the user ping to the DSMIP > > > ping, always DSMIP process gets all the packets. > > > > => Well, sure, and it should. Just like a user ping in plain > > MIP might get > > tunnelled unless you force the use of the CoA. > > So, the user doing a simple ping to the HA, will never pass. > The MIP stack on both the ends will capture that and consider > that as a keepalive message. => I don't know why you think the MIP stack has to capture it. This is getting into a side issue but the basic point is that it's done for the NAT, so it can be processed like any normal ping. If you get too uncomfortable with this there are many other ways of solving it, like DO option...etc. So let's not use this point as a justification for an additional header. > => Yes but you're referencing drafts for PMIP and MIPv4! We > know it's needed > > for IPv4 networks with overlapping IP addresses and we > discussed that > before > > (and it's typically used by the infrastructure not the > host). None of that > > applies here. I already said that if for some reason you > need it in PMIP > > then you can use it before the UDP header. Plus, why are > we standardizing > > PMIP extensions in this WG? > > DSMIP must be leveraged by PMIP6, that's Jari's direction, as I > understand. So, IMO, we need to make sure, what we design here > can serve the general MIP6, NEMO and PMIP6 requirements. => Nope. We have requirements from MIP6 and NEMO. Of course it's nice if we can help any other work (including PMIP) if we can, but I think it's wrong to do that at the cost of making the base spec worse for its primary users. If PMIP needs extensions (and it does in other cases) then it can extend those solutions for its own use and still reference this work. We shouldn't burden the base for the case of PMIP, especially when PMIP was never the main user of this work. But, I > agree, GRE may not be required for a normal MIP6 tunnel. => Great. So I think at least we're making progress in understanding where this is perceived to be needed. The question is whether it needs to be done here or in NETLMM where the beneficiary is. I don't think we should be addressing it here. Hesham > > > Regards > Sri > > > > > > > > > > > > From nemo-bounces@ietf.org Thu Jun 07 21:40:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPf-0004fN-7l; Thu, 07 Jun 2007 21:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPb-0004X1-2P; Thu, 07 Jun 2007 21:37:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTCs-0003yI-8Q; Thu, 07 Jun 2007 21:24:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 18:24:01 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="160838784:sNHT48351987" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l581O14f015105; Thu, 7 Jun 2007 18:24:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l581O020027140; Fri, 8 Jun 2007 01:24:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:24:00 -0700 Received: from sgundavewxp ([10.21.80.17]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:24:00 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Date: Thu, 7 Jun 2007 18:24:05 -0700 Message-ID: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgA== X-OriginalArrivalTime: 08 Jun 2007 01:24:00.0432 (UTC) FILETIME=[B1496300:01C7A96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3216; t=1181265841; x=1182129841; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=wigCp7IpxYo0C0a9JXQU6bIn/3AXchiFbQiu8eI4eow=; b=rD+9rDYehtLxmm9lGHRK2eQSBycnCLZc5jF8NI8KQrhh9WTy8GQ4KF1bSVhiHe+gfFJU9W9M v3SCRJCz3asHcA3+K4rifGNDo9A1egZr1+nCczUI0mFXactRyZDJiFfx8ZAeMMA8agN9InWVQE WYS1tocP6A4KB7OgXzF6ZoEhY=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham > > So, there is a proper payload qualifier in ESP header. The packet > > inside can be IPv4, IPv6 or GRE protocol types. So, when using > > ESP header, we dont need the additional 4-byte TLV header, as > > the protocol type qualifier is present. > > => Right, we don't need it and we can't have it anyway. No. We can still have TLV header. But, I'm saying we have a protocol qualifier. I thought, it might be better to avoid atleast for ESP, but, Vijay was suggesting why not have it consistently for all modes ESP or non-ESP modes. This is how the implementation will work: I define tunnel interface with the encap mode of IPv4-UDP-TLV. Now, I apply crypto policy on this interface. All packets GRE, IPv4, IPv6 packets when sent through this interface, will get hit the crypto policy and get the ESP header. As the packets are routed, the tunnel interface will apply the IPv4-UDP-TLV header. For incomming packets, the packets will match the tunnel interface, crypto policy check will remove the ESP header and identify the payloads using the payload qualifier in the "next header" field of the ESP header. This is one way of implementation. With ESP, TLV heeader points to ESP: IPv4-UDP {TLV {ESP (IPv4, IPv6)}} Without ESP, TLV header points to GRE: IPv4-UDP {TLV {GRE (IPv4, IPv6)}} Like I said, we can get some input from the IPSec folks on this, if you disagree with this. We can also avoid TLV header all together, when using ESP. We can carry all protocol types. > > > > DSMIP must be leveraged by PMIP6, that's Jari's direction, as I > > understand. So, IMO, we need to make sure, what we design here > > can serve the general MIP6, NEMO and PMIP6 requirements. > > => Nope. We have requirements from MIP6 and NEMO. Of course > it's nice if we > can help any other work (including PMIP) if we can, but I > think it's wrong > to do that at the cost of making the base spec worse for its > primary users. > If PMIP needs extensions (and it does in other cases) then it > can extend > those solutions for its own use and still reference this > work. We shouldn't > burden the base for the case of PMIP, especially when PMIP > was never the > main user of this work. > > But, I > > agree, GRE may not be required for a normal MIP6 tunnel. > > => Great. So I think at least we're making progress in > understanding where > this is perceived to be needed. The question is whether it > needs to be done > here or in NETLMM where the beneficiary is. I don't think we should be > addressing it here. I think, we can certainly avoid GRE in DSMIP, if we really want to ignore that requirement. There are valid use cases that are there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. As Yoshi pointed out, if some one wants to tunnel legacy IPX or other traffic from the MN to home network, GRE is required. Same thing for routing legacy protocol traffic from a network behind mobile router to the home network. We already talked about the NETLMM requirement. I do not think this 4-byte header will make the "base spec worse", it really addresses all these usecases. Sri From nemo-bounces@ietf.org Thu Jun 07 21:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTl2-0000qY-9L; Thu, 07 Jun 2007 21:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTl0-0000p8-1i; Thu, 07 Jun 2007 21:59:18 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTkw-00066G-Ct; Thu, 07 Jun 2007 21:59:18 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070608015911.WEOJ19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Fri, 8 Jun 2007 01:59:11 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 01:59:11 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Date: Fri, 8 Jun 2007 11:59:06 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3A Message-Id: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => Right, we don't need it and we can't have it anyway. > > No. We can still have TLV header. But, I'm saying we have a > protocol qualifier. I thought, it might be better to avoid > atleast for ESP, but, Vijay was suggesting why not have it > consistently for all modes ESP or non-ESP modes. This is > how the implementation will work: > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > Now, I apply crypto policy on this interface. All packets > GRE, IPv4, IPv6 packets when sent through this interface, will > get hit the crypto policy and get the ESP header. As the packets > are routed, the tunnel interface will apply the IPv4-UDP-TLV > header. For incomming packets, the packets will match the > tunnel interface, crypto policy check will remove the ESP > header and identify the payloads using the payload qualifier > in the "next header" field of the ESP header. This is one > way of implementation. > > With ESP, TLV heeader points to ESP: > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} => Do you agree that this is not 3948? The reason we opened this issue was Karen's question about how we'd use 3948 which defines UDP ESP encapsulation. If you run this format on port 4500 then it obviously won't work. Do you also agree now (given your earlier email) that this is only an issue for option 3 and not 2 and 1? > Like I said, we can get some input from the IPSec folks > on this, if you disagree with this. => I don't understand what input you are seeking, this is a different format from the RFC so if you run it on the same port with an implementation of that RFC then it won't work. What am I missing? > > We can also avoid TLV header all together, when using ESP. > We can carry all protocol types. => I think we'll have to. I don't get this "either or" description. Also adding and removing the TLV field based on whether ESP is used or not doesn't seem to be a good way of doing things because it introduces a dependency between the mobility implementation and the way IPsec is being used. > > => Nope. We have requirements from MIP6 and NEMO. Of course > > it's nice if we > > can help any other work (including PMIP) if we can, but I > > think it's wrong > > to do that at the cost of making the base spec worse for its > > primary users. > > If PMIP needs extensions (and it does in other cases) then it > > can extend > > those solutions for its own use and still reference this > > work. We shouldn't > > burden the base for the case of PMIP, especially when PMIP > > was never the > > main user of this work. > > > > But, I > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > => Great. So I think at least we're making progress in > > understanding where > > this is perceived to be needed. The question is whether it > > needs to be done > > here or in NETLMM where the beneficiary is. I don't think > we should be > > addressing it here. > > > I think, we can certainly avoid GRE in DSMIP, if we really want > to ignore that requirement. There are valid use cases that are > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > As Yoshi pointed out, if some one wants to tunnel legacy IPX > or other traffic from the MN to home network, GRE is required. => You mean you can't carry IPX in IP using proto 111? If a node does not implement IP at all then we're not talking about an MN. If the MR want to tunnel IPX in IP then that would work too. I understand you might prefer GRE, but there is a difference between a MUST and a MAY type goal. A MAY type goal need not be in the base and force everyone else to use it. A MUST goal has to be in the base. I'm a bit sceptical about unexplained scenarios that come piecemeal. If you have a scenario in mind where this is needed for the MR/MN then please write it down. I find it difficult to keep up with the discussion when each email contradicts the one before it. In the last email you said you wanted this for PMIP and MIPv6 didn't need it. Now it's a different story. It's hard for me to discuss things this way. Hesham From nemo-bounces@ietf.org Thu Jun 07 22:15:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwU0C-0005YK-2u; Thu, 07 Jun 2007 22:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwU09-0005Xn-D6; Thu, 07 Jun 2007 22:14:57 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwU09-0001DU-24; Thu, 07 Jun 2007 22:14:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 19:14:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuA= References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Sri Gundavelli" , "Karen E. Nielsen \(AH/LMD\)" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > No. We can still have TLV header. But, I'm saying we have a > > protocol qualifier. I thought, it might be better to avoid > > atleast for ESP, but, Vijay was suggesting why not have it > > consistently for all modes ESP or non-ESP modes. This is > > how the implementation will work: > >=20 > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > Now, I apply crypto policy on this interface. All packets > > GRE, IPv4, IPv6 packets when sent through this interface, will > > get hit the crypto policy and get the ESP header. As the packets > > are routed, the tunnel interface will apply the IPv4-UDP-TLV > > header. For incomming packets, the packets will match the > > tunnel interface, crypto policy check will remove the ESP > > header and identify the payloads using the payload qualifier > > in the "next header" field of the ESP header. This is one > > way of implementation. > >=20 > > With ESP, TLV heeader points to ESP: > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} >=20 > =3D> Do you agree that this is not 3948?=20 Yes, it is not 3948. > The reason we opened=20 > this issue was > Karen's question about how we'd use 3948 which defines UDP ESP > encapsulation. If you run this format on port 4500 then it=20 > obviously won't > work. Do you also agree now (given your earlier email) that=20 > this is only an > issue for option 3 and not 2 and 1?=20 Port 4500 will not be used. The UDP port number will point to the TLV and the TLV will say ESP follows. Vijay >=20 >=20 > > Like I said, we can get some input from the IPSec folks > > on this, if you disagree with this. >=20 > =3D> I don't understand what input you are seeking, this is a=20 > different format > from the RFC so if you run it on the same port with an=20 > implementation of > that RFC then it won't work. What am I missing?=20 >=20 > >=20 > > We can also avoid TLV header all together, when using ESP. > > We can carry all protocol types. >=20 > =3D> I think we'll have to. I don't get this "either or"=20 > description. Also > adding and removing the TLV field based on whether ESP is used or not > doesn't seem to be a good way of doing things because it introduces a > dependency between the mobility implementation and the way=20 > IPsec is being > used.=20 >=20 > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of course=20 > > > it's nice if we > > > can help any other work (including PMIP) if we can, but I=20 > > > think it's wrong > > > to do that at the cost of making the base spec worse for its=20 > > > primary users. > > > If PMIP needs extensions (and it does in other cases) then it=20 > > > can extend > > > those solutions for its own use and still reference this=20 > > > work. We shouldn't > > > burden the base for the case of PMIP, especially when PMIP=20 > > > was never the > > > main user of this work. > > >=20 > > > But, I > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > >=20 > > > =3D> Great. So I think at least we're making progress in=20 > > > understanding where > > > this is perceived to be needed. The question is whether it=20 > > > needs to be done > > > here or in NETLMM where the beneficiary is. I don't think=20 > > we should be > > > addressing it here.=20 > >=20 > >=20 > > I think, we can certainly avoid GRE in DSMIP, if we really want > > to ignore that requirement. There are valid use cases that are > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > As Yoshi pointed out, if some one wants to tunnel legacy IPX > > or other traffic from the MN to home network, GRE is required. >=20 > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > node does not > implement IP at all then we're not talking about an MN. If=20 > the MR want to > tunnel IPX in IP then that would work too.=20 > I understand you might prefer GRE, but there is a difference=20 > between a MUST > and a MAY type goal. A MAY type goal need not be in the base and force > everyone else to use it. A MUST goal has to be in the base.=20 >=20 > I'm a bit sceptical about unexplained scenarios that come=20 > piecemeal. If you > have a scenario in mind where this is needed for the MR/MN=20 > then please write > it down. I find it difficult to keep up with the discussion=20 > when each email > contradicts the one before it. In the last email you said you=20 > wanted this > for PMIP and MIPv6 didn't need it. Now it's a different=20 > story. It's hard for > me to discuss things this way. >=20 > Hesham >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Thu Jun 07 22:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUCg-00047O-22; Thu, 07 Jun 2007 22:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUCe-0003zw-Ss; Thu, 07 Jun 2007 22:27:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUCd-0005O5-GR; Thu, 07 Jun 2007 22:27:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 19:27:51 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="160867009:sNHT45962172" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l582RovQ010089; Thu, 7 Jun 2007 19:27:50 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l582Ro07003645; Fri, 8 Jun 2007 02:27:50 GMT Date: Thu, 7 Jun 2007 19:27:50 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> Message-ID: References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2868; t=1181269670; x=1182133670; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=8E1GOau+IQL0oHPUJrYPJ3isfZ5WlOC1+W3hHh6KBM0=; b=otus8LXfEr9UBZ6iHUV9jMcXy1+7E1IYfd38hvWgkfFR5CrNV/YpYd8ru2y0PkIjR+yZtT1q KPKmLkwpuTfoKaFmBC9NKQ8pzUc5K3dSUXFz5mL3tukUzFeK5IxhPuCi; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham: On Fri, 8 Jun 2007, Hesham Soliman wrote: > > => Do you agree that this is not 3948? The reason we opened this issue was > Karen's question about how we'd use 3948 which defines UDP ESP > encapsulation. If you run this format on port 4500 then it obviously won't > work. Do you also agree now (given your earlier email) that this is only an > issue for option 3 and not 2 and 1? > I'm again saying, we need a protocol qualifier. That is the title of the issue. We just need a way to identify the payload that is carried in a UDP header. ESP provides that and we dont need the TLV for that mode. When ESP is not there, we need the TLV header. Now, with respect to 3948, if it does not permit TLV on top of UDP, fine. No issue, as we dont need it. If using TLV after UDP is not 3948, as Vijay says, I agree. We dont have to use the TLV for that mode. > > > Like I said, we can get some input from the IPSec folks > > on this, if you disagree with this. > > => I don't understand what input you are seeking, this is a different format > from the RFC so if you run it on the same port with an implementation of > that RFC then it won't work. What am I missing? > > > > > We can also avoid TLV header all together, when using ESP. > > We can carry all protocol types. > > => I think we'll have to. I don't get this "either or" description. Also > adding and removing the TLV field based on whether ESP is used or not > doesn't seem to be a good way of doing things because it introduces a > dependency between the mobility implementation and the way IPsec is being > used. I disagree. We can skip the encap, if its not required. > > => You mean you can't carry IPX in IP using proto 111? If a node does not > implement IP at all then we're not talking about an MN. If the MR want to > tunnel IPX in IP then that would work too. > I understand you might prefer GRE, but there is a difference between a MUST > and a MAY type goal. A MAY type goal need not be in the base and force > everyone else to use it. A MUST goal has to be in the base. > Its not about preference. When using IPv4-UDP tunnel, to carry IPX or other payloads, we need GRE. If there is no NAT, I've no issue, GRE can be carried in IPv4, IPv6. > I'm a bit sceptical about unexplained scenarios that come piecemeal. If you > have a scenario in mind where this is needed for the MR/MN then please write > it down. I find it difficult to keep up with the discussion when each email > contradicts the one before it. In the last email you said you wanted this > for PMIP and MIPv6 didn't need it. Now it's a different story. It's hard for > me to discuss things this way. > Lets hear from others. Its my word against your word. We both know exactly what the requirements are and why this is required not required. Sri From nemo-bounces@ietf.org Fri Jun 08 03:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYgQ-0000Dx-G2; Fri, 08 Jun 2007 03:14:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYgO-0000DQ-P0; Fri, 08 Jun 2007 03:14:52 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwYgM-0007iQ-6W; Fri, 08 Jun 2007 03:14:52 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l587EYc4007889; Fri, 8 Jun 2007 10:14:34 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l587EYEr007886; Fri, 8 Jun 2007 10:14:34 +0300 Date: Fri, 8 Jun 2007 10:14:34 +0300 (EEST) From: Pekka Savola To: Hesham Soliman In-Reply-To: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> Message-ID: References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3377/Thu Jun 7 23:20:29 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org, mip6@ietf.org, "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] RE: [Mip6] issue 93 summary - IKE/IPsec X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Thu, 7 Jun 2007, Hesham Soliman wrote: > Good question. I don't know actually. Transport ESP on the outer header is > obviously not a good idea. Transport ESP on the inner header is obviously > possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. > Anyone else has a comment on this? FWIW, when we were writing RFC 4891 ("Using IPsec to Secure IPv6-in-IPv4 Tunnels") Mohan realized that the same issues we were seeing (that were specific to "IKE runs on v4, but tunnel is v6" scenario; converse IP versions is also true) would likely come up with DS-MIP effort as well. This significantly affected our recommendation to use transport mode. RFC 4891 provides some discussion and references on this issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Fri Jun 08 07:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd7Q-0005jp-Mf; Fri, 08 Jun 2007 07:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd7P-0005jb-Kb; Fri, 08 Jun 2007 07:59:03 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwd7O-0008ED-6P; Fri, 08 Jun 2007 07:59:03 -0400 Received: from oaamta01ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070608115859.XFBK19666.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com>; Fri, 8 Jun 2007 11:58:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070608115859.IETK26563.oaamta01ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 11:58:59 +0000 From: "Hesham Soliman" To: "'Pekka Savola'" Date: Fri, 8 Jun 2007 21:58:53 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcepnK8Je1WVgNzgS2yG/nxV+jOwtAAJ6mZw Message-Id: <20070608115859.IETK26563.oaamta01ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org, mip6@ietf.org, "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] RE: [Mip6] issue 93 summary - IKE/IPsec X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks for the pointer Pekka, it's good to know. I'll take a look. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, June 08, 2007 5:15 PM > To: Hesham Soliman > Cc: 'Karen E. Nielsen (AH/LMD)'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary - IKE/IPsec > > On Thu, 7 Jun 2007, Hesham Soliman wrote: > > Good question. I don't know actually. Transport ESP on the > outer header is > > obviously not a good idea. Transport ESP on the inner > header is obviously > > possible. It doesn't seem like UDP encapsulated ESP as per > 3948 is possible. > > Anyone else has a comment on this? > > FWIW, when we were writing RFC 4891 ("Using IPsec to Secure > IPv6-in-IPv4 Tunnels") Mohan realized that the same issues we were > seeing (that were specific to "IKE runs on v4, but tunnel is v6" > scenario; converse IP versions is also true) would likely > come up with > DS-MIP effort as well. This significantly affected our > recommendation > to use transport mode. > > RFC 4891 provides some discussion and references on this issue. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From nemo-bounces@ietf.org Fri Jun 08 08:03:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdBN-0001Mf-M1; Fri, 08 Jun 2007 08:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdBL-0001AN-MY; Fri, 08 Jun 2007 08:03:07 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwdBK-0002jX-TR; Fri, 08 Jun 2007 08:03:07 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070608120304.YIVP8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com>; Fri, 8 Jun 2007 12:03:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 12:03:03 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Sri Gundavelli'" , "'Alexandru Petrescu'" Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 22:02:57 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAJ4m4g Message-Id: <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Karen, > Option 1 and Option 3 both require scanning of the UDP > payload for ALL > UDP packets. => I don't understand why option 1 requires that. You can negotiate the IPsec SA and run over port 4500 with the following format: IPv4 UDP ESP IPv6 ...etc Where do you foresee the need for scanning all UDP packets? I don't think option 3 is applicable to 3948 as I mentioned in other emails. Hesham As a starting point > this does not seem very nice. > > Karen > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > Sent: 8. juni 2007 04:15 > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen > > (AH/LMD); Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > > > > > No. We can still have TLV header. But, I'm saying we > have a > > > > protocol qualifier. I thought, it might be better to avoid > > > atleast > > > for ESP, but, Vijay was suggesting why not have it > > > consistently for > > > all modes ESP or non-ESP modes. This is > how the > > implementation will > > > work: > > > > > > > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > > > Now, I apply crypto policy on this interface. All > > packets > GRE, > > > IPv4, IPv6 packets when sent through this interface, will > > > get hit > > > the crypto policy and get the ESP header. As the packets > are > > > routed, the tunnel interface will apply the IPv4-UDP-TLV > > > header. > > > For incomming packets, the packets will match the > tunnel > > interface, > > > crypto policy check will remove the ESP > header and > identify the > > > payloads using the payload qualifier > in the "next > > header" field of > > > the ESP header. This is one > way of implementation. > > > > > > > > With ESP, TLV heeader points to ESP: > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > > > > => Do you agree that this is not 3948? > > > > Yes, it is not 3948. > > > > > The reason we opened > > > this issue was > > > Karen's question about how we'd use 3948 which defines UDP ESP > > > encapsulation. If you run this format on port 4500 then it > > obviously > > > won't work. Do you also agree now (given your earlier > > email) that this > > > is only an issue for option 3 and not 2 and 1? > > > > Port 4500 will not be used. The UDP port number will point to > > the TLV and the TLV will say ESP follows. > > > > Vijay > > > > > > > > > > > > Like I said, we can get some input from the IPSec folks > > > on this, > > > if you disagree with this. > > > > > > => I don't understand what input you are seeking, this is a > > different > > > format from the RFC so if you run it on the same port with an > > > implementation of that RFC then it won't work. What am I missing? > > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > We can carry all protocol types. > > > > > > => I think we'll have to. I don't get this "either or" > > > description. Also > > > adding and removing the TLV field based on whether ESP is > > used or not > > > doesn't seem to be a good way of doing things because it > > introduces a > > > dependency between the mobility implementation and the > way IPsec is > > > being used. > > > > > > > > => Nope. We have requirements from MIP6 and NEMO. Of > > course > > > > > it's nice if we > > can help any other work (including > PMIP) if we > > > can, but I > > think it's wrong > > to do that at the > > cost of making > > > the base spec worse for its > > primary users. > > > > > If PMIP needs extensions (and it does in other cases) > > then it > > > > > can extend > > those solutions for its own use and still > > reference > > > this > > work. We shouldn't > > burden the base for > the case of > > > PMIP, especially when PMIP > > was never the > > main > > user of this > > > work. > > > > > > > > > > But, I > > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > > > => Great. So I think at least we're making progress in > > > > > understanding where > > this is perceived to be needed. > > The question > > > is whether it > > needs to be done > > here or in NETLMM > > where the > > > beneficiary is. I don't think > we should be > > > > addressing it here. > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we > > really want > > > > to ignore that requirement. There are valid use cases > that are > > > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > > > As Yoshi pointed out, if some one wants to tunnel legacy > > IPX > or > > > other traffic from the MN to home network, GRE is required. > > > > > > => You mean you can't carry IPX in IP using proto 111? If a > > node does > > > not implement IP at all then we're not talking about an MN. > > If the MR > > > want to tunnel IPX in IP then that would work too. > > > I understand you might prefer GRE, but there is a > > difference between a > > > MUST and a MAY type goal. A MAY type goal need not be in > > the base and > > > force everyone else to use it. A MUST goal has to be in the base. > > > > > > I'm a bit sceptical about unexplained scenarios that come > > piecemeal. > > > If you have a scenario in mind where this is needed for the > > MR/MN then > > > please write it down. I find it difficult to keep up with the > > > discussion when each email contradicts the one before it. > > In the last > > > email you said you wanted this for PMIP and MIPv6 didn't > > need it. Now > > > it's a different story. It's hard for me to discuss > things this way. > > > > > > Hesham > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Fri Jun 08 08:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdMP-0004rN-KN; Fri, 08 Jun 2007 08:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdMN-0004kb-UI; Fri, 08 Jun 2007 08:14:31 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwdMM-0006iG-Ij; Fri, 08 Jun 2007 08:14:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1181304869!1201997!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14397 invoked from network); 8 Jun 2007 12:14:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 8 Jun 2007 12:14:29 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l58CETtS018355; Fri, 8 Jun 2007 05:14:29 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l58CESEC005856; Fri, 8 Jun 2007 07:14:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l58CEQ4Y005796; Fri, 8 Jun 2007 07:14:26 -0500 (CDT) Message-ID: <4669481C.1050205@gmail.com> Date: Fri, 08 Jun 2007 14:14:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen E. Nielsen (AH/LMD) wrote: > Hi, > > Our (Ericsson) implementation of 3948 supports IPv6 in UPD ESP IPv4 > tunnel. For sake of completeness, my implementation of Mobile IPv6 over IPv4 traversing NATs does this for BU/BAck: IPv4 UDP IPv6 AH ESP DO/RH/etc MobilityHader And this for app: IPv4 UDP IPv6 AH ESP DO/RH/etc payload This is not an implementation of DS-MIPv6 however, it's just Mobile IPv6 and NAT traversal. Alex > > BR, Karen > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: 7. juni 2007 17:53 >> To: 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); 'Alexandru Petrescu' >> Cc: nemo@ietf.org; mip6@ietf.org >> Subject: RE: [Mip6] issue 93 summary >> >> >>> > >>> > Ok. If there is no TLV header, how does the IPSec >> process after > >>> decap, demux the packets ? Will it look in the version field > as >>> DSMIP ? How does it know, if it needs to feed the packet > to the >>> IPv4 forwarding engine or IPv6 forwarding engine ? >>> >>> => There is not much listening going on here obviously, my >> questions >>> reamin unanswered.... >> No. I'm :) My comment is that, the issue is the same for both. >> The issue exists and I already agreed to it. Either case, the >> IPSec process has to parse either the version field of the >> packet or the TLV header and I dont believe any >> implementations do either of them today. >> >>> To answer your questions, it processes them like any other packet >>> received using 3948, it assumes it's an IP packet and sends >> it to the >>> stack for normal processing. You get a packet, check with >> version and >>> send it to ip_input or ip6_input. What's the problem? Incidentally, >>> RFC >>> 3948 says that >>> it works whether the inner packet is v4 or v6. >>> >> From what I interpret from 3948, the mechanism of UDP >> transport can be used when the outer header and the contained >> header are both either IPv4 or IPv6. It did not state that >> the IPSec process has to look in the version field and do the >> demux to ip_input or ipv6_input. So, it did not talk about a >> scenario where the payload is IPv6 and the transport is IPv4. >> If we can get this clarified from the IPSec guys, that will >> be good. If 3948 can support IPv4, >> IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is >> not applicable to option #1. >> >> Sri >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Fri Jun 08 11:53:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwgm7-0001uC-DC; Fri, 08 Jun 2007 11:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDEn-000121-TO for nemo@ietf.org; Thu, 07 Jun 2007 04:20:57 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwDEm-000545-Ae for nemo@ietf.org; Thu, 07 Jun 2007 04:20:57 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:20:55 +0200 Received: from [10.193.199.59] ([10.193.199.59]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:20:54 +0200 Message-ID: <4667BFE6.4050401@orange-ftgroup.com> Date: Thu, 07 Jun 2007 10:20:54 +0200 From: frederic.klamm@orange-ftgroup.com User-Agent: Thunderbird 1.5.0.10 (X11/20070305) MIME-Version: 1.0 To: nemo@ietf.org Content-Type: multipart/related; boundary="------------030003020007040802030701" X-OriginalArrivalTime: 07 Jun 2007 08:20:54.0809 (UTC) FILETIME=[C49AA890:01C7A8DC] X-Spam-Score: 3.1 (+++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Fri, 08 Jun 2007 11:53:13 -0400 Subject: [nemo] [Fwd: FW: Last Call: draft-ietf-nemo-multihoming-issues (Analysis of Multihomingin Network Mobility Support) to Informational RFC] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --------------030003020007040802030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hi all,
Regarding the example of deployment scenarios in 3.1:

"x=1: Multihomed mobile networks with a single MR

      o Example 1:

         MR with dual/multiple access interfaces (e.g. 802.11 and GPRS
         capabilities).  This is a (1,1,*) if both accesses are
         performed with the same ISP.  If the two accesses are offered
         by independent ISPs, this is a (1,n,n) configuration."

IMHO the presence of 2 different access providers doesn't require 2 different HA.
A mobile service provider (operating its home net for MIP/NEMO services) may have agreement with several access provider.
Regardless of access technology.
So that :
"If the two accesses are offered by independent ISPs, this may be either a (1,1,1) or a (1,n,n) configuration." 

This remains true from monami6 point of vue, that is : at one given time, 2 tunnels may be established between MR and the same HA, one through 802.11 interface, the other through gprs interface.

number of HA, number of access providers and number of interfaces on MR are a priori independant variables
Unless I'm wrong, this concerns quite all the deployment scenarios examples in 3.1.

regards
	frederic


-------- Message original --------
Sujet: FW: Last Call: draft-ietf-nemo-multihoming-issues (Analysis of Multihomingin Network Mobility Support) to Informational RFC
Date: Wed, 23 May 2007 13:03:35 +0300
De: Jari Arkko <jari.arkko@piuha.net>
Pour: Shim6 <shim6@psg.com>, Monami6 <monami6@ietf.org>
Copie: nemo-chairs@tools.ietf.org
Références: <E1HqUJV-0004V3-KH@stiedprstage1.ietf.org> 


Reviews from these working groups would be desirable
on this document as well:

> The IESG has received a request from the Network Mobility WG (nemo) to 
> consider the following document:
>
> - 'Analysis of Multihoming in Network Mobility Support '
>    <draft-ietf-nemo-multihoming-issues-07.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2007-06-05. Exceptionally, 
> comments may be sent to iesg@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12101&rfc_flag=0
>
>
>
>
>

--

KLAMM Frederic RD-CORE-CAE
CAE/CORE/CPN
Tel : +33 231759306
Email: frederic.klamm@orange-ftgroup.com
R&D Caen.42 rue des coutures BP 6243 - 14066 Caen Cedex 4 - France


Mailer ThunderBird sous Mandriva
Installez simplement votre poste de travail Linux avec http://web2000.rd.francetelecom.fr



--------------030003020007040802030701 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------030003020007040802030701 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------030003020007040802030701-- From tjaraby@bubble-elegance.com Fri Jun 08 12:16:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwh8h-0003Kh-Rw for nemo-archive@lists.ietf.org; Fri, 08 Jun 2007 12:16:39 -0400 Received: from ts2-a76.syktyvkar.dial.rol.ru ([195.46.187.76] helo=bubble-elegance.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwh8a-00023u-SZ for nemo-archive@lists.ietf.org; Fri, 08 Jun 2007 12:16:39 -0400 Message-ID: <001801c7aa09$e78ca410$002a6fdc@light> From: "Lynda Peck" To: "nemo-archive" Subject: Thank you, we accepted your refinance appication Date: Fri, 8 Jun 2007 20:12:40 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C7AA09.E78CA410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1081 X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_NextPart_000_0015_01C7AA09.E78CA410 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If your family OWN property and want IMMEDIATE pin money to spend ANY = way you like, or simply want to LOWER your current payments by a third = or more, here is our deal we can offer you NOW (hurry, this lot will = expire NOW): $336,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest entire payment! Hurry, when the deal is gone, it is gone. Simply fill in this plain = form... Do not worry about approval, your credit history will not disqualify = you! http://tstyutes.com/ ------=_NextPart_000_0015_01C7AA09.E78CA410 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit history = doesn't matter to us!
 
If your family OWN real = estate and want IMMEDIATE ready money to spend ANY way you like, or = simply require to LOWER your entire payment by a third or more, here is = our deal we can offer you TODAY (hurry, this tender will expire = NOW):
 
$345,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have established the lowest entire = payment!
 
Hurry, when our best = deal is gone, it is gone. Simply finish this simplified form... =
 
Do not worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_0015_01C7AA09.E78CA410-- From nemo-bounces@ietf.org Fri Jun 08 12:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhSi-0004IA-0T; Fri, 08 Jun 2007 12:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhSg-00042X-0U; Fri, 08 Jun 2007 12:37:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwhSf-0002hy-Ko; Fri, 08 Jun 2007 12:37:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1181320636!915578!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15605 invoked from network); 8 Jun 2007 16:37:16 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-153.messagelabs.com with SMTP; 8 Jun 2007 16:37:16 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l58GbF42009690; Fri, 8 Jun 2007 09:37:15 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l58GbEvT024617; Fri, 8 Jun 2007 11:37:14 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.175]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l58GbABl024557; Fri, 8 Jun 2007 11:37:11 -0500 (CDT) Message-ID: <466985B6.1060108@gmail.com> Date: Fri, 08 Jun 2007 18:37:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> <4669481C.1050205@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu , Sri Gundavelli Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen E. Nielsen (AH/LMD) wrote: > Hi, > > Just so that we are all clear, the below is ESP IPSec in transport > mode and has nothing to do with 3948 ESP UDP tunnel encapsulation, > :-). Right, it's just a way of implementing Mobile IPv6 over IPv4. > If I understand you correct. Then in your implementation payload data > is only protected at the HA-MN by virtue of end to end IPSec > protection to CN peer - Right ? Sorry no IPsec at CN is assumed. The payload is protected by MN and HA with rfc3776. Alex > > BR, Karen > >> For sake of completeness, my implementation of Mobile IPv6 over >> IPv4 traversing NATs does this for BU/BAck: >> >> IPv4 UDP IPv6 AH ESP DO/RH/etc MobilityHader >> >> And this for app: >> >> IPv4 UDP IPv6 AH ESP DO/RH/etc payload >> >> This is not an implementation of DS-MIPv6 however, it's just Mobile >> IPv6 and NAT traversal. >> >> Alex >> >>> BR, Karen >>> >>>> -----Original Message----- From: Sri Gundavelli >>>> [mailto:sgundave@cisco.com] Sent: 7. juni 2007 17:53 To: >>>> 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); >> 'Alexandru Petrescu' >>>> Cc: nemo@ietf.org; mip6@ietf.org Subject: RE: [Mip6] issue 93 >>>> summary >>>> >>>> >>>>>> >>>>>> Ok. If there is no TLV header, how does the IPSec >>>> process after > >>>>> decap, demux the packets ? Will it look in the version >> field > as >>>>> DSMIP ? How does it know, if it needs to feed the packet > >>>>> to the IPv4 forwarding engine or IPv6 forwarding engine ? >>>>> >>>>> => There is not much listening going on here obviously, my >>>> questions >>>>> reamin unanswered.... >>>> No. I'm :) My comment is that, the issue is the same for both. >>>> The issue exists and I already agreed to it. Either case, >> the IPSec >>>> process has to parse either the version field of the packet or >>>> the TLV header and I dont believe any implementations do >> either of them >>>> today. >>>> >>>>> To answer your questions, it processes them like any other >>>>> packet received using 3948, it assumes it's an IP packet and >>>>> sends >>>> it to the >>>>> stack for normal processing. You get a packet, check with >>>> version and >>>>> send it to ip_input or ip6_input. What's the problem? >> Incidentally, >>>>> RFC 3948 says that it works whether the inner packet is v4 or >>>>> v6. >>>>> >>>> From what I interpret from 3948, the mechanism of UDP >> transport can >>>> be used when the outer header and the contained header are both >>>> either IPv4 or IPv6. It did not state that the IPSec >> process has to >>>> look in the version field and do the demux to ip_input or >> ipv6_input. >>>> So, it did not talk about a scenario where the payload is IPv6 >>>> and the transport is IPv4. If we can get this clarified from >>>> the IPSec guys, that >> will be good. >>>> If 3948 can support IPv4, IPv6 payloads in an IPv4-UDP-ESP, >>>> then the issue exists is not applicable to option #1. >>>> >>>> Sri >>>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Fri Jun 08 13:50:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwib3-00089e-3O; Fri, 08 Jun 2007 13:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwib2-00089M-3v; Fri, 08 Jun 2007 13:50:00 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwib1-0004Lu-Ik; Fri, 08 Jun 2007 13:50:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 10:49:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAJ4m4gAAwoTCA= References: <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Karen E. Nielsen \(AH/LMD\)" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham,=20 > > Option 1 and Option 3 both require scanning of the UDP=20 > > payload for ALL > > UDP packets.=20 >=20 > =3D> I don't understand why option 1 requires that. You can=20 > negotiate the > IPsec SA and run over port 4500 with the following format: >=20 > IPv4 > UDP > ESP > IPv6 > ...etc This is option 2. The UDP port here will point to 4500, different from the UDP port reserved for DS-MIPv6. Vijay >=20 > Where do you foresee the need for scanning all UDP packets? I=20 > don't think > option 3 is applicable to 3948 as I mentioned in other emails. >=20 > Hesham >=20 > As a starting point > > this does not seem very nice. > >=20 > > Karen=20 > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > > Sent: 8. juni 2007 04:15 > > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen=20 > > > (AH/LMD); Alexandru Petrescu > > > Cc: nemo@ietf.org; mip6@ietf.org > > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > >=20 > > > > > No. We can still have TLV header. But, I'm saying we=20 > > have a >=20 > > > > protocol qualifier. I thought, it might be better to avoid =20 > > > > atleast=20 > > > > for ESP, but, Vijay was suggesting why not have it >=20 > > > consistently for=20 > > > > all modes ESP or non-ESP modes. This is > how the=20 > > > implementation will=20 > > > > work: > > > > > > > > > > I define tunnel interface with the encap mode of=20 > IPv4-UDP-TLV. > > > > > Now, I apply crypto policy on this interface. All=20 > > > packets > GRE,=20 > > > > IPv4, IPv6 packets when sent through this interface, will =20 > > > > get hit=20 > > > > the crypto policy and get the ESP header. As the=20 > packets > are=20 > > > > routed, the tunnel interface will apply the IPv4-UDP-TLV >=20 > > > header. =20 > > > > For incomming packets, the packets will match the > tunnel=20 > > > interface,=20 > > > > crypto policy check will remove the ESP > header and=20 > > identify the=20 > > > > payloads using the payload qualifier > in the "next=20 > > > header" field of=20 > > > > the ESP header. This is one > way of implementation. > > > > > > > > > > With ESP, TLV heeader points to ESP: > > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > >=20 > > > > =3D> Do you agree that this is not 3948?=20 > > >=20 > > > Yes, it is not 3948. > > >=20 > > > > The reason we opened > > > > this issue was > > > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > > > encapsulation. If you run this format on port 4500 then it=20 > > > obviously=20 > > > > won't work. Do you also agree now (given your earlier=20 > > > email) that this=20 > > > > is only an issue for option 3 and not 2 and 1? > > >=20 > > > Port 4500 will not be used. The UDP port number will point to=20 > > > the TLV and the TLV will say ESP follows. > > >=20 > > > Vijay > > >=20 > > > >=20 > > > >=20 > > > > > Like I said, we can get some input from the IPSec folks =20 > > > > on this,=20 > > > > if you disagree with this. > > > >=20 > > > > =3D> I don't understand what input you are seeking, this is a=20 > > > different=20 > > > > format from the RFC so if you run it on the same port with an=20 > > > > implementation of that RFC then it won't work. What am=20 > I missing? > > > >=20 > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > > We can carry all protocol types. > > > >=20 > > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > > description. Also > > > > adding and removing the TLV field based on whether ESP is=20 > > > used or not=20 > > > > doesn't seem to be a good way of doing things because it=20 > > > introduces a=20 > > > > dependency between the mobility implementation and the=20 > > way IPsec is=20 > > > > being used. > > > >=20 > > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of=20 > > > course > >=20 > > > > it's nice if we > > can help any other work (including=20 > > PMIP) if we=20 > > > > can, but I > > think it's wrong > > to do that at the=20 > > > cost of making=20 > > > > the base spec worse for its > > primary users. > > > > > > If PMIP needs extensions (and it does in other cases)=20 > > > then it >=20 > > > > > can extend > > those solutions for its own use and still=20 > > > reference=20 > > > > this > > work. We shouldn't > > burden the base for=20 > > the case of=20 > > > > PMIP, especially when PMIP > > was never the > > main=20 > > > user of this=20 > > > > work. > > > > > > > > > > > > But, I > > > > > > > agree, GRE may not be required for a normal=20 > MIP6 tunnel. > > > > > > > > > > > > =3D> Great. So I think at least we're making=20 > progress in > >=20 > > > > understanding where > > this is perceived to be needed.=20 > > > The question=20 > > > > is whether it > > needs to be done > > here or in NETLMM=20 > > > where the=20 > > > > beneficiary is. I don't think > we should be > >=20 > > > addressing it here. > > > > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we=20 > > > really want >=20 > > > > to ignore that requirement. There are valid use cases=20 > > that are >=20 > > > > there for NETLMM, MIP6 and NEMO, we can solve with a=20 > tiny header. > > > > > As Yoshi pointed out, if some one wants to tunnel legacy=20 > > > IPX > or=20 > > > > other traffic from the MN to home network, GRE is required. > > > >=20 > > > > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > > > node does=20 > > > > not implement IP at all then we're not talking about an MN.=20 > > > If the MR=20 > > > > want to tunnel IPX in IP then that would work too. > > > > I understand you might prefer GRE, but there is a=20 > > > difference between a=20 > > > > MUST and a MAY type goal. A MAY type goal need not be in=20 > > > the base and=20 > > > > force everyone else to use it. A MUST goal has to be=20 > in the base. > > > >=20 > > > > I'm a bit sceptical about unexplained scenarios that come=20 > > > piecemeal.=20 > > > > If you have a scenario in mind where this is needed for the=20 > > > MR/MN then=20 > > > > please write it down. I find it difficult to keep up with the=20 > > > > discussion when each email contradicts the one before it.=20 > > > In the last=20 > > > > email you said you wanted this for PMIP and MIPv6 didn't=20 > > > need it. Now=20 > > > > it's a different story. It's hard for me to discuss=20 > > things this way. > > > >=20 > > > > Hesham > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri Jun 08 14:04:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiov-0001Vp-OZ; Fri, 08 Jun 2007 14:04:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiov-0001Vh-5g; Fri, 08 Jun 2007 14:04:21 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwiou-0006Dp-7B; Fri, 08 Jun 2007 14:04:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 11:04:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcg References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > How do you envisage to negotiate the ESP SA for=20 >=20 > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? You negotiate as if you are negotiating for NAT traversal. > - and should IP Sec now be made to understand > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to trick > IPSec to respectively decrypt and extract and encrypt and=20 > insert the ESP > header ? The IPsec implementation shouldn't have to insert the TLV. It would be done by Mobile IPv6. (similar to how Mobile IPv6 inserts the=20 home address option after IPsec is done with adding the ESP header). > In our "fast" IP stack implementation we use 4500 UDP port number > scanning to intercept > UDP ESP packets for IPSec processing. > Option 2 with a specified port for IPv4/IPv6 would be a=20 > straightforward > extension of this. > Option 1 and Option 3 both require scanning of the UDP payload for ALL > UDP packets. As a starting point > this does not seem very nice. You don't have to scan for all UDP ports. Your "fast" IP stack implementation, in addition to port 4500, would need to look for=20 the UDP port that points to the TLV and the TLV port/protocol=20 field that identifies ESP. Vijay >=20 > Karen=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > Sent: 8. juni 2007 04:15 > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen=20 > > (AH/LMD); Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > >=20 > > > > No. We can still have TLV header. But, I'm saying we have a >=20 > > > protocol qualifier. I thought, it might be better to avoid =20 > > > atleast=20 > > > for ESP, but, Vijay was suggesting why not have it >=20 > > consistently for=20 > > > all modes ESP or non-ESP modes. This is > how the=20 > > implementation will=20 > > > work: > > > > > > > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > > > Now, I apply crypto policy on this interface. All=20 > > packets > GRE,=20 > > > IPv4, IPv6 packets when sent through this interface, will =20 > > > get hit=20 > > > the crypto policy and get the ESP header. As the packets > are=20 > > > routed, the tunnel interface will apply the IPv4-UDP-TLV >=20 > > header. =20 > > > For incomming packets, the packets will match the > tunnel=20 > > interface,=20 > > > crypto policy check will remove the ESP > header and=20 > identify the=20 > > > payloads using the payload qualifier > in the "next=20 > > header" field of=20 > > > the ESP header. This is one > way of implementation. > > > > > > > > With ESP, TLV heeader points to ESP: > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > >=20 > > > =3D> Do you agree that this is not 3948?=20 > >=20 > > Yes, it is not 3948. > >=20 > > > The reason we opened > > > this issue was > > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > > encapsulation. If you run this format on port 4500 then it=20 > > obviously=20 > > > won't work. Do you also agree now (given your earlier=20 > > email) that this=20 > > > is only an issue for option 3 and not 2 and 1? > >=20 > > Port 4500 will not be used. The UDP port number will point to=20 > > the TLV and the TLV will say ESP follows. > >=20 > > Vijay > >=20 > > >=20 > > >=20 > > > > Like I said, we can get some input from the IPSec folks =20 > > > on this,=20 > > > if you disagree with this. > > >=20 > > > =3D> I don't understand what input you are seeking, this is a=20 > > different=20 > > > format from the RFC so if you run it on the same port with an=20 > > > implementation of that RFC then it won't work. What am I missing? > > >=20 > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > We can carry all protocol types. > > >=20 > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > description. Also > > > adding and removing the TLV field based on whether ESP is=20 > > used or not=20 > > > doesn't seem to be a good way of doing things because it=20 > > introduces a=20 > > > dependency between the mobility implementation and the=20 > way IPsec is=20 > > > being used. > > >=20 > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of=20 > > course > >=20 > > > it's nice if we > > can help any other work (including=20 > PMIP) if we=20 > > > can, but I > > think it's wrong > > to do that at the=20 > > cost of making=20 > > > the base spec worse for its > > primary users. > > > > > If PMIP needs extensions (and it does in other cases)=20 > > then it >=20 > > > > can extend > > those solutions for its own use and still=20 > > reference=20 > > > this > > work. We shouldn't > > burden the base for the case of=20 > > > PMIP, especially when PMIP > > was never the > > main=20 > > user of this=20 > > > work. > > > > > > > > > > But, I > > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > > > =3D> Great. So I think at least we're making progress in > > = > > > understanding where > > this is perceived to be needed.=20 > > The question=20 > > > is whether it > > needs to be done > > here or in NETLMM=20 > > where the=20 > > > beneficiary is. I don't think > we should be > >=20 > > addressing it here. > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we=20 > > really want >=20 > > > to ignore that requirement. There are valid use cases that are >=20 > > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > > > As Yoshi pointed out, if some one wants to tunnel legacy=20 > > IPX > or=20 > > > other traffic from the MN to home network, GRE is required. > > >=20 > > > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > > node does=20 > > > not implement IP at all then we're not talking about an MN.=20 > > If the MR=20 > > > want to tunnel IPX in IP then that would work too. > > > I understand you might prefer GRE, but there is a=20 > > difference between a=20 > > > MUST and a MAY type goal. A MAY type goal need not be in=20 > > the base and=20 > > > force everyone else to use it. A MUST goal has to be in the base. > > >=20 > > > I'm a bit sceptical about unexplained scenarios that come=20 > > piecemeal.=20 > > > If you have a scenario in mind where this is needed for the=20 > > MR/MN then=20 > > > please write it down. I find it difficult to keep up with the=20 > > > discussion when each email contradicts the one before it.=20 > > In the last=20 > > > email you said you wanted this for PMIP and MIPv6 didn't=20 > > need it. Now=20 > > > it's a different story. It's hard for me to discuss=20 > things this way. > > >=20 > > > Hesham > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 From nemo-bounces@ietf.org Fri Jun 08 17:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlny-0000al-Uv; Fri, 08 Jun 2007 17:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlnx-0000ac-HW; Fri, 08 Jun 2007 17:15:33 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlnx-0001WB-0J; Fri, 08 Jun 2007 17:15:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 14:15:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQA== References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > Thanks! I understand the port scanning issue=20 > as well as the insertion/extraction of TLV > header much better now. Sorry to have caused any confusion. >=20 > So would it be correct to say that the real difference IPSec-wise, > in-between=20 > option 1,2 and option 3 is that with option 3, then logically=20 > MIP need=20 > "to come in" before inbound and after outbound IPSec processing=20 > to extract/insert TLV and update length fields. > Whereas this is not the case with option 1 and 2. Yes. The TVL would be added for all packets that are sent through=20 a tunnel setup by DS-MIPv6, when the mobile node is on an IPv4=20 access network. >=20 > As it is also not the case in standard MIPv6 with IPSec=20 > tunneling to HA. Well, we kind of have tighter integration between MIPv6 and IPsec already. For e.g, the insertation of home address option and=20 routing header is done by MIPv6 after IPsec processing is done.=20 The use of 'K' bit (to update the tunnel end point) also requires this. I am not suggesting we continue doing this, but adding TLV shouldn't be a big issue. :) Vijay >=20 > Karen >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > Sent: 8. juni 2007 20:04 > > To: Karen E. Nielsen (AH/LMD); Hesham Soliman; Sri=20 > > Gundavelli; Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > >=20 > > > How do you envisage to negotiate the ESP SA for > > >=20 > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? > >=20 > > You negotiate as if you are negotiating for NAT traversal. > >=20 > > > - and should IP Sec now be made to understand > > > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to=20 > > trick IPSec=20 > > > to respectively decrypt and extract and encrypt and=20 > insert the ESP=20 > > > header ? > >=20 > > The IPsec implementation shouldn't have to insert the TLV. It=20 > > would be done by Mobile IPv6. (similar to how Mobile IPv6=20 > > inserts the home address option after IPsec is done with=20 > > adding the ESP header). > >=20 > > > In our "fast" IP stack implementation we use 4500 UDP port number=20 > > > scanning to intercept UDP ESP packets for IPSec processing. > > > Option 2 with a specified port for IPv4/IPv6 would be a=20 > > > straightforward extension of this. > > > Option 1 and Option 3 both require scanning of the UDP=20 > > payload for ALL=20 > > > UDP packets. As a starting point this does not seem very nice. > >=20 > > You don't have to scan for all UDP ports. Your "fast" IP=20 > > stack implementation, in addition to port 4500, would need to=20 > > look for the UDP port that points to the TLV and the TLV=20 > > port/protocol field that identifies ESP. > >=20 > > Vijay > >=20 > > >=20 > > > Karen > > >=20 > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > > > Sent: 8. juni 2007 04:15 > > > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen (AH/LMD);=20 > > > > Alexandru Petrescu > > > > Cc: nemo@ietf.org; mip6@ietf.org > > > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > > >=20 > > > > > > No. We can still have TLV header. But, I'm saying we=20 > > have a >=20 > > > > > protocol qualifier. I thought, it might be better to=20 > > avoid atleast=20 > > > > > for ESP, but, Vijay was suggesting why not have it > > > > > consistently for > > > > > all modes ESP or non-ESP modes. This is > how the > > > > implementation will > > > > > work: > > > > > > > > > > > > I define tunnel interface with the encap mode of=20 > > IPv4-UDP-TLV. > > > > > > Now, I apply crypto policy on this interface. All > > > > packets > GRE, > > > > > IPv4, IPv6 packets when sent through this interface,=20 > > will get hit=20 > > > > > the crypto policy and get the ESP header. As the=20 > packets > are=20 > > > > > routed, the tunnel interface will apply the IPv4-UDP-TLV > > > > > header. =20 > > > > > For incomming packets, the packets will match the > tunnel > > > > interface, > > > > > crypto policy check will remove the ESP > header and > > > identify the > > > > > payloads using the payload qualifier > in the "next > > > > header" field of > > > > > the ESP header. This is one > way of implementation. > > > > > > > > > > > > With ESP, TLV heeader points to ESP: > > > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > > >=20 > > > > > =3D> Do you agree that this is not 3948?=20 > > > >=20 > > > > Yes, it is not 3948. > > > >=20 > > > > > The reason we opened > > > > > this issue was > > > > > Karen's question about how we'd use 3948 which=20 > defines UDP ESP=20 > > > > > encapsulation. If you run this format on port 4500 then it > > > > obviously > > > > > won't work. Do you also agree now (given your earlier > > > > email) that this > > > > > is only an issue for option 3 and not 2 and 1? > > > >=20 > > > > Port 4500 will not be used. The UDP port number will=20 > point to the=20 > > > > TLV and the TLV will say ESP follows. > > > >=20 > > > > Vijay > > > >=20 > > > > >=20 > > > > >=20 > > > > > > Like I said, we can get some input from the IPSec folks on=20 > > > > > this, if you disagree with this. > > > > >=20 > > > > > =3D> I don't understand what input you are seeking, this is a > > > > different > > > > > format from the RFC so if you run it on the same port with an=20 > > > > > implementation of that RFC then it won't work. What am=20 > > I missing? > > > > >=20 > > > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > > > We can carry all protocol types. > > > > >=20 > > > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > > > description. Also > > > > > adding and removing the TLV field based on whether ESP is > > > > used or not > > > > > doesn't seem to be a good way of doing things because it > > > > introduces a > > > > > dependency between the mobility implementation and the > > > way IPsec is > > > > > being used. > > > > >=20 > > > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of > > > > course > > > > > > > it's nice if we > > can help any other work (including > > > PMIP) if we > > > > > can, but I > > think it's wrong > > to do that at the > > > > cost of making > > > > > the base spec worse for its > > primary users. > > > > > > > If PMIP needs extensions (and it does in other cases) > > > > then it > > > > > > > can extend > > those solutions for its own use and still > > > > reference > > > > > this > > work. We shouldn't > > burden the base for=20 > > the case of=20 > > > > > PMIP, especially when PMIP > > was never the > > main > > > > user of this > > > > > work. > > > > > > > > > > > > > > But, I > > > > > > > > agree, GRE may not be required for a normal=20 > MIP6 tunnel. > > > > > > > > > > > > > > =3D> Great. So I think at least we're making=20 > > progress in > >=20 > > > > > understanding where > > this is perceived to be needed. > > > > The question > > > > > is whether it > > needs to be done > > here or in NETLMM > > > > where the > > > > > beneficiary is. I don't think > we should be > > > > > > addressing it here. > > > > > > > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we > > > > really want > > > > > > to ignore that requirement. There are valid use cases=20 > > that are >=20 > > > > > there for NETLMM, MIP6 and NEMO, we can solve with a=20 > > tiny header. > > > > > > As Yoshi pointed out, if some one wants to tunnel legacy > > > > IPX > or > > > > > other traffic from the MN to home network, GRE is required. > > > > >=20 > > > > > =3D> You mean you can't carry IPX in IP using proto 111? If a > > > > node does > > > > > not implement IP at all then we're not talking about an MN.=20 > > > > If the MR > > > > > want to tunnel IPX in IP then that would work too. > > > > > I understand you might prefer GRE, but there is a > > > > difference between a > > > > > MUST and a MAY type goal. A MAY type goal need not be in > > > > the base and > > > > > force everyone else to use it. A MUST goal has to be in=20 > > the base. > > > > >=20 > > > > > I'm a bit sceptical about unexplained scenarios that come > > > > piecemeal.=20 > > > > > If you have a scenario in mind where this is needed for the > > > > MR/MN then > > > > > please write it down. I find it difficult to keep up with the=20 > > > > > discussion when each email contradicts the one before it. > > > > In the last > > > > > email you said you wanted this for PMIP and MIPv6 didn't > > > > need it. Now > > > > > it's a different story. It's hard for me to discuss > > > things this way. > > > > >=20 > > > > > Hesham > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From nemo-bounces@ietf.org Sat Jun 09 10:27:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1u4-0006GW-5l; Sat, 09 Jun 2007 10:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1u2-0006G8-4v; Sat, 09 Jun 2007 10:26:54 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx1u0-0002Q5-6w; Sat, 09 Jun 2007 10:26:54 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070609142649.NMVN23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Sat, 9 Jun 2007 14:26:49 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070609142649.MWDH5648.oaamta07ps.mx.bigpond.com@PC20005>; Sat, 9 Jun 2007 14:26:49 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Sri Gundavelli'" , "'Alexandru Petrescu'" Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Sun, 10 Jun 2007 00:26:43 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAAa2WeA= Message-Id: <20070609142649.MWDH5648.oaamta07ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > Well, we kind of have tighter integration between MIPv6 and > > IPsec already. For e.g, the insertation of home address > > option and routing header is done by MIPv6 after IPsec > > processing is done. > > The use of 'K' bit (to update the tunnel end point) also > > requires this. I am not suggesting we continue doing this, > > but adding TLV shouldn't be a big issue. :) > > > > Vijay > > > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing > and there is a > very good reason > IPSec shouldn't know about those as we exactly want the > movement to be > transparent to > IPSec SAs anchored on the MN's home address. => Which does not at all result in tight integration with IPsec, quite the opposite in fact. It is done to be transparent to IPsec. There is no extraction/insertion, we swap the content with the src/dst address. Having tight integration with IPsec means that we would require IPsec to know these mobility specific events. Hesham > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more > like a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > > I agree that it is feasible from an implementation perspective. > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. > > Karen > > > > From nemo-bounces@ietf.org Sat Jun 09 11:46:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx38z-0005Rn-Pb; Sat, 09 Jun 2007 11:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx38x-0005OW-Ez; Sat, 09 Jun 2007 11:46:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx38x-000806-4X; Sat, 09 Jun 2007 11:46:23 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2007 08:46:22 -0700 X-IronPort-AV: i="4.16,403,1175497200"; d="scan'208"; a="492196043:sNHT51688704" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l59FkMDv031546; Sat, 9 Jun 2007 08:46:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l59Fk9tV002554; Sat, 9 Jun 2007 15:46:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 08:46:09 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 08:46:08 -0700 From: "Sri Gundavelli" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Hesham Soliman'" , "'Alexandru Petrescu'" References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Sat, 9 Jun 2007 08:46:08 -0700 Message-ID: <000001c7aaad$4c40ae80$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAAkb6CA= In-Reply-To: X-OriginalArrivalTime: 09 Jun 2007 15:46:09.0022 (UTC) FILETIME=[4C5791E0:01C7AAAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2491; t=1181403982; x=1182267982; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=ERa2cK6TqBjqT+OAKRL4FK70exoS77+CX4tJcONSAoU=; b=Jca25yozwbwoyXP1N9S6f7QAypZ8lIphVLaFPSaLhYgK/uJFJ1qYP+3tWpBwJ1GOM/g2f4A6 Wg8DV9cB1gdTLAlBslAzNPBy6MrIu+zgukX0ybVi0/8n/h6V3VuiAvSu; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Karen, > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com] > Sent: Saturday, June 09, 2007 4:28 AM > To: Vijay Devarapalli; Hesham Soliman; Sri Gundavelli; > Alexandru Petrescu > Cc: nemo@ietf.org; mip6@ietf.org > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > Hi, > > > > > > > > > > As it is also not the case in standard MIPv6 with IPSec > > tunneling to > > > HA. > > > > Well, we kind of have tighter integration between MIPv6 and > > IPsec already. For e.g, the insertation of home address > > option and routing header is done by MIPv6 after IPsec > > processing is done. > > The use of 'K' bit (to update the tunnel end point) also > > requires this. I am not suggesting we continue doing this, > > but adding TLV shouldn't be a big issue. :) > > > > Vijay > > > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and > there is a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more like > a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > > I agree that it is feasible from an implementation perspective. > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. > When 3948 is used, ie if the port is 4500 and not DSMIP port, the TLV header is not required, as we can carry other protocol payloads and the required headers are present for that mode. So, the behaviour is consistent to 3948 and its the same for both option#1 and option#3. If we prefer both the ESP and non ESP traffic to be handled as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for this traffic and will remove the tunnel encapsulations and pass it the the IPSec process. So, its about the registered handlers, IPSec is the handler on 4500 and MIP on the DSMIP port. MIP understands all the encapsulation formats and hence can do the proper decaps and pass it to the crypto system. Sri From gdsfz@hokane.com Sat Jun 09 13:44:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx4yx-0002v2-I1 for nemo-archive@lists.ietf.org; Sat, 09 Jun 2007 13:44:11 -0400 Received: from [190.48.193.30] (helo=190-48-193-30.speedy.com.ar) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hx2oB-000067-Rr for nemo-archive@lists.ietf.org; Sat, 09 Jun 2007 11:24:56 -0400 Message-ID: <466AC644.7080300@hokane.com> Date: Sat, 9 Jun 2007 12:24:52 -0300 From: Barnett User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: install greet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 CAON Releases Fact Sheet For Investors Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Read this over the weekend, you won't be sorry. CAON has changed direction and investors love it. Friday's volume went through the roof. Big news expected Monday. Set your marker for CAON first thing Monday! Hope to see you tonight. " The Cyber-Security Enhancement Act, introduced by Rep. As they pulled up to the intersection of U. the rest of the agency staff had left, leaving only his handlers behind. But I won't add to THAT anymore in this theread. To have three WW books makes it a collection! Nice legal system you all have down there. The criminal justice system must be brought to bear to stop fraud, viruses and identity theft, but the law alone can not stop these evils, or milder, but still annoying, spam. Any society that would give up a little liberty to gain a little security will deserve neither and lose both. - - - Jennifer Granick is executive director of the Stanford Law School Center for Internet and Society, and teaches the Cyberlaw Clinic. I fear we may be near the point of no return. But, mostly, for the fun. No judicial determination was made of the period of time needed to delay notification. The government here certainly had important reasons for employing this unusual procedure in seizing the car. " Dolan acknowledges, however, that outside the office Johnson was on his own. Strackbein, according to the Associated Press. then its obvious to me what he gets up to during lunch break. Otherwise we create more problems for e-mail users than solutions, while failing to stop the money flow. TURN OFF THE MONITOR and wait for IT assistance. But this strategy has failed in the spam wars. If you are going to hold a "Tournament of Champions", let it be known. as in Pornographis WebSITES"? In California, a basic rape charge carries a maximum penalty of eight years. I was hoping to get to play a game with you, but apparently, I can't. If they dont,God help us all. This is not usual in an administrative search. But it was all a set up worthy of David Mamet. A few minutes later, the stolen car comes flying back down the road with the police cruiser in pursuit. Strangely enough when ever I see it I think of, "Colonel Bogey March". If you haven't read it, try The Time Traveler's Wife by Audrey Niffenegger. Strackbein granted the motion for a new trial filed by Amero's new lawyer, William F. The Browncoats here would love to take you out to dinner too! Laws against fraud and transmitting computer viruses have long been on the books, but that hasn't stopped Congress or state legislatures from looking for a more targeted fix. So, of course, I started playing on Pokerstars solely because I trust your recommendations, way back in. "It was downloaded by a screensaver installed for Halloween by the teacher Amero was subbing for. It sounds like it's almost here. " The Federal Trade Commission already enforces cyberfraud, and state and federal laws cover more than enough ground to allow for prosecution, Serwin argues. Why How dare those evil JOOooo's think they deserve survival. The Browncoats here would love to take you out to dinner too! But statistics are unavailable on the number of criminals used as informants or how often they commit unauthorized crimes while working for agencies. Just wait for the first report of a wayward Israeli schoolbus being blown to smithereens on a field trip. The agents then decided to stage something, perhaps even a carjacking, in order to seize the drugs without tipping off the conspirators. "The jury may have relied, at least in part, on that faulty information," said Judge Hillary B. Using wiretaps and surveillance, the DEA learned that Alverez-Tejeda was using the leader's car to transport illicit drugs. First, criminal penalties are nothing new. us Sphere See Also: Desperate Botnet Battlers Call for an Internet Driver's License Wired Blog: Threat Level I'm the Blue Security Spammer Hackers Admit to Wave of Attacks A Chinese Call to Hack U. If he is just lying to cover his own back. I fear we may be near the point of no return. com article's message board will be full of angry and of the wall based comments about the mid-east issues, complete with "Jews are Nazi's" references. One popular criminal justice theory posits that when enforcement is low, the penalty has to be extremely high in order to dissuade people who otherwise reasonably believe they will not get caught. By building the wall well outside their borders, the Israelis have reinforced their status as an Apartheid-like oppressor. When the messages contain spyware that routes private information back to identity thieves, the virus code can reveal where the information goes. He says that the government could extradite wrongdoers, or even seize them, ala Manuel Noriega. Via Volohk via California Appellate Report. We can never see the babies, but we sure can hear them! It is permissible conduct by law enforcement if done in connection with legitimate activities, such as an arrest. Strackbein, according to the Associated Press. "You're looking at a new species of criminal conduct," says Roma Theus, a white-collar crime expert at the Defense Research Institute and a former federal prosecutor. From ssox@ibgagent.com Sun Jun 10 09:23:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxNOf-0002bm-TV for nemo-archive@lists.ietf.org; Sun, 10 Jun 2007 09:23:57 -0400 Received: from [218.234.228.220] (helo=ylobohl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxNOe-00006e-SO for nemo-archive@lists.ietf.org; Sun, 10 Jun 2007 09:23:57 -0400 Message-ID: <466BFB4F.8030603@ibgagent.com> Date: Sun, 10 Jun 2007 22:23:27 +0900 From: artichoke User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: "It's our culture, our society accepts it and in some ways society encourages it. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 CAON Releases Fact Sheet For Investors Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Read this over the weekend, you won't be sorry. CAON has changed direction and investors love it. Friday's volume went through the roof. Big news expected Monday. Set your marker for CAON first thing Monday! They shouldn't be so hypocritical regarding history; they just keep denying the facts. I totally understand why the Chinese hold grudges but the situation should be improved little by little. Often women can feel trapped, and suicide seems like the only way out. The reverence appears to be sincere. The UN does not posses the strength it is expected to have, and not because there is any flaw in the idea of the UN, but in how its membership and representation is defined. "Most of this stuff is just a broken spirit of the Aboriginal people. Ahmadi-Nejad and his guardian Islamic regime are not representing Iranian people. Australia's indigenous population is suffering more than any other group. We were the poorest people in a very poor village Li Suxiang Three times more women kill themselves in the countryside than in the cities. One even saw South Korean videotapes being sold. There is no mains water supply in this part of China, so Li Suxiang still collects water the old fashioned way - using a pump. If the teachers tell them off for something they will say they didn't do it. That certainly is one of the complaints of Michio Kono, the owner of a small restaurant that serves whale in the Asakusa district of Tokyo. No qualitative change was affected. I think that was really bad. One even saw South Korean videotapes being sold. Kim Jong-il is portrayed as a caring, nurturing figure who looks after the needs of his people. Long time survival will depend on the goodwill of neighbours like China and South Korea, and the outcome of the nuclear chess game with the United States. There are far too many variables to make a meaningful call on regime survival. Only officially sanctioned guides and some military officers would speak for the camera. But we didn't really get into the details of what actually happened. Citizens are taught that Kim Il-Sung gave the country back its pride and independence. Often women can feel trapped, and suicide seems like the only way out Xu RongCommunity worker Many women feel the same in the small isolated communities of rural China. I totally understand why the Chinese hold grudges but the situation should be improved little by little. We've learnt that Japan fought a war with China and colonised parts of the country. "We need to continue this fight no matter what other countries say. Poverty is still part of her life. His charges are unknown and according to Dr. She buys and sells old clothes to help make ends meet. Despite the gloom - and there is plenty of that - there is hope that things will one day improve. "We need to continue this fight no matter what other countries say. The specialists practice an arcane version of kremlinology. The history book I'm studying now has quite a few chapters about Japan's invasion and how they started the war. Dariush Ahmadi Hostility to Jew by the present and past Iranian rulers has always been condemned by the Iranian people as a reprehensible and disgraceful act. I still feel that the Japanese government isn't right. Wahaha said in a statement that it thought the joint venture company would struggle without Mr Zong. The UN should eventually be the final and independent authority serving the interests of the people of the world. The brief debate acknowledged the reality of ongoing forest destruction in south-east Asia, but nobody spoke against Cambodia's resolution. We've learnt that Japan fought a war with China and colonised parts of the country. Now every day is a struggle to survive. JMI, true to the Iranian heritage, has always maintained the highest standards of integrity, truthfulness and public leadership. I was told more than once that they are one and the same - the founder Kim Il-Sung seems to have morphed into his son Kim Jong-il in the popular mind. Very few people seem worked up about the issue. North Koreans are brought up to believe that they are uniquely virtuous - that the outside world is malevolent and potentially aggressive. So I really couldn't tie any part of the horrible history to Japanese people. Poverty is still part of her life. Pictures of these cutest of creatures apparently shivering in terror in market cages have tremendous emotional appeal. "There's a strong capacity in our people to make sure we survive," said Ray Minniecon. When I told them that anyone could fly into Seoul, hire a car and go where they liked, they were incredulous. So now one organisation is trying to change that. But CITES is supposed to work on sound science, not emotion. Behind the rhetoric and fear, it's possible to detect a grudging respect for the United States. Varjavand, a University professor, respected archeologist and cultural expert, had been very outspoken concerning the destruction of Iran's historic sites and cultural herritage. Neighbouring countries should cooperate and get on with each other. I still feel that the Japanese government isn't right. Long time survival will depend on the goodwill of neighbours like China and South Korea, and the outcome of the nuclear chess game with the United States. Some have managed to conquer their demons, but those dark days of the past are never far from the surface. Kim Jong-il is portrayed as a caring, nurturing figure who looks after the needs of his people. Khatami and his guardian Islamic regime are not representing Iranian people. The history book I'm studying now has quite a few chapters about Japan's invasion and how they started the war. From nemo-bounces@ietf.org Sun Jun 10 19:38:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxWzH-0006FA-4E; Sun, 10 Jun 2007 19:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxWzG-0006F2-M7; Sun, 10 Jun 2007 19:38:22 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxWzF-0004GU-DD; Sun, 10 Jun 2007 19:38:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Sun, 10 Jun 2007 16:38:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAExIkyA= References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > > > As it is also not the case in standard MIPv6 with IPSec=20 > > tunneling to=20 > > > HA. > >=20 > > Well, we kind of have tighter integration between MIPv6 and=20 > > IPsec already. For e.g, the insertation of home address=20 > > option and routing header is done by MIPv6 after IPsec=20 > > processing is done.=20 > > The use of 'K' bit (to update the tunnel end point) also=20 > > requires this. I am not suggesting we continue doing this,=20 > > but adding TLV shouldn't be a big issue. :) > >=20 > > Vijay > >=20 >=20 > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. >=20 > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and there is = a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. >=20 > The TLV header is not a mobility thing, per se, as I understand it.=20 > So the insertion and extraction outside IPSec seems more like a hack = to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation.=20 Well, the TLV is specific to DS-MIPv6 tunnels setup over IPv4.=20 No other protocol is using the TLV.=20 Vijay >=20 > I agree that it is feasible from an implementation perspective.=20 > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. >=20 > Karen >=20 >=20 >=20 >=20 From skt@cegercotcg.qc.ca Mon Jun 11 02:52:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdl5-0005Wx-8x for nemo-archive@lists.ietf.org; Mon, 11 Jun 2007 02:52:11 -0400 Received: from [88.247.17.129] (helo=dsl88-247-4481.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hxdl3-0001ri-QG for nemo-archive@lists.ietf.org; Mon, 11 Jun 2007 02:52:11 -0400 Message-ID: <466CFE80.3050804@cegercotcg.qc.ca> Date: Mon, 11 Jun 2007 09:49:20 +0200 From: Albert J. Potter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: With a live axle, a bump on one side disrupts traction on the other side by tilting the wheel and making the contact patch smaller. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Really, out of all of them, only one of them was doing things right so far as I could tell.
From nemo-bounces@ietf.org Mon Jun 11 05:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfks-0006Jq-HS; Mon, 11 Jun 2007 05:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfkr-0006J0-1J for nemo@ietf.org; Mon, 11 Jun 2007 05:00:05 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxfkp-0007FM-O0 for nemo@ietf.org; Mon, 11 Jun 2007 05:00:05 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 11F24200018A; Mon, 11 Jun 2007 11:00:03 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9FmVnW6O-mo; Mon, 11 Jun 2007 11:00:03 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id EDC042000178; Mon, 11 Jun 2007 10:59:42 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt Date: Mon, 11 Jun 2007 10:59:41 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD696013CCB0C@mx1.office> In-Reply-To: <1181249714.4614.122.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt Thread-Index: AcepRj5BjyQm3qq5SFmCW6NaGIeMVwCvJ/eA From: "Roberto Baldessari" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF NEMO WG , MPI@multicasttech.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, I support the idea that relying on a PKI could be possible, at least in = some particular scenarios.=20 For vehicular communications, for example, it seems like PKIs will be = needed anyway (i.e. regardless from usage of NEMO). Of course, a Return Routability-like solution would require less on the = infrastructure side, but as we know, it is not easily applicable to = NEMO. Therefore, IMO IPsec/Certificate-based solutions should also be = considered. > [Carlos] > provide more comments after looking at it), I'd say that IMHO=20 > main advantages of using a not IPsec-based RO solution > are: no need to change CNs (to support the mechanisms defined=20 > by BTNS) and no high additional delay in the handover.=20 > [Roberto] Regarding the first point (no changes to CNs), it depends which kind of = CN is your starting point. I guess you assume CNs implement MIPv6. But = if they don't, then you have to chenge them anyway, so you could do it = directly for a NEMO-RO solution. In some scenarios where CNs are not = random nodes in the Internet but dedicated hosts deployed from scratch = (e.g. control/info centers), IMHO we can be less strict concerning = changes in the CN. Regarding handover delay, it depends. For example, if the CN only has to = check locally a certificate and not contact the CA every time, then the = delay might be even shorter than a MIPv6 RR-like solution. Best regards, Roberto From nemo-bounces@ietf.org Mon Jun 11 05:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfr8-0004AE-Mq; Mon, 11 Jun 2007 05:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxfr7-0004A6-9w for nemo@ietf.org; Mon, 11 Jun 2007 05:06:33 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxfr3-0000zO-QU for nemo@ietf.org; Mon, 11 Jun 2007 05:06:33 -0400 Received: from [10.117.55.24] (unknown [212.201.107.24])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id ECD15461B9; Mon, 11 Jun 2007 11:06:27 +0200 (CEST) Subject: RE: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Roberto Baldessari In-Reply-To: <113091BD57179D4491C19DA7E10CD696013CCB0C@mx1.office> References: <113091BD57179D4491C19DA7E10CD696013CCB0C@mx1.office> Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Mon, 11 Jun 2007 11:06:25 +0200 Message-Id: <1181552785.5814.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-11.0837 TC:1F TRN:61 TV:3.6.1039(15226.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF NEMO WG , MPI@multicasttech.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Roberto and all, El lun, 11-06-2007 a las 10:59 +0200, Roberto Baldessari escribi=F3: > Hi all, >=20 > I support the idea that relying on a PKI could be possible, at least in= some particular scenarios.=20 > For vehicular communications, for example, it seems like PKIs will be n= eeded anyway (i.e. regardless from usage of NEMO). > Of course, a Return Routability-like solution would require less on the= infrastructure side, but as we know, it is not easily applicable to NEMO= . > Therefore, IMO IPsec/Certificate-based solutions should also be conside= red. I agree that a PKI solution can be a very good and simple solution for AOS and ATS, but I don't think the same for the traffic of the passengers. Actually, maybe it'd be better to design different solutions for each type of traffic, since the requirements are quite different (specially those related to security). >=20 >=20 > > [Carlos] > > provide more comments after looking at it), I'd say that IMHO=20 > > main advantages of using a not IPsec-based RO solution > > are: no need to change CNs (to support the mechanisms defined=20 > > by BTNS) and no high additional delay in the handover.=20 > > >=20 > [Roberto] > Regarding the first point (no changes to CNs), it depends which kind of= CN is your starting point. I guess you assume CNs implement MIPv6. But i= f they don't, then you have to chenge them anyway, so you could do it dir= ectly for a NEMO-RO solution. In some scenarios where CNs are not random = nodes in the Internet but dedicated hosts deployed from scratch (e.g. con= trol/info centers), IMHO we can be less strict concerning changes in the = CN. If we want to have a solution that can be deployed in the short-term, the most that we can assume is MIPv6-enabled CNs, but nothing more, IMHO (again, talking about the user traffic, not AOS or ATS that have different constraints). We cannot assume PKIs nor support at CNs for a modified IPsec processing, derived from the work done at BTNS. >=20 > Regarding handover delay, it depends. For example, if the CN only has t= o check locally a certificate and not contact the CA every time, then the= delay might be even shorter than a MIPv6 RR-like solution. Yes, in that case, it might be shorter, but I was think about a BTNS-like solution (I don't know how it'd work, but it might be possible that it adds an additional delay). Kind Regards, Carlos >=20 > Best regards, >=20 > Roberto --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From maticBanzon@aquitaine-instruments.com Mon Jun 11 14:51:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxoz0-00067Z-7N for nemo-archive@lists.ietf.org; Mon, 11 Jun 2007 14:51:18 -0400 Received: from [217.22.237.54] (helo=[217.22.237.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxoyw-0004dd-TR for nemo-archive@lists.ietf.org; Mon, 11 Jun 2007 14:51:18 -0400 Received: from ENRICO ([177.138.41.56]:13600 "EHLO ENRICO" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [217.22.237.54] with ESMTP id S22FPTXYTSGKSUTN (ORCPT ); Mon, 11 Jun 2007 20:53:27 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jun 2007 20:53:12 +0200 To: nemo-archive@lists.ietf.org From: "matic Banzon" Subject: A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_21047062==.REL" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 --=====================_21047062==.REL Content-Type: multipart/alternative; boundary="=====================_21047062==.ALT" --=====================_21047062==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] But I first saw to it that it cost them a good penny. You can then compile this resource file using the resource compiler. When will Perl stabiliize. Only the most abandoned and shame- less characters venture to manufacture I. Is this the same as 1. Evening guests had to be entertained in the kitchen so as not to interfere with my future translator's sleep. When I'd told her that my mother was named Dara she had finally begun speaking freely. If not Microsoft then some other company such as Stingray. When he knocked off for a drink it became possible to talk without being the center of attention, as separate conversations had sprung up. Since KISGB now ships with a default kisgb. His probing hands fell into water. If you do not get it right position, repeat the procedure. There were even women who worked for Nicci's father, helping to make chain mail. On the first system with a tape drive, use bst5 to create a stuff pattern media using "write pattern" operation. The commander was up a good distance from the low flames, but there was a expansive bed of broiling hot coals. A packet is dropped if there is no more space to store it in the circular buffer that the driver associates to current instance. The Warder separated out the largest piece, then raised the knife high and brought it down with all his might. Represents a base implementation of the interface that uses the class and the interface. Press to clear history lists. You can then dig deeper into properties of the returned plugin object to retrieve, say, its name. He could keep them both safe by keeping them as far from him as possible. Kaj krom vi neniu povas. Building and Running the Sample from the Command Line To build and run the Delegates samples 1. Haze was to drive her to the camp in the early morning. --=====================_21047062==.ALT Content-Type: text/html; charset="us-ascii" []
But I first saw to it that it cost them a good penny. You can then
compile this resource file using the resource compiler.
When will Perl stabiliize. Only the most abandoned and shame- less
characters venture to manufacture I.
Is this the same as 1. Evening guests had to be entertained in the
kitchen so as not to interfere with my future translator's sleep.
When I'd told her that my mother was named Dara she had finally begun
speaking freely. If not Microsoft then some other company such as Stingray.
When he knocked off for a drink it became possible to talk without
being the center of attention, as separate conversations had sprung
up. Since KISGB now ships with a default kisgb.
His probing hands fell into water. If you do not get it right
position, repeat the procedure.
There were even women who worked for Nicci's father, helping to make
chain mail. On the first system with a tape drive, use bst5 to create
a stuff pattern media using "write pattern" operation.
The commander was up a good distance from the low flames, but there
was a expansive bed of broiling hot coals. A packet is dropped if
there is no more space to store it in the circular buffer that the
driver associates to current instance.
The Warder separated out the largest piece, then raised the knife
high and brought it down with all his might. Represents a base
implementation of the interface that uses the class and the interface.
Press to clear history lists. You can then dig deeper into properties
of the returned plugin object to retrieve, say, its name.
He could keep them both safe by keeping them as far from him as
possible. Kaj krom vi neniu povas.
Building and Running the Sample from the Command Line To build and
run the Delegates samples 1. Haze was to drive her to the camp in the
early morning. --=====================_21047062==.ALT-- --=====================_21047062==.REL Content-Type: image/jpeg; name="defense.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070611205312.03a7f518@aquitaine-instruments.com.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="defense.jpg" R0lGODlhTAFUAYcHAAAAAIsAAAOGC4V6AAoAd3sAcQeDiMHBu8jWyarX/T0oAG4kCn8TAJUnALgV ANUlAAA7BSpBAD5AAlY3AIRGAJxBAMQ5BNs6AAdcBhFXCzdZAG5dCX5VAJNUAL1jCeNkAAt4Bil1 BzKEAFx2AIGJAKWBALeNB+N5DQCgABGRADqbAFecAISnCZOXAMSaDuCiAADNACayAErMBm3GAIXN AJe0BLjKAObMDALaAxLXAD/bAGXcA33oCaLaALzkAO7rCgAATCwBTj4ASWgAPIYORqIIQL0AOuQM OgURTB8iPjYqRF8tN3sqOaMnQMYrTdgfTQ1DTBtCR0M+Pmo8RHZISpNBSLFHS+JNQABuPyhWODpn P1xXRXxRAK1bPrtrTOtoRwN6Rh+MOkyJQV+NSYSMTaSNPsdzPN6CSQCXSx+lMzSfMWClRH2ZOJOl TLibPuGcQQDCSx7BSkLGOFXDOni3OJK9MsS9S+HKRQDtThngS0voTGrUSXnUR5jfMcTrOuDqRwAH eBMAdT4LeGwAdIcAcq0HfckAfNEAiAAZhBYehkkShGUXcXwVfqYpi8ctjNglcQBGfy0xeEJBc1JG inRNfKo2dbdEed8xcwFjgh1lcklYhFxhdIZhdKJfeMBTg+tuegCDcSGJczaEe2J+h4F4ipiLdsFy fuGChwCdeCSYgTyuhGacenyog5Gai8CojuycjAe3jhbCij3Id2jDi3S/gaW1fLHCiN7LfwPegCva gTnijWXajonRhZXee8nnd+XmggwExxUAyjYAwmoEsocAxagIzrUNuuAAuAAnwiYgwT8Wymkby3Ym wpwmusMou+sRvQBJzihCyU45vV01zIdNwps/vMNExudLxgNpxhdWy0xoy21dtYBbs5drvLhtxdhT tg5yvB51wUOLs1OGs3R7vJ2Nv7KJvd6IzACdtxSquDqXtGSgvHemtJ6uvsukzNOitwDDvSXOvzSz xVLIt4a2y5i7u//94qifqXtyjv8AAA78AP/1BQAE//QE/QD//////CH5BAC24rYALAAAAABMAVQB Bwj/ABEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt2K+fKxzHv3bt6/ek/yFTh4I+C/Awv3lXsYscnCijM2Hhx5 sVvHiQUHBqkYcWXLbD9rFhmZr2jQaE8jaEzQNObVhwtOThyYNW3Yqkvrdd059m3Pux0Dpj1ctvDN sFGvzG0bt2/nmCdvptxcekLd0KNXjy3d9mzCrI8r/1+OfCHk8wjR3wZ/8Pz08q2RU3+f/r189+uN 51/NPvn4lKplt19vxWHXn4AH+tfed73FV5yCCTYIXoHw9Rfgfx4x95yE2dVWnnrfQXhacyLa96CB EXrom2ieYQhghRPmJ6F2CSrIm4z3XQfjjOpBWGJ8uK034msulsRijikm6SN6HHJo0JFA/lijk65F OeSFRXJEZHDEDehhl0HGyB5+Si5Yn5X27SflmGmGSRiYWWoWXog8brddh/SpGeWTSFo3JZJs2vmg j3GSJKiNgA5HIJcWAueljmfiWOWfe/qn6H1bwljopjZhyemnLnkK6qgvkmqqTKKequqqrLbq6quw Tv8VQKxkzTorQbcWFMCuCeWqka+47gqsQbcO25CwvHJkLK0j2TqQsAgtK5C0FBnrK7XUMnStssye hGyy00YbLrQIIFsuubY6S+65yZr7LLHlsvtuvOnm6i6uutLr7LzfTtsutO6m6y+43Ua0L74HFWtv uPG+C+7DDTM87MTn8jvuwtsi7PDCDuPLcbEec8xwwRAdPC+8ETcMcscn04swxflmDPK2Gbfscssm myyxxxqnTPJC3wK77Mo7swtwz/WiizLPFt988b0jj4t0ygp/zPTA6/58rM9cF100zFHrHPXYTqss NcviXk312i+HzbbWBnc9tNtmo722zAm33XTOb9P/XTOv9h68Ms1Tw62tz/0Gy7e/RtMtcdYEY43z zjJnjbXIA6sMeObPJj021Iafmm3opHddeuign6766qy37vrrsMcu++y012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6999QC4eMMNFIHvUPd96aOPQOYjkD5I5A/U fkEAxE+Q/DuJjwD49mP0/fcH2Z+/QPvjn0H+p5D3xe997qPfAen3lfWtLyQLFAgD5+c+CfrEfxwh YEEw2L+EaPAgEWwfAkWIAASCxYHnQ+EDzcdC9bXQhQ+s4AhBKMOfYFB8+xtIAO/Hw/sJUIcDFGAO /3O4QYIQcYcA/GEJl2iQGVrQhCd8YQxdSEUqvpAgU+yeE5uowAP2BH8ALOINCfi/IwKRgwPs4A1p aMI2ytCLYmHh+aooxxTOMX0xrCMXDUjDJ1awfj3E4RDPaEQipnGNYeygDgcZRiUmkI9N/KMkGyhF O6LPklacIx01SUESRtKPFgQkDnvIQ0SS8oNgbCQQFXnKViYxkuSDIhNnGcqwrBCTeLwjJjfJxknG soa1rKUnZznMYkrSmGlUpTJLuUpSipGQiUxmK9HoTD+6kZjYjKMmVcjNXcIwi3AsIQNFOM4JCvOY 6DynOrNJy2YKUoiMTKISkejDUS5SmvXE3xEdGf9BccKRnAC9yxTHV5YP5kSWWZIjRRCaFUP+hKHb i6hEmdUPjPSjohPBaEMgahN+8AMiHA3dRS+KAI0SpKImNchIUyoQjbJ0pSwt6UMMaE4JljOkDfGo ThHgUYT0tKcMoaksb/qqmKp0IUYdiEsRktSkws+LwzxnVCkC1Jx+dHxQnWQwp2qql7aUpDLF6EhP qlKwjnWsBTEpWleqVLCCEn5wDWY7JVLVgQBVp1f9aV532sk+apWrpPIqWVEq04OsVamFTWxaDZtY wsLyqZ8kJk4VUleBVFavPP1oZYFJwacqUKtdPWpJzxpWpzo2rIhlbFtJulS3zq+mbQynXOl6VYL/ 3BWvmc0tX/fY2bgysZ+r8mprG2vU0xqXqalFbUvb+tjeRna2EdksZnWr2drutq9zXSd0A7vY4aoV ucNdrmobS97k1tCTTpwqMud62epa1r113ewStfjJqE62UGwVK2lR6trRuvWwzF3savlr1v4CN5zk fO012QlFvLo3szvFLG49G8t+BtSmEy3gVO6b4ZluuMMgDrGIB2IABJR4IRzGSophdWITu1gjBojx QUrc4oQIFYQTXLFG7kvfiNyYwoAFVYtrvBEiC4TGKM6qXNGr44ykmMMhBO0fazqqIb84xkPGsotP rOUZH1nGW36xmOfr18g2GSMj/Kw15ddj2ZL5/7nOPTNokDzmMB/ZxEY2sp3DTOcx99i5rwU0SiD5 ZjIn2LeFlvJWW0VnLmvZyjXGsp5pLGk79/mRgvatnC0i1M/+0r5uli1Ct6iqRou5z6gmsZeJbGo9 tzmoii4JoYH55/XSWsOZJhWkVb3rO/u6IKlOdS+vaet0MtjY6u2tMdfrxj8bO9ZCVjWewVzpSHf5 y1nm8qn3WOF/YtqmC2Y2sv/6zxxP2dnA9We31dxON2tNzxeBd3bFsmm4XZsj8q43VPQ94n77G3b8 Rso9OBJwVqWb04hWcMKBMvCBDPzhO1Y4kKFNqoJbGIrFLDhKGi4QiHOc00qe9281fpfYdluc3//m 7HanLHKefNzj9/B4x2M+84d/vNBBnrWrvA3KX8a53bj2+VBejgCIz9wgRm/4x2utaJ3Diuk+X7dn cy1Zd/uE6EYvOkFiTnOld3zq7AQ0yS0D9VAyHa45L3NQsK71r7td615ve18BS+pYlf23YX8rJIdq 5nGvU9x/TyfbOU54h7c97nNn+WzHXpcDqznqokbwOMFtbk37/diBzzw7uR73rm+d64d/u7pTrl4q z47xX0H961TfFdb/+/WwR57rRwJRhs5+oWvZhO51z5BNOMT3tJc4FylPcqcvHNEW9nFFnnx8X14F +L3/Pe1DvuDmX8T4VF/0Wwlqkovb+NBVgT7/AnY/EPKTf/y8F4j5039+3wO//edHv/gT/VeEjH3v nh49uLU/X8lL3Z/7Z2hs9mn+h3bNh27PV34KKH7Q14DjRxAOqH7oJ4ES6IARuH0oR2HWd30LBHVC N0OEdnc4d2yPZ02cxUd1Z3bZ1xQNuHvud4EWCIMu+IAU+IAxGH8BKHbP1hEoGGXq5IOUJ1VAWGtD qIIeGGqVN3Er5xQXCIHup4A1yHtNSINU+IQVqGF1V2wEh13jRkI654WWl2wqaGgq11wth31PAYMQ WIVQeIVRyIZuaINteF6Kh172d3liqHckqHJbJIJnN4J454dm+IUryBQMyH7pN4Hyp36JiIjv/+eE j0iBOKh/AChMk+dXgAd05/aB/oeAyhaATAaKdQiISEhUS5ZytHJ7c6GKn8KKceGKsReLsjiLtFiL tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN0wcUpjcR2fhv HWhyVldAxadFFbZQsGg8B4dh6IhVH2FO2wiOttiNw4eOHfhI4mh18FhOQYhyAwhV48ht+yiOCUR8 /8c9Q5Vg+MiOBRmQ+BhoA5iOXRSP+viQGHaQ5Yg78JiBEQlZOKaQ4DeRAImRlBhoHhmQI1mSIUaR 81iJICmSGSmPIfSROWaPBgl+DemSFVk7FP/5femokS3Zkg0pkfnIkzWJkUMZkyCWkzsJlBrJj/v3 kDWJkPZ3cgvJlCq5khF1keo2kFVJj110cUxpilbJlR8pkGR5jsjYjtqIemh5jGsJUuH4jdYYl3KZ FG15jXMZlWaZkhwYlRC5kezTZKZXl7aTlx3pEYK5kzx4k7eDlSSpYJ0IUE9ZbsN3kSlZmfzoeOXm bpRJlfP4jzcFl60TmCZnkkOJmKXpkf24kBF5cj2plBK3jyaJmqSpmBXnfbO5klAJW2MJlEhJlLvZ jxBZlGN5m6opPMKZlafZlafZmsDZjb/JkZbJl8SZZr5ZncRznLoJWU4ZW9ZZnA45k34ZnM//mZvg iZi705vYSZ3bOZmHpprHeZthWZ29OZ056DuWiZmfCZMvyZ6NmZm82Z7pppnRaZM/CaBmGTyH+RQJ mpayR5swsaBYBZp3OaEUSo5EAaEY6qCsw5hkqY4kgZbZyaA86aEIKpMiapcSkaESxaFWiZ9ZGY8S eZ/rFpkluZnf+JLeZ6OSiZUs6jqiqZNQ6ZfrKZvymZoAiZ7c+W0FOo47Wo/wyTscmpyj5pzfaZ0Z 6JxMWp4tSlMcWaRdiqT26Y2sGZ/I+Z9Wqpw5OpN6+ZrgCabp2ZjnSZ0g6ZqOaZvMSZJYSp8bNZ58 +qVaCqGqE6RGSaZXSpPPqZJm2pVWyp8j/+mmfbqVuaObl/ljMNppwImceGqg/olxktmoMjqkhXqg FZqiSWqho4pmpTpTonqqrNqqLJkSyzmqLDqrZxarBKehIgGorWiiEDSc64irvao1tKqBaNqhmEqj /tidkzqjAvmYQemYReqVzjp6a9otP8qm0UqfdBqkPVmlNZql0Bme2bqa01mYgdqZf/qoPsmr/emr 7qmfetqXjtqlsamrOyenq7mfekqYQjmm71qoqKmvONac6vqmcLo63Lqc8xqSB1ucZvqtsWme2pmu XlqvwEoXCVuw+nmofRmqIvmvMaqufKmoC9ut9toqGUt83nqP5sqVZRl5zAqwoUqnQcmy0rman6Z5 siVqFSFKizrrEz3rqkI7tERbtEZ7tEibtEq7tEzbtE77tFAbtVI7tVRbtVZ7tVibtVq7tVzbtV77 tWAbtmI7tmRbtmZ7tmibtmq7tmzbtm77tnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77ugUTEAA7 --=====================_21047062==.REL-- From nemo-bounces@ietf.org Mon Jun 11 15:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpS6-0003S2-Hz; Mon, 11 Jun 2007 15:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpS5-0003Rq-BO for nemo@ietf.org; Mon, 11 Jun 2007 15:21:21 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxpS3-0001pF-Se for nemo@ietf.org; Mon, 11 Jun 2007 15:21:21 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2EAF019868B; Mon, 11 Jun 2007 22:21:19 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9F3F19868A; Mon, 11 Jun 2007 22:21:18 +0300 (EEST) Message-ID: <466DA0AF.5030406@piuha.net> Date: Mon, 11 Jun 2007 22:21:19 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: frederic.klamm@orange-ftgroup.com Subject: Re: [nemo] [Fwd: FW: Last Call: draft-ietf-nemo-multihoming-issues (Analysis of Multihomingin Network Mobility Support) to Informational RFC] References: <4667BFE6.4050401@orange-ftgroup.com> In-Reply-To: <4667BFE6.4050401@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Frederic, > Hi all, > Regarding the example of deployment scenarios in 3.1: > > "x=1: Multihomed mobile networks with a single MR > > o Example 1: > > MR with dual/multiple access interfaces (e.g. 802.11 and GPRS > capabilities). This is a (1,1,*) if both accesses are > performed with the same ISP. If the two accesses are offered > by independent ISPs, this is a (1,n,n) configuration." > > IMHO the presence of 2 different access providers doesn't require 2 different HA. > A mobile service provider (operating its home net for MIP/NEMO services) may have agreement with several access provider. > Regardless of access technology. > So that : > "If the two accesses are offered by independent ISPs, this may be either a (1,1,1) or a (1,n,n) configuration." > > This remains true from monami6 point of vue, that is : at one given time, 2 tunnels may be established between MR and the same HA, one through 802.11 interface, the other through gprs interface. > > number of HA, number of access providers and number of interfaces on MR are a priori independant variables > Unless I'm wrong, this concerns quite all the deployment scenarios examples in 3.1. I think you are right and this needs to be corrected. I've already sent the approval notice, but I think these edits, if agreed, can make it in time (or otherwise the authors can take care of it in AUTH48): Section 3.1: OLD: This is a (1,1,*) if both accesses are performed with the same ISP. If the two accesses are offered by independent ISPs, this is a (1,n,n) configuration. NEW: This is a (1,1,*) if both a single home agent is used for both. If two independent home agents are used, this is a (1,n,n) configuration. OLD: Alternatively, the train company might be forced to use different ISPs when the train crosses different countries, thus a (n,n,n) configuration. NEW: Alternatively, the train company might use different home agents, in different countries, thus a (n,n,n) configuration. OLD: This is a (n,n,n) configuration if the two access technologies are subscribed separately. NEW: This is a (n,n,n) configuration if different home agents are also used. Jari From nemo-bounces@ietf.org Mon Jun 11 17:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrZ7-0003k7-R3; Mon, 11 Jun 2007 17:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrZ4-0003fT-2q; Mon, 11 Jun 2007 17:36:42 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxrZ3-0008Jq-Nn; Mon, 11 Jun 2007 17:36:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A660E328D1; Mon, 11 Jun 2007 21:36:41 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HxrZ3-0004fY-IX; Mon, 11 Jun 2007 17:36:41 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 11 Jun 2007 17:36:41 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: nemo mailing list , nemo chair , Internet Architecture Board , RFC Editor Subject: [nemo] Document Action: 'Analysis of Multihoming in Network Mobility Support' to Informational RFC X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The IESG has approved the following document: - 'Analysis of Multihoming in Network Mobility Support ' as an Informational RFC This document is the product of the Network Mobility Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt Technical Summary This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. Working Group Summary This document has been relatively non-controversial in the WG. The document has been reviewed by many members of the working group; The document has gone through working group last call, with one comment raised and addressed. The WG seems to have a pretty good understanding of multihoming and how this document defines the issues related to it. Protocol Quality This specification has been reviewed by Jari Arkko for the IESG. A call for additional review from multihoming-related WGs in the IETF was made on the AD's request. This call did not result in any reviews. However, some members from the MONAMI6 WG and the SHIM6 have been involved involved in the NEMO work around this document. Note to RFC Editor Please change in Section 1: OLD: Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks such as vehicles typically require the use of several interfaces and technologies since the mobile network may be moving in distant geographical locations where different access technologies are provided and governed by distinct access control policies. NEW: Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks typically require the use of several interfaces and technologies. For example, this is particularly useful for ITS (Intelligent Transport Systems) applications since vehicles are moving across distant geographical locations. Access would be provided through different access technologies (e.g. Wimax, Wifi, 3G) and through different access operators. OLD: o multiple global prefixes are available in the mobile network.--> NEW: o multiple global prefixes are available in the mobile network. Please expand first occurrence of MNP to Mobile Network Prefix. Please add the following between the first and second sentences in the first paragraph of Section 2.1: "The MR and the AR are connected to the Internet via a single Access Router (AR)." Please change in Section 3.1: OLD: W-PAN NEW: wireless personal area network Please change in Section 4: OLD: [8] and [8] NEW: [8] Please add an informative reference to DHCPv6 (RFC 3315) in the last sentence of Section 2. Add this text to the end of Section 8 (Security Considerations): For instance, an attacker could try to use the multihomed device as a means to access another network that wouldn't be normally reachable through the Internet. Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to enable it. Please replace Section 4.10 contents with this: When a mobile network is multihomed, the MNNs would be able to benefit from this configuration, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly: o In the (*,*,n) configuration, the MNNs can influence the path by source address selection (see Section 4.1.3, Section 4.7). o In the (n,*,*) configuration, the MNNs can influence the path by default router selection (see Section 4.1.3). o In the (1,n,1) configuration, the MNNs cannot influence the path selection. One aspect of preference setting is that the preference of the MNN (eg. application or transport layer configuration) may not be the same as the preference used by a MR. Thus, forwarding choice made by the MR may not be the best one for a particular flow, and may even be detrimental to some transport control loops (such as the flow control algorithm for TCP may be messed up when MR unexpectedly performs load balancing on a TCP flow). A mechanism that allows the MNN to indicate its preference for a given traffic would be helpful here. Another aspect of preference setting is that the MNN may not even be aware of the existence of multiple forwarding paths, e.g. the (1,n,1) configuration. A mechanism for the MR to advertise the availability of multiple tunneling paths would allow the MNN to take advantage of this, coupled with the previously mentioned mechanism that allows the MNN to indicate its preference for a given traffic. This problem is general in the sense that any IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the MNNs may possess such capability. It is recommended that vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks. In addition, the Monami6 WG is currently developing a flow filtering solution for mobile nodes to indicate how flows should be forwarded by a filtering agent (such as home agent, mobility anchor points). It is recommended that the Monami6 WG considers the issues described here so that flow filtering can be performed by MNN to indicate how flows should be forwarded by the MR. Please change in Section 3.1: OLD: This is a (1,1,*) if both accesses are performed with the same ISP. If the two accesses are offered by independent ISPs, this is a (1,n,n) configuration. NEW: This is a (1,1,*) if both a single home agent is used for both. If two independent home agents are used, this is a (1,n,n) configuration. OLD: Alternatively, the train company might be forced to use different ISPs when the train crosses different countries, thus a (n,n,n) configuration. NEW: Alternatively, the train company might use different home agents, in different countries, thus a (n,n,n) configuration. OLD: This is a (n,n,n) configuration if the two access technologies are subscribed separately. NEW: This is a (n,n,n) configuration if different home agents are also used. From gpesw@oxfordcoverage.com Tue Jun 12 13:27:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyA9d-0000ff-6w for nemo-archive@lists.ietf.org; Tue, 12 Jun 2007 13:27:41 -0400 Received: from e178008097.adsl.alicedsl.de ([85.178.8.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyA9c-0005Ff-LT for nemo-archive@lists.ietf.org; Tue, 12 Jun 2007 13:27:41 -0400 Message-ID: <466ED788.2040504@oxfordcoverage.com> Date: Tue, 12 Jun 2007 19:27:36 +0200 From: Kate E. Peters User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: stifle Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d News Hits! New R&D Facility Engaged! Chan-On International Inc. Symbol: CAON Close: $0.73 News hits today on CAON and trading continues to warm up. Hitting highs of $0.90 today, we can see this building. Read the release and get on CAON first thing Tuesday. We can see this climbing all week! Ein wesentlicher Faktor, der zum Erfolg von IBM bei dieser komplexen Aufgabe beigetragen hat, war die Simulation des Verhaltens des Materials auf atomarem Niveau. The summer dates include the band's Aug. The Dodd amendment would honor the bond between U. The venerable music festival, now a permanent fixture instead of a travelling affair, takes place Aug. Georges Fellowship, an annual grant awarded to journalists on the staff of The Crimson and administered by the Nieman Foundation for Journalism. It's quite different to last week's seascape painting demonstration, which is more of a traditional landscape, showing a whole scene. Most importantly, with the simulations one can follow what the individual atoms are doing. Andy says: "The aim is to learn different ways of painting water, so that you can either vary the way you approach it or just choose the method you like best. Among the amendments that CAPAC opposes are the Cornyn amendments, the Inhofe amendment, and the Coleman-Bond amendment. Urban, wearing a T-shirt and jeans, kicked off the show with a cartoon heart beating on a large video screen. He then "used those same instructions to build a nicer lucida out of salvaged Douglas fir boards and shortly after that started selling them on eBay. The photo was taken by artist and painting forum member Tina Jones who says: "I looked out the back door to see a welcome mist in the air from the previous day's rain. " Contributors to the project include Strokes vocalist Julian Casablancas and Mark Lanegan. "I am honored to be a part of this amazing music legacy," Jackson said in a prepared statement. The Cornyn amendments would gut the immigration bill by making millions of undocumented immigrants ineligible for legalization. Diese Entwicklungsarbeit wurde im Papier "Hierarchical Nested Surface Channels for Reduced Particle Stacking and Low-Resistance Thermal Interfaces" von R. The entertainer has since racked up a heap of awards and platinum-selling albums, and launched an acting career. The photos on Artists-Reference-Photo. Org-Mitgliedern BLADE Network Technologies, Broadcom und NetXen. Die Studie kann unter folgendem Link eingesehen werden www. EUR DVD REVIEW: Maxed Out Home :: Web Directory :: journalism News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. She and Harp also admitted it is lonely on the road, as outlined in the song "Tennessee. Org-Mitgliedern BLADE Network Technologies, Broadcom und NetXen. org auf Ihrem Privat- oder Firmencomputer. His art gallery, "the only one left in Baghdad" is "far from profitable", but at least it's open. IBM kann heute mit Kunden den gleichen Aktionsplan teilen, den wir selbst bei der Modernisierung unserer Rechenzentren anwenden. Even the staff cannot get inside", according to a Guardian news report. The screen turned white, making Urban and his group appear as silhouettes during the opening number, "Once in a Lifetime. For more information, please visit the web site at www. From wxkkvic@mchsi.com Wed Jun 13 19:16:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyc4m-0003nA-F6 for nemo-archive@lists.ietf.org; Wed, 13 Jun 2007 19:16:32 -0400 Received: from 12-214-108-97.client.mchsi.com ([12.214.108.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyc4l-0004nz-4f for nemo-archive@lists.ietf.org; Wed, 13 Jun 2007 19:16:32 -0400 From: "protects something" To: nemo-archive@lists.ietf.org Subject: Bad credit ok Date: Wed, 13 Jun 2007 18:16:29 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C7ADE6.F6A01C80" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acet5vagckohuurZSkaQzrKsEjx1MA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.3 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0000_01C7ADE6.F6A01C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $321,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

http://occyupal.com/ ------=_NextPart_000_0000_01C7ADE6.F6A01C80-- From ecalve@networth-solutions.com Thu Jun 14 09:31:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypQS-00046M-Pu for nemo-archive@lists.ietf.org; Thu, 14 Jun 2007 09:31:48 -0400 Received: from p57a6523b.dip.t-dialin.net ([87.166.82.59]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HypQQ-0003Az-Kp for nemo-archive@lists.ietf.org; Thu, 14 Jun 2007 09:31:48 -0400 Message-ID: <001001c7ae99$24081fd0$006fd6ec@NIKI> From: "Charlene Parks" To: "nemo-archive" Subject: Fw: Thank you, we are accepting your debt request Date: Thu, 14 Jun 2007 15:30:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C7AE99.24081FD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1158 X-Spam-Score: 2.9 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ------=_NextPart_000_000D_01C7AE99.24081FD0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If you OWN real estate and want IMMEDIATE pocket money to spend ANY way = you like, or simply need to LOWER your payments by a third or more, here = is our best deal we can offer you THIS NIGHT (hurry, this offer will = expire THIS EVENING): $254,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = monthly payments! Hurry, when our best deal is gone, it is gone. Simply complete this = simplified form... Do not worry about approval, your credit score will not disqualify you! http://moloynfresh.com/ ------=_NextPart_000_000D_01C7AE99.24081FD0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit history = doesn't matter to us!
 
If you OWN real estate and = want IMMEDIATE money to spend ANY way you like, or simply wish to LOWER = your payments by a third or more, here is our deal we can offer you NOW = (hurry, this lot will expire THIS NIGHT):
 
$445,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when our best = deal is gone, it is gone. Simply complete this user-friendly form... =
 
Don't worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_000D_01C7AE99.24081FD0-- From wexq@rediffmail.com Sat Jun 16 05:17:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUP2-0004L1-5d for nemo-archive@lists.ietf.org; Sat, 16 Jun 2007 05:17:04 -0400 Received: from [81.215.68.128] (helo=dsl.dynamic8121568128.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzUOy-0007ub-Ed for nemo-archive@lists.ietf.org; Sat, 16 Jun 2007 05:17:04 -0400 Received: (qmail 7528 invoked from network); Sat, 16 Jun 2007 12:16:59 +0300 Received: from unknown (HELO hpo) (45.229.43.189) by dsl.dynamic8121568128.ttnet.net.tr with SMTP; Sat, 16 Jun 2007 12:16:59 +0300 Message-ID: <4673AA8B.7030600@rediffmail.com> Date: Sat, 16 Jun 2007 12:16:59 +0300 From: Maloney Bartholomew User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: This information is not a substitute for medical advice. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 SREA Gets In On $75 Million Project. Investors Respond! Score One Inc. SREA $0.20 UP 33% Investors are hyped about this new project. It will not only bring increased revenues to Score but increased exposure on an international project like this. Read the news and get on SREA firs thing Monday! Theatre kicks out disabled girlOpportunities and Growth: Plausible and Workable SolutionsDisability Sex Dating and Chat - Adult StyleWhen a Loved One Has Chronic Fatigue Syndrome - What Do You Do? If you are the system administrator, please click here. Visit Britannica Store . Included are all receivers entering their third year, listed in the order they were selected on draft day. My Kind of GuyReise, ReiseHandbags and GladragsHunterNatural DisasterCatch a Bad OneKarmaWhat Goes Around. The language and terminology of disabilityLately, the term disability has replaced the older designation handicapped. If you are the system administrator, please click here. Giants linebacker Antonio Pierce on dog fighting: "Anybody who fights pit bulls is a punk". No reason to not enjoy the true pleasures of a summer's reading group. Troy Williamson, MIN - Has been a disappointment so far for the Vikings, dropping far too many passes. And doesn't it seem rather convenient that the house's alarm was not working at the time the items disappeared? Some people believe that in getting ready to sell the house, Vick had promised stuff to some family members and other people felt they deserved things. Now that the kids are out of school, the temperatures rising and the evening prime time programming is set to re-runs and oldies- it's time for you to begin a summer reading group. Police reports also indicate the alarm at the home was not working at the time. Jack and Meg's banter makes the song worthwhile. Jack and Meg's banter makes the song worthwhile. His condition is seen as disabling; the social reactions to it are justified, and the barriers unavoidable. "I don't think it had anything to do with possible evidence," in the dog fighting investigation, Poindexter told the Journal. For more information, read this introduction to this site. There is something very strange with Poindexter moving so slowly in this case. Giants linebacker Antonio Pierce on dog fighting: "Anybody who fights pit bulls is a punk". My Kind of GuyReise, ReiseHandbags and GladragsHunterNatural DisasterCatch a Bad OneKarmaWhat Goes Around. Now because we are a for-profit company, we hope you understand that we can't afford to do this for too long a time, however for the next week or so, let's play! " Indeed, this song showcases their unique and charming form of song presentation, and combines it with their heavier sounds reminiscent of their first album. Police reports also indicate the alarm at the home was not working at the time. From vsjni@charter.net Sat Jun 16 22:55:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzkvM-0006SI-7k for nemo-archive@lists.ietf.org; Sat, 16 Jun 2007 22:55:32 -0400 Received: from [189.4.177.144] (helo=bd04b190.sts.virtua.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzkvK-0008Jt-Je for nemo-archive@lists.ietf.org; Sat, 16 Jun 2007 22:55:32 -0400 Received: from byish ([127.217.220.105]) by bd04b190.sts.virtua.com.br (8.13.5/8.13.5) with SMTP id l5H2xIJP015803; Sat, 16 Jun 2007 23:59:18 -0300 Message-ID: <4674A29A.7050105@charter.net> Date: Sat, 16 Jun 2007 23:55:22 -0300 From: Tim Haynes User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: imagery Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Word Is Out, Big News Monday! Score One Inc. SREA $0.20 UP 33.3% This week's news has already been pushing SREA up. Word is out a BIG news release is expected Monday! Keep your eyes open and get on SREA Monday! Expired domain names that are not trademarked can be purchased by a third party and used to point traffic to websites of their choice. Proceedings include color copies of papers presented and PowerPoint slides from all Short Courses. Expired domain names that are not trademarked can be purchased by a third party and used to point traffic to websites of their choice. Discretion and careful engineering must be used when oversizing conductors to avoid exceeding the allowable range of conductor sizes for equipment terminal lugs. Although details can vary, a typical corner has three vertical studs in close proximity to each other. It is not uncommon for large office facilities to have a computer at every desk or workstation. Infrared radiometers must be within calibration in order to accurately measure temperatures. They basically trip the circuit off-line when the breaker senses that the design maximum temperature has been exceeded. A domain name not only represents your online identity, it can seriously influence the success of marketing a company and its products and services. Properly sized thermal-magnetic breakers provide adequate protection of phase conductors and equipment against harmonic current overloads. Under unbalanced single-phase, non-linear load conditions, the common neutral of three single-phase branch circuits carries positive and negative sequence currents from the system unbalance. Far from being a "point and shoot" application, a thermographer needs to understand heater operation and heat transfer as well as issues pertinent to thermography. Expired domain names that are not trademarked can be purchased by a third party and used to point traffic to websites of their choice. Oversized transformers typically have lower impedance than those sized to more closely match circuit load requirements. Corners are typically constructed with vertical framing members that both support the framed wall and provide a nailing surface for interior paneling or drywall. They are designed to respond to the heat generated by the true-RMS value of the load current. Higher levels of phase and neutral conductor current can increase neutral to ground voltage loss, dropping the voltage to potentially damaging levels for sensitive electronic equipment. This is what creates the non-linear loads that become damaging to single phase distribution systems. The most common effect of these types of harmonics noticed by a thermographer in a three-phase four-wire system is the uneven heating of transformer windings as seen in the IR and visual image below. The following images were taken through viewports on operating heaters. Process heaters are large, refractory-lined structures used to heat hydrocarbon product during refining. When thermographically inspecting corner details, it is normal to observe a straight vertical line from floor to ceiling. When a thermographer sees neutral buses or conductors abnormally heating up, this again is a sign that this type of harmonic condition likely exists. It offers a line of infrared temperature measurement instruments, thermal imaging systems, radiometers, spectrometers, and blackbody sources for the calibration of infrared thermometers. For over-current pickup, thermal-magnetic circuit breakers use a bi-metallic trip mechanism which responds to the heating effect of the load current. Verifying infrared equipment calibration is one of the many topics covered in Infraspection Institute Level II Certified Infrared Thermographer training course. Never use an inverter in a wet location as electrocution may result. Because of this, and to be cost effective, the neutral conductor is often downsized from the phase conductors. This is where the thermographer begins to become valuable to help detect destructive harmonics. For course schedules or to obtain a copy of the Guideline for Performing Infrared Inspections of Building Envelopes and Insulated Roofs, visit Infraspection Institute online at www. These loose connections will in turn increase junction temperatures and cause the breaker to trip on what it thought was excessive load, when in reality it was a loose connection. Recent advances in technology have resulted in power inverters that are both small and dependable. Zero sequence harmonic currents carried on neutral conductors from harmonic generating equipment can also have an effect on transformers. They are designed to respond to the heat generated by the true-RMS value of the load current. With this Tip, we offer some advice for driving in winter conditions. Water spray racks are mechanical devices that permit controlled wetting of a building surface. Under the right circumstances, infrared thermography can be used to provide qualitative and quantitative data for in-service heater tubes. For more information or course schedules, visit us online at www. From nemo-bounces@ietf.org Sun Jun 17 20:51:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05SZ-0001vJ-Ep; Sun, 17 Jun 2007 20:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05SX-0001v6-Ug; Sun, 17 Jun 2007 20:51:09 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I05SW-00069f-3Q; Sun, 17 Jun 2007 20:51:09 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.191.178.123]) by omta03sl.mx.bigpond.com with ESMTP id <20070618005104.TTWP28147.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Mon, 18 Jun 2007 00:51:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070618005103.EHGX24129.oaamta03sl.mx.bigpond.com@PC20005>; Mon, 18 Jun 2007 00:51:03 +0000 From: "Hesham Soliman" To: "'Mobile IPv6 Mailing List'" Date: Mon, 18 Jun 2007 10:50:57 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcexQrtnp4iPHSFpQ8KvK/VonMv5SA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070618005103.EHGX24129.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nemo@ietf.org Subject: [nemo] DSMIP progress report X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, There is a couple of drafts in this WG on DSMIP and this is a quick progress report on them. The problem statement was approved recently by Jari and has moved forward with a couple of notes to the RFC editor. The DSMIPv6 solution draft (for MIP6 and nemo) is currently waiting on Jari's review with the chairs. I discussed this with the AD and chairs and we will move forward as soon as we resolve the concensus issues that were raised while addressing issue 93. As soon as I hear back from Jari/chairs, I'll submit the new revision. We're hoping to get to WGLC by Chicago. Thanks, Hesham From nemo-bounces@ietf.org Mon Jun 18 01:18:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09db-0003X3-PK; Mon, 18 Jun 2007 01:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09da-0003Wx-4F for nemo@ietf.org; Mon, 18 Jun 2007 01:18:50 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09dY-0003Io-QV for nemo@ietf.org; Mon, 18 Jun 2007 01:18:50 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6CE00212F31; Mon, 18 Jun 2007 08:18:47 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 382A8212DF2; Mon, 18 Jun 2007 08:18:47 +0300 (EEST) Message-ID: <467615B7.8050407@nomadiclab.com> Date: Mon, 18 Jun 2007 08:18:47 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: NEMO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Robin Whittle Subject: [nemo] Network Mobility and Routing/Addressing X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, for those of you interested in the routing and addressing problem: There is currently a discussion on the RAM mailing list about solving the problem with a network-mobility-like solution. It's also about the trade-off between route optimization and triangular routing. http://www1.ietf.org/mail-archive/web/ram/current/msg01524.html Kind regards, - Christian From nemo-bounces@ietf.org Mon Jun 18 18:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PIv-00029v-EC; Mon, 18 Jun 2007 18:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PIs-00028R-FL; Mon, 18 Jun 2007 18:02:30 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PIp-00081z-Iv; Mon, 18 Jun 2007 18:02:30 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B829D1986A7; Tue, 19 Jun 2007 01:02:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4A34F1986A6; Tue, 19 Jun 2007 01:02:26 +0300 (EEST) Message-ID: <467700F2.4060204@piuha.net> Date: Tue, 19 Jun 2007 01:02:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , IETF NEMO WG , Monami6 WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: Subject: [nemo] Merged WG charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mobile IPv6 Mailing List List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, Please find below the first draft charter for the merged WG. Comments appreciated. Note that the charter has changed only in terms of merging material from the three working groups into one, shortening the text here and there, and removing completed items. I've taken bootstrapping away as a completed item even if we are still a few weeks away from sending the last document (the option) to the IESG. Replies set to mip6 list. Jari ---- Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: TBD Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3776 o RFC 3963 The primary goal of the MEXT working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios (A). Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained (B). The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol (C). Deployment considerations call for solutions to enable dual-stack operation (A.1), allow the use of multiple interfaces in mobile nodes (A.2), mechanisms to support high-availabity home agents (A.3), and ways to employ Mobile IPv6 in the presence of firewalls (A.4). In addition, there are specific needs of the automotive and aviation communities with regards to route optimization of network mobility (A.5). Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA may need to be taken offline for maintenance. (A.3) Use of multiple interfaces. The protocols do not today provide support for simultaneous differentiated use of multiple access technologies, although several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG does not plan to define a tunnel selection mechanism, but may document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address [Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO networks/MNNs. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. The group will also not consider general route optimization, multihoming, or other problems that are not related to the deployment and maintenance of NEMO networks. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Jul 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Aug 2007 Submit Multiple CoA Registration to IESG Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Sep 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6 Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem Sep 2007 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Nov 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Dec 2007 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Dec 2007 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Dec 2007 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Feb 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Feb 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Mar 2008 Submit Flow/binding policies exchange to IESG From nemo-bounces@ietf.org Mon Jun 18 22:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0TXz-0002Ll-GJ; Mon, 18 Jun 2007 22:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0TXy-0002LZ-3Y; Mon, 18 Jun 2007 22:34:22 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0TXw-0004JV-Gr; Mon, 18 Jun 2007 22:34:22 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l5J2YHS1016634; Tue, 19 Jun 2007 11:34:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l5J2YIt19206; Tue, 19 Jun 2007 11:34:18 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id l5J2YE710011; Tue, 19 Jun 2007 11:34:15 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.103]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:32:48 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 19 Jun 2007 10:32:44 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 19 Jun 2007 10:32:44 +0800 From: "Benjamin Lim" To: "'Mobile IPv6 Mailing List'" , "'Monami6 WG'" , "'IETF NEMO WG'" References: <467700F2.4060204@piuha.net> In-Reply-To: <467700F2.4060204@piuha.net> Date: Tue, 19 Jun 2007 10:32:38 +0800 Organization: Panasonic Singapore Labs Pte Ltd Message-ID: <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acex9DFDjINqk7bUQdmMFdjiMw6ajwAIZsHw Content-Language: en-us X-OriginalArrivalTime: 19 Jun 2007 02:32:48.0111 (UTC) FILETIME=[201E77F0:01C7B21A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [nemo] RE: [Monami6] Merged WG charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: benjamin.limck@sg.panasonic.com List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, I snip points for comments. [snip] from (A.3) Use of multiple interfaces. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. [/snip] [snip] from (A.5) Route optimization of network mobility. > > The WG will not consider routing issues inside the mobile > network. Existing routing protocols (including MANET protocols) > can be used to solve these problems. The group will also not > consider general route optimization, multihoming, or other > problems that are not related to the deployment and maintenance > of NEMO networks.... [/snip] I feel that there is a conflict between A.3 and A.5. From my interpretation, A.3 mentions that the WG will consider multi-homing w.r.t multiple interfaces for mobile host/routers. However, in A.5, it is said that WG will NOT consider multi-homing that are not related to NEMO. Suggest removing the restriction of multi-homing consideration from A.5. Regards, Benjamin Lim From bpybs@galileo.com Tue Jun 19 00:52:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Vho-00059C-2V for nemo-archive@lists.ietf.org; Tue, 19 Jun 2007 00:52:40 -0400 Received: from [210.18.134.225] (helo=omhfp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Vhm-0003HJ-1K for nemo-archive@lists.ietf.org; Tue, 19 Jun 2007 00:52:39 -0400 Received: from [26.109.85.97] (helo=xpcxl) by omhfp with smtp (Exim 4.62 (FreeBSD)) id 1I1jjF-0007RJ-5w; Tue, 19 Jun 2007 10:24:09 +0530 Message-ID: <46776124.3060806@galileo.com> Date: Tue, 19 Jun 2007 10:22:52 +0530 From: Eve H. Livingston User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: There are farmers, craftsmen, milkmen, weavers, casual labourers, construction workers and shopkeepers and so on. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 SREA Jumps 25% After News Releases! Score One Inc. SREA $0.25 UP 25% SREA announced its plan to develop a $75 Million project duplicates a successful plan in 2006 than returned over $100 million in profits. Investors are getting in fast. Read the news and get all over SREA Tuesday! Conferences organized by Banknet India are premier banking technology events with topical and relevant agenda with senior level participation from the banking and finance industry. The Code is non-statutory, and the eight credit and debit card scheme operators have committed to adopt and comply with the Code. Panelists at the summit agreed that as the deadline to start implementing Basel II comes closer, Indian banks need to step up their efforts to become Basel II compliant. With this move, larger foreign banks who decide to incorporated locally will get new avenues of growth, but competitive advantage of smaller foreign banks will be affected. the guarantee is to secure a direct contractual liability arising out of a contract between a resident and a non-resident. While Saraswat Bank acquired Maratha Mandir, Cosmos Bank took over four urban cooperative banks. Thus combination of falling crude oil prices, investment in stocks by global funds and higher overseas borrowings by local companies will help in rise of Indian Rupee. This interest hike will directly impact the borrowers of home loan and other loans, however, depositors will be benefited due to the increase in deposit rates. From yxp@omeros.com Wed Jun 20 06:34:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xVi-0007wn-6s for nemo-archive@lists.ietf.org; Wed, 20 Jun 2007 06:34:02 -0400 Received: from bvk14.neoplus.adsl.tpnet.pl ([83.29.208.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0xVf-0001Ie-BC for nemo-archive@lists.ietf.org; Wed, 20 Jun 2007 06:34:02 -0400 Received: from [93.207.213.25] (helo=qeyy) by bvk14.neoplus.adsl.tpnet.pl with smtp (Exim 4.66 (FreeBSD)) id 1I1~X8-0007hV-O4; Wed, 20 Jun 2007 12:35:30 +0200 Message-ID: <000b01c7b326$803fc320$19d5cf5d@qeyy> From: "Snider" To: Subject: diarrhea limerick Date: Wed, 20 Jun 2007 12:33:54 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7B337.43C4E9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 2.8 (++) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 ------=_NextPart_000_0007_01C7B337.43C4E9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C7B337.43C5D400" ------=_NextPart_001_0008_01C7B337.43C5D400 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable With too much risk comes almost certain loss as in the lottery and = gambling where mathimatically you cannot win in the long run. It comes a = day after Tesco reported its slowest sales rise in a year. Pro-Level Percent I use this method and it is a combination of the first = two. Royal Mail officials said the contract loss showed that it had to = improve its efficiency still further to be better able to compete with = its newer rivals in the postal delivery industry. Mr Ashton added that the Chinese had put out their first climate = strategy, in an effort "to get to grips with their emissions and use = energy efficiently". "The competition is always strong," he said. Our = reporter says that subsidised fuel is one of the very few benefits = Nigerians have seen from their oil wealth since the government has = failed to provide even basic services. One started early but was the worst timer their was, the other started = late and was the best timer there was. It helps if an investor is = mentally ready for all types of market conditions. Like other Chinese = energy firms, PetroChina is urgently searching for new sources of oil = and gas to support China's continued economic growth. The other thing I try and do is "beat the indexes". After all look how = we have managed our other natural resources like gold and diamonds. = "There is also a moral case. But this would lead to a lot of angry = people in the cities, who would accuse the government of making their = lives harder, he says. This stock works well. Who does NOT know an African leader? Tullow chief executive Aidan Heavey said the discovery was one of the = biggest oil discoveries in Africa in recent times, but warned it could = be up to seven years before the oil started to flow. I have renamed PE to the "Popularity Evidence" ratio. You can be tempted = to make poor trades because everything you try is working. I still = invest in futures today but am cautious. "In America, you do not convict = someone for being rich," said Edward Greenspan. "Responsibility for = China's soaring emissions lies not just in Beijing but also in = Washington, Brussels and Tokyo," said Greenpeace UK director John = Sauven. The other thing I try and do is "beat the indexes". "We should = export clean energy technology to China to increase low carbon and = renewable energy take-up so the products we import have a smaller carbon = footprint. The fall follows other recent data that showed a drop in = German production and lower employment levels - another example of = Germany's patchy recovery. On the other hand, a wider trend for export growth and revived consumer = spending after a value-added tax rise in January have raised economic = forecasts for the year. If you have the entrepeneurial gene, consider a small business. It comes a day after Tesco reported its slowest sales rise in a year. = The government offered concessions on fuel and value-added tax rises on = Tuesday, but the trade union federation said it was "too little, too = late". After all look how we have managed our other natural resources = like gold and diamonds. It looks like I may get into this trade in the = next few days. We're going to really zoom, accelerate. But Sainsbury's itself has been = at pains to distance itself from any spin-off off of its property, = arguing that its value was closely tied to retail operations. The move comes as foreign firms are increasingly tapping into Africa for = oil. All investments trade risk for reward. However their leaders should = not make this discovery of black gold as a means to enrich themselves as = most of our previous and some of our current African leaders are doing. com has said it has no plans to boost its growth by making acquisitions = either at home or abroad. "The competition is always strong," he said. ------=_NextPart_001_0008_01C7B337.43C5D400 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"snitch"
With too much risk comes almost certain = loss as in=20 the lottery and gambling where mathimatically you cannot win in the long = run. It=20 comes a day after Tesco reported its slowest sales rise in a = year.
Pro-Level Percent I use this method and = it is a=20 combination of the first two. Royal Mail officials said the contract = loss showed=20 that it had to improve its efficiency still further to be better able to = compete=20 with its newer rivals in the postal delivery industry.
Mr Ashton added that the Chinese had = put out their=20 first climate strategy, in an effort "to get to grips with their = emissions and use=20 energy efficiently". "The competition is always strong," he said. Our = reporter says=20 that subsidised fuel is one of the very few benefits Nigerians have seen = from their=20 oil wealth since the government has failed to provide even basic=20 services.
One started early but was the worst = timer their=20 was, the other started late and was the best timer there was. It helps = if an=20 investor is mentally ready for all types of market conditions. Like = other Chinese=20 energy firms, PetroChina is urgently searching for new sources of oil = and gas to=20 support China's continued economic growth.
The other thing I try and do is "beat = the indexes".=20 After all look how we have managed our other natural resources like gold = and=20 diamonds. "There is also a moral case. But this would lead to a lot of = angry people=20 in the cities, who would accuse the government of making their lives = harder, he=20 says.
This stock works well.
Who does NOT know an African = leader?
Tullow chief executive Aidan Heavey = said the=20 discovery was one of the biggest oil discoveries in Africa in recent = times, but=20 warned it could be up to seven years before the oil started to = flow.
I have renamed PE to the "Popularity = Evidence"=20 ratio. You can be tempted to make poor trades because everything you try = is working.=20 I still invest in futures today but am cautious. "In America, you do not = convict=20 someone for being rich," said Edward Greenspan. "Responsibility for = China's soaring=20 emissions lies not just in Beijing but also in Washington, Brussels and = Tokyo," said=20 Greenpeace UK director John Sauven. The other thing I try and do is = "beat the=20 indexes". "We should export clean energy technology to China to increase = low carbon=20 and renewable energy take-up so the products we import have a smaller = carbon=20 footprint. The fall follows other recent data that showed a drop in = German=20 production and lower employment levels - another example of Germany's = patchy=20 recovery.
On the other hand, a wider trend for = export growth=20 and revived consumer spending after a value-added tax rise in January = have raised=20 economic forecasts for the year.
If you have the entrepeneurial gene, = consider a=20 small business.
It comes a day after Tesco reported its = slowest=20 sales rise in a year. The government offered concessions on fuel and = value-added tax=20 rises on Tuesday, but the trade union federation said it was "too = little, too late".=20 After all look how we have managed our other natural resources like gold = and=20 diamonds. It looks like I may get into this trade in the next few = days.
We're going to really zoom, accelerate. = But=20 Sainsbury's itself has been at pains to distance itself from any = spin-off off of its=20 property, arguing that its value was closely tied to retail = operations.
The move comes as foreign firms are = increasingly=20 tapping into Africa for oil. All investments trade risk for reward. = However their=20 leaders should not make this discovery of black gold as a means to = enrich themselves=20 as most of our previous and some of our current African leaders are=20 doing.
com has said it has no plans to boost = its growth by=20 making acquisitions either at home or abroad.
"The competition is always strong," = he=20 said.
------=_NextPart_001_0008_01C7B337.43C5D400-- ------=_NextPart_000_0007_01C7B337.43C4E9A0 Content-Type: image/gif; name="lever.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c7b326$803b2f40$19d5cf5d@qeyy> R0lGODlhVgPLAPYAAP///0Z4jl6hhmaPaUWsi3tch7NTqH+GgFBpVG8qSl9JVUCcnS5qbS6XrJZu dztDgSuHdH9kWYifbrduRohiQYyeoqiZVHjTmKNqoJc2U9NEAZgndlZEdJFAKzNnMKCYvF5YsliY R3xxojvJR7C4h4mnmatBa4omaDKYW7Z+tX16LX6VPLOS1JGDjlFzM42QqpySeLQ4QllSLEDlnVlf OyJvrWc92iHKf2YS4JrXjLx6erKiZ5HA8MVrG6eWiIyCvbapx1elVms3aV84anjQWJHIV58YW6Zo fpSdi4hh1g6adruqtqTepC7rs8hOvFR4P3pZuHSJRn4nhnIGrafXwONq1UOE4XcQJG8yejS+0Xwa lsqVZ3l5zxhYrNM9kR2rXi/DLZyJHGltzzDkhMHSeJOsQZ5QyhJjkY5kuQ2/tVXiiR9bMnDZ6tRP seG3Qn0kdjNFEt21WFYmrLopWuOwd1YdFiVox6q3T+KwicdgaFzPQ7WjR98qPq2F8dMmqDWYGCwA AAAAVgPLAAAH/4AAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn 6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAMKHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq7NXD BA4bART1oOYRJINEIx9B+SQgABN7bATIEGXgVYNDN0AV2MgTXokvISwwKUKgUIMGFyAQ6qEFB4gA DxJ1eBSBWNOnDxIgmvqIg6cBAUqQ8DEoCwQhEEISCjqUQAUEhv+U4lLbyS0CGSfiaqrpSm6hL5C4 NqJQjOhbvAJG0UAwwETVaw561mqA4PEgAiNWkMhBZAGhBQ0WqLmRU5AJQgqGYNo5DAehIXQrweU0 YcCgyIIoR4DwgLUgzZwXCPBQaHTpwJsiGGBR4YcIr4JOduo8yPeg2Zj4UvqBCTuhEcgdTeikXZB3 BBweBIDuqMCEFoU6D09QwHOhDhpOFwqQmND4RTIwEEEG1k2CnnocRIDbIr29l8oBks2yAAQKgHUI CYYccNMgfklRCHuDPKDAf4UYYAAMFGAHYiEVNJbCB5BEwd9YhVQYG3gwbAbAW424Rkh/IY54iIko ehebbYO4+EH/BY9EgYhfADigwyAwLDIGAFA2MqIKmpjwYnMFsEdcJ0AacgMEFGjQg4eDDMFBmYNM oEIIElQ5SHmWOcKdIejFpkiFhYwQwiACHJZXIWiqKYWPgrx5wAswCqIAAHPWiUkKhRR1HQcBgKCg IyBIWQJ4iGhYSJprMgqAoy8E6UiesnHqqQMkKhKqDqMOakqrEcLyw4YABFAgADkYoukhU7zm56od 1CqIiRhEEeB1hEAoiAgEKGAAEGzsyUhtYZGBASEMIJCWb5ltRsQF8zFiAyH8fdisIdBKK50gQB6A XbbbdiuCI2CVYMi9gkwpCIaKXOldI1ONuYm3g6wBgALqgZAJ/7sOE3IDAvjFkKwgCcAmAHyENOvB ChIsCMC4gjiQwSP+BkDADElS3Kkjcv1HKgDrznfCseZ1PMW7gojcwgdLDGIyyg7AKQkQhdA8yKS3 OYsIuisgArQggoE0iFqRrvrIy53Q2gjWp0DcKytZFKKyIEUYkkYiTkF1RVSIEEaIiYg47ACSAPA6 SNiKTODkIUoIUbUgYPwnAA8gM4LV3U4Loved5RUCeZSAA7D1iooIwMQWKw2ieJyCU6HICE0AkCZy GT+LIg1ZNkK4IB4MMEQXB+Cg8uilQzKADPQdokEhD1wxCAabTyyYIXZC8PYiWXzA6QwX4A64743k zDihhcxtSP9Kg9y91eUAtG0J1IRk32Yhh0NiNQAFiJ8IXf1t3gXVjZB9GwA0UEABBCc/R6hsAqob BPHqVwNCoK98hOABCUSwvyGt7RXqG8QWDEEEQwDLEHUbglYS4YJCtCERKBDEAVQmgMawoIBPKoTB dOW5QRzKVgEQ4bIGUUJCnDARrVphIVx4u0f4oAAbsCEBwrIFgwmCCUQgAA88kIAbAmBnx3MEBQhD p71hQAIBOgCsGMEyQjzBO3YCgFiOmERJnEAAHxREFt9HCPa5ThESAAADrBUJvA3iCYVIoyJC0sTE 0BB3VYSj8QoxwkM80AqXuB2TBgGi2khiB4eo3H4IdYAUQK3/Bn5sBKwcgAIZKEAELYwEDOZ3iA0S 4iWIfGNo3AcA/BRChIPw5A5AuUVD/PCCrIij1ZwWR0IQjRE9vFMiEhMBQQpCOUBojngSsTCSZU0Q AhPEsAyxQ0Mk81mKgEEzhxRN51DiCIPYTQBI4KwcCKAE87HODQhAAw3MkRGCyaMyCeE/R/yrEAuz AL4QBoAjqO0RxbwnABopiKRxTRHSqp0j/BTQRoRkPEW5Jr6oWJ9iAqCfYstbIQ4aiUkOgoAPAAEI amABVipCM4aozyICQDBICaKBkCjQALwzxkUIdJqEKBbuikMIhTL0dg8EQOaAiQqCAcCJ4CuEfQ5h sUYcUqmJ/1jh9AjxAhF0c4iJ4B++BJHGbAJAk/CyaokU4QAH6CsRXp0qJPQTLEHsAKoAoKUhxnCm NMVAC46wAA3oJEgMwGAxlFjWwv5TAjKw0QTbbIRcBRGDWxaCoD9FxGIGkFTJArQQLiUEk6aEo0GU wDuTFQRg06rZQpSREgSs69dUGoDQJsKZY50pIgIQEsE6YmELo6tFbUsIvOr1rKERwJUG8depqWYQ QCABbxOxVKaaQqwAIEshjguA5nHTERp9FskM4QAFdW5im6yRISx0CHMNwgeaIiiQUjuwRoRXqeM1 xGPusrdMOcKsBmgjlt4LNLQudxAfW4QEKHAyCUygTFGgAf8DXCaJZWH3pyWggwiEEOCFKcJhDfCu IObwIbosAQmDYHAiaCAIAkliaxT7WmYVgYQJkCVdUc2NiAWRYEHE6xCxWypIF6E2gn3VvgQ1HX3h 5VRBICEkCz5ZI2K3sOreDxLazTEAhAAaHozgwDweBEOdzNsFW9C6qsBulgfB3R1/Dbwlyi8hyvs3 9bIWNevtpnsFAd+D5XjJ5LJvnBOx35ns8zL/vZOA/dJnLRcCzADocSKijLIHEyLCEx4yIyxcCAxr mMMb8HAiQLxjEhOCU4M4cYpjRwgWfzSyioCxHwMw40TU+MYwza2OkbUfTQbZEJpORJHvPIlcE4LL M20yAJ7/DABKT/mz/X3EkQ2x5rMeu8tfLkSCx7zsMnfWymgWhRV3ZIgdX2BnAJjjtAcRt0CmKAAm 8J/eSsnPKgAhCykQwNYA8NxCCIAMWyjACX6pxwrsIA8mTSAAUpgbRoQyEe0mRJHg3U8+CnAQ9sa3 vqXGCIALnOAEO04NEdE6QqgqEbXOICHiDWutGaLfgtAnGSqBFw159CpQwZcADMADOhTCBUU4gACy 4ARCYKcArF4ExwfBOxxAgI+MyEOcCFHKE9icuwCoW1bwxXM65FwQ38RqIYKNCEwRQmKDgHokGncI tRviKbsVxE8j/uFCGBrjj3g6JEwKAKLYEOolH4RTALB1/0RYQAVhF3u4TyGEY+nAaXwfBGk4poHK RscR+rT7Hl1sOTGDiAVJSMIL9k14RJCgBVjYgBcKUQILQFWoAAAxI7CLiMwTIoycVyEh/imI0I+e 9IlAvYB9/B2NuoWKJwCNIEhTCBysu9ZcGEQZCtHyQ+z74Ug6fSWS71FBOJ8B/GuBJw8hAQEsgAsg J8R5GTGDDwTAA9iBghwkmggnYpIQVVS+GnYL/n7rEpSDcFVLVX2FMHpfkzHBEwmZcQjJpwjOhwi7 JHcxtwgFUAAD8AKXM2YvhDORACScQQhWxHz7AX6GcH8BaAivtXilAAEiwE6Rp2uZUk8K5Ql5QoD5 wHsSiP9NMkEfR7F8hzBthzdSfBFhAeAyfAMJSycID0cXBYAFJrABHCBqx/ACDJA73DAzF0CFhVBV kUAAQWABm1EmLad1CQAiS8BHiCcBtjckBpAC5TU1hbCBm7ZumfKFYUgIBXAUojFPh1B41VIDA3B4 LrCGAIBbKjgKJdBEhwgMtQZO0XEABAJuiZCEjLABJiAECCCF4TYDFbAsXAgJmQEDnIF1iFA3qREb KLYWhOgI2JUEEyUJoQh7hNAAVkAAOcFwdsZNEmABLnBVi/iLwBiMEMEA3CaMxniMyJgQWpeMzNiM zggQvKVszziN1FiN1niN2JiN2riN3NiN3viN4BiO4jj/juRYjuZ4juiYjuq4juzYju74jvAYj/I4 j/RYj/Z4j/iYj/q4j/zYj/74jwAZkAI5kARZkAZ5kAiZkAq5kAzZkA75kBAZkRI5kRRZkRZ5kRiZ kRq5kRzZkR75kdlgA1YAaCBZkiZ5C0lgAw1AAMDHCQiQAFzWfSc5k/J4AAtAkqrAAseEPaNAPDaJ kzQZlOpoBATQACXQQaCAAgfQWYjginUEh50iBZanCS2pCECwAyBwAtMnlFyZjVU0COhGCRBCU76x AxBwBB2QgkBUgIPAAF0gAlCQARPgJ3GQAHIwCYF3gnOgBRowbgCANEgAAhlwB11ZmNbol4SwARkQ AxGw/zDRhYMqBBUBgAHjUgKZJwJAaW3VMghKgFPENwg9MAFvAAVBIAnFFAQUoJiM6R0YYEeG+ZrU 2FGHkAEbEAMZgABiBZie4m90wR0SMAAD4gABkJmeKQiAcwbpBQBhQCIhYIOzaAhR0E+5CZvUWY2z 1DkUwCYoaEcWMGPLMgDACVkL8IKHEEeA4yd0EZpvYIFPoJaLkFoPJFauWZ30yYx64ABGwFzCBlrE Jgj0twhxFHF+wkdu0AFaIAIhEAGxxQhmpZ+v8ZT1GaHN2EjDVwhIRQgPhyXoFAkLcCwDEHGQaRmu VAmwlJjIQwgk4HZrJaEsylTKIwgVCqGD4GpKeAgmYP8CmPkBTGksnHgAnQOZlyOalsBdFfpwIlAA 3RlAhoAGLdqkPDFVRiAYtYkISzBeKkCjenQ1w/mGjnABLVIICUgphCAFB9CcIgBIjiAcKZOfg1Ch TRYBh0cDwnUtTlqnGLEAFzAAGzBmMVAACmAz8IIF3Rl2dDgKA9CeAfA875mne0oIU/mZdhqp1jUC R8Cm/laGDOAnQVAExCWpnvqpoBqqojqqpFqqpnqqqJqqqhoPHRAC8ZMBApAAe6CJq1qr/3gFHYCa bNKYHbADDAAkAQABX6gC2mIIWGqryOqOuKqrz8Qxvgqswnp4xVoIx5qs1oqORvCiAMAm3iF+N4UC ZbD/AjQgBClYAC6wldearuZoqUZnof65CHCxfuo6r954BU9wVWL1Aw5VlQAASLhIrwDrjUGgAhsg YFewBb+KAXJYlQrgJNITsBDrjVoQA5ZHARawR691AYelLUJHCMk0pxEbstdINv9xNIRQAhQgpxgg AKXJQ785ICIbs9jIGpn1AQRVbUa3AuAZAZAlsz6bjK+KJJ2TioWYCGj6Zj+btMEYBlJQm5ZBMCIg Fzg7CPelBEp7tb84sY/qJ5ryASmAAUIXBGrhArW2AAuKtWh7jB9gAC3AsgPAGlwCPWk7t3Rbt3Z7 t3ibt3q7t3zbt377t4A7DJ1KCwoQAWhQAI8qSieg/2kjsoqs8ImBG7lSYQHy6grxIwjkAwAygAFi EAExsHqOAAYGkACwClAdQLllAgFbg1adcEyS+7oAZbG/ul07QJ6J8AEdoKIAUAUfwLqEsDWZmzFt 4J6HQEM3MEcFgB07d1NKcAEm2LGLgLsH4AcokCKTIGmw+7oDMCm2kV8EwAQ6sLZp2gIRcAQbSggs EE3KxwiTVSuwYoiMMJXntSc45US+Kwjka76oKY3leQYhMXwU8AehqTe012zZS7fWcl4NACQGoLss knaXywVy2KGMUJwAUCs4mAKOuwgClsCCsCcbol3Q6wi6WwE36UFKEJX+owAqoAKhmQAeckqFIAGX e//AV5sCeCBbiPYjknC5feBfi2DB6HO4MTAHbDsJtJlLnxl9nlMCPgAjKxsJ8mrCHQo0Rdmml3Os bcSkhLDBNuyzO4AAAvBa/bGB91sILWAdGwhJAECJhvBwDCUGFPC5xMsI2gkAZtcfXOgDIiwJcgYA QAAknDgI5lkILyxwgiDHg0DDX0y3T5cCzeM+efwIXoACVRCHgsDGeYkID3c6gmAHl6ABqpLDGEov EBIE/GsIl+yuhBA2cQQ0YRCaQlAAjTRHXtzIMvvIkSwIk+wIlbzKg7DGgrDJfVgIngwAoGwJokwI pBwipgwAqPwIwDw4rAwAr0wIsTwBs1zLi4zLdNv/KkwMALDEFy17NgJgdtDVcHnFCCuCBXhoCVGQ uCMqCF0waEHwtpJICOg8CJEnOFb7GQGYufwTA6cBA+jqzVjLHXtcCOXcHtMpWrNXCHdMdozAWYZA uYOwUivasnVMfYYAJ3x0Bp45AJ4ZtyAjVm14ywgNsUjyAVzgmdXW0K9ysmy5CDRg0qnnqJQwANFZ m/0UAEfz0iWyoS27z4oAOicsCC/QOSBgAxsQAQGAnIKwnB2QejLwNi2g0isNsAMwxjwQGz6AzkTg VPIKuhMDdQLAxjtChy48AcWj05NAAExBsbDCPH6SAtrBABhgAA4V0YbQoZy4LDgQA7YRSm6NyCmo /9VbDbDiF86D4AQry7LkNSSWTIKFUIsE0ARGrQgF6s6tUHR7k894Zn2arQktQHeLnbTHXB0TsNma aQh8YEuZNMbYkLme4AAmcASVm9q8vQ8UcARb1dvCPdzEXdzGfdzIndzKvdzM3dzO/dzQHd3SPd3U Xd3Wfd3Ynd3avd3c3d3e/d3gHd7iPd7kXd7mfd7ond7qvd7s3d7u/d7wHd/yjY1ZEpbpqgFzgL3p XWb+9gMm8sfo4FRg8AvzaQsPACcZyg0Jrgs3wHa3Z3VHcW6DYE9XESIIbhAzQwUHsAZWCA2mNEAE kAHTjApup6jsABWBaNLp4wREgj5IxwMUsEL/Kv8II24NfnJfs8BtTnkK+Wc8MaAqRjMIANgIDmw7 vLDguCAAmbEDsph/oTEaE/41JxHkN4Xkh+CcluDZnPDjJ6cKM+N+8FfAulULFXheZYhKCGACcigI 7fd+hCB/T7d+XiAEDNB4hrACTI6UgzBZHFMI/ccMsngJEQh2hODY06JNFxjjpFQIar7j1wCZjSgL tOfob6xSm7BAPVhUGrABg9coSi3kjxDcjnC2mrCDeUit6cbpkLtewHAs7oQIUF7M0CE4FswIoh0J y6Llm6DqnuDaAAM6jACZsJABJuKG1ncI2EOFHQ4AT8FbP9amUbhng2CH7tSgH0RP+5EVb/ILK9L/ TpvgwGpDF/lcE5ReDQ1atGOVSKUAicNyFwIkANhhBmc1M3xXMXBnCEmEibSKf4NQi0ozR/euFnsy XYyweQXQhpOwbjOnF6HzkrKk1rVUeThnCCcGZcVAiiKnXgLvY4VKTRNTAPBeYfi+OisAv4uw6mQW ALsYCQDOipPQoCU/ipFjCDO+Cbn3KdD2u0vHP5/YWHxiCAuoZcByAzN+7699CQpS5NKmRo7VrsVF JaMY8r9LGihg4rul8mf2iEqsCJgi79lQbfJFA/Sxvo0wxjbLdyVUflngJ9JDIKB9HQrAAdjCP2ZQ AVhYAdIRYxxPLxsAfgPwn4lQzgolHQJg9muN/zMuUwBOsOYTI/fWx5NGZgM1QPAAsAOQ+feLACd8 Z0+B1sok0Im09giKv+aitpNeeggNFKxnfAjkGQRWRoxnZfidCAluD1BxP/dvX8G8BQECQFA14fdQ ghlgGOgWdSGgL4jwYiI+8ECLT2e7jQjb+wgVohRZNgLDXyiJ8dZfQ6MfQVPFGAkgNT2058Y3VQgm mCRArwgbYgDL0vElsvy04zbmtS8A4ARA8C523z29b/mejF3jBQgkOQIVAjQAiAAVQQYBNBoaiZKT iAEWKi6TBgY+FDQQkiyUkk5AAGYVo6oCJDuUAwACPhMtqra3uLm2rpJMiR4yiQ0XugICBjxxAf8P iS4SBwJZDAaJDLCITh+UBZQpBJJriEM1IjhKB12UXifVupMhiZEAOIjMiMeV7okRozIKBRVASSJA oAmVAOEQkTOHTkkibgPdGRHQYJgkeYnsIUKWaIAFdxHMZOuQyN8kFvQAFDyYUNK5LkpKkNGXiACP UfBUacQHIABNACGdTDKZqIq+lzFnIlqnxAgBBqkAlPiSqMg3mj4pxZmUCZG0TRI6MCD1ocOBIyh+ XtPV9GkFXgBy/ro3SSAALThALEuQ9ackfpKOUMpAqYkth4nI+KB0VZLcUQ3iUqO09ydYsWsBlC2p ABGEDFVQeiuYK2aiE14QGZlUYlJjScQu0qT/4UzS5bGSyp5FQRSRUUSvbyX1AbEm1B06pvpdzhzA hEk55koSUGwSh0QhJNhOZBdRrUkiKL2Y5KFeABAgIAQ4Q8lE81gH4uUDkIASjBoAylBwVzwRivqI KDAZAC80xkB58/mXCBbuISIEYrgkcAIBDSxAnXySAIhICpPsl0sGxVEAQzuSJAFcYx5kBoB6iZDg 1wKjCBDfKAxomMh9+XnoDocZnvQTe5OY0FmLwI2wgg85EAEjTbiNwoF+LsgVmSTdIaIjTQMMmYsC TZLwnCRJLlABghQ+hEAiKSXSF3P9ATDjdpPMYIt6Z6BQgouUQJjICrdYeECbiSQwRAAX5lLA/4CU fEeigIiYMR4AcuKSliQNCuHaJEtOImMBZzKnXSKTJVBlCyIe8F+TALCQhKPBqVLngg0iosSaI7xn qy5fJhIdIsFIouItH5BwQA1rfZoIBmpO4oB4lBSKCIJrqrLBe5nJk5WNAAgLgEeY6IIoIodIwmMs 5E0SwLkQPEFpR7rIwA67GAaa2yQq6EKYJG8W8GiqZgA3wwUieJCiue8J0NorqixDibbcdqXLvgH6 SFOVAEwrCS83hGCBIAb/pNEkxF5SWyUFYDCiKoCppU+nieSa7SAlDNArAFMCwDIAcpz78Xvf/jpu IrGNgu4TeFJC8Ue2XAALAldqegDEtgAqyf+ykkB0LwBoAJ2LupJYrOINrKnCKQWQLPcmAMhWkjIA VI+SAgtmoCEAAZHeUmWsK75z69626NBYkvJO7c4HSyBxrrHGIpK2m5OsTZemk0waABS4XMccAW0D EMMkQ0yCBCKfPmbLtwDMjIgojyuYiF5DU3odAhSPYiPmkmwuSeeJLMGVLm2eXaiJ/lYQgAcoaJmg X0QEPVDmiRwQLSKfAxC6PopGXOJPFFueCNK1vme8mmsmjgEGUdCAaiLM61K8PtojokMiSPaICBff cDqJ8woMeuu3N59OSVRCy8XzFmOLxnQAI6PQRi4WNwrHhQcAA9oXAG3BtURYrjsE6F4inDX/Cg3E wGK4QJyzGHg1oNgCdYmo25yCJIlo8YlvMJzEDUZgASYUIUPFYYQuMIBCACCNcZI4GVCuFoH0tSo4 a7FBDQQQAAj0DwDn08ciJgFCRLSPBA9EWuJsIZRJfA+FSEyEEiXhMEQwQAi/UkUCCrCABiwCUVUE wBUfCIBu5YJyvhqIpVhggxTi4nnuKAIHExGEUeRBBA9IAAcKhUVEaFEfjmtTH2nyxPO9DwA0fA+2 jveMUSAgAI5jm1/SaAtLSUJRviiJjRgROysaw1ZdTES4QvE/WwByEjVLRCpVUch4xJGWu9PELRzQ Nn1hY4OJmKAqXACXDeAGAg04gA5aMMNJ/6TxW78chcg6GURJZACPolRFDwGgPFX0r4q59GEM14md HexSNRSygtLcgSgJ/PBsALjhQwwwEk+aoAo/mGRw1vaSLzQtb36RJyWmYDv69CUZ24vSFlUxkgNQ DQHFAWhNDIMIFKRsklYSHQCMADZ3xJMYiJoCwSRhByzYM0reiqUDqLKuH0iiCaawRTr8YkObeMBG 86SEDgKgAL5cCKKOlKg+SFK1SYDUHQet0iUB4E6r8ABB+tgkAFxqAYm+6VslRET6JBXKW5A0EToo VE+vmoDV2Eaq96PED3WRjUR8oQ6UsKm5WgIAOu70FukEgA0l4VZEqIihgYPgTfSmCX2qYv+mdcBo UWqSLFyEgDgbWIckGmCBtMaFPG0t00YgcEANIFYXSp2EYzfSPMhi9EIalQQQbpkICshFs8KYBFzY yVtJsMONg7QF4WAAggzcQUccfCGoUlA9TaiqXyrx4sr8AlwH2C8RPcBAItunOzIqNxctiAAM3oQB AghonDN4wYGytDo6oUAFIi1rb427n+/egrnixScEVTUJ9aZIATsD0k8GYSE42Ci4tuhuM+yLC8cx 8BQ/gS8GGISI/lWPwAKAw084QChKHNcFfCqUAY6wAhlAwAFhddOpHqwKUtotAAugxWsEUGAAvOsh lNCuIgnVXAAcFBfhHe+kJgE88mTpAef/SYSAR6GeGDeXxhmWkOAm0QML8liBk2AwAEp8YhBR4lTA jK4ZcwEPBuFNFxISbYUPGAMt9BYRQk4AA8rrP0pEkRIhmLAJzpwpRBTtzb3VrzuwWAB+1Ct1VgI0 O4cxgLGBJ5GK3tYJftY8D6irfa07dCI+GWlbEVPQANAreZ6AAA7XpdNvHqutVFCAzFY4bHtbJKhV AQMKIGAA8qWBAlBQUt4GQJoAoKmhngiA7cpoFJrWhwMO4GJzchgEVHqxNA8miRIgwF0/kRHUcnHr CESAdKMQNYpykWxUm9svrU5NXCXx53Pfqs/ujre8550IE3CAA8Smt773ze9++9tW9LPu/3JWUMZ/ G9zdYTi4whfenMAy/OEQ3wAETAnxilv84hh3xwV0uJxyZ/zjP6kyyEdO8pKb/OQoT7nKV87ylrv8 5TCPucxnTvOa2/zmOM+5znfO8577/OdAD7rQh070ohtd0eeB9sNnffTm/Iq2TY+60D0u9TefKwIq oPreUoxxLqCaxe5GMhRq0Jes92ALXm+hAGDQggyWkz7LwQDhVMF0izschrP8i18mCvWq+33k8PZL weUt0ltQYTlZ0moz6E1224ZB5Ot0M8nF8HV9m9qw2Hm8D8SATgkkZwQ2GcoJEGyLA2CAB3QA+VT7 BOg7q/oWE23232evcCKMgtrrzAIAlP/gAKbeAqs33SCAJ0cJMNBkVz+pEe5UAXx3CGZv+EmEG7Z9 qzSB/Km28qD1K9GCFABhB3aQ984SYfxEvGH5ur9FfVSoix4n4hlSa06rdIF9xfFbT4l4PhTBMAZV NOEDYzFIdUd7BNhvwfV2+qAfzZcIJSABXRZ/iVBBsIEIRTAAQ/AAIqAX+6ACK9ADO0B5uYB8fjF+ tgJ2yxEtIKgLMSMDa0QJpVUxueA4pBdpHegK9XcLLFgAaRAAygMJG7ABkHcPcics7YMLKAaBNIGB SicJ9kVxMwh3aaAPDCAAQ6hf0ECCy8JGULNrI3ADEogI7OcON0h9krCDCAhDJ6YsacP/hV5ICf/y AgNQgZRRgHSocElyAQKAADZiextwBQc0Cg8AAfpFcIUnPWvRdw6AOlYAhgezRQBEASoQBhNQAdi3 ADCQVhpke3mYABSnCyS4ZTA1CWhQARIwACoSAUfAKTSQb/rQH5SIKZdICXioh0JAEZLghx60AQ1l C3PVE4mQNaUoe5RgA1awAHQjCWcyOUkwQZE4iTZAR9zGiRQhALaHCH+ICCvwKwrmDgOQASYAY8ho M7w2ZHe0jM6ScIkgBFoiRLJjKQ3whNxxAD9QOPFHgt4IYy+QMqs4jomYCMY4AyUgAMKICJQoAurY HdShBjwAOLhEjZOwOTGQjcYzj0hQ/wAF0Iu2cC9L8nyriD49dIyg80R9V4ckaW6DUAEDQAOrZAJG UFpxxAFTyEOjoGXS8xOiIAbGSE6TIHY/gHsAEITCIE1IkEEbhJIqyUZSqAqYYF8GwAUNiGsl9G0F oGvkuBxYpwJnl4KIEE06MJSToEyZ0pKJsAEuowq92BdOWYoRwHWqYAM4STcXAEAcwJMlkBVZJ0YD KEsTGA8a8IMTMABR1G64gGvJ1DZU2YUIYIKqUJd9kZU2cABvIAld6XZUIIIacobihAt35mWIkDJf VBP/gpITpQpi8JhvMAAYNAIXUJmEMAq9NJZkCZiKpDgsQAIvUGgYqQr3EhWTwYaJ2f9D7FeEvliS xLlvi2VNVaRSiXCBifB9lDCaAPCa7mAii/gNOWVFASACNvAB+ASUUHR3oZdb7gB1W/QtZwYAVdkc jtcDZckANQN6lNBWFJEpVzAJe5ALvagRWVA0JoCEkoB9fXF5CoEIolOIsrOXiAAJDLUHREUJu5UL +KQjkSUufvEm7CkFUCA6mEgAVDBYiTARFYKZo3CdCTMK51lhKDAGwjYJJKoPhQefiXCceSQJp1UP 9rc9+uAeC/AC+zEZCJCiX1AAKVBkAMBRFkQJeVmcSspbyoQI+ocIymlFDBAALTBcz6kK+JcLJhIZ 34BlANZCk+AGlPCJAABv0acL5Cn/ihewA1mqOrfiIW7ge/WQBRPgDao5CQZ2Ak1QA0Ejp/mUC2Wp EeU0kgNBNwCYESCDCOWHHVmlp3yqB7KBC+yYC09qQohQn2GmbNKHCAcgOpSWIY56AXpQqbewjaMg NaRKfjPgATI5CVhGEy/6laNQqVE6ZpohCauFC4IBI/wAEXfmR5Iwfq+3pMTKW2kUR3jzAAxgesEC jZxaojRBjDASmsspCcIzCWU5nLeHKfrAdPrVgAFgAlyXd++haQkgBy10AJM4QzIqMwjqp8JYbhrh k4FnC/8Yl2txpvNRbl94CyeggwtQTn2JC86KC2fWNp95R2qSMrnyBGvSpKdBRfog/5iTIDUFSwmh gX0QuzWjoEGYRwnIOgm40ay4qQ/hMR5Z2FEeOwlxuZz62pnFGrORRmyFhQgu86vTgTLUlUzBOjlS 4ADn0iHNYgscBI+J4H7IpJvfSAnf0xzJBo0zeDMOaY0YUQbCWEYPUBxbVK+Q8RqHWLGI8HjYIV+j IARtRI3MQ5ZWmz/bcJEE9yGxgoqbRmS68LPn0h9XgpClNAk1iwvRMzoBNAorCgDYN5CUUFblRLPY ulL0eJFYsQC1kIoscwMokIhJULimOJfP82My27l7YzqJZbOSMIW4gGBka69JmwgioAUxwA/RcgJS MAAukDbANgpVKaKToJjkUm3cOv8JrDh/tpBssts8qzcUCXAACxCw1bIBGTABEsCKzSABEiAAyqq1 ayEm7tBnA2AszsqwsCu7uns/yas0JoAtzosAX0oJDiAyvCMmxCQJVXmDDRS0vkUlNZNBVMCabIAI xzsJCeCntnCxcNK7lHADXzAAb0OM1hR3o3B4kgC6/Lu4OZstIoAF66t1qgBAKoLAfLSIk1CK11Gw /eq5JKxJTtEA1IapLXM/3rcDIHBjlbVvIhACiYlWAqCaHSodiVCNutDC0JoIcYACB0AB3xh4DMB/ lXsp+gCUN4OJq/lOI0UhrYFPDPUcTTsK06swAyLERAyOJlUQszW9qzMJcioFM4z/NvqgZgCgwr21 o46zqIggv+4gBbiUCDjMBETQmiM1CgCsCktIE1yLng4wpPU3vcOnD9rVABMwVQ4cuonAxs6xbi58 AmUwAaH4MG5awprsb466S34Kw4hAOEhQXB83Q2xQmYmgYZKwssBSOD/MHUfQARjQSiPQBB5AaWH4 HqaMyvEGCrLcSrYwA+kFCoUCTolmK0Y6Un0caSurlUcnAAzQBQKcMDE2Lo0cwbkAymkzyri6yd78 zeB8boa7byEaAn0YzjAHjSODzuzczu7sF6drcGjbt+98ciAQAZdAA/Fcz/zcz+C8z/7suRZwCVcc 0AZ90Aid0Aq90Azd0A790BAd2dESPdEUXdEWfdEYndEavdEc3dEe/dEgHdIiPdIkXdImfdIondIq vdIs3dIu/dIwHdMyPdM0XdM2fdM4ndM6vdM83dM+/dNAHdRCPdREXdRGfdRIndRKvdRM3dRO/dRQ HdVSPdVUXdVWfdVYndVavdVc3dVe/dVgHdZiPdZkXdZmfdZondZqvdZs3dZu/dZwHddyPdd0Xdd2 fdd4ndd6vdd83dd+/deAHdiCPdiEXdiGfdiIndiKvdiM3diO/diQHdmSPdmUXdmWfdmYndmavdmc 3dme/dlNHQgAOw==^% --%^V9^%-- From vvs@cfl.rr.com Wed Jun 20 13:06:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13dU-0002gF-HH for nemo-archive@lists.ietf.org; Wed, 20 Jun 2007 13:06:28 -0400 Received: from ip-89-102-18-207.karneval.cz ([89.102.18.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I13dS-0007mu-R4 for nemo-archive@lists.ietf.org; Wed, 20 Jun 2007 13:06:28 -0400 Received: from [88.232.125.169] (helo=shdv) by ip-89-102-18-207.karneval.cz with smtp (Exim 4.62 (FreeBSD)) id 1I14j%-0003hl-AQ; Wed, 20 Jun 2007 19:11:22 +0200 Message-ID: <46795EA8.7050105@cfl.rr.com> Date: Wed, 20 Jun 2007 19:06:48 +0200 From: Tim User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: With Opposition Research, Tone Is Revealing - washingtonpost. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-0, 20.06.2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a OTCPicks.com Picks SREA As The Stock to Watch. UP 272% In 7 Days! Score One Inc. SREA $0.30 UP 20% Today Up another 20% today and over 272% in the last 7 days, OTCPICKS.com puts SREA on their watch list. Read up and get on SREA first thing Wed! dk - this website - are what we print. 'Renegade' Joins Race For White House - washingtonpost. Bomb Iran: For Israel and America! City is about to celebrate its first anniversary, and players are marking the occasion by packing the joint for its Summer Poker Open tournament. Native gaming cuts unresolved Home :: Web Directory :: gaming News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. City is about to celebrate its first anniversary, and players are marking the occasion by packing the joint for its Summer Poker Open tournament. Check out my article on these little fish who "run" on to the beach right here. A Look Back, And Up - washingtonpost. Gonzales Meeting With Aide Scrutinized - washingtonpost. First Nations group in Ontario rejects casino settlement offer Home :: Web Directory :: gaming News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. Race and Democracy: The Civil Rights Struggle in Louisiana. From nemo-bounces@ietf.org Wed Jun 20 14:17:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14kM-0000Gs-Cj; Wed, 20 Jun 2007 14:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14kK-0000Fw-FD; Wed, 20 Jun 2007 14:17:36 -0400 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14kI-00062o-OO; Wed, 20 Jun 2007 14:17:36 -0400 Received: from ndjsxgw02.ndc.nasa.gov (ndjsxgw02.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id 84D77375298; Wed, 20 Jun 2007 13:17:33 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw02.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 13:17:33 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jun 2007 13:17:01 -0500 Message-ID: In-Reply-To: <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Monami6] Merged WG charter Thread-Index: Acex9DFDjINqk7bUQdmMFdjiMw6ajwAIZsHwAFP7PJA= References: <467700F2.4060204@piuha.net> <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> From: "Ivancic, William D. (GRC-RCN0)" To: , "Monami6 WG" , "Mobile IPv6 Mailing List" , "IETF NEMO WG" X-OriginalArrivalTime: 20 Jun 2007 18:17:33.0389 (UTC) FILETIME=[459737D0:01C7B367] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [nemo] RE: [Monami6] Merged WG charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree with Benjamin. I think I understand what is implied by A.5 in that we only should be addressing NEMO specific items. Perhaps is should read as: "The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols)can be used to solve these problems. The group will also not consider problems that are not directly related to the deployment and maintenance of NEMO networks...." Or=20 "The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols)can be used to solve these problems. The group will also not consider general route optimization, site multihoming, or other problems that are not directly related to the deployment and maintenance of NEMO networks...." Here, "site multihoming" is meant to mean items associated with shim6. I am assuming that monami6 issues related to multihoming are withing the bounds of the MEXT working group. =20 Regards, Will Ivancic NASA=20 > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com]=20 > Sent: Monday, June 18, 2007 10:33 PM > To: 'Mobile IPv6 Mailing List'; 'Monami6 WG'; 'IETF NEMO WG' > Subject: RE: [Monami6] Merged WG charter >=20 > Hi, >=20 > I snip points for comments. >=20 > [snip] from (A.3) Use of multiple interfaces. > > > > The objective of the WG is to produce a clear problem=20 > statement > > and to produce standard track specifications to the problems > > associated with the simultaneous use of multiple addresses for > > either mobile hosts using Mobile IPv6 or mobile routers using > > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > > etc). Where the effects of having multiple prefixes=20 > on a single > > interface is identical to the effects of having multiple > > interfaces each with a single prefix, the WG will consider a > > generalized approach to cater for multiple prefixes=20 > available to > > a mobile host/router. > [/snip] >=20 > [snip] from (A.5) Route optimization of network mobility. > > > > The WG will not consider routing issues inside the mobile > > network. Existing routing protocols (including MANET=20 > protocols) > > can be used to solve these problems. The group will also not > > consider general route optimization, multihoming, or other > > problems that are not related to the deployment and=20 > maintenance > > of NEMO networks.... > [/snip] >=20 > I feel that there is a conflict between A.3 and A.5. From my=20 > interpretation, > A.3 mentions that the WG will consider multi-homing w.r.t=20 > multiple interfaces for mobile host/routers. However, in A.5,=20 > it is said that WG will NOT consider multi-homing that are=20 > not related to NEMO. Suggest removing the restriction of=20 > multi-homing consideration from A.5. >=20 > Regards, > Benjamin Lim >=20 >=20 >=20 > _______________________________________________ > Monami6 mailing list > Monami6@ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 >=20 From nemo-bounces@ietf.org Fri Jun 22 05:02:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f2N-0003jK-Q9; Fri, 22 Jun 2007 05:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f2L-0003dx-Qi; Fri, 22 Jun 2007 05:02:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1f2F-0005hj-Ov; Fri, 22 Jun 2007 05:02:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7838B1986A6; Fri, 22 Jun 2007 12:02:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 260EA198691; Fri, 22 Jun 2007 12:02:30 +0300 (EEST) Message-ID: <467B9026.7080600@piuha.net> Date: Fri, 22 Jun 2007 12:02:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman References: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org, mip6@ietf.org, 'Ahmad Muhanna' Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, > => No that's not true at all. There is an IP version field in the IP header > that tells you what the header is. The fact that the IP header fields (for > v4 or v6) are not revisited in this draft does not in any shape or form > suggest that we have no way of parsing header. I suggest that we get off the > header parsing argument because frankly, it's a waste of time. Everyone > knows (including people who want option 3) that you can do this with the > version field. Let's not debate facts here, it's pointless. > He's not saying its impossible, he's saying it needs to be documented. I agree with that requirement. You need to change the draft no matter what (but of course adding this description is trivial). Jari From nemo-bounces@ietf.org Fri Jun 22 05:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f37-0004W3-BN; Fri, 22 Jun 2007 05:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f35-0004TT-I3; Fri, 22 Jun 2007 05:03:23 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1f34-00063i-3S; Fri, 22 Jun 2007 05:03:23 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CF901986A6; Fri, 22 Jun 2007 12:03:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2369C198691; Fri, 22 Jun 2007 12:03:21 +0300 (EEST) Message-ID: <467B9059.5090508@piuha.net> Date: Fri, 22 Jun 2007 12:03:21 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> In-Reply-To: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Henrik Levkowetz' , 'Basavaraj Patil' Subject: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, > 4. Tunnel Keep Alive message > > When DSMIP chose IPv4 UDP transport for NAT traversal, > the need for keepalive messaging between the tunnel > peers for keeping the NAT bindings came up. The authors > of the draft chose to use MIP6 signaling messages BU/BA > as a way to refresh the keepalive messages. IMO, having > a simple keepalive messages is lot more useful than an > expensive BU/BA. Most 3519 implementation today optimize > on this, by eliminating the keepalives when there is > traffic. We cant do such optimizations with BU/BA. > I don't see why not. First of all, you can always skip a keepalive when there is other traffic. Secondly, you can skip the entire contents and send an empty container. Etc. > 6. Why do we need GRE Header ? > > We need GRE tunnel header for various reasons, when ever we > carry multiple streams within a tunnel, the GRE header for its > mature header semantics, the key field and the sequence number > field is useful. > Hmm. Reading on... > We have some NEMO use cases where we use the GRE key to tag > certain MNP flows, and the tunnel peers use these keys as a > form of a selector for differential treatment. Its a color > code. > > Use cases: > > a.) Overlapping private IPv4 addressing support on the MAGs > (PMIP6 Usage) > >From your list, this sounds like the most valid reason. But are there other ways to deal with this? Can you expand on the requirement and describe why there are no other ways to deal with it? > c.) Carrying other protocol packets (Lets say, IPX packets) > in a MIP tunnel. > This is not a very convincing use case. We can always encapsulate L2TP etc. inside if we really want to. > e.) Industry direction and related work, these are the active > drafts: > Mumble. It is very clear that the Internet has many, many tunneling schemes from here to eternity. Jari From nemo-bounces@ietf.org Fri Jun 22 05:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIH-0008Kn-4I; Fri, 22 Jun 2007 05:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIE-0008Au-TH; Fri, 22 Jun 2007 05:19:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIC-0001d4-IQ; Fri, 22 Jun 2007 05:19:01 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA8DE198691; Fri, 22 Jun 2007 12:18:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8F23B19868B; Fri, 22 Jun 2007 12:18:59 +0300 (EEST) Message-ID: <467B9404.20709@piuha.net> Date: Fri, 22 Jun 2007 12:19:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" Subject: Re: [nemo] RE: [Mip6] issue 93 summary References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nemo@ietf.org, Alexandru Petrescu , Sri Gundavelli , mip6@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen, Vijay, >> Well, we kind of have tighter integration between MIPv6 and >> IPsec already. For e.g, the insertation of home address >> option and routing header is done by MIPv6 after IPsec >> processing is done. >> The use of 'K' bit (to update the tunnel end point) also >> requires this. I am not suggesting we continue doing this, >> but adding TLV shouldn't be a big issue. :) >> >> Vijay >> >> > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and there is a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more like a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > For what it is worth, I would like to see as little changes in IPsec processing with Mobile IPv6 as possible. (But as Vijay points out in a later e-mail, the TLV is only used for Mobile IPv6 / DSMIP, and when IPsec encapsulation is not used. So maybe this is not creating additional changes. But as a principle, I want to be very careful about any new interactions.) Jari From nemo-bounces@ietf.org Fri Jun 22 05:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIM-0000Gq-BY; Fri, 22 Jun 2007 05:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIK-0008Vg-6Y; Fri, 22 Jun 2007 05:19:08 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fII-0001dF-Qb; Fri, 22 Jun 2007 05:19:08 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3C78E1986A7; Fri, 22 Jun 2007 12:19:06 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D3C6B19868B; Fri, 22 Jun 2007 12:19:05 +0300 (EEST) Message-ID: <467B940A.5020104@piuha.net> Date: Fri, 22 Jun 2007 12:19:06 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman References: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> In-Reply-To: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" , 'Sri Gundavelli' Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, > => Nope. We have requirements from MIP6 and NEMO. Of course it's nice if we > can help any other work (including PMIP) if we can, but I think it's wrong > to do that at the cost of making the base spec worse for its primary users. I do not think we should treat the users of this technology differently depending on what they are doing. I do think we need to listen to the PMIP folks, too. (But its a separate question whether the PMIP use case truly implies need for the TLV, and even if it does, whether it should be done as a part of the initial DSMIP application or as an extension. However, in practice we know that the NETLMM schedule is quite tight, so I would at least like to entertain the idea that if they truly need something then it should be in the base DSMIP document. I've also told NETLMM that their current charter does not allow work for IPv4, except when then they can directly reference an existing spec. This may change -- I want to recharter them, but that's another consideration to take into account.) Jari From nemo-bounces@ietf.org Fri Jun 22 05:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIV-0000qW-Ja; Fri, 22 Jun 2007 05:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIT-0000jR-8V; Fri, 22 Jun 2007 05:19:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIR-0001e3-Vu; Fri, 22 Jun 2007 05:19:17 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 65231198691; Fri, 22 Jun 2007 12:19:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 045A519868B; Fri, 22 Jun 2007 12:19:14 +0300 (EEST) Message-ID: <467B9413.5080105@piuha.net> Date: Fri, 22 Jun 2007 12:19:15 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] issue 93 summary References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> In-Reply-To: <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, > >From what I interpret from 3948, the mechanism of UDP transport > can be used when the outer header and the contained header are > both either IPv4 or IPv6. It did not state that the IPSec process > has to look in the version field and do the demux to ip_input or > ipv6_input. So, it did not talk about a scenario where the payload > is IPv6 and the transport is IPv4. If we can get this clarified > from the IPSec guys, that will be good. If 3948 can support IPv4, > IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not > applicable to option #1. > My interpretation of RFC 3948 is that it does not in any way change the ESP processin rules. That is, a tunnel mode packet contains an IP packet. IPsec can deal with both IPv4 and IPv6 packets in the inner packet. Jari From nemo-bounces@ietf.org Fri Jun 22 05:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIj-0001Yn-5n; Fri, 22 Jun 2007 05:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIh-0001XL-D9; Fri, 22 Jun 2007 05:19:31 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIg-0001fO-4S; Fri, 22 Jun 2007 05:19:31 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89521198691; Fri, 22 Jun 2007 12:19:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2730519868B; Fri, 22 Jun 2007 12:19:29 +0300 (EEST) Message-ID: <467B9421.20905@piuha.net> Date: Fri, 22 Jun 2007 12:19:29 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli References: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> In-Reply-To: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" Subject: [nemo] Re: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, > As Yoshi pointed out, if some one wants to tunnel legacy IPX > or other traffic from the MN to home network, GRE is required. > Same thing for routing legacy protocol traffic from a network > behind mobile router to the home network. We already talked > about the NETLMM requirement. I do not think this 4-byte header > will make the "base spec worse", it really addresses all these > usecases. As far as I am aware, we are not chartered in any of the related WGs to produce a legacy protocol mobility solution. Lets leave that part of the kitchen sink to other protocols :-) Jari From usduh@ohio.net Fri Jun 22 05:23:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fM6-0005ah-GJ for nemo-archive@lists.ietf.org; Fri, 22 Jun 2007 05:23:02 -0400 Received: from [195.22.235.237] (helo=ifdown.eth0.ws) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1fM3-000232-RF for nemo-archive@lists.ietf.org; Fri, 22 Jun 2007 05:23:02 -0400 Received: (qmail 6381 invoked from network); Fri, 22 Jun 2007 12:23:02 +0300 Received: from unknown (HELO fqn) (97.153.106.125) by ifdown.eth0.ws with SMTP; Fri, 22 Jun 2007 12:23:02 +0300 Message-ID: <467B94F6.8010706@ohio.net> Date: Fri, 22 Jun 2007 12:23:02 +0300 From: Bishop Herman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: reunion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 SREA UP Another 36.36%. Read This Hit List! Score One Inc. (SREA) Close: $0.60 UP 36.36% In the last two days SREA has been on the watch list of OTCPicks.com, OTCStockExchange.com, and Boonmarket.com rocketing it over 200%. Need we say more? Get on SREA and ride the wave. You're way too close to Rummy, Bush, and Rice. And if you'd like to subscribe to my podcast feed, here it is. Actually do tell me and give me your address . His copy's missing probable cause. La radio est dangereuse, n'est-ce pas ? For instance, I'm not suggesting that breathalyzers be enhanced to test for freshly applied eye shadow and just ingested Big Macs. In fact, I cited Americablog as one of my favorites when I was interviewed by Bloggasm. My legal humor is here, and my Supreme Court humor is here. and He Has Ours; Telco Haiku We Have Bush's Number . And because it's too late to pull your name from the publicity. " You can find my Ode To Kenny Boy song parody here. Happy Mother's Day, mom! The GOP onslaught against the New York Times illustrates this truism: When people feel threatened, they attack. But here's some non-political humor about giving a speech, which you might enjoy. Here's the personal limerick I've written in his honor: Ode to Norm Jenson of OneGoodMove By Madeleine Begun Kane The OneGoodMove blogger named Norm Religiously posts and informs. Some Notable Posts: One Good Move has the clip of The Daily Show's Samantha Bee on the shortage of virgins following Zarqawi's death. Carnival of the Feminists. Some Notable Posts: Skippy interviews Prof. The Carnival of Moms. My previous Arlen Specter satirical verse is collected here. " conclusion that distracted drivers tend to have more accidents. Dems will raise your taxes. Or is it reverse sexism? My previous Arlen Specter satirical verse is collected here. My previous Ann Coulter verse is here, here, and here. He flouts it joyfully. His video files Of Jon Stewart are wild, And with laughter my mood he transforms. Dems will sin, If they win. The money's gone, and all the chips are falling, 'Tis you, 'tis you must go and you must hide. Exploiting danger, risks, and fear. Ne monkey pas avec les babouins! Not only is Arlen Specter a coward, but he's an arrogant coward who apparently fancies himself an intellectual. I suspect that he once was a hippy. Or is it reverse sexism? Warn me when I'm near anybody who'd use a gizmo like that, so I can get the heck out of his way. Our Fourth Amendment tops the list. Avedon Carol's Spin, Spin, Spin. assuming I'm not the one at the wheel. Major issues don't matter. You oft behave as if your word's the gospel. But if you're so pressed for time that extra-car-icular activities are a must, couldn't you please, as a personal favor, do them at red lights or while stalled in traffic jams? Here's the personal limerick I've written in her honor: Ode To Avedon By Madeleine Begun Kane Ms. It's been twenty-eight years Since we married, so Cheers! ' Carnival of Satire. And don't tell me you don't have red lights and traffic jams in your neighborhood. And that reminds me of the latest Bush excuse for slashing New York's DHS anti-terrorism grant: Bush was kept in the dark about the DHS grant allocations. " conclusion that distracted drivers tend to have more accidents. How deliciously serendipitous! And recent attempts to paint Kos as some sort of lefty blog Mafia Don provide yet another example. unless and until John deliberately breaks it again. If you'd like to listen to the audio podcast version of this post, just click here. What a pain in the tush! Carnival of Satire Carnival of the Liberals Tour de America: A Tribute to Patriot Floyd Landis Howard Mortman is helping a great non-partisan charity called ThanksUSA. After seaching AmericaBlog I discovered that John changed the link to his offensive post, in an effort to hamper blog discourse. Major issues don't matter. I even suffer from Web withdrawal when I'm away from it for substantial periods like . From nemo-bounces@ietf.org Fri Jun 22 10:15:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jua-0005kZ-Vc; Fri, 22 Jun 2007 10:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1juZ-0005kM-Fx; Fri, 22 Jun 2007 10:14:55 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1juY-0001Kz-1i; Fri, 22 Jun 2007 10:14:55 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.190.105.118]) by omta02ps.mx.bigpond.com with ESMTP id <20070622141451.FBBO7838.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Fri, 22 Jun 2007 14:14:51 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070622141451.ELHE27015.oaamta02ps.mx.bigpond.com@PC20005>; Fri, 22 Jun 2007 14:14:51 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Date: Sat, 23 Jun 2007 00:14:44 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace0rBYCaH3ogJBAQrWT/JIjmJyElAAK1zfg In-Reply-To: <467B9026.7080600@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070622141451.ELHE27015.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, mip6@ietf.org, 'Ahmad Muhanna' Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => No that's not true at all. There is an IP version field > in the IP header > > that tells you what the header is. The fact that the IP > header fields (for > > v4 or v6) are not revisited in this draft does not in any > shape or form > > suggest that we have no way of parsing header. I suggest > that we get off the > > header parsing argument because frankly, it's a waste of > time. Everyone > > knows (including people who want option 3) that you can do > this with the > > version field. Let's not debate facts here, it's pointless. > > > He's not saying its impossible, he's saying it needs to be > documented. I agree with that requirement. You need > to change the draft no matter what (but of course > adding this description is trivial). => Agreed. Ahmad said in a later email that it is more of an editorial comment than a technical one. Depending on how we resolve this issue I'll add this comment among several others that he sent. Hesham > > Jari > > From nemo-bounces@ietf.org Fri Jun 22 10:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jzb-00018b-QU; Fri, 22 Jun 2007 10:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jzZ-000188-Px; Fri, 22 Jun 2007 10:20:05 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jzY-000376-Bq; Fri, 22 Jun 2007 10:20:05 -0400 Received: from oaamta05ps.mx.bigpond.com ([124.190.105.118]) by omta05ps.mx.bigpond.com with ESMTP id <20070622142001.YLOZ23363.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com>; Fri, 22 Jun 2007 14:20:01 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta05ps.mx.bigpond.com with ESMTP id <20070622142000.RFQZ4317.oaamta05ps.mx.bigpond.com@PC20005>; Fri, 22 Jun 2007 14:20:00 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Date: Sat, 23 Jun 2007 00:19:54 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace0r1KDDj3Z1vubTSyysjYZuC3IvgAKJQlw In-Reply-To: <467B940A.5020104@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070622142000.RFQZ4317.oaamta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" , 'Sri Gundavelli' Subject: [nemo] RE: [Mip6] issue 93 summary X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > => Nope. We have requirements from MIP6 and NEMO. Of > course it's nice if we > > can help any other work (including PMIP) if we can, but I > think it's wrong > > to do that at the cost of making the base spec worse for > its primary users. > > I do not think we should treat the users of this technology > differently depending on what they are doing. I do think > we need to listen to the PMIP folks, too. > > (But its a separate question whether the PMIP use case > truly implies need for the TLV, and even if it does, whether > it should be done as a part of the initial DSMIP application > or as an extension. However, in practice we know that the > NETLMM schedule is quite tight, so I would at least like > to entertain the idea that if they truly need something > then it should be in the base DSMIP document. I've also > told NETLMM that their current charter does not allow > work for IPv4, except when then they can directly reference > an existing spec. This may change -- I want to recharter > them, but that's another consideration to take into > account.) => Again, I completely agree. The main problem here is that we haven't seen this discussion in NETLMM, so I don't know that we're getting a *representative* view of NETLMM requirements in this discussion. I think the main point of my statement above relates to your question of whether this should be in the base or not. Of course that is after understanding whether there is a need for this. Hesham > > Jari > > From nemo-bounces@ietf.org Fri Jun 22 11:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1l0D-0000Mv-ON; Fri, 22 Jun 2007 11:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1l0C-0000Md-FP; Fri, 22 Jun 2007 11:24:48 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1l0B-0000lM-6g; Fri, 22 Jun 2007 11:24:48 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:24:46 -0700 Message-ID: <467BE9BA.9020702@azairenet.com> Date: Fri, 22 Jun 2007 08:24:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005><35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com><004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <467B9059.5090508@piuha.net> In-Reply-To: <467B9059.5090508@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 15:24:46.0474 (UTC) FILETIME=[774106A0:01C7B4E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nemo@ietf.org, Mobile IPv6 Mailing List , Henrik Levkowetz , Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Jari Arkko wrote: > > We have some NEMO use cases where we use the GRE key to tag > > certain MNP flows, and the tunnel peers use these keys as a > > form of a selector for differential treatment. Its a color > > code. > > > > Use cases: > > > > a.) Overlapping private IPv4 addressing support on the MAGs > > (PMIP6 Usage) > > > > >From your list, this sounds like the most valid reason. But are > there other ways to deal with this? Can you expand on the > requirement and describe why there are no other ways to > deal with it? IMO, GRE is the cleanest. I had looked at other options, it is doable, but ugly. Anyone else knows more on this? Vijay From dxsdeltqglg@siampart.com Mon Jun 25 00:32:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2gFC-0007Qi-Jo for nemo-archive@lists.ietf.org; Mon, 25 Jun 2007 00:32:06 -0400 Received: from [66.50.230.81] (helo=[66.50.230.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2gFB-0000np-7e for nemo-archive@lists.ietf.org; Mon, 25 Jun 2007 00:32:06 -0400 From: "Zune" To: nemo-archive@lists.ietf.org Subject: Get pre-qualified Date: Mon, 25 Jun 2007 00:32:02 +0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C7B6C0.40069DE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace2wEAGb92TXmknS2mYU034iHruYQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <644D710B09C77F1.E6ED7F7858@siampart.com> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ------=_NextPart_000_0002_01C7B6C0.40069DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Your credit does not matter to us!

If you OWN property and want IMMEDIATE pocket money to spend ANY way you like, or simply need to LOWER your current payments by a third or more, here is the deal we can offer you THIS EVENING (hurry, this offer will expire THIS EVENING):

$446,000+ loan

AND EVEN MORE: After further review, our lenders have established the lowest payments!

Hurry, when best deal is gone, it is gone. Simply fill this plain form...

Don't worry about approval, your credit will not disqualify you!!


------=_NextPart_000_0002_01C7B6C0.40069DE0-- From mext-bounces@ietf.org Mon Jun 25 08:48:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nzf-0002E1-Pr; Mon, 25 Jun 2007 08:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nze-0002Dw-5f for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nzb-0000ay-GS for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB9551986A6 for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E7A219868B for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Message-ID: <467FB99E.3000105@piuha.net> Date: Mon, 25 Jun 2007 15:48:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Subject: [MEXT] new charter version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing the new list... this list should have all the subscribers of the existing three lists. For now, please continue your technical discussions in the existing lists, except for charter discussion which we can move here. In general, you do not need to take any action with regards to list changes, once we are ready to move complete away from the old lists we can deal with the from the secretariat. Here's a pointer to the list page: https://www1.ietf.org/mailman/listinfo/mext Here's the new charter, revised according to comments from many of you (thanks!) and the rest of the IESG. The charter will go out soon for public IETF review. ------ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From hvd@yahoo.co.jp Mon Jun 25 16:03:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2umL-00033k-SW for nemo-archive@lists.ietf.org; Mon, 25 Jun 2007 16:03:17 -0400 Received: from i577a5e9f.versanet.de ([87.122.94.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2umL-0000QO-0O for nemo-archive@lists.ietf.org; Mon, 25 Jun 2007 16:03:17 -0400 Received: from xjj ([60.109.233.79]) by i577A5E9F.versanet.de with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Jun 2007 21:58:38 +0200 Message-ID: <000e01c7b763$39001320$4fe96d3c@xjj> From: "rearrange" To: Subject: stairs Date: Mon, 25 Jun 2007 21:58:38 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C7B773.FC74BEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2499 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2499 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b ------=_NextPart_000_000A_01C7B773.FC74BEE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C7B773.FC79C7F0" ------=_NextPart_001_000B_01C7B773.FC79C7F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable "It's clear that the real purpose of this bill is for a California . The materials presented here were prepared by independent authors under = the editorial supervision of Medscape and do not represent a publication = of the American Society of Clinical Oncology. Lottery Commission = approves Sumner County vote Home :: Web Directory :: gaming News :: Free = RSS news :: Free Newsletter :: Tell a Friend Clientfinder. John, a professor or geology and environmental science at James Madison = University, said the surprising aspect of the report is the scale at . = Antarctic Icebergs Are Oases For Ocean Life, Scientists Say Home :: Web = Directory :: geology News :: Free RSS news :: Free Newsletter :: Tell a = Friend Clientfinder. Renal and Prostate CancersImproving Treatment for = Advanced Prostate Cancer: An Expert Interview With Dr. BRIC nations = emerge as growth drivers in Global Entertainment . Another man's = treasure Home :: Web Directory :: gaming News :: Free RSS news :: Free = Newsletter :: Tell a Friend Clientfinder. Atong seeks permission to leave for US Home :: Web Directory :: gaming = News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. John, a professor of geology and environmental science at James Madison = University in Harrisonburg, Va. All readers or continuing education = participants should verify all information and data before treating = patients or employing any therapies described in this educational = activity. Lottery Commission approves Sumner County vote Home :: Web Directory :: = gaming News :: Free RSS news :: Free Newsletter :: Tell a Friend = Clientfinder. ------=_NextPart_001_000B_01C7B773.FC79C7F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"incongruous"
"It's clear that the real purpose of = this bill is=20 for a California .
The materials presented here were = prepared by=20 independent authors under the editorial supervision of Medscape and do = not represent=20 a publication of the American Society of Clinical Oncology. Lottery = Commission=20 approves Sumner County vote Home :: Web Directory :: gaming News :: Free = RSS news ::=20 Free Newsletter :: Tell a Friend Clientfinder.
John, a professor or geology and = environmental=20 science at James Madison University, said the surprising aspect of the = report is the=20 scale at . Antarctic Icebergs Are Oases For Ocean Life, Scientists Say = Home :: Web=20 Directory :: geology News :: Free RSS news :: Free Newsletter :: Tell a = Friend=20 Clientfinder. Renal and Prostate CancersImproving Treatment for Advanced = Prostate=20 Cancer: An Expert Interview With Dr. BRIC nations emerge as growth = drivers in Global=20 Entertainment . Another man's treasure Home :: Web Directory :: gaming = News :: Free=20 RSS news :: Free Newsletter :: Tell a Friend Clientfinder.
Atong seeks permission to leave for US = Home :: Web=20 Directory :: gaming News :: Free RSS news :: Free Newsletter :: Tell a = Friend=20 Clientfinder.
John, a professor of geology and = environmental=20 science at James Madison University in Harrisonburg, Va. All readers or = continuing=20 education participants should verify all information and data before = treating=20 patients or employing any therapies described in this educational=20 activity.
Lottery Commission approves Sumner = County vote Home=20 :: Web Directory :: gaming News :: Free RSS news :: Free Newsletter :: = Tell a Friend=20 Clientfinder.
------=_NextPart_001_000B_01C7B773.FC79C7F0-- ------=_NextPart_000_000A_01C7B773.FC74BEE0 Content-Type: image/gif; name="disgruntled.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c7b763$38e6e5d0$4fe96d3c@xjj> R0lGODlhhQHJAPMAAP///4x+WKhatkNpLFZTkwS8qysWtaSQJz5fnH8wPRMObW6ojoyTKRolLNIU VRy1USwAAAAAhQHJAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6LYcDYzB4Wq/HAwWBtUqpA0FA0mgkCgNGN1XVRGNjSrvV0E2pYq3kPAcEElwABHEZZmgM b2s7fQBqAAkJCoiJCJWDiRSEGwiXeiOcAZgAYpoTohoCGwelLJ4SrCSaCR+MamaRiB14AQEMs4+S mFyBrhi4UasAgRhiii2MdQDRE3GgyIx/0xqhUYwfnQdU1H8XyR2wN9gqvxIGtBV1Bw0GCFHoFKkW 8+MSoACnbrZsu+dsBK8ABCos6/dKAwF3vjw4IlEs3wR2JBIm8OWOAoFKFP+07KrAkcsDDow6JqD3 4KQIjC7PkQTQcULCDWMebmQoUIIWKSA0ESzo4uEgdg+ofOTkM4OBm8piavB2lJ6qDRglLCUprpnW Pyyl+ptAJQApqCsRtBS34ezTamsH3LwZZeIro4/kfCjlTqoyDkbBmqwAVYK3TSEblaXw1oJcS0RH EFCwwDCksYrlWmyol8NmPwkmL0g6dYMCC5gNE3C7p7A3V6s9Tjh98Vzg0BcCcbsD9fZkClk11JRQ mcrlQYA1nVRHNuFQ2RN4k6KGGzigQaEiy+zsYI8mzdmh1+ZQrHDeDOYt+DVVId+vOMMBdJ9JrQJS 8cIVWnZAoAC7KfVptYX/VOllUEoVCfDn33MXVDEfe1qlcsBKHnxXWHwLCUKfdg7ZJ0EBpkz02YDG 8dcBhkkNkCBOGxzWSAV6zCWBXyBW0EdWNamoYI0s6pVgfwUU4MmN45FFAY+AeVhgCN0hCcAc8Pnh gSufHVhBkHW5yKFHCxiXQBxIytUUBl4GEOR2ckBippMeahCcYRV0FMdNKh5pwWbmVeZdkGxiYN4s mgggIgbxvdmBeWP0uYGeE4B4pmo+vYeQB32U1yY+0m3Zopo8VimgMVceeumH+VHAKKkXfPZLR3p+ yWcBm5EyqZSdAfCqACNegKitQeIqAJQYnGomPh+cauuxIajo6qO44mET/2PvPIsfrRN4qmkI1iZw wEMILMBoKbl6RI+31CDAJ65ucOvtHOb2is9BvRG3B0O9VomQAateWi+uS5oa6ii+jiKtY2q2S6wH BfMpsAgBtIvkagxyIEsF3zpcLcS89HttCOp2yY6T4U7QrcdHworuJutitG8m906TYcQgfJZhCtpU 0PCZmymKgcP5hEzEn43Wu0XG8W1stBK+FoBAAA8e7fTTUAuhNFhRV231CgbUXELRV3ftdRCqvjAA 1598bfbZPnxG9hBaou322ywUQIgBa5egAFse0E03svPC7fffKzjggDt0L0NFAYI3KgGuCxFOD48D IH7nKOZCpbe5CtAmQf/TgHfu+QeE/0Vb5GgI0N/i/BawwIOFF5B5HyOarrrgHQ3HiMaf5677GLjm 9OkEMQlQk+Yn8wRnnJrTulmG6+nuvO75VDNmtbNlEuD1AKxXc/RLIUdB88+HD7j0tFY0gda/Tw+A sQAkT6slvYgvv/zm6cGI5jMbL4EjqwmffFZz6YRdaDK/Av4tQ/zLgwEUMI1iDOx4oVigNoqhmyyJ qXoGzCDazDOHVZShUhgwX0CgU4zvaPCEKHzGLoCSwha6MAWkiMgLZ0jDGtrwhjjMoQ53yMMe+vCH QAyiEIdIxCIa8YhITKISl8jEJjrxiVCMohSnSMUqWvGKWMyiFrfIxS7/evGLX3MfGMHoANnpTAZ4 G+MYgVQ8HDjJZG3Emhpv0LtZAQEhkHkB+GjgvRk9wFcLbJ8CsLM8a4SjPRbgxRxpcJY8+qB73EiO WXx2MNlMkhCGRIEIq0fI6XwFGQyQigQnt0gZlGKAfjoIJctGAUdUxn/TUGXGTpRIs2SMC4OYBIBM sEkBlWIZqJxNHQZpM9yV0gQZopL/NKetS8roHyxc3AIZmKTOLLMBCtCNfjggxjY6hzAnuB8Dk/cZ qDhQAtT0yS+PCQNrJPIAEoyc+v7iBwvSJZ5ouMrBAgmhVQDCkaWxmUDPaYL0RG4AifhDJTCjFK8c D0IPZGcrvtCHU84T/yq7pFXNCBodGJHBo49Y6CV0gRqPts0gGbCHMuAHmzyYEDgglSgMwkAI9J0H on1wBB8mwdGHfpRvnMkfeUqqF2icgAHaGOAwfFLCENrjnxuSqQpqUaRtQjRXwbDHUML2op6A46TQ XIVQbOSHXiTgFjaDWd/myQVCpDGY/+CFSMkq1RUYtR3gFAQ3wgEsou4FHmw1BV/BKtaPJMZ6jzCD PCxgWBDs4xV49AeVaoqBUrgiDHVdAbzwNZGW3HIZFpzWjD4LGM6mhTPY6wFTQiAWd3b1eiXxrP7+ gdjMquA2NuqeqHQFv3OkZY9OS8kEwqKU9D2JH7ZNbgqMqdzmOhcLff/AEkWfu0hYwTUDkDiSoBpK 3S0Gx1dpxMqwqNfdLiasWhZRpMS4gKRUyKq8V/wSzxaXVw2Yi76NWlrL4FtFPdUoH04S45U6lYmm 2ZS/TMSZQCkg4CP1D1c6qxuClegrPMWpLUlbWgbYN2EnCmBqw6UYCDCSIbB2GIk56ch9DcOIR11g OK7rko5ODMUa3WR4d6tTe0IWnxJxjsZLtDFe0Znj7/LYRjr6MZCTSLvLyUFyd1rlkq94uTNOua5S vrKWt8zlLnv5y2AOs5jHTOYym/nMaE6zmtfM5ja7+c1wjrOc50znOtu5w/O9glCZsOc7Z+BcAeOB lYO1BiUfMY5ydML/G3sw6AatQcIk6PMTsAnpFnw4BWw6sBGstQNKzmNcE+hOAhZQAKh8eGkYqcO4 5gAJUjPXIKEJXT9krDKAIdrRMOjfKJxEt0+f4NPdgmkTWEG2UZc6y4w8NWrGFmyxHXthZFq1jhMQ uQf34w8PqYm0V0TtYxcP23sTGa07EOvCtYHWDiAH6iCs4QyUSN0lSHe31z01dtCD2V0yQY5qhRJl yNi35nHHuHFS7ppwoUSG8fatd7A0/tQkSJQxTskCvblsD+9JM/4QHC+dAffNx8VAFdkE8k29RcvH 4itGdxk5AOPR/QtgogWO4ASwYg5AnOTyobnQojfkkBuqwNkW8eb6/7GyUFt8NiovbXxUTkmUQy7J NA+5pHWgN3RW4EEbf5TFH8fiBJXxJjkjiIuspTeu+/RY4YqPy+20gR4PvZK8rqYHXFfk+ZgnFUIm IJF9jJWtL8QbWbdJ2Vecxlf3uNYst8CKFJc0uf0cB5yr0eFmbuqr99zqtmrafy3/Z2ZYvsqZCzUi 0/64123u6yDPQIY2X8mA2xwE7gNwqOajYrJEjvJtr8DoELdyRF6YwahSXAecxDkps6n4lCs17YKg do2HAUjktYDbj3sw17vb96633Rw+kwrrYy7HPGLjwoHfqDY4CSqRLxkpKeV5CnSndpgPeeI7U7rT vXy432cLI7Ice//fm4axiNRoOnBJeIRa0td+0iJCyaNeITQALfFH+eA+vPNZULF/7YNNg6Re6GCB GwBJidASgKQ5u0INDmQRmmZc0Wd1cZAPUMENDghc+CVyRnIBWtNIq9VL9kVXKah6EOIX7oCB2DEE pMVUofRHFLA9BkhbrzVkmdNJGwCCxdN/ggAZnuAXtJGBZmETLAU8EOg/hxJJIgJLtaU/ACFBoadP 5GWGGQhtZFiEq1QKyoEBxJOEHQUtm+Ba2aN7X4gMMwJYejVJTEAFC9BGWGhL/QAKk3B2scQLqaBW N5BLooArozQE2MRcFDWIJoiFRQE/uTBylcWI1YCIQ+KHDtELmGD/LCcoWINCfhyyCr3jEbuxgw1G RJohPDhAAJ3gf1GmCQLkZ774i8AYjDWQT1mUSZ7DUWbgPJ3YA4+HNBRRUHvFFgdxVuxQD4U1Mybm EVNXAs6iD5WmJYv1Aq8mAj21ManIAtPxECbgiHX4jAdzLxtBIdlDgUiGbMowjiLgSQoBg2dnA9s4 AmDlWXYUVmrQBzohQ/PIClpwB/bISjaQjpVmICRwXR0gQvDIEaMVWRyEWR+wWi+gjwNCUjrwjyIQ kA8wS4IFFAZpWsDDgOzBkDNAkilANEcBPEqxjfi4P2XhUCDQVHoHPP0oB2PgkjVgitEUUQaSC7vU iHjRDy0BTrpU/0xPcVMXwI4usRVViRKPcYMUlYU2IRgu8RgWcAe2xI4EZxX8yAI3EQeaoyxjYT+x EVFigR1DgjE5yWJxmVpt8HN5OZUSAxD30kcGYk/1ZXtZYU9M+RbVkSI2Q5haoZi/kVKZcSFH4RrH oV68QS0Vsj9j6BiidUGXl0qR5Ev30hqUwZiP+CngYz/gMSFFgpq28iVZclglkAfyKAgsIXGxOZqp 1Yw+kVF7AJkS5pNVtQcm0kqfogV+qT+cc5SEUBiSJh3hARrcQiA8IhKt6Zv9IZv2I2z4lyIYwQqc NpjTVU8rUZPDsXg28AuBMAd8UhfV8pwhBp5s90ARmRzsCZ5YN/+b3hmaHTItMHhSZOMkbRAlViJ8 M1gkGHFSoPmTOghUVUCZG/CeX7A4oXCeJKIjheFAlhIzwQktNIIDHbGXGmddeOMKhDBwmNJQY1UC OHI8X1JJjEWTHFZZUkkAOIcei4IBINM3vtOf51dfT6GiCIhaOOol9ZlaQxEmdHGeB6px/BaaxsSi MSJiLYYDrYIqYWIRS6Is4rkLLgkVNVoqnnhTLhYygbkuf0UYKdOMcPigMkorHZEQODqG40ktbSox edWm4xWDqSVh4EVTj/kl6ngRy8IsI1GcY8pisrKWZKUyDRlO/+IrGFOctWExSLkFKXMllLQt40Jy gcKCTjEquef/Lz1hIDrhqaS6g3TBEB4jX/9FqX9KFuf1nzIYXe11gOLmGRBDK9rSMVugMCz4XhHV jJuBL6E5CzwzfjnQHxoWL7mBXhahXw+hNcoSZRwwMjoWcvlArVmTolYlHA1QmpYBq4M2rtwCHDfT Xs5KWf4CKAaDOs4aYqb6COsKKxpQM61yrzmTSB2TjQDYnzNANOgqLz0BRxqiBELVo4LHQOeIOiRg cg7nsPuWpIUwD822B6SWeiGwsfiaX0xzlyRgLD5TMx/jLqukrVQJAtoKCb7JAhJUB+15f8IYAkHy YJH6AyXysjVrBRUmgD9wn4DDcUsAav2Zs1K1qIrnN+0GBA13/3TopKLxyqwTSrUrALRek6MmALBB 5wFIa0AFZxXtMwe9ByKyV5tWqwKzGG991wTbegKGJn2E849fuwSDwzW313tkyjcO8nWl6plsFzCl hgJYu7UocDttJ7QwtDgr9n6F0wHuVTmMwXVSmLizQRu8Zzr4oHMEELePFm4l83wc+3vxV3/uMqrf h6AxmBCr47VsZAGcEwg5ZgKvUwWFewEmZ7P1l7juUHMfIrro1R+r47illzzP1x7Cu3w0kX9XOn9G YrofKwizMzgbMyKlAIPLI1hxumNDiINrayMPGEcSqJGEEL6fgYXcs4V9SK+b0AltcBKSKIFx5L5P aSAE2ILd8P+AwyWCfpC9puCAyINY/vs9kAtO3us0CikFIKinA4ODaYVYvURM7BgfrAASYwKFXjgO dURPTJWC57hXoYQ6avgulqWLpEQ+Shh92sA7hbm+5+N7Lbq9VemBKewnTpM/giiJHYicZ/e9IHU/ X9m/z4GJk5haCcuZ60OKJcVBKejD7dgOC+hXv5nDPaJNSMy+YmRRJiyBhwiJkSaKItEjRmNQepiD EJWX0gACCSRMENJ9GDZN2GTCmlktcJxN76JbpQAV/xMtGGTEBtU//GTDCTuKrBgcyaSrxRlAvMmK tgon5oGEs1UQxmih8MRAJyVA0ljJDSBPOlormtxBegBVI/T/u6t6TviEUNQhUmMwWS8MUZ4Bpw6U x0pMVHGwignqQCVmAe5DQa8QWrNso5b0yU6iUBasHbuBDR/UaNPFc5tMjClFUWjczLTJwRd7UMv4 Tx5Jfb8sgx1MpYRwneVIm1XACMFRQh4kzZ3cneqUzB2USIXJzq48yNJJsyG0YPCMGtksPg9re4Lq AofwEyKDh9p8JGnAhyKDyZRsC9GBDPDGAWXABzVMzRTVBw/tzPUso4aQBiawU+FMVVTEs1jA0JbV DQMdQookk7hwUXKQqJFBU2a1z0akuF7DiwbEC9TYs2qpvjhNHTLtQl4sBOGcWaFxmkwQ1ClEkclV sUqA1O64/wPACQQAK1Mx4blPeAJ9oZu41gI9PVXpYZYqULdqdBjb1aDXhzBvkaJl0il3wIYpcNaF WgJjMKRR3cI4YNQS5aUgA6YXEZjluiYsR6h++baxqtfidSZbehDeYRRKyzLkShM4+qo4EaZDqrWp UlZvLQibGnxnJ7JzZK7/6akqa66Fm6UHsxkDWZXLGp9EU40hsNrbQhynImmN7W+QHdmpehN8GggM a6nP1SfeGg2Forpt17Kzdbat3HkpKMsG+w3b1LxizNt+MhwzG7ifotzwZb0TWwawrSwYkWUtm13c moQnmKsNWwZiu7LcJHRZIWVFA9LuQ9rk1a0oiGAjMhygq/8j8+anGnAq1GZcgWDfgJphDEZpRisf wi2HdLXeHYCNH+A+JHowNfIL703fcgts8P07FvF4+G1s+r0qWVM4SstupXBgxobGo+p+y63fZGIB BLa3Bp7E74ibPwinJ4Zv1PcH1VY8qHbZVTlvq2TjJ1Vvl71thJG26/Nuv2AekvZumwthOypsOKs0 j9m7Y8N5Swbkr9BtunZtsUZw8vTjoBbkO27f3YLVEZJl6KZuSt4iOhKqTr7fbRLlgRB0CFDlKB5m RSd4W61ZDve4hpk4Gz1zMmkfgt4eUt4iLyfidtg+O81H9NzoQQR6TgzpOpR/lH7pmJ7pmr7pnN7p nv7poB5L6qI+6qRe6qZ+6qie6qq+6qze6q7+6rAe67I+67Re67Z+67ie67q+67ze677+68Ae7MI+ 7MRe7MZ+7Mie7Mq+7Mze7M7+7NDu6REAADs=^% --%^V9^%-- From wxfov@mckesson.com Tue Jun 26 00:54:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3344-00027C-P9 for nemo-archive@lists.ietf.org; Tue, 26 Jun 2007 00:54:09 -0400 Received: from 201-35-219-152.jvece701.dsl.brasiltelecom.net.br ([201.35.219.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3344-0001Ae-44 for nemo-archive@lists.ietf.org; Tue, 26 Jun 2007 00:54:08 -0400 Received: (qmail 22206 invoked from network); Tue, 26 Jun 2007 01:53:14 -0300 Received: from unknown (HELO fozc) (196.120.103.73) by 201-35-219-152.jvece701.dsl.brasiltelecom.net.br with SMTP; Tue, 26 Jun 2007 01:53:14 -0300 Message-ID: <46809BBA.3010702@tampabay.rr.com> Date: Tue, 26 Jun 2007 01:53:14 -0300 From: Macdonald Daniel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: The government says the new bill gives "maximum flexibility" over holding a referendum if the tests are passed. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 SREA Takes Investors For Second Climb! UP 40%. Score One Inc. (SREA) $0.42 UP 40% SREA continues another huge climb this week after hot news was released Friday. BusinessNewsNow.us has released SREA as featured StockWatch. This one is still cooking. Go read the news and get on SREA Tuesday! The biggest hauls of fakes have come from South-East Europe and the Baltic states. Cabinet and then Parliament would then have to approve the decision before it went out to the British people. By furnishing information, IBM does not grant any licenses to any copyrights, patents or any other intellectual property rights. Patent ownership should be transparent and easily discernable. "We have shown that with the achievement of sustainable convergence and flexibility all five tests can be met. The journal articles examine some of the challenges, such as power dissipation, and offer solutions ranging from new device approaches to nanotechnology applications. From nemo-bounces@ietf.org Tue Jun 26 03:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35Uq-0001xr-7u; Tue, 26 Jun 2007 03:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35Uo-0001xY-Da; Tue, 26 Jun 2007 03:29:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35U9-0000Yb-Aw; Tue, 26 Jun 2007 03:29:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2007 00:29:12 -0700 X-IronPort-AV: i="4.16,462,1175497200"; d="scan'208"; a="4843564:sNHT22560060" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5Q7TC0G009888; Tue, 26 Jun 2007 00:29:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5Q7Svka002367; Tue, 26 Jun 2007 07:29:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:28:57 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:28:56 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <467B9059.5090508@piuha.net> Date: Tue, 26 Jun 2007 00:28:52 -0700 Message-ID: <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace0rDWZxhwuwNAaS8CRy2KiWfMalwDEsshg In-Reply-To: <467B9059.5090508@piuha.net> X-OriginalArrivalTime: 26 Jun 2007 07:28:57.0039 (UTC) FILETIME=[A81DF5F0:01C7B7C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2857; t=1182842952; x=1183706952; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=8G5W3doBIFbLq07l5XkNxxGE3IAS1hhuRZdpNDvOypM=; b=t+derRcgMTCF87kK82k2B7fSVJkWZ0PohfTPrB/xakwOwUTZZLym/eA97s5Gs3kwZjYRuE8d aL3YGQCJHiLoGSciD2A5fhD6p3y+3RvzW63PuGpNqUC/ifXIxvJoP26A; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Henrik Levkowetz' , 'Basavaraj Patil' Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 22, 2007 2:03 AM > To: Sri Gundavelli > Cc: 'Basavaraj Patil'; 'Henrik Levkowetz'; nemo@ietf.org; > 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus calltoclose issue 93 > > Sri, > > > 4. Tunnel Keep Alive message > > > > When DSMIP chose IPv4 UDP transport for NAT traversal, > > the need for keepalive messaging between the tunnel > > peers for keeping the NAT bindings came up. The authors > > of the draft chose to use MIP6 signaling messages BU/BA > > as a way to refresh the keepalive messages. IMO, having > > a simple keepalive messages is lot more useful than an > > expensive BU/BA. Most 3519 implementation today optimize > > on this, by eliminating the keepalives when there is > > traffic. We cant do such optimizations with BU/BA. > > > > I don't see why not. First of all, you can always skip > a keepalive when there is other traffic. Secondly, you > can skip the entire contents and send an empty container. > Etc. > That's what I meant, when using a KA message, it can always be skipped when there is traffic. The KA processing is not expensive as compared to the use of BU/BA for the same purpose. > > 6. Why do we need GRE Header ? > > > > We need GRE tunnel header for various reasons, when ever we > > carry multiple streams within a tunnel, the GRE header for its > > mature header semantics, the key field and the sequence number > > field is useful. > > > > Hmm. Reading on... > > > We have some NEMO use cases where we use the GRE key to tag > > certain MNP flows, and the tunnel peers use these keys as a > > form of a selector for differential treatment. Its a color > > code. > > > > Use cases: > > > > a.) Overlapping private IPv4 addressing support on the MAGs > > (PMIP6 Usage) > > > > From your list, this sounds like the most valid reason. But are > there other ways to deal with this? Can you expand on the > requirement and describe why there are no other ways to > deal with it? > This is for supporting the overlapping private IPv4 address scenario. As Vijay was saying, GRE is the most simplest way to solve this. It has the proper semantics in the header, such as GRE key etc. There are many MIP4 implementations that use this mechanism for tagging the flows between the PDSN and the HA. > > c.) Carrying other protocol packets (Lets say, IPX packets) > > in a MIP tunnel. > > > > This is not a very convincing use case. We can always encapsulate > L2TP etc. inside if we really want to. > The scenario was about using about using MIP tunnel for routing other traffic. L2TP cant be used, as it wont provide mobility. Regards Sri From nemo-bounces@ietf.org Tue Jun 26 03:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35VC-0002QE-Go; Tue, 26 Jun 2007 03:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35VA-0002L4-6H; Tue, 26 Jun 2007 03:30:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35Ui-0000bi-PT; Tue, 26 Jun 2007 03:30:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2007 00:29:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM5dgEarR7PEh2dsb2JhbACPIAEBAQgOLA X-IronPort-AV: i="4.16,462,1175497200"; d="scan'208"; a="381793044:sNHT55508240" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5Q7TlUN015700; Tue, 26 Jun 2007 00:29:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5Q7ThXH014553; Tue, 26 Jun 2007 07:29:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:29:42 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:29:42 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> <467B9413.5080105@piuha.net> Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Tue, 26 Jun 2007 00:29:41 -0700 Message-ID: <017901c7b7c3$c2b86a80$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace0rmhEvuXgAGJZRP+FsWTktDWqygDEpK3w In-Reply-To: <467B9413.5080105@piuha.net> X-OriginalArrivalTime: 26 Jun 2007 07:29:42.0632 (UTC) FILETIME=[C34AE680:01C7B7C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2802; t=1182842987; x=1183706987; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=tT+3FYcsRHku1lNUHKqLxiT4TAaFVOsHnflDl7sO6RQ=; b=ORI0vHaV2kpcKtrnXD94EH3JXH1RTaig5i0TATUDF0k/O7xqlQ9vg0aWQ/D/XtWsM/+wwV5z e3cs4bzHQRxxVBd/AsBuvgGGOkeexGqbWy17C6GkB1rkeujRAxTPt4LK; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , "'Karen E. Nielsen \(AH/LMD\)'" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 22, 2007 2:19 AM > To: Sri Gundavelli > Cc: 'Hesham Soliman'; 'Karen E. Nielsen (AH/LMD)'; 'Alexandru > Petrescu'; nemo@ietf.org; mip6@ietf.org > Subject: Re: [nemo] RE: [Mip6] issue 93 summary > > Sri, > > > >From what I interpret from 3948, the mechanism of UDP transport > > can be used when the outer header and the contained header are > > both either IPv4 or IPv6. It did not state that the IPSec process > > has to look in the version field and do the demux to ip_input or > > ipv6_input. So, it did not talk about a scenario where the payload > > is IPv6 and the transport is IPv4. If we can get this clarified > > from the IPSec guys, that will be good. If 3948 can support IPv4, > > IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not > > applicable to option #1. > > > My interpretation of RFC 3948 is that it does not in any way change > the ESP processin rules. That is, a tunnel mode packet contains an > IP packet. IPsec can deal with both IPv4 and IPv6 packets in the > inner packet. > Sure, clarified further in that thread with Karen. Copied below. When using ESP, we dont have any issue supporting GRE. ESP follows the right protocol convention and it has the "next header" tag that identifies the payload and the same we are asking for DSMIP when riding over UDP. >>>>>>>>> The "next header" field in the ESP header identifies the payload. So, there is a proper payload qualifier in ESP header. The packet inside can be IPv4, IPv6 or GRE protocol types. So, when using ESP header, we dont need the additional 4-byte TLV header, as the protocol type qualifier is present. We need the same qualifier when there is no ESP header, when riding on UDP. So, the point to emphasize is that we are asking for a payload qualifier when using UDP, so that we can send GRE packets. We need this: IPv4-UDP-ESP-GRE-(IPv4, IPv6) (This works) IPv4-UDP-TLV-GRE-(IPv4, IPv6) When 3948 is used, ie if the port is 4500 and not DSMIP port, the TLV header is not required, as we can carry other protocol payloads and the required headers are present for that mode. So, the behaviour is consistent to 3948 and its the same for both option#1 and option#3. If we prefer both the ESP and non ESP traffic to be handled as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for this traffic and will remove the tunnel encapsulations and pass it the the IPSec process. So, its about the registered handlers, IPSec is the handler on 4500 and MIP on the DSMIP port. MIP understands all the encapsulation formats and hence can do the proper decaps and pass it to the crypto system. >>>>>>>>>>>>>>>> From mext-bounces@ietf.org Tue Jun 26 17:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3IEC-0003As-C0; Tue, 26 Jun 2007 17:05:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HDE-0005Hq-LX; Tue, 26 Jun 2007 16:00:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3HDE-000743-6r; Tue, 26 Jun 2007 16:00:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D608A175CA; Tue, 26 Jun 2007 20:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3HCj-0006C0-Ex; Tue, 26 Jun 2007 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 26 Jun 2007 16:00:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 X-Mailman-Approved-At: Tue, 26 Jun 2007 17:05:35 -0400 Cc: mext@ietf.org Subject: [MEXT] WG Review: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by July 2. +++ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: mext@ietf.org https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 27 06:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3URQ-0002WZ-Gd; Wed, 27 Jun 2007 06:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3URE-00022q-GJ for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3UQJ-0005O9-N7 for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1182938811!2338471!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 6441 invoked from network); 27 Jun 2007 10:06:52 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-7.tower-153.messagelabs.com with SMTP; 27 Jun 2007 10:06:52 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5RA6pn7027274 for ; Wed, 27 Jun 2007 05:06:51 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5RA6ow8011429 for ; Wed, 27 Jun 2007 05:06:50 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5RA6nGV011410 for ; Wed, 27 Jun 2007 05:06:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:06:47 +0100 Message-ID: <468236AE.8060805@gmail.com> Date: Wed, 27 Jun 2007 12:06:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jari Arkko Subject: Re: some dates (was: [MEXT] new charter version) References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:06:47.0881 (UTC) FILETIME=[DF978390:01C7B8A2] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Just to say some dates should be updated to 2008 instead of 2007. Jari Arkko wrote: [...] > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational ^here. > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 27 06:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UkM-0008NK-CI; Wed, 27 Jun 2007 06:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UkH-0008Db-F5 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ujd-0002nW-I3 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 54A331986A6; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0E526198691; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Message-ID: <46823B6B.9020600@piuha.net> Date: Wed, 27 Jun 2007 13:26:51 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alexandru Petrescu References: <467FB99E.3000105@piuha.net> <468236AE.8060805@gmail.com> In-Reply-To: <468236AE.8060805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org Subject: [MEXT] Re: some dates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ah, of course. Thanks for catching this. Jari Alexandru Petrescu kirjoitti: > Just to say some dates should be updated to 2008 instead of 2007. > > Jari Arkko wrote: > [...] >> Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem >> Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG >> for publication as a Proposed Standard. >> Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the >> IESG, for Proposed Standard >> >> Jan 2007 Submit final doc on Route Optimization Needs for Automobile >> and Highway Deployments, for Informational >> Jan 2007 Submit final doc on Route Optimization needs for Personal >> Mobile Router, for Informational > > ^here. > >> Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for >> publication as a proposed standard. >> Feb 2008 Determine how to proceed with remaining automotive/Personal >> Mobile Router solutions > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ejo@wachoviasec.com Wed Jun 27 15:48:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dV7-0007ql-8A for nemo-archive@lists.ietf.org; Wed, 27 Jun 2007 15:48:29 -0400 Received: from [201.82.180.136] (helo=khpuhb) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3dUw-0003P7-WB for nemo-archive@lists.ietf.org; Wed, 27 Jun 2007 15:48:29 -0400 Received: from adzhf ([180.226.166.134]) by khpuhb with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jun 2007 16:48:12 -0300 Message-ID: <4682BEFC.3060003@wachoviasec.com> Date: Wed, 27 Jun 2007 16:48:12 -0300 From: Wallace K. Alec User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: They teach that in law schools everywhere. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Market Makers Short SREA, Watchers Pick It To Explode! Score One Inc. (SREA) $0.31 SREA hit price spikes of 600% last week and is still hold at a 300% increase as Market Makers are pushing it down to grab control. Stockprofiler.us, Businessnewsnow.us, & OTCPicks.com all pick it to take off. Get in on the Market Makers play and grab SREA first thing Wednesday! Actually, he has been added as an additional plaintiff to a lawsuit filed earlier by the World Organization for Human Rights USA. It didn't do either, so Novell says they should be excluded. Additionally, as a result of Novell, Inc. Before she dies she kept a portable cassette recorder by her bed. government couldn't prevail against Microsoft in the anti-trust suit. email to Democracy Forum, and Yahoo! He throughout his testimony, Novell writes, and without foundation, "offers inadmissible speculation. When she felt up to it she'd record a story or two from her life. They can't claim that Novell is responsible for a decrease in revenue. Microsoft's problem is they have no real design or quality base in their operating system. Their Unix business is going down the tubes. And yes, SCO can answer. Sworn or certified copies of all papers or parts thereof referred to in an affidavit shall be attached thereto or served therewith. Guess they are not 'cute' either. For example, you can't say, "The other side offered us beellions of dollars in settlement talks, so they must know they are guilty. The results were amazing. I guess it is just because they are not as 'cute' as a baby seals. SCO forgot to cite it in any of its memoranda. government is backing us with the Patent and Trademark Office, and we're so big you can never afford - even the U. That brings us to the late expert report by G. A distributed legal attack, yeah. , Yahoo Holdings, and Alibaba. As for Steve Sabbath's new testimony, "As demonstrated by his lack of memory, Mr. Or speculates about, Novell calls it. Some folks can waltz, but they can't tango. THE COURT: Several years ago. He was convicted of leaking state secrets. And I'm no expert in any of those. Indeed, SCO did submit conclusory declarations from Drs. They move to places where they can continue to contribute, like the people that are leaving Novell. But they really should have been able to show special damages. There aren't many cases on point for either side, because who sues for slander of title on a copyright? As for Gary Pisano, Novell says bluntly, "Mr. THE WITNESS: I don't know of any other companies that SCO is aware of that they haven't made available. Transcripts Where is . " Jay Petersen's declaration is also objected to on the grounds he "improperly speculates as to the actions and intentions of SCO, Novell, and Mr. Sworn or certified copies of all papers or parts thereof referred to in an affidavit shall be attached thereto or served therewith. It didn't do either, so Novell says they should be excluded. They just keep doing the same thing over and over again. So here's what's so frustrating, too, is that the fact that Microsoft won't name the patents prevents anyone from curing the problem that Microsoft is complaining about. The other parts will be decided, but not directly in this motion. From yviit@bucyrus.net Wed Jun 27 16:10:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dqe-0000eq-3O for nemo-archive@lists.ietf.org; Wed, 27 Jun 2007 16:10:44 -0400 Received: from [201.82.180.136] (helo=khpuhb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3dqc-000310-L4 for nemo-archive@lists.ietf.org; Wed, 27 Jun 2007 16:10:44 -0400 Received: from qgi ([207.130.208.159]) by khpuhb (8.13.4/8.13.4) with SMTP id l5RKDlDZ046473; Wed, 27 Jun 2007 17:13:47 -0300 Message-ID: <4682C425.2040006@nwlink.com> Date: Wed, 27 Jun 2007 17:10:13 -0300 From: Washington Z. Frederik User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Fwd: Info-211.pdf Content-Type: multipart/mixed; boundary="------------040808030703010202050005" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d --------------040808030703010202050005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit --------------040808030703010202050005 Content-Type: application/pdf; name="Info-211.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Info-211.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDc3NiAyMDhdCi9Dcm9w Qm94IFswIDAgNzc2IDIwOF0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo3NzYgMCAwIDIwOCAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDc3NgovSGVpZ2h0 IDIwOAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhsVjslls1ntFptVrtltt1vuFxuVzul1u13vF5vV7vl9v1/wGBwWDwmFw2HxGJxWLxm Nx2PyGRyWTymVy2XzGZzWbzmdz2f0Gh0Wj0ml02n1Gp1Wr1mt12v2Gx2Wz2m12233E6LsFKEZMmq CrQVeSAS5AwuAUZF0TMhk5C5i5QHDaXC4Fxyp5eiO93M3MnDgR2bUZ5MmA0FDsOLVZKUSSb+AarP 0Da/NVbXxJaTrvLRe9aDguh75okMgBBc/SLm0bQBFwd4/Owi7+i0LQakmSaLhgfz2oq/6HwC7qbB i/CBOk5SKxGh4DFOgYOiMhwapnCkLoG8COPSiBJnQgcIAAGIyREa7uIG6w5DkKUNIPDaLhig47I8 86ZRggcKIPHiGSsiMBoPHSIlwjY/D9GUcovDTfw4iMnRAmprkabYACgbQcIIOQYn8f0zIKaAADsb ZGoI8qBO0ghoGvGqCz8iA9w6OM0oZGaDvqOaDt3B0rBiGADUUiIjE7C0uABPSNlwaFGT6h1PoLPA AAvIQAUrOs7oNUY4oxRDeIcPaHk6mddoJR6KUsiEOoNUKIHehNFAGh9BSqgsRwDOLdoPJkm1MgxO iM7Ve0GOVmVvNSaPw3re2YC4BSOKQyWU9A7DsRpGxrQEwII+BVlXdaBjnNgoDtVqFFOLT2g7dqCO cAQRy9XyCRqa8fX1WTrXNDd1H8PeASUhg/VogR/IHfCIvaAeKoGKWB3dWyF3qg1VTegjloW9tGxO g9/ITFb1I/dORVyh2EoFTqCgGOVDRJfocW9QF1IgEaDve+N7ofl6DYtgOMIVLSDaHfMR6MLzqoPj 6B3bd+iFwLUwDjbaBXvocUIJmtwJc/FWPHaQASxqwAUYgc8P/bKCHRjqBFjbz7m3umcPbWk3IE50 Dk6PcXIHR+oAARtqAAa/GSHY+OIFzCBbyhONoMWPLYcgsFbsggpBiKVM2HmSHXsAfTXzt7xoHrCE WV2SJx83nc1dB86oJ2HXY+VbmhdqUXDjCtfoHy+WABusG3p1vX00hvIi95/ogBwmUABw84G11dqd aiO1IHwPadshvdoFTOPdIhX7INy4ADnGs4IGg4gzeW9uNTw5AgaFWFr4eA6luJM0RncDgQVDQMQB pQII75n4AD+kFHQfE+Iw23IkIispkqTlbKAUCwoADlXMnNSAv5zrQXYESRkQaEB9UfooOkF4OEMS BwUY8QRyREhVwgh+NdIK/SCpYgCekIz4zmECge/864Xl0EDWSFJkr0g5oFAEh0LwRkxKoczDh0AA Gjw9OuyRoJ6owpUIQ25IJCT2vqfWQlohDYmAAZ42IhsYz4qpR+2+JZBoLR+T+QN9iv4PxIOaQZOU DSYubIEz4ACdgyDXH9Ic8JCADITWI7QYcRiCwYIUtRyT4wayfg2+2FahmHJsG27KHzxkwuuIip5Y oAJSECUQiUgUACCQhIJJQiSKJZRKiWrCTLgiBrFigRJST5CBSRVcqkgsZ14EIe8oMgkvU2EEG1BE gSPJmycIYsMhLoJjQSVjDSPBEo9u7lMQVTqOThR5mmQOa05ZDEGdk1KdUjJRsNDJPsgbwpJEuQ+k MgaGSCR9IHEMgocFs0UAA2FJrIFDkED8COi0YV6ADGHNghTUiERaRuRA+FJSBUuekQKhSq08kJmi Q+ZB4aZgAAEhldI0JnECYHE+m5EDhiNAuk6ftPKfMsatUWjDH4QH2nCQOFCeWKino0QlbxCVVUNI OmWXZDqMEEq2Quq5Amb0TIa+xlZ9yCVLrTRIgVGHmkFV/Hkg1aaFkqrBHwgdQQDPynaQI/7z2F16 kIRBqyNQXJSIE/afLH6DtXIPJysrsyB0wIE4ypbeKbERRqMNzCKDpzZIUAMIwRk+vKIufhNxvaFJ 0TtEB1hBbFN6txN+WLmiCTkIUFqXBDaukIq+QpwTr1NkJrPKcg9wqJ2FIM+BgqkrfUyuAnQg1hFb PMomsxMdm7OEHuBX0li/ktD+GgAMaCma10xufAeRkRRh2ugZYwgs+1hhGshRltdnERDbCM/5OZB2 LCdFwFKAZEl8NEclUuM86IuMGIbB++sxZEkEBg/ekzM0XHjUBdqZ5BWrUIILf2FbCyFSWm9bchtm WVu4ISsVixDhOtnv4Qe3JCcNkHwSqUh11ICUTO4gxV5B734TOQQW/iFR0RkvrC6YmLLzEpX9WAAb OwAZJcsQhrD0ZRjDGg9SNJ1sK4dBHJ9tDarR2cEavyYCOyECnAMFIAdKFHI0WLWNNMPEdtWrpILJ ZDcwrfIEHCS1QSDZ4eo/IhWb6lZ+n8x7RTYZHkHfYobMZCcqMcYtnTOxDn8EIxNmUF2WCCZcIQ2d jVbpeSj02Q3RVZgXT1unepew0KYMsggADU8e8t51ZWc7TCFlQLEoPVUgmncqldDIg3RxBozqqHfR cAF/bOY7JEe8a+YsWyIABtAC9xc8Efr/D69V7Dj1rBi7u70QiI0NVUF5O1672zZD8n1RDzD9bVgP TVgrhqkkElqy4U4pxcXNIpHnZ6Dq/kgvrrElG3MxHCIZszVPCdm8bI7PngBA1WnX2iS8+EFUVVr0 c7vUZC6G3lkvyUAE6LWTbIEH4GuN0tPRrHGUIyrGXGd4xxzoRg7EdDJBwXo3STATq6V03p3T+odR 6l1PqnVerdX6x1nrXW+udd691/sHYexdj7J2Xs3Z+0dp7V2vtnbe3dv7h3HuXc+6d17t3fvHee9d 77533v3f/AeB8F4PwnhfDeH8R4nxXi/GeN8d4/yHkTBgXa0a5dDFOd+S80SMP24xGzEJk5rh5HAv ACDmI28ZLcTKB8/MWpNp53OtqBny+Pm/bEVQfD8m8SOetwI0AILy9ttEm+C1mJAMVAe9aPizWcF4 nkGBr0j2/0yFbAIvCa+xFQOq2QUSKvR+AvBy+3RXaH1iJemay5hHjMnr2BIVCZSdfPqfzIL5Sm6c UGYs9kQiojyyBg4ABP5I4iCjyjlgBE7GrABotCJPUqMgyA/AjE2KGv8tTwBPzlmqNufo2CEkXKbw LP6P6AYnLqrjpJxhcKJE7pNPMlrNfH5guvgKdiEoQpyHiJMEULhA4LVCIwGvkCCEPpxiPv0NpH9N DI+GsJmhoEJnME+IVnqAAAvQYwQQpEewIOQQokkCBQkn8lroYpWiGJjGEsRQsrDF8QmCHweFvwPi KrikaN2qKEFMjHdgYvZgtQFCBnNwnINQpw9iDIdI6CCumIoADQXgvAoAtPhoRNltJv3INItLVA7K VtCCDteNDiQNtERFbNTCDLmvtnlQ8umQ+QpLTCEuXKNIoQAABAcAtBJqiv6iCnOqrnBABwcgjE+R WwtiDNSpKiQRbrOp+Jgn5PMnyF3nlq+MhRQvNpkRMqvLULdiCnViIK/mXmrFQozrRCDxdNwtyiMx EIhlmEioJCERIqeGmxkQQHlH+G3HziEFLofm8nqPgCJsCHhnPMWtQiKK+GiHhQawsMXQdrjQ7qGn 0IJQknkGNnxxQRjxzPJIciDNEQKmML1Q6nRQnBtEwkLQGiERNR6kpkWA7KiPVrjABPOksIQmkF0R rHRCGBhwnIco5v/nWKgwkwFISnLJVJatjSFyFlKgyNFEJvQCFJ7h0SMiENEN0RAILrWw8q9jrtxi NxhCGP5JZCCvmCGJoxoSFSdStDBSRiXycytywDDxwCWSvywyzDCPzCRysyzy2S2y3S3y4S4iGPfS 5S6jNk4KlmOJBiIBOlsFIS7TAC7muvmGdPmiEGENWGgxETAzGCyufDxtEpnH6K2iBuipLl7TGzMi 3M+iDSfCJrIFlOFTNTRiwESuXJLx6xQCFmgKzTSTXCzgcP8sSR6zRMmEERnTXzcixNEA9msFqEoR rH7oECCyiTdTjCsFjkrGwugiELwrNzjzoCujlzlTZiJNFTizozsimEzPOlvN7pKtLP+HJzrztTyi pSHg5H5OTthMOiCnvznKMpRr2TzT6CmlKs5hOsJSllPLcOIyoT60AChQ1UA0CUC0DUD0EUE0FUF0 GUG0HUH0IUI0JUJ0KUK0LUL0MUM0NUN0OUO0PUP0QUQ0RUR0SUS0TUT0UUU0VUV0WUW0XUX0YUY0 ZCYQIqkHfGJEymwyVCEUBygCUzgiay80difDkGmIbK4DPTFiBxtixmJOwzupivRA7LPyeoJpds7O VtSCG0fS0iOSliZqdzDCWoJiHN+BOuXPUFCtpg5LpDHUgCEuRiwg5SewvihPTwGj60umOQEi3EHg 5IkD6K4lvU4mYiH0lMvC10xCV0ciGkDCBnVzMOakePkQIrTKu0hiCF4UvihUfPOCcVOsqGdEmvnq jCK1FJfCNVOvSPhIQmGgBQImIGpVGLDVMCxABVJr4SYPdLmE91DJX1biDPtrCx+VNsUsKRcpXmiA YvwiJQkzVKuPTVIp/GGrikFTTqgp1RbP4gvPSiIF+wriIUmMUsCkelmJZnqwTIf1TkaNLiNQoiTx elps7RamCqeJVxoVkm7iHz7k8wlVaiH03twmVniqAQWCHUBiEV114iG2Fps15tbCCJ9hVlAGGnpJ KSjPczUWNEe0+iEGUEGF6I6InWFr6nLySFnKkEAQD0yCFnlgXA/DoFD2St2mCwq1YlzSCAaw7CHE FgBPUBVlbA5BGgBwHqMTY1Qpnr+yPxiKKwA2e2Fqkv8PYw511wWhcwATiHPtJmWKlRdyOUyiOWEC Q2GmPKVWl0l2X2rwApv2gN2vRiEQK2cyaRxiEwA2flD2iQIVVRw2PEsv3k4qUxxSPsuiG22vOsmQ JDxCH252z2/CBGwwJmfQDgAENxZV/05QxSAwSuXQbSJIg1UNCG3Tg232NiGV2xB2ZM5FnSHQTniF 6Fiwc2eTcQRD6MpsYlQL9lG12gARoV4nDv/zIwkVG17x4znwn2tRyHMoRHcmeWCGoiDvTU0iCQRP kK/jpzeU43HiDqUQYEq3MxfVdCFptUloUFmPUEd09XpuPq6iGkF07lC1M3q1ALfwTiESoVD19XqI UFWXrxJmwRarW3QhVvw3MokHyy8p1qOiIVmXkFn3wnPXhLoC30/hVnQMBw4TOvZXPK6xbWSXViDS 6WqnGwCWsiFIQ2QWEyZnWsYCDD+oiw+iCp2uCkmL1JSt9IuoUWnVniDqMYZlhFthtEOqXEBkRkBn GMQNoEe3LwNCCYXJR4Kpy01W9JxQ40urMmpYdKu0/X4N4CBYUMX4O0lr7peJCr8FByJlhRmqPCEY kiDyoSQvq4KQ3K6khP231JsohhG44YS1AsmCKYAF31DWaVdop2vEIHBKgXtC5EfQllAzTyVRHxO1 i4yJhmaQ/iHGWKrzsHxzT4zmqwdHZr6FDIQmatymROdxIVNNiCCRCxDzFqAxNiIMUYhYPlqDuJIs zXKCJtyp1GX3xyqCH16Vxt3wXkaLHKGoFpOwn5OneRaxO4xLF5KVdiHtZ5P4WRAF7SiWA231n5Jk 5nQGuCC5TZY160yvKERKACJ5IuaXCtT5ypfqHV9ZdYmmQ5ri0ZGpKpa5mKMZJnxqt4ERK2wMM3jC EwwCFT/iHWTXPiBuHxgr1MUU22ZTsZlHdFiS+K8Vc5FIzq5GOg4WA4WiEJR6FHLWiY9vpCEE3BGp HlAQAxVRWKYSSWhrKo/AcV8LmKKG+ykKX4FZqQOQzSraRTg5tiEMUZyiHyS6KOa6LY/ajXxaYqNW IX/6miGvKHbq4n/4vaAiBWdKM4AC4w/ZoG+CEHZZJ1lCD6AAAZvNfaWKuzsKMOgpQD3Yykek8Oem szOrDHQPxpuY+CFM4o12+CHXUGfnKEtWK3lZWE5j2gYGKCH6ioV4n2M66F9Jo1xCDj0jhjf62AoF O4Xpyk6KDKEIdiIRIvssUFtsLnP29iCseyOiCW6CFj5ImVOtgZuiI5fl/ImNZ6yXCzfYQCJbS61Z pxswW6mj/kb7YCykUUkHqqPFLEMyCnFKA7Las6pqZJ17oYdtfAtAZRCVkCFNz04yDafiFhJpRg5y RpzR03f677Ax7m12XFh4gyMBh49nUgu427A2DwoRViCkHgvYuHMnNx11d3KiHgZLprObZ72Y1iHk /DfjlowCEvzHVTmCCFS5VCB8EIVYvb/8AiHGrbx2DCEno7ZrnFpiE7qYYMMV0HdbdQtGxQ8cVXk7 4CDV3nRxbRPCGp98AEaEUPu6lY7oNFqSDi2KDZ0Rf6BqMyJSaVertmMz2iBw2LAyZiFj5h321q9i F0blz2WHWKh2GyWSRqwDfokPfK0pdxxovObRASMbhSH37CJSLRQG2jeGuk/kNlqaEOCLpwfEIIz0 biIY9bNc2KZNovK6zpK8Zq6l3lJFAScP6mtaPtpIm3GlHcxWTlnM4UhXA0eCI5ScpSHvR8q1M9B8 s8rPKD75kp+IeZcsX9G8aCFcx9EIpdNwfFALbQ6mxKiC2gumHiqbHiMUqgu9JiL77CfbtCNAjAcJ +0511JPiH7vH2hhkDA5SnXebKHDqy05k7abXbtrp7FPdqVMhr9fNlI0cXCqdqSmiEAL9ly8zDFRr MgBAa8N0txXHOXsiDcdWEPPD8SQ2MCR9rQ2d3S89hnMJ1cRqF9gif9ii0KuzJ2DovlU8x7EEe8zJ TPLiGk8aikLE7qr5GX5oU8pVEqUmBiDubaT9KILi5kyupMJCgbV0Z+Z+aea+beb+cPBaojEX0iMH d9k2ODB7kiQYli789u7S6C1TPCM+e+Vj1FtlOd7i6eHWydhCEUsiG+jttvdiZ+tCGoZyFl0iBmAC Nemo2iHmETKtXcVi5+iiYedneSvCb38CRTaiHmqDXHECIAB8MCgHoHAiMI7chiNHC771QnXewTVn Im9Thm1nagvGUR1TOx+o2MgCt114AiS8vH68ciJH4D6cGCGFcyDCHlPB/VpHGn+LGHjrG60t3lAz 3kaHw/ICIoJrlfOZxINHIKMH3F7/PsUny7/Xv5pjVmjCCjtIJ0dcwHxldj+57CMcmj1e/pAj6MpC HIKDz40HpdTL4z+ZK7VVBI1JsoKlkzKDtD1nKJGj64+o0VL/ksSfl4vIvy+iODsIrsrI0yj/sNAy bPVj1iAEYtDVJgCDQeEQmFQkpDEBwoOnYjI1GnOFwsBquHsOEtdrlA7FCDHCFjGDloBlIpREjReF JNJuiMw+DmQyDGPS6EgMDHuUSqEnMyAIBFpOwYvQKCTGDRlhx4yTqEv6Gzw9weVxJGwiip1Olqkw iZRpVxyER6QFAcQcXHIvFJ/QspVK6XW7Xe8Xm9Xu+X1tQkYv5/GRrv4DVhoToDFqwHGjwiNWaEI1 tyG1wc/HLA3GEFoYlJoS264+DquDtcYmQ5tfKXVrgDDloAXODNtGqubC4BQpOzB0NDTaeDauEDi/ wbMwrD3fZF7HACCwbgzWDtuDcbAZwAYaEaHSgAyboa4vZXbV5Q7QvNYLCSfP3c49CmQfJQbXwa1N o4Lh3n6DsGwoDD88qFKihLGt6+aDGGp7UosvDtIS6y7uAyL6tYg7sFwhb7gAzyEQmuzEsBAwAMqu sItohCbIO5YvITEYBsk1UUQixCDtug4BBqhD4oS6aEtagzjv6/8SqwvskyVJcmSbJyLt2hAYQiq6 DRUi44NEADSAAYanQuRoLjsbQcSiFwLgFKYpRKU6aAAiS7kmf0ZTdDqDAuurEj3NrZxwhL/IS3r6 LO8EgABMpcFxM8ooRKq7NE8rovop8WTuAEyIVNQyGgf1HAADqFUYpC7DIVbWTE46uBgg8RzalVQL qoyYTnQdCSGhM8StI83ITI6kS07bSwYa6bUMukbT8u1aQXC6Et3RSDVW8ERgBXgAK2u9rPAhL02O hEroNXyEQTZdDWMhdkSsoLMQOhVtINbCEhdXqFXBJ973xfN9L6kiERtQFqqlAkfumYaTPshN+4Ap r3CkAYjCNEKpJjCs3QdOy6No8trNyF0eITSSFQchT9FwPbM4OhGFrpYAAHQhEGYNGk7rVdB/IcKU BIRloABdj0uLrB8M5EhUBoPiC6oI0rgvqAEOuM/eiIRlN6ITF7u1q4a9OWhV4rpakF1sg+FAAzeA oPqlrrxY1fJEukBM9h0Coupbf6YjsUIvjiD4/vl3IviV2IRbV333w3D8RfMN38hJToPHyXYGyEvt whIoTIAXFs1KbeFwKQ4js2y6wUAEgJua5t54i+uINyAAKE3SjJelybJxZy6ccu+V5e6T65Ty8yoV dKD27A6vC1la6dT4FMoUU5O890HA7onewxArj+OSg9rcWhV5oTls3d8vVPMnbMf+uhHNABVbE7B7 t4bXuaEVSnU9+he2eoWGu+9L6xwmvkXdctsgzQH+nSIu6oOSMCFQDcTA+CEES8vwWCQh3LPXikLe SdIaDMRoJHMsF5qKVjBADV46xOJ3Wmn4JCXV8r33SpHhQdB2i8G3Ejgo84vDK1qH1OIfiHBU3Cpv J0H4P0DiXCNLSDhq7jHGgGYcC4OzXiXMhAAiNpsNyEAXDkipaz+X9EJgGwUYcH4fl4gu+guyhmwE gbG+suJD0UxqjWQqM7NXcCnigAOGBbCFpcFW0wySGC6QmIXFImqJYURWS6ReDJB4uvbWRH0hMM4J SXkw4Yd8DILIgIoblqxF2wK4gzJsnY0GuC4iHFUfw14ynAOo/QuslGAJHE7KYhEjJYgATEQg/oFw vGCedKoGMG3wN4d6KuD6piDqpSK4OVALhTxpem5KA5LnUIreFDovUVkRqGVzAQ/6rHqyHIVAcyQw 5lKlL3GlFZ4QXOSIVGU0so0xg4DI92YMcZUODaqiI4E6jTjbVQXaacxA/OBkoQYpcrZ6JdnXMxEQ BppCne6bYRqlSDS4INIwss6yESPP+P4aAA5RnIJdRyTNK6WJOkotaFBtwyBdlpKJws4QALQT6Qh1 gAw/MRRynmQJiTJE4GuEYC8eCpTuS1TMFwfgalfIU7wkpCItAADkH4uC6WHU/LpGNmFJiTNPIRAu SoBppusenVF5ER5rkXTtCKbclYwE6QVSVhjR5wn7LbVo7UKHCvJgOwWsROS8zuIRTSqDX0ZJepPE xfs4yDWAn+XaxqvKkVXJ1Hp9LgiXt2iu2EaDti8Voj0lemS7ZckLsc1SzR/5DELqAQueVLbbW3ST TA+BLqPjQGgh1y42h3vZIMYKkphnyhaNs5VJR6HL0GQkQh2IMkPEKpPbiCRjK3F3MrcG4d1iMAxu VUEqTdplLUt8ay7svmUIRhQ2mu0nHS3pPRJmj9oW82TuwuOT1+793Lv9gHAV2JXiTTtExRMvFWUm U7gPB2D0mT3RfDkl1PyKNCJ0XGxzIFTqXpXb6kOEMRU8q6RPEeJ8UYpxVivFmLcULSwe2CpOLsBA DMY9PGmOcdY7x5j3H2KJV24GgJMiYq8cY/yRknJWS8mZNydg9c+AQjBQKfk/K2V8sZZy1lvLmXcv ZfzBmEhkwsrraPzmLNGS3n11zTS3NZFzxW2XEXhWGbbbAxSnXghiTrruIHQstrBCRtDazni5nxRm gZ2yy8+KF8F8n9M09uVCe9FEHE7FDODsl76OJ1oUu0SMKaVXyAKLzUkmZ9cMnKWBdrI47qeeMsC9 3h6iv3BeYxF9VEJwLlNwKig5akM4ANTtaSXULJdkHGmnL9L3zYQsLq+NQ4Q2VirTwuBoTxdEZ0GV KriyuxBOQhaGzM5zcdtbYxOqqGQ2+QraJPbELhZ6UVPLINRkIC9SJJOs8fVEvOQkHAONW7kLrdS1 Z3aA5RLu7meKcc/yu3VkNy6dj+ROxhTnPqoipcIXyEbe6TQyQlXfuejZeDE8RL1ua5V0mdoUEnVc /ekNPNdXuZcvHIsVVbLlT4ibXgvawZXSSoavM6v+INr6vzzo91eIPTSJsudVSB4N0N9RF9h2cQL0 w8chZjoZC8onmxdOmgAcgjaFa9wXc9SZhOvpCk97vJ0Y5Wbg0GW+A6loVeCHuv57dJXek9bG7rL3 0lOKkplEKdVqFG2yC6dlubTLZ5J4jHPIMYmZRG9UMqq3CZZGt7ql37roPVfmF09JxNH4gzyPPBGf rTno2zTIEXiPokunNHdY9pIAPipJ3vIEaMQY35LktADZTM87co9LnVJrofgkubzUndUADbj7GuAG W0eH3XGXLNoG0F17NZi9sDIHuBrIAOI/CZs2Bx31DGLyniDJyTFOocGym/X7mkDA08fu1zHHyyBm +9CLKqsKa+GUAzIWkeeVi768mvkL4xsm0vi0DACIU+iNgcGnk0OIW/gYLAiSG/q84Qkpk+s9OQIJ gOkvOt68uIMbShmtq+uUehuBi9WbMUCksIMe+/WLy9WpQLvBAZ8ZU/6l0b1Bg/qRg9wJ6tU3gT+/ CxO0m8MIUckQI30NEIy5Un8l8IWKGRatqiG+e2M3cFOHeIaVCLyaaVSZW4wLw0uLAIFCqIOFiaOG 0G2IyD9DO9ugtDAvE9KAAKIJOiaVmJmvQyG9VDibGo4r+UdDCbUOVBagQf+Vu6IkgnJCY73COo6O 6LLDcSWIaC0NEKEYmjomanMIW7bDuIWK6JeTkJnDbDeMwAEDgHeLbDOtkipEWhodKJoGHExCAusp NCM62Iu7CKkZbFipPAm9ONhBYKkxw+8LqIqKG3kV+IOTkjXDnFcj6pK0mmm5WXC4wKS/6xSeSrWI S+W8uJEGgipGWbOIOwoV8dU4QteqwIWQEee3Me9DG0EIOos4mSUMW44Ds+XEery/IIS1CV4egfNB qR3H5D6vklGXigor+D9Hm2uXgOCe+MWIOBkN8nnHubKIS+8jkAAP89ktkIS3SS6sdBQKk2sNqhiL pJMhXBzHgg1IkMUZBCAJoDii0nc2m+QgTJKf+MkiQeE80Z0uiJdGAJ0quwoW02iAA1gL4uvHQLqX E7DJS6mb+v5J6o0IM45GjJMwesRFmgOb6lXDgpPHQlGfy4xKlIBI4IVLYfLFCLvExJ66KP4LcSSo 4aVEY/FLM40vw2WWSZ6IGHeC0DlBGTmWNEDBygoWo7a8Ea0AE4WpVD8SBLpJZJClCYYLi/SLtHQe HECL6RUwuvy/HMxI8IvEnCs4KIWMSyIISFyUTGKIXFnEgicTdLo+eX8/Q5kciLw9XKWXqJ0BrMLL YgCIVKQKlDOck8VHUJc6qdYK3E7I8MYoaweTdIjN6p4QJL2dK4QG0I8bSkiKaXA5CT+IXO+IvLZO yJ05spOV5PAPULgL6/eO/AgacNRGyIuSuXAOnPcqGlG/msM6KnLMyIuKiXmR5BYqGe2mRP0qwi8Z yAAzesqs8ZcbAiycaWyQIuYKklGhWYwINONNVFpF0Gg7q3CFwMy9cfi9gQI9/MATdHeicORLCJ1G QIXPiIMosIwXdGQOW96LxRCp25rCdE+Lo1CZzIiE6tRQ7B8brKspXF40oa6NyUZDVO68m4ObAQmC 0jSM3Gu1MK4QILCvAcAIvBkgsmI5TEpKw4M5bDgXi5/Po+Y/EiuuuFOD81Cp6n+00J0oDNovEIOf KTdQeXoN2KOYGm9TtETJCZM0ip5OcfmfAbq0Aogt9ThPOOYoxSsKkWsWNNq/uRbR2LsclK+VZUzT QzIKkoyJdUq/EWpJjCJGxLDK2IQKWLsNsvFTylEtpU4lsb5F1TQ/OpMLtDPO7CmLuwon7QaRwlBF 8xONu4QBiyMpwuIusMYPfMFB6VuC8AEwwbQIuPyu/NaiSIuTJKQDkAuBiEavhRmnEcGCMdDEeBcx sDnXRTEJ0uG/s4NWyblRbWaIUSApxI6QyuFWufZCOZaRKckwwBjXVXYZTWqUOuEamH8BgJu3XP7A rXBEfLYyivbXgbKYdXlHqLwBiC8UAoIKkJuPdYEIuiZW+qDJ4IOpVYub0Nqa8kpGA0dWooIqVRFV FAUXVNOJ0DnWlYKZVWo9hUgLoK3WfNpTRZTaXFBNsLu0LW9aOLtYJaDYu5jR7O0qwpxZVYI+IzSa 8QI9oLyUROexaM8TJJjA9HU0hGAGgJ+U+RwdgKLQWrKMAWc+6KwBiU5bsTcdCwvBDaTL5REDkKhA 3DoIaU4xXGecNcGJQIXY6R0C9ABB1SQXrcEpIQIzqIqJPbeONDOmMI+nvOPSJNqpZda10xYnucyW +KoL1dKVSnVXaMzGWhgTHI8LeKpZoy/bU1oIPa4XvSsFymwanSOmxdAckuXVsL4eK1ax3FiXzbtB Za+L4woMLeyeJAc9ODm3/KReOyVL+xyahKaLxfGiYLOEaTPcS1beILhYxSGzTVk1ED9fNeLf7f8x 3e3f/gFgGSVONgJgPgRgTgVgXgZgbgdgfghgjglgngpgrgtgvgwXub2xPXBblQJgzf9ZlaixZgCy u8eSXJGtuwQb0pJgxfQL2IiNLhLeWL3RYYIMxgNIGwgDI2FhBRFPDevQ8L2AFc0XPfupXeFSIzDf WLvNmpY0GhGOzbsSUkCAFhySfiCwHiyL7ZKXDhmIvdeKlhsMgOmDlivZq2lhaxFjCX3Sjcu/ibQN QC8Dk6kZLX4O7BuLxi2Sc3wLpG4txSHXfZwcRiYLthOv9eJPuL6FXd0i5j0L5g8pXdO9ndmLuK0P BcQL5jCMFPKVeTgLtdzJDkcaOVOkej7k6fyXmD8FzerexNoozcRlbLaX1jYX1jcWcEblDMEaca8c yUUTQRsMTOaSGKJlyUMEaAHi/GCL2ZXbkAFVWtCJSJWSYXffyJc6kSecwpyX9cgO0fyV9j2kuPyP 2fKMJeeL6yrXCLPZWqqyRDOgXYjDPfVLiJcPTaejCAAC7iIG1FigXXaUYYk1aM2PabQDgYfXnlAf 9nheMI9Z+9oYAMGM6BjoMZ4PEANn0INZlnSLqL+ZMmMnleiPCSjowZhiOqtfUL3heKeFXjnHQNfZ /VLiGaESAipoCYFcSLpn5aPo2XgBjFjo6ZOLrXleijXpbXYUsdQxmZFmhWzoplNITpIKk0dkTmWg RpEmvp2MBn+pxnGZMpHnNimABoMV7nAkzcYXO0GczbMbLcrmHI2mweW9WM0LhEQlnT8VGQYFXiTh waofdbuLsG0LALKMljMGvr06USHDLjPJZGajCHeKJsDc1LfsMmKNES1krZGVYRtN0JcI4mKgWQ6Z afqrNdqJPcKoUQIN3sFrziTrUZQtpbC87D1dgLouDtcnHc+nsdFcw10nVs/pdrjsUM+RsNkIbs5M 1PQRAWBKbinrqjqwrFK+6ZTtyYHcNsaLrt/sNK4dQ/nVkSvctLrD0nilvD2LomK0FtHW0J3DCeKK FMkKMo5c1rykhsop+Puueo3ohYVQrtmkuM0NQ0LllUYL28Zl464rLrph4LuY8hQkDrzfiLsTOi6O 1eeJVOaCgC1wdsIaowOhFl/sXbwgIe/kPlmtIacIMW6rkKwKph5jUaOL0LMVyYwiW6agXtKJPwtX k6koWck6+jfxXSNCungb6C8huQYLqqunCTW2Fe/K4DsA6tSKkPrKkiUIOavwlwSM7xzj7YFc2RIJ xyrKuIuQJrdlneYIViiNpxbeyXBlqPUI655QOM6IS6Gj7nDBSiAUOi3wmXAC1y2kSsSJOOmFWe+b SWxySJ3nPyd0BuQghlGde0duYSXdfqSDs3/xIgqL1erlyi2Ls+IH8X7xcABuOSDLemQOvA6TQLsi oYGBwC0En051KIUPSBxxIMEDhtyW4L0ioV4oJ0t1qK5mgKbqc2zFoOhlzwKIvIfTcnediS4QJ2SI V1SbGaoJpi7kw8Xb7KNU1nV2GOrzdJPXaV6DmJweml/mf1BVuAHopHsJd0jnabH1kLzpcIT0xzxY DYBv7oyLuYOVy5pf32ob5tOl332o72Rd0XhmTXBbUpxtyBr174IaGgl3o3ZRuSWOmJwZSEaszhWI S9yLvxIUNxAkoQMnsflb9IOVGL2ipyICgN7y8gActfcKnqr5P2743zENna95RVdPRrzkjm2SlXzJ bVG0sILyOLs6618+8V8YOkfe2nVd2vhN1frwV273yLoFWe1CR5wXljN6rdIM+JYLx2TSHKXdAIvh fXyipIJzPl3qhiILuNesyAAib6/a8TcckzrrKo7sH60+8YuXjbV6YV4apyh2wIVkEXy7DSHNnRxW MNPQ6yOW+L44wabOSaL5R5MLvRB23nzkLZeIQ4IC8fqhXrQ+3IezZ8mJc4wRKYk+4iczwW+lXH+V D62KkpUXsXsSOBlxIEn6Ro5kPumz2iJCpaMAEMzfLVVeC4rY33mIQaFqVQtTb9XrergIXAndBvV4 iLsYw16Iv+bE+C1977j7kwUL/hOPX+Z6vUbZ3GiLpqTA4kh+GbRP7elGMgkUNSG5tzKg0n+IAUDs AIJBYMABjB4VC4IAoOw4Oq4ZCgvBwHBC1ByNE4XEIO14OUIOuBcFwEUn9HIMc4O74I2oMwzJCoTC hxBJJBxiA380C1F4MjUaczJDpVBD9B5nBIEUBwXjguINKYJPYMHTsRqFLINLoOk4OcqPBJLBSlNY MUoVRQEfhq76NMaXYy9BpPBaBZoJG7tR7aFzkq5BB4HCrvBapBLVK7HYYNaABIoNFYZeYIjcbBLn C8HBxdKikUg7SszBs7TJHDMSAMXBa5BLeAgE2qTjZBA5ucILcYVrcvu4PMIIk49OsJBajJcOAJ5P gHobXvINGdL1YYjc6jW3C9rDNPBs3KjllIJrwARhwOKjXsf1oJdZjB8xYzlcxjVOpBe3meLBe+8i Cj8+p/NWjjwi6phOkmSZ0GG6QAQQm0ArEqYDC0LTvgAVYyDIz76IO8z0PUAD2AA1b8oIOxtkbDaD wig0GgEFzxvgo8BDJAkXoMaAjMKgoXAEGoZABB7+qO9cbsTApoIJFcfwehUZguLzsR086Fs2fwDR 2vkNPChjiym0yDPSg0KIVDD5IkxsoP07iFy2g0us1IEhMya4ujma7MQBEiGTigkmPAgwZC6AQvCh BTGm2C6NvUqTNQKgpcUEAEWOAgzJIJB0pPhPM90ZOZ3wFEyDQtNNKoLL6CrA91XIKGIyBia8MoJM 6Ft8vrMjlWlYsgACnlwnKLAMPcLtLFAAPDWqGJQKQyLzZL5saoo/MAglfx9V6VQUSaUwfVcagBcV t3LcyVWra7GrFZyGKxOajn9VaOJIOS6sTQCCNGy6iRk7qJ2tQdM1wf1ngHYqrqyrdqL/W4AO/cQv WdaE42S8tzonhyCWMLTQqxKK3RKo9ZVoAFtABD1trgg1WrHH1IMRg2EILd+FqQg44oPhrO1ma6BX OouMaEAE9WnjGUttWLzMaAw/C1X6VWS6WoI4GFZPaoLqxmOWqaHr2v7BsLq41bcFnRVNy3zK9VQ6 AAaqPW4yaWierBiGAAX+jcVzWxutuq++6hhtWxWQGIpAHeHCXNHUFszTWYVVu2msJJ158UhcWQ5y /N85zvPc/0HQ9Fc9yXLBdJdGg7AOxzXU9d1/YLsAQjBqGuW9jzpG9b3Hed733f+B4Le+Fr4YkaGM reJ5XlqOLw4hl2/mel6fqer63r+x7Pte37nu+97/wfD8Xx/J8vzfP9H0/V9f2fb933/h+P5fn+n6 /t+/8fz/X9/5/v/P/gBAGAUA4CQFgNAeBECYFQLgZA2B0D4IQRglBOCkFYLQXgxBmDUG4OQdg9B+ EEIYRQjhJCWE0J4UQphVCuFkLYXQvhhDGGUM4aQ1htDeHEOYdQ7h5D2H0P4gRBiFEOIkRYjRHiRE mJUS4mRNidE+KEUYpRTipFWK0V4sRZi1FuLkXYvRfjBGGMUY4yRld4QECmVuZHN0cmVhbQplbmRv YmoKMTAgMCBvYmoKMTE4ODYKZW5kb2JqCjExIDAgb2JqClsgL0luZGV4ZWQgL0RldmljZVJHQiAy NTUgMTQgMCBSIF0KZW5kb2JqCjEyIDAgb2JqCjw8Ci9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dp ZHRoIDEwNgovSGVpZ2h0IDI4Ci9Db2xvclNwYWNlIDExIDAgUgovQml0c1BlckNvbXBvbmVudCA4 Ci9MZW5ndGggMTMgMCBSCj4+CnN0cmVhbQqAP+BQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNR uOR2PR+QSGRSODPp9vt7vZ7v2WP6XSx+vt+PyXTWbQOYPyTzWYTafT+cPyYP2awahy2XSl7PWlvq nU590SiS6DTapz+sP6Hyd+PJ5PV+0KeSyZ1d7vl8vZ7PiiwJ6PR7PK4T+uPd6vef0KZzO6TuXTqh SySYOKOZyuRgLthshnsvDOVttVqtRqtppNVmttvNZuNRsTByONzM9jMpoNFsOBtt1pthntNqtFrN 9xsxotJ1Ot2TVwNZvNrOt9wt1yOZ0uR0ORtNdrupzOSYNZrtBhsZgs5ktFltJpONxN90udywZzul ytxrt5st5vt5wuJwuZwfPRN9yfZuuV0/Jzuhrm4bK0Hydh2HgZpjmkc0FHAbRwG8bpwmyb5uL2dx 3Hg550m6zaTn0cx0HYbhwnObUJHwe57vMdZqGUaRrm2a5lMY+z9HUdLImubJsG8a5omuY7SHQ4y7 HuwkjIgeh4noc5zHW2BpHSdB1HmeB4nE4jKmgbxyG4bBtm+rh4Hkd72G6YpfGZHJpx8ZpqmgacLn obBtG8dbcpq4bgHAappzeZpoGzKR1nad52HJKKXm6c0SuY4BumiahoG0axsm4bpuSSeqBuGbxiGI ZLFmCbMYGS7Bum0cJyHCcBgmOXhrGwbMmnYZZmmelS1KYeR4HnJR4mvLxvHAcbRHIstCnidRynWb hxmws61rQeR5no35vrSfB3tyahqGZCRtGM7ZynMdhynKdBsUub9USubxmGsZMCnefJ9n1I97oYrN 9KwwN9LLfeAQ6sjAKhfSBp+mB8YUrmGXonGBn4p16XrhR8H1eiYYveiTJrf+AKOq99J7gC8r4lyZ KvkeSJvfGW5dl+YZjmWZ5glp5rkmCqp9g6XHzhS9oTiy0YuoedoKmCZJQlJ6nmu58Hseh6nleqZZ MrWaaxrOtIqlJ8GUZM0xecT9v6+5vGwZBpwSdB0r3SZrtfOezwAbCa3I+RzG+aBnmgZxrm1aZ7La f8Cnacjxa+ZRdl0Y5pmyappGg0xnGU4p0RQfGt81zfOJLepuG+bLZGybpxHAb5wG4dx4naZ7Lvgc Kwn7F/U2JU5sGgZZjtBthxOKdJ1HU9Juq+eSTXsgR1HcdZzxtPjZQ295vmo7XSGwc5vnKfK7877v vaxi59T6bD9HKdp3HamBznEdR0SYe+npwrOVJaludZYf+qqhlV9H0fA+XBvfgFANIz8B8i3GCMsa g1xrDgHKONjaezNjXGkmIdsBIMQZg0SAwI7B3FfLgSoe7SS4tSSo/9IsG4VQrhZC2F0L4YJGJqVB qA9WFFpJSScfbHSkD+f4VQhEPB+kVKOTSIBDYeRGH8wp8KAh8Q6ZIRsoBCyxxDIEv2I792VlZYeP 0p8UyCRgfu0kvbICyQBJGPEr4yxljQGALoX6PhrDSGoM0agzhmEzH2OIdDqUHjmHCiNKQ5n2tCGq ewco6lVDlHA740I6h2DnSYN4bw208DlHE44aA2xtjaOE79cx8xqDTGcpIbBxhzGAbOOEcY5zvDlG 8VwYwzE+DaGmuEZQxhhjHGYtwu49B8sXUOkJZSqRwjpmQfYc5ZYajtSqqkci5pkJRHYO8dyeBvjd GstwapmjKjUQIO4wMrB0DcOWPEeC8y0ISGuOIcY4HgPBSrIMdrwS3jyJgcI0Q4kFSEkIf07w7HmP HViNocawh2jpHWTWbI2xzjkHE1VFzkRpDPGqqMZU2zYDOHqW9IzUR6GvGdNsbSDRuDRGeMxAA2n4 D4dWO55o5x2DqmcPIeI5pXFMHuMUZ41ByDrHM00eY6x0JOG6N0cA4RvR3GdD4fp7hujAGOMQZ4zR mvBHef0cqpxrjDGSMeqwzoHSxmCNEao3EpDqLePEsrahso6G03wZwxxijKF+7odI7B0GBNoOcXgx BfiyFsLQZ4yhmDTG0N1jbqBuC/NKLgXIvBbC7F7YYZQzoFk1GyNIaIzbOmHHQbYZ75x2k1pfKQZs kRzq5F4MIYE2XUIQNyO0dD7pIPnSqTAbilncjSVhMeh9nBnx8HKPUpgubKScG474dBNRrDPGc6Ab DVTTjXjxKUZ41hljTGeM8ZAxx3I2SM1SvQ7CmFvHoPNKg8Clj2Keh1E8N2fRMKchWmlQn/j4L2OV JiFh2lwhsSoeCYh3DvW1aTAxan4FnNUONGyILwleK8km9KVMCuYJaxJnw+R44dWoPQkxUSWYfWmP QdZusT0CHcOxakalejxdWO+dJch5PwHsOsd47XWDuaYPIvY8R5urnSW8erx8DLzZ+Se8Kdh2jrRP S0fChELTptmOhcY6x3DoKeige6Fx3pjHhieZ2A8C4neAO2Z0zsgNNZGVcqDVMtonJ1iKKxg2qVIH G6AyJlBvzZkqOJIAvxjjLGEK4WAuRhDJGIMEYAvxw27f8PkYgvbIjBFsNg2EwR9N8GkMIZGi6wDl QaesbMvBlCvMUqMbzwbzDzHsNVd4uxjC0FvZIZpthhjKGCNxSgykgGNGuQOzozXKXRdSMAXwwXl4 sy+NMZgyhujfGwMHXIwRkDLReNioo6RxO+0wNUW4xRXvNHMTWtLplFGGKYPO7YwW96EGYMwy4zk5 jVnQO5qh0jGjNGXUAdVNh6CyFuLlVA36SC4FkK0Yw0BfooHrgUdg1YGK2GSNQaVBjhH/GjtIbQ0E XSNG8f0c7BYsubL3l8d5b2b02y+PG+J/akunGonSpI3Zp3qHiz4e6BH1nzeYOuZkNq85Nxw/5/7F 70j1SrjVFGaB4NDY1l/NXKVdZAaePhXY9KEjwIHIAw5/S0D4dhcbD485AjZSuNyaNCh2DtwWVBE4 +ecDEGALevQ6SucALOPnEsKL+TwkgcYdFpL8tJJeXLMmSH/PwcgNXIl8ULDqHePEdhe6Oj1zF4KG 7GsCD5fhefsl/iuQ+H9nMfTVoxECjB6kibTR5UXMvLUbClkJOoN8Nk6WepKDcPcf88A5x1uQGYOR 1N/D9yQsMNUcR/VU8jYujYcysEAKpJ+MsZQ1D0Dcg8OkbJzI1DweAOeQI4RnjR7RngcJqzpDUPYp YcY1RrDbeAOvPI4vujSGmixP40kJDcgebaJmoSyykws8GCKWLAJYbYHUGIGOGOeOHQekHATmMuGu NoGiGmGsQ2G+PKzQSkmiPsd8kOHE00ZuHeS+RKGiMiGsGY26G2L2UgGaz6HCQsHe26HQJgHcrycg GoSkkkRsG0G214kO7i6MPuHCXeG2f+HydWHak8G8HEuWXqH0WmHmG2ncdQqSVSP0j6GyHCfCIkYU Hs26j4P2t2WGHAVUSuG2Gwm2gW5AyAHkb+5CSkw6v+K8wMHgbYHYO4GuymcwJUWqGwdwGgeogWHi 5SJqUgnMUogYGcF+GEGCNyXKOekaHAGESANOb6VAGEF+F2eyHIk4G+GMGQGTFIUBEERyGe7aHUGy 5oO8P6HWLWHsoOgekYgoGeeCHcJawGHeGYGgGYhuNDDQkA4gS+tgHChEmqHiQc95DYTcGitavAxk oEHS0wGu0ePeHGockwj0WAGmQUHOUIpmRAaozMS8G4yAHeN0HUPcG+O+HOZ8H0Jg5wXOHK4cK8Hn EITmQAmCaeRQGmOYGEGGGGlK/yM8roGUo6Ho9YIMMAVwd8QyHSHG0eL2Jq8mHcpwHQUKdWK8wWJq WoHs1cHmYqJqRQLSKWYUhSH+SqHiXOfcPKHEXOJULSai/wGiVQHAw+NyHSfOpmvCPLHqHMmCHyla HCrczyVSSkQuvCmmxw+AHQhQJgx0zAdWxgeyHFKqLOHuMANyHcaiqEyCvCL0ywHYpsHmUKy+LefQ HYaevcKcdKnMS6WEN/DQweo6HmJgsQGoeaHI+/KmWoSozQw6HeJgSkHYdMHEvSxNHUwe6WprI+vU UKwHHwZu7ag8nmqApwOecOG8MOHGkZDgHeZuLvJUIS1YTe2MlaN1ImG9CUJqn4HEGMGSGKFmFaFr AyocfaJqlaHUGmG6GkVSHGJat8G4/yGeHGQ2IGS+G2GcTWm2GqFkF8GI7avYo6gWGoFgsEm65mG0 Gwl2GWOyGM/uG4k4JqcOHIGcGcGeFoFcFwGaGtAuGqGeVAtePi0QF5C0WicaGmv4HITK1QF6VKGV LKHWyAHoFSFuF+swNeGY34pQwWFGFWFg9xO6MqF2GOF8GUGWGMlCeOGOcoGQGYl4GSGaF6GPRIGU GVImG+JqG8HMG8Qur0Ts7QHKGKOsMkGmlYHEJqRyG0d0GORqOQHEPYG2qkGSF0VaJqGop6F4F4GK FyGIF8jwbApTF8GiFeFwFgFmFsFgF8r+0GGcGCGCFySAGRC2ZuHoIYhQzKKgLKaSYsH0JquMHskg eUSqhCwmIGaGLuHq7DIsV2Wm5cJSIGhCwM5yf+p0jKh8xCHgQuLWHueOLgJScwYULucEL+KEaGvU xBCkLQuMHoaqxk6YYmH4poHavmvajUHoxW6ALCarGULUHtF4ywHeK4TeGmTE5cYUpkryRs3WJgN0 Hgy4yIRAHTViYkIGjKLIJkvqxOHWvVU2HsIGJUx6Hm9OL2L2H2NFAguWJqHoLkg+HjJ5HWHTUCcw twHaQIvUKYJUWmHhHDAAMCzqhjXpXrXtXvXxXzX1X3X5X6haICAKZW5kc3RyZWFtCmVuZG9iagox MyAwIG9iagozNDg5CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+PgpzdHJlYW0K ////6WAKGFBQYVs62DG/r3SQZXODvIxekOFRRZC82cvJBrUqEM16YS7WmwcHW7d86xzwb9l8zmpe H7Du3Im5po9u0KA8SgFrIJ1zKPgqpeRHlVQhEiKLcEI7Xx7FGcRVh5X1xOD3MAGUoymMzc9xFWTF Nnfowucq/kdIw2ANGOiiDqyDBdyEmYCuJk59l2PiXZpZRVxBcFqIuB7oxjfQaUV97EpacOTaHgoo m6KLfgAl10aCGbbcoW77ijUyW5532IrCMvqmDRmwNbRTwDNT5gqaaSNQRcW/QVD0c6uS6oQdrLcX U8QxBPnlV7oYq6EjRQpHllANVZFdSQUJ3PCO+Z1GEfAKQvQEKEy/QfdhZT1srdO8uilOGHJUIk9E sEnh9lrRAZ3FBsYRxQgJJ21HkxobUNVEn+228w8GOMBPGbaq67hIsb4OwoQWzKuEEz6fLo90cy5i KiJxMFoyf3PpKl6hcg9fgdLjmJ+OHLPNvOJcMFWLkn+tBK8HNy97IFrawczqIU69BOZckwMPYb/y vvBHSYPH9od2/r+met8AVKDNPsEb+8YCWFoFaLvEWnm0ocI4aLm/37h/hjJeh4f/VcbBccGHcxri eYKdPtwX8n7aKueU6sdMak1/yNUHxyrNiZyPEQ+p84krkccIqLqGguRuF881ZDmD4wJY6sqDuFMf R2Qv8Ve4HOl/JZE5rBQeGivuT5Ao03MrK171rxZIz16t/k8Ft2zuNpGAcD6Vj1jBfahRpnvE0acj xlc6DyaYvSTowtxUsBPmMYMkxhJ9h5Al2DehnQhIwM+f+97GlJzqfF7G0Q/Zt0Bd3AZwWY0BfmY4 IANAacQPCL/uz1OKudDpgKH4Wlk5uDY/KI/NKg40Yi43opf8sqC7oW8PLCngFqqCDgXbSL0Sh+ah VRCwiXPewRZ2vcgXeWqGiZewaa1b67xgxwQe2YwEe+IVK2uICi2egOpnl2PSHuxqz1YXKkLUignZ qeNlrV9Iw4qzTJTh6xXLUqwvJcscj5typ8W0CmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKNzY4 CmVuZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAwMDAwIG4g CjAwMDAwMDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkzIDAwMDAw IG4gCjAwMDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAwNTk4IDAw MDAwIG4gCjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAwMDEyODEx IDAwMDAwIG4gCjAwMDAwMTI4MzMgMDAwMDAgbiAKMDAwMDAxMjg4NCAwMDAwMCBuIAowMDAwMDE2 NTEyIDAwMDAwIG4gCjAwMDAwMTY1MzMgMDAwMDAgbiAKMDAwMDAxNzM1NiAwMDAwMCBuIAp0cmFp bGVyCjw8Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJlZgoxNzM3 NgolJUVPRgo= --------------040808030703010202050005-- From gtbarium@fast-email.com Thu Jun 28 06:28:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rEf-0004wi-8g for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 06:28:25 -0400 Received: from tri69-1-62-34-125-7.dsl.club-internet.fr ([62.34.125.7] helo=fast-email.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3rEe-0000zC-MM for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 06:28:25 -0400 Message-ID: <001501c7b97f$ef925bc0$11a3de54@marin0ayg41o62> From: "Rene Lovell" To: "nemo-archive" Subject: Thank you, we are ready to lend you money regardless of Credit Date: Thu, 28 Jun 2007 12:26:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C7B97F.EF925BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0012_01C7B97F.EF925BC0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you OWN real estate and want IMMEDIATE pocket money to spend ANY way = you like, or simply want to LOWER your monthly payments by a third or = more, here is best deal we can offer you THIS NIGHT (hurry, this deal = will expire TODAY): $437,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = entire payment! Hurry, when our deal is gone, it is gone. Simply fill in this short = form... Don't worry about approval, your credit score will not disqualify you! http://timelyytfahionn.com/ ------=_NextPart_000_0012_01C7B97F.EF925BC0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Your credit history = does not matter to us!
 
If your family OWN real = estate and want IMMEDIATE ready money to spend ANY way you like, or = simply want to LOWER your entire payment by a third or more, here is our = deal we can offer you TONIGHT (hurry, this deal will expire THIS = EVENING):
 
$362,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when the deal is = gone, it is gone. Simply fill this user-friendly form... =
 
Do not worry about = approval, your credit history will not disqualify you!
 
http://timelyytfahionn.com/ ------=_NextPart_000_0012_01C7B97F.EF925BC0-- From uatdemarcate@down.ro Thu Jun 28 06:33:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rJ9-000585-5e for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 06:33:03 -0400 Received: from [219.128.219.140] (helo=down.ro) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3rJ7-0001Jb-R0 for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 06:33:03 -0400 Message-ID: <001401c7b9b2$c18d7920$06c3352c@billgates> From: "Caitlin Aragon" To: "nemo-archive" Subject: Fw: Thank you, we are ready to lend some cash Date: Thu, 28 Jun 2007 18:30:52 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7B9B2.C18D7920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0011_01C7B9B2.C18D7920 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Your your credit report does not matter to us! If your family OWN real estate and want IMMEDIATE pin money to spend ANY = way you like, or simply require to LOWER your entire payment by a third = or more, here is our best deal we can offer you TODAY (hurry, this lot = will expire THIS EVENING): $435,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = payments! Hurry, when the deal is gone, it is gone. Simply fill out this simple = form... Don't worry about approval, your credit history will not disqualify you! http://timelyytfahionn.com/ ------=_NextPart_000_0011_01C7B9B2.C18D7920 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Your your credit report = doesn't matter to us!
 
If you OWN property and = want IMMEDIATE pocket money to spend ANY way you like, or simply wish to = LOWER your payments by a third or more, here is our deal we can offer = you THIS NIGHT (hurry, this deal will expire NOW):
 
$250,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have set the lowest entire = payment!
 
Hurry, when best deal = is gone, it is gone. Simply fill out this simple form... =
 
Do not worry about = approval, your credit history will not disqualify you!
 
http://timelyytfahionn.com/ ------=_NextPart_000_0011_01C7B9B2.C18D7920-- From okw@wradvisors.com Thu Jun 28 16:36:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40jW-0001pT-J3 for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 16:36:54 -0400 Received: from dvg114.neoplus.adsl.tpnet.pl ([83.22.40.114]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I40j1-000089-GO for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 16:36:54 -0400 Received: from ujn.nart ([75.59.74.98]) by dvg114.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Jun 2007 22:36:18 +0200 Message-ID: <000401c7b9c3$fb13d250$624a3b4b@ujn.nart> From: "egreetings.com" To: Subject: RE: Date: Thu, 28 Jun 2007 22:36:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Give that penis of yours fabulous look with Penis Enlarge Patch. http://www.hustea.hk/ From dqc@centerpartners.com Thu Jun 28 19:03:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I431k-0003A6-TP for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 19:03:52 -0400 Received: from dnvrcochds0a902.mcleodusa.net ([63.253.90.146]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I431f-0004wI-PA for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 19:03:52 -0400 Received: from xhwkd.fw ([88.106.166.115]) by DNVRCOCHDS0A902.mcleodusa.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Jun 2007 17:03:57 -0600 Message-ID: <001b01c7b9d8$9bb78a80$73a66a58@xhwkd.fw> From: "123greetings.com" To: Subject: You've received a postcard from a family member! Date: Thu, 28 Jun 2007 17:03:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2499 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2499 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your family member has sent you an ecard from 123greetings.com. Send free ecards from 123greetings.com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://71.201.114.105/?c43d852d4b9999b98562bd22ca398b69146019a -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://71.201.114.105/ Your ecard number is c43d852d4b9999b98562bd22ca398b69146019a Best wishes, Postmaster, 123greetings.com From gjl@dmail.plala.or.jp Thu Jun 28 21:59:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45ll-0001Gz-Vp for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 21:59:33 -0400 Received: from [123.188.187.126] (helo=srocjo) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I45kp-0003NA-Q9 for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 21:59:33 -0400 Received: from gfubc ([135.191.39.176]) by srocjo with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jun 2007 09:51:53 +0800 Message-ID: <468465B9.2070305@dmail.plala.or.jp> Date: Fri, 29 Jun 2007 09:51:53 +0800 From: Clements Q. Vivian User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: invitation.pdf Content-Type: multipart/mixed; boundary="------------030701070007080406030705" X-Spam-Score: 1.7 (+) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 --------------030701070007080406030705 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------030701070007080406030705 Content-Type: application/pdf; name="invitation.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="invitation.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDY4NiAxNzJdCi9Dcm9w Qm94IFswIDAgNjg2IDE3Ml0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo2ODYgMCAwIDE3MiAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDY4NgovSGVpZ2h0 IDE3MgovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhsVjslls1ntFptVrtltt1vuFxuVzul1u13vF5vV7ipjGYeG43vOAG77eoXC8cB0FPc Xfd8yGRkp7PbbEQ3C71peIwOCtD1RwXD2PABjf+nPa0gedw60xMDDcID0Of+MgWY0Gihw3w8r1+S 4FuJQby4XRygpueiuzgiijqyhRoKUi44P0aCfoA0+ofuLAHKgxSPfMgvkhe1gmxAHGUHWfaChgeH Xr38VURKiHm4P7tHqiBZMIzSFvq8wPHqUALhYgYxu0BwlNU1bXNAh7wIGbbxDHBiFP0IiGvqhb9I K8SRQFCztIK6DvoREcMoNEKEO9Ez1oLCqDN4gbEIuIj8IfF7+R+sJtoQ+CCMa+jWNe14pA234wII 8jAQQB4wQ6AAHH+MAHFof8jBuWgWNAFkfRsgwxyWC8Mw/GiCx4AEsy3IyBxKhkaoqC8pw7NqFEcg sGPRHDbta38lxxJyCTqg8YtugU5gAHCFwq+s0ydBSPNJIFMLEERBAuWjkNW2wARSgcIE4OMlvHIQ AUrRaBP1HgwT+AEeSIgdLoW+cRILRSDD+gtVAAGZtn+WjhoFTr2tGgjttTUAdBY1z0vGgsFMJDQA MOFj7m3XiEPdWrtS4WgZlkz1ntc37/IFVlWoZYCBSJZL3hvd6D1ygY4oGDxtguBwWAfdgxg8Dw/x KJVuIK1TiU4gtwUzh6uH6zBQT5C0IAAylXBvAzEYvC8FoEB9DzlNiBVkAD1Ym0NlQ88I9zQMc1IL T7vT0glVAvijRUvZg9gdFOOU7HKBZfa6BQAwGBOY+ubQ2fd6QhLmfQBQCDTjkM+odi9W5Xp96oPj rEAvYGjXYAGBwPBKBCUJVDIGPYNm3iWc5HiG7K3RET6I1YbkE1rlOnqt2WBT6B1hX9j4pMT3odmW YAuMGzIK18qxjOG4vByWTtfvyCQ/o2zvNAV2W6hjTNrIwZvrx1JhZswAtpyd1ojTsvTRwLSoJUaD 7dvTYXfiqBa/u/iKlmWTdRP+83UgdWBvOMP9SgoRUYimt72gmRITSvDgBYY9iJhcnoNk6B8KgV88 88uZoEMFtj33qFVvE84sDUiD9bgCC/KhGr2wq4iL1z/OQX+mI8qCAWPuII/F5j2iBOgeLBEp7x2T O+bOgh2qRSDoAMCaZHALAHI7DGkZmx2QAM6NHCZAbtXVqTf09ttcFQANbH6gR8hCEPr1Q+hVmkIn /Pyf3BYDynxaGYDGhcxroHdkQOG3IxCn0xkIeu9AMDAIlj/bTCBKpAleQ6glF8qqYTRr0SKsQgpr RaNbeO0mC0IQlMxfu3VVcY3hkGU7Glz8BHJK7VnHBQwAW4NyMwQRnj2FQIzII7h9qa31AAhEBcTj 8SEr0dOlyGcZyBR4iQYl0B+ofkJkEZlW0AXZPtdc0iDRA0dkEhK+sgb/IwSxKKI5b423QPXIVBBs 8qSgI7SFJFGLcFNv/IGIKWxp2iC0BEYQ5kAlCuuVYvV7g2wWTAl0/hZhAnqEEj21VfUQSLMOItNB gcZGTIJSowd9oDjTJxYcreWEsp5FkMCEo1BQ1gOlIQNtLahzAj9PJFMgYDl/AsVGzZSq9ZcEsniS psyehZLaPwhqdiW02ofXBQ2edGyvunk+XsMc1UHT9LKYicsHqOUppUXKa1GiugBAuP2flK6aU1pt TenFOadU7p5T2n1P6gVBqFUOolRajVHqRUmpVS6mVNqdU+qFUapVTqpVWq1V6sVZq1VurlXavVfr BWGsVY6yVlrNWetFaa1VrrYWoG9ABQKNP29cHVMlYtEA2akG53h+igACCx8MXob1tsIckwMQ2hn8 D+1sUDEgHCcWa3APaXglKPB0AFcZw5tshMK+Sj9hbQFBQq3klBqB/hiJBZMWgDo6kidgQRe8mWUE FOy+cgpoQACCRrS60NvScwqXaHtMVbyCgBrqNttyRoiz6IbaYUIAbSEVuWJS6JHh6q8uAxi7TI7X kGtw8J69z7fXjKAxsUDZgpBgXKP0P6cQpWNW5ZCvAewlX0UeAAMQ/52QUWXbR5p3zXPpIs00yZBr 4tXvpfYG5sb9MxVlA6GUcryYTJ1BhLzb4+PVIIxd8CoBQ2rZiI54JCWTnKAu7aI6cQ/gBAcGsNZD 16oMxE/aYoNwx0kIq6UMBqRaJGCJQQbYN7X37xFI2V6ZMKZJJ2Dcf6SSE2xkvIaS93cNEKf8eTGi xyBYrQcGsPdciEKRFoI4eoN2KLwpkluZBFcCNvrylY27F4txnOxPzNZBLs5Kz0S+2yGoKXZTjnNd dBALh1boQvK8h2qq+tgbtyYdZuLwVCRTF5BROG2bcBu1GcCDnvG3PbO+is96jJbDmABBAZ6iu3pw glBBaBjDigchjJ3CvXOYAEIglAZgBHrnl/rWZG3VIhqnSZAkO5ztXlEgzDnyxR1Js8kWJ0vRHDQb fLmLk4hjDAGCNLcKBplIkKGUuylW4ty8PUHWwgAbiIJgLDVrSBIIIfl9hOPa84/e81kG4cczZjNe hXK9ttocDJJiiRQfwwCUDWryyDz11NNFoP0OMQ8wHhWpN4gUJhKEU03N+QkD7iszm6QjKDGAN73m 0wkAHE64mcIFffI5BOK8E5oUIOOsd5J0sPBhkBBFPhr13Y3YQe8PpaZIQRIgnFmD/kUfQiDEiURD 5r1MrJgeeENy/uma5BeihjRLbY5VziM9bI/wLqnZ+0dp7V2vtnbe3dvppowl6jTEhoG2YBgpDr1L 942fEww+wBAXT+rJ5ncPDFKrfe1mwSrHkSP1zN9hBEGS28TfQhi/l+sHuqYYw4Y+lNE6ZJnKnh/S FGrfX4JQa4trcx3QshOseZbq1M6DSpCr0EM4qbW1/o/S+9KEZ47yRtPqks+QXfjhTDeyILtU/XtS Eu7FpuwhRmgLiyzvc8zW9PffbKFexWbJZeEKDqbNARhkVENQqkLyvqbmEHwX+gG6Yp7vVFp7z7n9 ydi0G2DNdg6NiswjPMnPviGumjnJbP9P+CIMmiHAxk9FeH5v8QIidAiP+JCsNkQDlGzPCopCCkOt 4CFB/sRiItiGQjHs2wJQUCZJOEqnrvIDvjAjDrErZiGlGj8PXDzreCEwSBHDHhtgNwbwUwgiUkNE ID1KMFID5GxD6wNiDrbEhQgCENQiGnmFRjSDGr+QhQsiSMfhQh/omnElbNAG8kPwmCDEEAZgiJfH ciIlmMbQSFSQlgNo3gZi/iBB9jSApBaQXQtQ+LUkuG4uZI0h6pxMso7K8HHw3iEQ0Q1QBwFEuDAw ZFjnPmYlyJRujw+xMCUJPgNxBv3LmDXq8k0g9oliXRIxMxTxURUxVRVxWRWxXRXxYRYxZRZxaRax bRbxcRcxdRdxeRexfRfxgRgxhRhxiRixjRjxkRkxlRlxmRmxnRnq2loiarOizDcQowcxUo3uRlMB BAcHTlSGNjOsNnbkmDwRSCSEfE0CbEbiDQyiNQRCbDMx4GTPipEs2JqCSumi4woCnJqNLiNt1CEm rtBCnrdFhjtjbjOrECBhOAxg0K8gPIVKQvpCTSAidR6iMMICMQsCKyNCJx3CFGDkExsCKyQCiSMC NR+CHF6rXjiGJMzCZSSEQHzyGtqkygWSKGMM1j7v0OzCfOALZMjHjugIZrqqREHs8QYHgjBM1E/o iurHVmPrmvwhOKRyZQmxIjxNpD6ynqUCFnLlgDcoxiMyOCKGZEuQcyUCDk2v2iJk1S1CgyTSUiNH QD0JBDeLviJDXIkCFkNA9pLCDFFF1Q9lDucoZmxkRiCOgK9INMfCHEJiiOYIZEKmLpdPUjVt4Jqk 3zAAbgzy8IDFHJKy/jbmJG/FJFCJWGMSnsMI4gAJgHLuZBHHFzHlOiCxyjMHLDAhtgAzACEywTOi BTZDrzJS/rnjlG/vXPgiCP7CDSwEXCDzio7Iij1s/DvvMiHlry2y9RDTcGbTdy0QpsgzPCLODCJy 4CLnryLNIpUkKkxtxK3m+xxkzRyouPUlmiBTeS/rJTAmbiCR5swj4DXxpD1jlTLjblgQ/oZwTy+l wzRidJKkaGNlzmLlUSIiBgLP/tLPwJ3oHlZFZExn/ALAZgpNpEjFZOwzbDVl5LdCHqFs8kPqNMSu Pn9y/0SMaFoI0yGmiSIjZkeJFP/S+kuLNUOEVzm0cz5mzqAEHURHGiDUhjPHtLdOyF1o0haUdFXU lAlUmDbg9h0T9R60nyYF4MbM7umNpMN0rT5k4jF0RUSIymMx6rNtT0yQpLDlnyGG30LCJx/nDNJU ZiD0bUJFWU+OMm102sTm3k/ofmjU5SPMwpmiBVCAAIVUMPwjGrJiHFkllulx9Caulm+QYmtytMsv nILCDVJNVEiHrsqOZkPsvL+oLDlSrJAnzHEGtP3EbEvP5wQJAuoOkGrJGHEGXxIMWygsIzfVg0/C DpcEIDXjGxCyMMbKRM3S7jkDRSDMcIcI8Gxm+JeJnCFHmGK1sSEB/rMDWTWstIuNsTVjtT9K8ror sjZmoJsyEjeGOstVRiK1JGUszGVpxRwShJNxCtFGrkaoaMjCFMs1m1g1SnyyAmV1NwLieh/rxJdj 11vjGSnyDiFJJF21C1TMqIKSgVYGrkYkHw/m5CBmuqZQFGwCDyD1diEm4yXk5s82KLoGN1VMmTEJ EG1tKjwKXKNNfWPFWmcPz10EYTNE21ww7IVLeWHOVHkDUM3iFS7zIVJjbScjf0ZWfT+oLTp2Ezgw 7N81YWj2ikziLn4lVS8Gd2w2JHvEzxICBMvWNOYsSMJNnFXFOHajarBNV1jyilViHp4VkibWuMsG tpdVA0uvixEptlGpt2uHZ1Ir/R7JUmrk2t4DrgRSvCGVUNWHA2RiEtBHzrNj0OmT4OpIi0rFTjYj 9NiWgCGU4iEs8kIHAjZj9SyzXUUns1lVTCEVUXciB0vGpWqCFLdEDjrJtTRDG1O3KM8CB1S0TUMp GUojSmenlIhloMLgAElmBCL3HMqiGLsnACDugXFzWSBI5GWSZ3t0rXusM34VLDsglBOXPiDqM3Ki cWuHzx1V02o30y1qLWZt41/JzXJUCDXFrytnLFQ13rVhtx/4B2UuMXf1lk0SpKB11vQS0NvVwVqs Rs7M1uOsJER2RjlUHSQvIrc15riudpG3Qj1lFN1IupSz1Q12EWjyZV4rwVPzmYcF22G3AS2wAlFy my/uOrEMTxpDpyt0IiHJWoTkKYAVRpBgAPnYUrP4JjboUV/kBiBOm4GvwjPEhTtWPYEXDTi2cX/n hG+PM1XzKDz1enPIU0EXC2dp/Tr2iGLrlkGJg2ZjwY6s1LmzEIf26Fltuy5WaR4SET8DOuc2dpN2 zT7nTtuiGZAS8CBs006yoJGkukrT7V2CGYouPQP2XpDleDlZEz72E22GWKFrRkLYqjfn/D0WS0pv qFlEhJ4yfHoEHFD0p2kDPT/1cWy0CTcJkoOs7wy2UIVWIWhiFVnDf5fyElSY+DPK90F2vMpWzCb0 ariXJiBncGNgwP2DptACb50CKpjRvihmJXtEcUkDBAPZyuFgpDyRHwZiFlNhttZCLJOvvgHZ75oN wOkZ+hQBORqZgjwzboY5tuTK86CE5aERqFwmpD0Z3rzxCzbjzOmkjOTg9h+r6QP6KLcpbUG0aufA WDA0B1XGby1UvJhJjXniG3hEQKZVLiKHz5TaCwX56TvT9DwLgREkhpj5bJXQstcgZ1n1jy5LymdF ayVGrDACUrTYksLVb23rVDF6JWelry0AxPR4l0riOrNVfWeicjQhBDsaF5ogLyCV26pCFB+sbwpR XliN7TzxoFGSDa9yKz96/KeX7iJAcB+uSu3ljCUazi36uuaXdE6AdSfCw69C7Hl6eCOMbC5YbmHx 2CnkX62iHYfiIzCCB7RCZ7TCLuxCO7KCX7NiVbXCnH+a5VwCU7DiWKDCQszioEXjVEAPvCBURuhU WkbD26KiGbH4pW31jAALMAZ7Ejz1gjOX3mjyIrFufCQ1ODwbkNfiaoTLIMOLKbCzbARAzjaApH7W 8rFvUwSK93P7ZiXLK7DMqbyOrMa523PVl4r7giKanCN7GiTGqCZasbBiYSoVEG3jRAbsuYrussbW OlEwza1UWJX4kLusLUBn+t0cHbltWK/L94KQQJGbpYMD1u8MWPasob38QsJGZcTFFOtMdjYCXNrv a8HMeEu4IbDFf7Fj4MbMcLT2cUxCE8aPtNtH/EvLWcdCPYFBtmr8T1XuQIZsetWm5bIsWHhSXmdY Wa667GE4MGXtWtscNZrbAJQCU7YCXLJXuCF8tIg8KnzcR7QCVYlRCzQIYn/cH0nCF0EY1ZwDOY8C FLjK7FDLlCBO+7mCC7ytET8NTno2LXo5NcyDVgHLqbNmToTc/wFmNB+rr0DLjtto05uLojXs0uuL oKAMtZIs8dOsvLutt8ZCB9D5i2m4RD0SKbJRLiBLYz09KDAsqBHB+zPHz5N2nmxrhDmdWA9rjH2t ua89YvwLsjNZ1MSdjc7FZvnFVZV2wCEDs1+yuV6OM4lHBaqXo9lD56eAAq/o3pDjMp4S0SciEjAL s9BLkM3K9dKWzHQDQq5d39T42btiVo9olsXr3qZLHy1IIAHjChBXOYA2zSLF6oSOX27WiToFWjma WALlTknP1yiY2uGk4r6rKsF4SCHDKPQpueMsBEKtiZ1E4gcP32Ej33OUy7z6MwXsAr0iBu5N408d YeJiEk5+GJUpFdcGib1r33C+gHPB/3kD2l4eaWYv0ZuIVVMJDTJQ1+neFXl9wCF1O1SjvXRX8Deb ijSXmXs6NDPeNr1tGXzr4YzL8r9j0Xk+F3I6L7zv0bf4we3r5W/lHZ9a0RLEi2C5wuViecWiCsXx B8bapEP8JcfVE6w2B7ZnQD1ewtvsJQolWlPsUcmkFL2cntsvW348ODafJY439HsFEEOrWMhCG8Jn feSjE813BdGVf5ufM4V5ukjWcSFiGcxfYNyNVAAQRN/3qE+/PU9LmGtotlI0VcJJM1P3ZXzCClDa 8sfv2xC1VCC+SzWrhbS25vJc8iEngy8kNY0dAuZWot7sgCBSKR5pxNE4E8SMl9Zm97bCGHr9viCT jKALYiAP8AQOCQWDAAwQY9gAHA5tgBaQQiQZQQeDqEADd+h4ABeBjeLH+LQMwGBaRGCw4brRQgGR y+DxsdQWBQaRQV6wMxyOGtuQTCCv2aQQAxoPDoLx6fwSOQMHQalyiLVKJwZHQWH0OMzKPUAAEqDT uCQuD1KCI56jdQI4LzkANtaP+5WSYBdtnsLh4bzewSOzQW/yilwOhX+MV6uwqDQkAHsNns9z2YYM AUIATWiQSkBcbjfMYmGQO6SSvR0iBdaWiCaCUP89v+WxrS06CjobmOS2bIyqIy6zxbLVrNR/PXbZ 8fkcillKCcGB8x+tsHJw95SeBc6heKx99oJtkq5ZmC9uB4nQSNOQQN40iQmfeundjtPWr0ApbIPK AWQNaBcxikbauj+MAlDWBzmII9Ibsc+CBveMQWKe5LfII8iOoOm7htCgr4QInzjqyg6NBu/IWJAv 6lr6gkQus9UIIanBHRMfaBxUgbfH7Ej9Rag0DCkHTowlBYNseg0Gwk+cZBvGiBrk1w9wokaxMIm4 1oNCTGpGDcXgc7CBvpGbvMuucoQQoDEsYAEzNEgcGtKt0VyaqCBxKzr+tWi01yyoEIy67LyRayAA vvHLjxst7puqsjRgA9b9zwg8QvFCqPv6/9JOTTNNP4/xtjRSicKcMA9pO0paDGOJ6wsQTbqezAxM 7HTQDHTwxqamFSFoxzaTYgtUVVCzJ0gnVa1uIhKBmAM4T3Ro9qrTEsIGtagDEg1ZqZG9j2SerLVG k7HLIicFlCv8pJHFr/KCglkWVHMsXKwEYPGthBEFXiCWqjL8qSlavXaG933AqqCXIhqUWWlKDXyl 9in6UDfW3d000ZeIHVOgt6VYgi5n/hagA9hwA4HhCUMeIgHCJTCD2mgixMwj9pILdM6ItZdSK9aN VIJeyD4o45KIKylw5Qnw9oxnKDVYMYHZfj0LohTo0VtTeqU1WlP6rrOg1kg+pVuoFdTdrWxoMv8h JYAIHDHhC2KAotZNBYqljWNY9nqmaCW/IsHKJtWcXPfbOWJry9oLuzbSnsjLoM32vohxSU7XCrUr bnkxtc2EoykvSRSxu7bzTRvIUyP+0tnk6VKAth61Y6Umte2Kf34ldaIJFvENzeCwrSOK1Klyyadj xyXgdum7J13NdqcnyWJ13nfaC6Tw0m8r+Tn0fsez7Xt+5qsthYIly8EoCN1VR6sL1qgRbKr3QoN8 zOp0t69Od7qYfglbz+3fh9udzCg37QBgER5/oOHEj/UGbJ2z+U1HNJGdI6izCYD9Diflp5lSRqEA 8wgl4lEDBibwAA6iQyvQUgs/o5B/kAP0gFC2F0L4YNaSZDGATWIaEvX4neG8O4eQ9h9D9sYaBtq2 frECI0R4kEvO7ElyENomRPihFGKUU4qRJWDFV7EIHIQziwcllUXUHEljBGBoEY4zRne1FdTMao0F ecSeOIsbSRxsjk1RRMdYog4jwzuPcfVztahRDt3TikeRIH66VAqVmySBfY9ePzeWqwcaqocr0X5C w3kvGOTKmWfQDM5DoAAYyNSINEWmIaoyDyMhiso78YiCBgFkBcB0ZQAIQCUWkgrjpVQXb4UCL5L3 ztVdmZgbbnB6s5O/EYP8x4PJQZwJQlZhyLPDIsdaTckQbwVjoiIfoGx6y7K8ZSWc0SvSSKAP8u0Q iDS0Nmi0OMSCIy2nNFgATo3NQtmGcYAExpZpWlYEo3K1pZwxlGHtFQoAbhKjuU4FksglIfDEZAWg oIKrYPKGM9JMJgwNSpQaRSNTkSdJGQsf4UluLSRM/ksUopD0GaDQog9DQHUPhehlmJA4RmQILQ8G 6Wy6TaJzNQgtJh+i0ACeSQZyCnoPP5RQ/M3yCMILotyoyO2qmjpmg80dTy8pfUzCqIZP6PAODFNt GtWpcpSE4XMxCaqwmlQWQuhqHKIqkooasDw+x6luoyZBl4AEdr9hbXmvcoXFVkoRTA0tEq7tUo2g icVgC61Lmu5AjTD0CsDQ2QWx4AJpVeIGjQzoF6Ml1eqACG1mA1hEIWDc6S3lrMpBumYiM2bCq4Y6 28lx51JR0fcCyWNsraGdVSTi0dpVNuaJ+t5XQDqNljI+qmb9eW3GdWUeYt7UjB2rbtJm4QoRQ2tI MrdoTtpHKaNHZpZl0i816IyYo5BlrM3dkrbO8Boyc3tLdaRJxrygNXpYduj5bzAGRuABdgd4CCzv I7YS0blzXhiQpN+T7M1M3OuCwQxotH4lMr1ccxEDCs2XACX27trzS3hw5bZmhaQbzgl5agwhipCy xIIFKz79ryyvIOLIgxGKRYfxhe9p8b6olvoArlmRDqi4KAA88UFXSXmwVCeeJ097oEFx8QUw8t5s lqK7kIWT01Nz9xOr0gmWzKksvCX3BidIuEvYpOlWzhQATNlNJQrBziwZfyiB5W5XSamYQXhSyuci sEGRUZS/LG7/S+cJTakRI8crSLzg4AGaiB6VIMp4gpvsBo2LJltEOOSfuOy2a7I9p04qawPkzTdB nn0WIHmNM5nROTpn2XttMHtWmzUYdvBwF9bFA1wed0uZicytZuzLH8LqWoFWjCKVLCivkvxdc+P9 htuGN2lWVBJFtplkH6HWtJL3NEVMopKkSjJAl/K6wiv5ydvigRCorAxXatBKJQ46eenyDn/IKlVK 5MFMERDrVy6hA1Hk1SjUelNSW/6/etTe8x+0yRuQBSymzTivceyeaAkAHkyQAJgnosi0Volk31ll UGDgbgsKaaM4PEcLNZrEjY8mcd53nshwWkChn32hWXz0stYCCB/rGvmhUI+gcugELQbYM6G8iyy/ UhYM1rbhCUkQUVbR6iy60X3qXVCk6LOBttYZFtNWGT11/X55zKRx0yZ0o5SacBj66BvuDVOtEdRs XtBYtBBGWZeDPLbjrkEvOt20lHVeujo3/X/H0hT4FZzVnGszYDha1Q0y1RvfJf49V8WbIfUO17X9 EA7xGRiDd/1aaBm2M3Fkk9gABvBSROd6SIvcg4Uj59iU34UfpciuvuhCefvsGSC9/iH2WuZAx0HI 9u0/5X1BRdk4YYn6ZI/izoAuHt9z3S/uJPmqUyo9R/lsAcQkGZeklj1fOYkDditsZRAAEQIhfXEh jLohQnMMolUccLAFoVUAuBm/0IKCI6oH2SmxeFAHqKkfqMY/gr0BYKkDGSI/q2mOS9gaMVAIO/YD A9YKai47wnC1W+qLEBZAcaMH+kuPqWw/jAwNAPWoU60VuH2oSVIZ0Kw4kP4Fof6MtBHBK1W9ASI/ sKBAS/2Lg/6vMfbCgAAo2PWbEK8vUKqi4MGJRCIIJBKM6vcxiII+q9Qs0DGvUJHCG/Ubas2tAl4/ qbBAPASQcVPAZBaY3COJe+qUePOz06Gp2fktCZc2w/WllBIhc70S6P8vVAkLM+MNQgWBuqg9AYST OIIRUoUKTDOmkTgTgr+7/AEWEQ40tCYlS5uLbEaqjEeFoSEXNEqeiNmNAH+YOJOdYOcNQ9YyIwoK S5uYYA3AMO2vUL69OxiJ/F3Bspc8QMGG3F/B8MA9cLLFsThFwBmNBF5E0IXBu9Y7aJHCaIiRsCIF DFmxg9YM4KWPOPWoNG2k2vUQk/MVCye1Y60VjGmP8QZDGL9DlAVEvA6IseBBQ+qPM/8SIpcfuyjD m4qKnFRCBHNElBRD6K8WCKzHAIwkHE+heBnF+AvD8h/I0LAfWWk0KcsScw4Ac8SIM8WvOo4cVJIK WRIM2MSQYA2OlDI/8Nm3gLHFsmvF4PS0mqGO0II+WAA7/I2A2BExenPJUIsRDGgL9KamEtIDiLIQ aFklEazKO9OFkw61YTaKc9ak2UOPg67KxGceA9qKBKlA2zSJfAjARKFIyNKRySdFm882cLHLVH6P Gm+Bm+yP4DHIylAS+oQna7uMSze98JHL2+yiGIG+qfWLaoQbtJGING4keewJO54OrL/DzDEh8r3B qQ4/rM2IOCUT0ym62h3HaPUG3KwiNDQe0UPGIe1HQdHNZKQ3+hg04KmScyIcdCBLZAQ/0po/yAdH FI4aojfDIItCZOHDaABMfAjMwOCr+qFMtOtOvOwU1CVOzO4OO0eh6PPN/O7PHPJPLOtOVPNPTLPP AAdMW/RPVPhEDPjPnPpPrPsOOFEZSDHPFPuj7P5P7QBQDQFQHQIcMMdLINLJMKBCsQnQLQdQfQhQ jPjLGxeAupsJfK0KBJ8K86NQlQ9Q/RBRCilQYbHKeNK/HRFRTRVRXRYgCi+SYDGzIPLK2NWP+PWS mE4BY5khma/DRLzRbSBSDSFSGJhKwEcPI8KEpLma28UDGDQCkD2A8SmAe5k0ALEa/KE27SJS3S5S 7RYfyPpB+khD+7WDHGgLEWXDRP/S9TZTbTdPSd0cSOsYQjeMSFk0ANuK6QtOPTfT7T9T/PIkDQ64 YIMT0QlSqM6anHi4pITUBUdUfUgjbUFEsqGZkMY000A1YCUkpQ3UjU9U/VAh2jZQ6m+w4KkA2P8D GAuDAUfTwG2ACg24YDA/3O2dFVDVvVxVyhfVGmBVMVnVUISAegWv8PJMWIRV1WRWTWUkeWjUHWXW fWhWjNcCVVUE5RRWlWxWzW0hcG2BZWtW3XBXDXFXHXJXLXNXPXRXTXVXXXZXbXdXfXhXjXlXnXpX rXtXvXxXzX1X3X5X7X9X/YBYDYFYHYJYLYNYPYRYTYVYXYZYbYdYfYhYjYlYnYpYrYtYvYxYzY1Y 3Y5Y7Y9Y/ZBZDZFZHZJZLZNZPZRZTZVZXZZZbZdZfZhZjZlZnZpZqOSICAplbmRzdHJlYW0KZW5k b2JqCjEwIDAgb2JqCjg5ODAKZW5kb2JqCjExIDAgb2JqClsgL0luZGV4ZWQgL0RldmljZVJHQiAy NTUgMTQgMCBSIF0KZW5kb2JqCjEyIDAgb2JqCjw8Ci9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dp ZHRoIDEwNgovSGVpZ2h0IDI3Ci9Db2xvclNwYWNlIDExIDAgUgovQml0c1BlckNvbXBvbmVudCA4 Ci9MZW5ndGggMTMgMCBSCj4+CnN0cmVhbQqAP+BQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRh9P l8up0up9vyQv1+Pl9Pp/P5+yuSSR8RuTSaTvl9vmUv53O94O54PGOTaUyGRPp9yx+yqbzd+UuSPy SPuBymjymBvB6vFzO10Oh1uZvORxO93u58PmyvuoQJ7Pd6PCdud3OqnP17xx3PN4yykyl9WWlSui WmM4PCYXDYV2Ot2MBisNvOJuMpnstWrpatJmMloNhotNtNlesZfMNirhgMZfq9krmivxyVtttxuL BXqx2O92uZ1OhrtNpL9drRitBkNhytlptlmMdps5tttst9wN9mtdrr9hr1vNttQNitpmqlcKRSLB RrBeLZfrxas9sNB1O12wNwuFuMRmshXsVfPW1m4cRvlwYJfluYZdmob5rmMZ5kGqZ5nm+bTYnGcJ 2HieLDw1DcOQ6gp3raYhqGab5xG0bhwm2aLenYdR1GOaBmGUZpimoaRpHWjyvnCaMJJudB2HScRy nGY8Gnkex5Omb5iGIXhgl4XbNmuZpqmSYxmGWbhwG6a5sGmZRpmZABwk4TxKmaZ5jIGbJwm0Zhom EbBvG0aRpmiaMbG8c5wnkeh3oGcxynMaxvm4u55JueB5Hgb5wm8RhTEqXxkmEVJVlIY7UG+6RwHU ch5nqeUPVJUtTImvdU1UsqXr6wikJWfibpYpZ9sDWih1slieHaeh6nmqNVWEvaDVTYqUtudy1nuk 9mn0o1iVPaVp2patrWvbFs21bNfHtMJpHOdRznkeZ5Pk252nWeJ4Heex8Hsm52ngc52rieZ6Hon6 l1klJ0q2ez/LRW1bJvYKcHedht0MZBiF0YRfl8YxkGEbb7HOdh0J0ddt45juPMHRZ5Fu9ZfGCXs7 GgYzURoYJaluWRf0qm8TmfMJnGSZxnFoWhYGoapppubZsGwZ5qGmYppGUZZomQeB5ncmigH8bxum 3oxllkU5PFiVZVF0YZcl3SpomwZRwHIceP7Vte2IUoh9HAcBwrAcKtnKjxynqeh5yHQTdpvRxvmg a5qnMc5zmiaRom8cJvrEd/GmybpxnAapvGuahrmKnh2Lqe9FJ63DFcPDB5HGdBzHje56HseZ4HpU e29l2eP32X2IGQYphGsapnVqbTHmCZplHOdBzoGchznIYZeGLAhgYEb6vGcZpjpYZprGiWZflWYR lF0ex7Hp2nyfL8yGJYY5iF6ZZmGNQptHSj5rG6bpgmOYRpGgZyWGybQ1xmDDGWPJDBNxwDmGuNAa ozR1DuHYNwbI2Rhn5Ggio/z43zwZg0+UpS+1akiX2TcmY94SKzKMVMfxAyjlGg9CdY0G4YQxhlDO GkNYbELLQPwx6hkuDeHGOIbpnxyDkHK+EexIR9E8HWotdZeB3jyYwOsxQ7R2LlSQ+Ekw+D/RWHcP Vd5rSbjmSCWNeS7C3DvViRwe5Yh3DlHcOiEiyy1j4HuPiOxP4Vk3HuwCBsSy2jpHYOEmMBHXrlhE SccbaFmlzVSqxRg747R0HuPUqUIISD4g9JmPY9l9xpjoU2ExTS5l0XeRwfDBSBMCjiVsdI8lflNj qPhcjqh5JIHqqIeK6R1jpJyOwojUl9jpioYkdS7DcLpdRIKOq+x6yTjqPVWJFS1j2F2MMVorhciy FsL0W4uhbC0FuLYWo3hvjYNuOkYoxxejBGUMqCaMBrjJGCMsY41hsOEcUMoZIwxoMpF+L8WotRXi nFQMAWo4RzDkJYNKBI2BrDUGO7kVgshOr4HgNwbQ1RZCzFiMBph2BZiuFwLEVIqhRC3FyLkZwzxj k8jhHtGQxhsjeK+Okcw1RrDPGtRmjZ6Bei+hIPccw6Byi+GALgY9SRgDOGUOwdw65mj1gEMIYdER mH5FqLMTReB3IBHEKwXNWReCuGGMYWw1RsjVGQMgYc+xijNGaMR/Atm9jyHSYoYo0RmC3GAKcXYx hgi4F8LaqgwJaj0JYosdxshsiyF4Lga45BvjssoMt/QshYCrFYKoVYsBXCqZ+MccY4xvNGGkc4ap QhxFbFULcV1V0ZtKTwMgXx7CxDtSQPMZg2mcjVGC6EisSDpDXoQONw46HeDUHK2heqFy8DmtGONf w7Sxn+HqOuB1d0XIuXKPAsEB20PGHQNSjETx3L7K2OYnaQaiDlHKNwtA+m9j0Nea8dQ4xuopGo0J GLShkTqF8LB5Q3mBtyHGOoxI7x4xvikTxyB9TnjakvLceo51BjRG2NUcQ5xzK1JY1QbkiRykfHQN sawziZxMGeNwagyBni6GciMcEPxuU0N28q/A0xnjNj3UIdY6BkjRGWM4aIvBlwLGkNUaR9RwxUvO UtvQ8ns3KpsXOOo+U/DzUGOQ2MEBsDULM+IvDkhsjFGeNAlhLx8tnHCNVwg4kuDiiBe4co8VGH+H uNZqyix35XIqYEZA0xoDRGyNYYAwxfi6PS+EemdklDkHCLkZgxBpjWGaM5pIyxqDPbeOWojiRmHb G2M+vSnBwqxSGN4ZTihWi0FiLasOg0xjbGvWka5MyBpAHCMcZYuxnDWGkY8cVOGfZKQeMyMxQmzq DHOOJFeehvDcfqNoag1E8DRqSMQZBYBypeatl8ZAzBgOTHCs09YuBkjKGPTQbo06cDWHANkbaXG5 jaJuNYbI1xnP7Gsnc62GBrjaGVVcW4whgi0oBjPW5GxmINTvkIZQxhlJOXKVgcw5htGQG+OMaxX9 4qGS2dsbQ2CPjqJYNsbw2Bujk2jywbA2Rmk/WWxUcCJxsIP0ChB1Q8RtjmG6VwcY1RsDNF0MUYA5 35EVKmNaeygivbRGIMUXkpicjvM8NhSgxchn8n2jcajrB7E6HaM+eQ1HqDS2raschKh+7SG5ZYaI vhei/GCL4XY0RoDHGUMIXwshWimbqn11pih0DBGYMVnD1EId6GKcuf4thboVHAs0bzckVjSFCK0V YvRgDEGZ5/dw1B5uuzg5Mcw4Bmp1kSOAUYshVaa04ScYgwqPDOGXZIbiEBkiqGBSIYosxijGFgSw Ye2he98quMkco4hvUJHFkMZYvPDi/GQLZQQ2yWU7GrcscKARtC2FUKZdY8Bt8sNCMMZGvRaDAF0L QXYub8jfGKMQXw4j7SmFWzwYyYnJDWFsFsFWV8woW8rWFgFiFKF2FkFYFuFiteGqgUGyGwHEHIxq vwE4E+FEpoHEIqJuI8HU/sG+8qROO2HAToHAwsbqHIVqlcT+HcHceUHIoSHIluHoXSN2I8bejowq HSHIvy5qG2G64uuWSI6QLgPkHQX8HGHWHOHqHyHumYj2nucIN8iJBKG0G0h+RM0gKFCQoSUFBKbm bmqCYAHsHQbQGqNkHcgIluHkG4UMbvCYYAKQU4GycoHCxuHDBgHSHKV8lcVEO2poGyG4lqHiWaHK OkHXCOqeN0HCKWH0b0uurukkLcHciIHIcwGkukHQG+T4HGHK8qHIU8sokiJZESgagcQwHiG7CGK2 YFCQHSLEHguXAmQqluaeRaHMX8HMRyWaHaHiHeGc0EGC0O9mGCU4RQzkVsH0IYhyFgs8+KnYGeP4 GKbCm4GUQen+FylMYqG8GAF4F+E+E6E0FwFwFmp2aO6MGKRmXoRcYwTSGQp+F2GequoY02Oa88GI FutqFGFms2FIE2I8HMk2IGGMecFuFuFgFOFcFGFYFYPPHKFyGWGEJCH2aoG24GGQGSGOGSFCFEE8 PqG8MUHUnaGQE0FcFSGSPzHUGIFatcvyG9FSJuzI6ifuOW4KF4FeFSFAI+vUJ0FXIYGMGGGGy2Ja GgGWQYS+F0F+FwFCFGEk9GHiHQSGZqGYn6cS02ra7qqOFWPSFOFYFCROGkFlASGMU0J2HcJuF672 FgFuFWGaGiGcF8GOGAf+GkV8HoFSFaFPHCE8FsF0Fk3kGsJu2qGkFyGOnmtOb0HmHOx+pCFeFmNo UuFAoYGeFsF8FcioHSfQJW1oGuMUHYgumEHSzs0cHijsHuJYmmHcPkRywQgcHYHgHXE8HEVCHozU KELMlkgIkimafEfFF9CWx+uMh+Oeb2HmkmHsIGmaLaHkLGLcXvOagJNgHaJvNyjOrqcaHAWXIoVY Hib2fE0azsXwdglrNXOoJTN6VC9Gb0HRA8X+hIKaXLNqlufCIGXIXKXwicRcHSJZGUkmHqbQHNNq jqdaosXWwWHYYEwVNWRaLGHUJuYub9BmYAgcHUzEussyFU0EGel7PUJuT8HoHWuqluYEmm+YHBQO HGuggamKHmHeJkIYI2H0qoeEeyYqGuGk3zCmF+74FW/ZDdJCeMLEHYhvSKhmg6X4hSY+KFOmieHY V8HmM82qTu8MGIe2F2s8FUbQHBCdOTSNS/TAY4WHTGKkJWJyHal/TDTVTXTZTbTdTfThTjTlTnTp TrTsIyICCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKMzI4NgplbmRvYmoKMTQgMCBvYmoKPDwK L0xlbmd0aCAxNSAwIFIKPj4Kc3RyZWFtCv///2FsPlMScmxf9lOex1Dz2nG21iTcl61ZGgoTCdDA l5YiBNR2Fkfidj02FASGCN/4vrYcm03J9WjTCHGkyAk66g0PYCRWQ5qTeq+YAbd4+XYuFhF83wbk sw9WWNdgk8JuoiOS+WctjeLdJeOVntwLzPIdSNIkLIYzg94L43HOURTy5A1aEpo878AfhF78kCrv rXLC0p9IBiInEQaZ4Fit0jy7LU5VaT4WicJ0hVOedQARN9OxgNnUp+vaQMsz7p5vqcu+/zX9Fb7A iUQTKLkUOvDn63DAvxismll3zUcWPfHh/PAX+QXVuo8ZzbfS4fHDyN00iZ1MNTelrQXtw0LepT/O vDnUkfNjq8AbfqENQmrqdvOHwym/aNbEVpoHND9GA/t/2I1zOzkzV7fVZPlAT2801zNdlps0W/HO YiYOqSoJKQKXnD7Q0JWIpvqB5knxGiEkeLjArROye3bZiR8Dk0gGKuVE+7Xag1vUBUIe91w/HNX3 3IIKj/2AaIegbBvockXOtkGDkcXfZcohg8F9wt1TurrVxEnTRbJb5h52z5G8nUj9INnC/z6NIMJO noQs8T7nxwMxmknj9TACa/+TJ5zbJb21573zdN21w3w68G551zV9CNDG7MX27jH2glmSXX5QEmYN BtrrvJ5n9o/Wb2YL7W/bs1yhqkrSoc0rMyqqhD0QkUTqfACJ5PcYumd/xVTvoQhLQ7OWFVRjQYiO 6wzM+50Q5hkRcP4IibhwCH7E+B/MQ2KA2njUPbldzKVpmKEHqYghuvgfw4HXM4pV+IJ1xcbXRaBQ Gt4Kd6qv4ENR6OzZCafRKGpT/57dVZdgylwmoaHH8bym+zNQqxST/PyA1QUnpy2S+y0x2ILIOUwk YO7GJ+CCzdu2HofKsoPGMlnMWQH66/wnHNWq5Q72Cm/l0JfFU2WhCoMo1DWsm2gGaMEHYq0EicnZ M6/oKrlXD4ru1N5UdejXnr0NS1l1UcE3WSPkXa2uN+BdIAsWeBqgZu9/u2VnkgMloE9+FgplbmRz dHJlYW0KZW5kb2JqCjE1IDAgb2JqCjc2OAplbmRvYmoKeHJlZgowIDE2CjAwMDAwMDAwMDAgNjU1 MzUgZiAKMDAwMDAwMDAxMCAwMDAwMCBuIAowMDAwMDAwMTg1IDAwMDAwIG4gCjAwMDAwMDAyMzQg MDAwMDAgbiAKMDAwMDAwMDI5MyAwMDAwMCBuIAowMDAwMDAwNDk3IDAwMDAwIG4gCjAwMDAwMDA1 ODAgMDAwMDAgbiAKMDAwMDAwMDU5OCAwMDAwMCBuIAowMDAwMDAwNjM2IDAwMDAwIG4gCjAwMDAw MDA3NDQgMDAwMDAgbiAKMDAwMDAwOTkwNSAwMDAwMCBuIAowMDAwMDA5OTI2IDAwMDAwIG4gCjAw MDAwMDk5NzcgMDAwMDAgbiAKMDAwMDAxMzQwMiAwMDAwMCBuIAowMDAwMDEzNDIzIDAwMDAwIG4g CjAwMDAwMTQyNDYgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSAxNgovSW5mbyAxIDAgUgovUm9v dCAyIDAgUgo+PgpzdGFydHhyZWYKMTQyNjYKJSVFT0YK --------------030701070007080406030705-- From jzisn@poplar.ocn.ne.jp Thu Jun 28 22:03:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45p8-00062I-KC for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 22:03:02 -0400 Received: from [123.188.187.126] (helo=srocjo) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I45p1-0004bd-Go for nemo-archive@lists.ietf.org; Thu, 28 Jun 2007 22:03:02 -0400 Received: from oepui ([53.112.217.227]) by srocjo with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Jun 2007 09:55:48 +0800 Message-ID: <468466A4.3040801@hibr.com> Date: Fri, 29 Jun 2007 09:55:48 +0800 From: Guerra C. Sibil User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: it New Exhibitions in Northumberland New York Tokyo Do I challenge art traditions? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Everyone Is Watching SREA! UP Again! Score One Inc. (SREA) $0.41 UP 2.5% SREA continues its steady climb for the second week. UP nearly 400% in the last two weeks, Stock reporting sites across the board are issuing stock watch notices. Read the news, look at the numbers, and get on SREA Friday! World of Art is a trendy and sophisticated global art publication created for artists, galleries, museums, dealers, art collectors, who seek the latest news and trends in the art world. Made by Asbjorn Lonvig - as usual. Read the message from the Board. The competition is judged solely by visuals submitted online. it New Exhibitions in Northumberland New York Tokyo Do I challenge art traditions? Giancarlo Alu director of Mantena Museum director of Mondial Art and Culture Rome Furthermore "septimus severus", "san francesco" and "piazza san marco" were exhibited. Read the message from the Board. World of Art editorial offices are in London and Stockholm. are you sure you are not Italian? See the Swineherd, two of his pigs. Secretary General Lars Seeberg has resigned as Secretary General after mutual agreement! See editorial Logos Sculptures Portraits See below Storytelling used in companies? Or, is it the princess? Or, is it the princess? I have no words to tell you how much I enjoyed your art presentation you sent me. It is built in solid, rustic materials where close attention has been paid to every little detail. First you must install a News Reader to handle the RSS news feeds. The five winged building contains gallery, studio and private dwelling, including office and library. Giancarlo Alu director of Mantena Museum director of Mondial Art and Culture Rome Furthermore "septimus severus", "san francesco" and "piazza san marco" were exhibited. Read the message from the Board. Secretary General Lars Seeberg has resigned as Secretary General after mutual agreement! Made by Asbjorn Lonvig - as usual. See editorial Logos Sculptures Portraits See below Storytelling used in companies? We hope, however, for business as usual. See editorial Logos Sculptures Portraits See below Storytelling used in companies? are you sure you are not Italian? are you sure you are not Italian? One of those are the Hans Christian Andersen Festival Plays in the Village of Funen in Odense. World of Art is a trendy and sophisticated global art publication created for artists, galleries, museums, dealers, art collectors, who seek the latest news and trends in the art world. com A well designed online gallery in Piazenza, Italy BabeleArte. It is built in solid, rustic materials where close attention has been paid to every little detail. Made by Asbjorn Lonvig - as usual. Editor and Publisher Petru Russu. According to the Chairman of the Board, Neil Kzokoss, Chicago Athenaeum, the house is located "in the middle of nowhere". And it might be the emperor to the right behind the fence? Editor and Publisher Petru Russu. it New Exhibitions in Northumberland New York Tokyo Do I challenge art traditions? All of the artists participating in the Awards go through a two step selection process. This competition seeks to attract artists, galleries, museums who are redefining standards of art excellence challenging existing trends and tendencies in art and culture. Lille Fejringhus Gallery Probably Northern Europe's most fascinating artist's house. We hope, however, for business as usual. Editor and Publisher Petru Russu. According to the Chairman of the Board, Neil Kzokoss, Chicago Athenaeum, the house is located "in the middle of nowhere". From mext-bounces@ietf.org Fri Jun 29 17:29:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1e-0004n0-Vo; Fri, 29 Jun 2007 17:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1d-0004hb-Ee for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4O0j-0004Xn-Uq for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5TLVjTL026544; Fri, 29 Jun 2007 16:31:45 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Message-ID: <46857923.3080302@ericsson.com> Date: Fri, 29 Jun 2007 17:26:59 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2007 21:28:12.0270 (UTC) FILETIME=[6569B0E0:01C7BA94] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack hosts which > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. Several > proposals exist for such support, and some of them have been > implemented and tested. > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, selection > and modification of multiple simultaneous tunnels. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. > > The WG uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather document how to use existing > mechanisms based upon preferences or policies. In particular, > the WG will consider that a tunnel is alive as long as packets > can be exchanged with the corresponding peer. In addition, local > information, such as interface up/down events, or other failure > detection mechanisms can be used to quickly detect failure of > tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO Basic Support nodes > and nodes served by them. > > After gathering the requirements for these types of deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. Similarly, the group will not consider or rely on the > results of general routing architecture, Internet architecture, > or identifier-locator split issues that are discussed in > separate, long term efforts elsewhere in the IETF. Finally, the > group will not consider solutions that require changes from > correspondent nodes in the general Internet > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow extensions for > experimental purposes as well passing of optional vendor-specific > information. > > (B.3) Finish working group documents that are currently in process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 29 18:34:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4P31-0005Y7-TT; Fri, 29 Jun 2007 18:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4P30-0005Xc-IL for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4P2u-0004To-Kx for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: (qmail 44804 invoked by uid 60001); 29 Jun 2007 22:34:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ymMdslFbjk2WgYIVQpqTM2wvozSG9Oa1E+vWdFSCsPaimUjJBvTx/IwkjtLZQU3UzZd1vtpnJKEmlDiQum14CuoQTo3ODRTsUklbsrZ463zgGtr+hN3D6neLH4k9pT3S6455mw8120U8Nnm2XxfAN5zQQTZSF7ILa00pfibCgck=; X-YMail-OSG: DZWOWDEVM1m1TSRnjz.7zH0hyQPweR_nrJzLGQBjkXD997R7boesSbJtUBP.UK9S5Y_Tsy_Ce9WOFqYh.D1vi89YLDPv34mXrgsrZenAxLVp61TXUew- Received: from [206.16.17.212] by web84106.mail.mud.yahoo.com via HTTP; Fri, 29 Jun 2007 15:34:32 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Fri, 29 Jun 2007 15:34:32 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [MEXT] new charter version To: Jari Arkko MIME-Version: 1.0 Message-ID: <84929.44768.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0222891421==" Errors-To: mext-bounces@ietf.org --===============0222891421== Content-Type: multipart/alternative; boundary="0-1884647686-1183156472=:44768" --0-1884647686-1183156472=:44768 Content-Type: text/plain; charset=ascii Hi Jari, In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter. Kind regards, Behcet ----- Original Message ---- From: Suresh Krishnan To: Jari Arkko Cc: mext@ietf.org Sent: Friday, June 29, 2007 4:26:59 PM Subject: Re: [MEXT] new charter version Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack hosts which > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. Several > proposals exist for such support, and some of them have been > implemented and tested. > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, selection > and modification of multiple simultaneous tunnels. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. > > The WG uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather document how to use existing > mechanisms based upon preferences or policies. In particular, > the WG will consider that a tunnel is alive as long as packets > can be exchanged with the corresponding peer. In addition, local > information, such as interface up/down events, or other failure > detection mechanisms can be used to quickly detect failure of > tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO Basic Support nodes > and nodes served by them. > > After gathering the requirements for these types of deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. Similarly, the group will not consider or rely on the > results of general routing architecture, Internet architecture, > or identifier-locator split issues that are discussed in > separate, long term efforts elsewhere in the IETF. Finally, the > group will not consider solutions that require changes from > correspondent nodes in the general Internet > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow extensions for > experimental purposes as well passing of optional vendor-specific > information. > > (B.3) Finish working group documents that are currently in process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1884647686-1183156472=:44768 Content-Type: text/html; charset=ascii
Hi Jari,
  In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter.

Kind regards,

Behcet



----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: mext@ietf.org
Sent: Friday, June 29, 2007 4:26:59 PM
Subject: Re: [MEXT] new charter version

Hi Jari,
   The items A.2 and A.3 are reversed in the following descriptive text

"Deployment considerations call for (A.1) solutions to enable
dual-stack operation, (A.2) allowing the use of multiple interfaces in
mobile nodes, (A.3) mechanisms to support high-availability home
agents,..."

whereas in the following bulleted list A.2 talks about HA reliability
and A.3 talks about multiple interfaces in MNs.

Cheers
Suresh

Jari Arkko wrote:
> Testing the new list... this list should have all the subscribers
> of the existing three lists. For now, please continue your
> technical discussions in the existing lists, except for charter
> discussion which we can move here. In general, you do not
> need to take any action with regards to list changes, once
> we are ready to move complete away from the old lists we
> can deal with the from the secretariat. Here's a pointer
> to the list page:
>
>    https://www1.ietf.org/mailman/listinfo/mext
>
> Here's the new charter, revised according to comments
> from many of you (thanks!) and the rest of the IESG.
>
> The charter will go out soon for public IETF review.
>
> ------
>
> Mobility EXTensions for IPv6 (MEXT)
>
> Chair(s):
> TBD
>
> Internet Area Director(s):
> Jari Arkko <jari.arkko@piuha.net>
> Mark Townsley <townsley@cisco.com>
>
> Internet Area Advisor:
> Jari Arkko <jari.arkko@piuha.net>
>
> Mailing Lists:
> https://www1.ietf.org/mailman/listinfo/mext
> http://www1.ietf.org/mail-archive/web/mext/current/index.html
>
>
> Description of Working Group:
>
> Mobile IPv6 specifies routing support which permits an IPv6 host to
> continue using its home address as it moves around the Internet,
> enabling continuity of sessions. Mobile IPv6 supports transparency
> above the IP layer, including maintenance of active transport level
> sessions. In addition, NEMO network mobility mechanisms built on top
> of Mobile IPv6 allow managing the mobility of an entire network, as it
> changes its point of attachment to the Internet. The base
> specifications consist of:
>
> o RFC 3775
> o RFC 3963
> o RFC 4877
>
> The MEXT Working Group continues the work of the MIP6, NEMO, and
> MONAMI6 Working Groups.
>
> The primary goal of MEXT will be to (A) enhance base IPv6 mobility by
> continuing work on developments that are required for wide-scale
> deployments and specific deployment scenarios.  Additionally, (B) the
> working group will ensure that any issues identified by implementation
> and interoperability experience are addressed, and that the base
> specifications are maintained. (C) The group will also produce
> informational documentation, such as design rationale documents or
> description of specific issues within the protocol.
>
> Deployment considerations call for (A.1) solutions to enable
> dual-stack operation, (A.2) allowing the use of multiple interfaces in
> mobile nodes, (A.3) mechanisms to support high-availability home
> agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls,
> (A.5) address the specific needs of automotive and aviation
> communities for route optimisation in network mobility, and (A.6)
> support for AAA is needed as a continuation of earlier work on
> bootstrapping.
>
> Work items related to large scale deployment include:
>
> (A.1) A Solution for MIP6 session continuity for dual stack hosts which
>       attach to IPv4 access networks. Additionally provide a mechanism
>       for carrying IPv4 packets via the Home agent for MIP6 capable
>       dual-stack hosts.
>
> (A.2) A protocol based solution for enhancing the reliability of home
>       agents and a method to force a host to switch home agents.
>
>       A mechanism to force an MN to switch the HA that is currently
>       serving it. This is required in deployments where the HA needs to
>       be taken offline for maintenance.
>
> (A.3) Use of multiple interfaces.
>
>       Today, the protocols do not provide suppport for simultaneous
>       differentiated use of multiple access technologies. Several
>       proposals exist for such support, and some of them have been
>       implemented and tested.
>    
>       When a mobile host/router uses multiple network interfaces
>       simultaneously, or when multiple prefixes are available on a
>       single network interface, the mobile host/router would end up
>       with multiple Care-of Addresses (CoAs). In addition, the Home
>       Agent might be attached to multiple network interfaces, or to a
>       single network interface with multiple prefixes, hence resulting
>       in the option to use multiple IP addresses for the Home
>       Agent. This could result in the possibility of using a multitude
>       of bi-directional tunnels between pairs of {Home Agent address,
>       CoA} and a number of associated issues: establishment, selection
>       and modification of multiple simultaneous tunnels.
>    
>       The objective of the WG is to produce a clear problem statement
>       and to produce standard track specifications to the problems
>       associated with the simultaneous use of multiple addresses for
>       either mobile hosts using Mobile IPv6 or mobile routers using
>       NEMO Basic Support and their variants (FMIPv6, HMIPv6,
>       etc). Where the effects of having multiple prefixes on a single
>       interface is identical to the effects of having multiple
>       interfaces each with a single prefix, the WG will consider a
>       generalized approach to cater for multiple prefixes available to
>       a mobile host/router.
>
>       The WG uses existing tunneling mechanisms defined for Mobile
>       IPv6. The involved nodes need to select which tunnel instance
>       to use when multiple ones are available due to multiple
>       addresses on either end. But the WG does not plan to define a
>       new mechanism for this, but rather document how to use existing
>       mechanisms based upon preferences or policies. In particular,
>       the WG will consider that a tunnel is alive as long as packets
>       can be exchanged with the corresponding peer. In addition, local
>       information, such as interface up/down events, or other failure
>       detection mechanisms can be used to quickly detect failure of
>       tunnel(s).
>    
>       Deliverables related to this include
>    
>       - A document explaining the motivations for a node using multiple
>         interfaces and the scenarios where it may end up with multiple
>         global addresses on its interfaces [Informational]
>    
>       - An analysis document explaining what are the limitations for
>         mobile hosts using multiple simultaneous Care-of Addresses and Home
>         Agent addresses using Mobile IPv6, whether issues are specific to
>         Mobile IPv6 or not [Informational].
>    
>       - A protocol extension to support the registration of multiple
>         Care-of Addresses at a given Home Agent address [Standard
>         Track].
>    
>       - A "Flow/binding policies exchange" solution for an exchange of
>         policies from the mobile host/router to the Home Agent and from the
>         Home Agent to the mobile host/router influencing the choice of the
>         Care-of Address and Home Agent address. The solution involves two
>         specifications, one for the policy format and another for its
>         transport [both Standard Track].
>      
> (A.4) Work on solutions to deal with firewalls and the problems that
>       firewalls cause as identified in RFC 4487.
>
> (A.5) Route optimization of network mobility.
>
>       Three use cases have been identified for this. These are called
>       the Aviation case, the Automotive case, and the Personal Mobile
>       Router (consumer electronics) case, though the actual technical
>       problems are characterized by the type of movements and
>       environments more than by the specific industry using the
>       technology. The group will explore these cases to gather
>       requirements and proceed with solving the open issues.
>    
>       (1) Airline and spacecraft community, who are deploying NEMO for
>       control systems, as well as Internet connectivity and
>       entertainment systems. This use case is characterized by fast (~
>       1000 km/h) moving objects over large distances (across
>       continents). The main technical problem is that tunneling-based
>       solutions imply a roundtrip to another continent and that BGP
>       based solutions imply significant churn in the global Internet
>       routing table.
>    
>       (2) Automotive industry who are deploying NEMO for in-car
>       communication, entertainment, and data gathering, possible
>       control systems use, and communication to roadside devices. This
>       use case is characterized by moderately fast (~ 100-300 km/h)
>       moving objects that employ local or cellular networks for
>       connectivity.
>    
>       (3) Personal Mobile Routers, which are consumer devices that
>       allow the user to bring a NEMO network with the user while
>       mobile, and communicate with peer NEMO Basic Support nodes
>       and nodes served by them.
>    
>       After gathering the requirements for these types of deployments,
>       the working group will evaluate what type of route optimization
>       needs to be performed (if any), and formulate a solution to
>       those problems.
>    
>       If no requirements for those scenarios can be collected by the
>       deadline, it will be assumed that the work is premature, and
>       that type of deployment will be dropped from the WG.
>    
>       The group will only consider airline and spacecraft solutions
>       that combine tunneling solutions for small movements with either
>       federated tunnel servers or slowly changing end host prefixes.
>       The group will only consider personal mobile router requirements
>       about optimized routes to another mobile router belonging to the
>       same operator. The group will only consider automotive industry
>       requirements to allow MR-attached hosts to directly access the
>       network where MR has attached to. Work on automotive and
>       personal mobile router solutions requires rechartering.
>
>       The WG will not consider extensions to routing protocols. The
>       group will not consider general multi-homing problems that are
>       not related to the deployment and maintenance of Mobile IPv6 or
>       NEMO Basic Support protocols. The group will also not consider
>       general route optimization, or other problems that are not
>       related to the deployment and maintenance of NEMO Basic Support
>       protocols. Similarly, the group will not consider or rely on the
>       results of general routing architecture, Internet architecture,
>       or identifier-locator split issues that are discussed in
>       separate, long term efforts elsewhere in the IETF. Finally, the
>       group will not consider solutions that require changes from
>       correspondent nodes in the general Internet
>
> (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG
>       require AAA support for Mobile IPv6. Part of this work is
>       already being done in the DIME WG, but the MEXT WG is chartered
>       to complete a design for RADIUS.
>
>
> Work items related to base specification maintenance include:
>
> (B.1) Create and maintain issue lists that are generated on the basis
>       of implementation and interoperability experience. Address
>       specific issues with specific updates or revisions of the base
>       specification. One specific area of concern that should be
>       analyzed and addressed relates to multilink subnets.
>
>       This work item relates only to corrections and
>       clarifications. The working group shall not revisit design
>       decisions or change the protocol.
>
> (B.2) Update the IANA considerations of RFC 3775 to allow extensions for
>       experimental purposes as well passing of optional vendor-specific
>       information.
>
> (B.3) Finish working group documents that are currently in process, and
>       submit for RFC. This includes prefix delegation protocol mechanism
>       for network mobility, and a MIB for NEMO Basic Support.
>
>
> Work items related to informational documentation include:
>
> (C.1) Produce a design rationale that documents the historical
>       thinking behind the introduction of an alternative security
>       mechanism, the Authentication Protocol (RFC 4285).
>
>
> Goals and Milestones:
>
> Aug 2007    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Aug 2007    Submit -00 draft on Route Optimization Needs for Automobile
> and Highway Deployments
> Aug 2007    Submit Multiple CoA Registration to IESG
>
> Sep 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Sep 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
>
> Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
> publication as a Proposed Standard
> Oct 2007    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
>
> Nov 2007    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> Nov 2007    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
>
> Dec 2007    Submit -00 draft for solution to aircraft/spacecraft problem
> Dec 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
> for publication as a Proposed Standard.
> Dec 2007    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
>
> Jan 2007    Submit final doc on Route Optimization Needs for Automobile
> and Highway Deployments, for Informational
> Jan 2007    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
>
> Feb 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Feb 2008    Determine how to proceed with remaining automotive/Personal
> Mobile Router solutions
>
> Mar 2008    Submit the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Mar 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
>
> Apr 2008    Submit Flow/binding policy format to IESG, for Proposed Standard
> Apr 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
> Apr 2007    Submit I-D 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
>
> May 2008    Submit final doc for solution to aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> May 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
>
> Jul 2007    Submit Multiple Interfaces Motivations and Scenario to IESG,
> for Informational
> Jul 2007    Submit Analysis of the use of Multiple Simultaneous Care-of
> Addresses and Home Agent addresses, for Informational
>
> Aug 2008    Submit I-D(s) related to specific updates and corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Aug 2008    Submit I-D 'Home agent reliability' to IESG for publication
> as a Proposed Standard.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext

--0-1884647686-1183156472=:44768-- --===============0222891421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0222891421==-- From vqux@wpc.net Sat Jun 30 05:13:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Z1Y-0001oh-4W for nemo-archive@lists.ietf.org; Sat, 30 Jun 2007 05:13:48 -0400 Received: from [91.140.141.198] (helo=zjmg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4Z17-0005Sf-IZ for nemo-archive@lists.ietf.org; Sat, 30 Jun 2007 05:13:48 -0400 Received: from uwpcr ([198.43.204.221]) by zjmg (8.13.3/8.13.3) with SMTP id l5U9GpOo029096; Sat, 30 Jun 2007 12:16:51 +0300 Message-ID: <46861EAA.6070204@wpc.net> Date: Sat, 30 Jun 2007 12:13:14 +0300 From: Dolores User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Re: email.pdf Content-Type: multipart/mixed; boundary="------------020807010003020808050700" X-Spam-Score: 2.5 (++) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab --------------020807010003020808050700 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit --------------020807010003020808050700 Content-Type: application/pdf; name="email.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="email.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDI0OCAyNzddCi9Dcm9w Qm94IFswIDAgMjQ4IDI3N10KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQoyNDggMCAwIDI3NyAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDI0OAovSGVpZ2h0 IDI3NwovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr0QOo+YzGJh/P4As1ps6waEELDNZsEEgkr91jZIs8FD7YgZYCzOVMEVQkF8EEIhuzYKkDwF 2iIfD8GIxGgaqVRmM2BAAWCwhdWFACeZ0MxRUaTSIMoIx9y2WkWsgeYx0QIOUguygWczg+3m8VYA ZzOucP10rIhEhnCiyp5G5CwA3kCVe/2cHzCp5kD3e9ACwWAAD4lADkX8CYjEiBE58r6ML88GTp51 sL9vd7/hgS/8sDE39Tr/rsziDO8TZNoGTZHgAIQhAAC4TAAYhOhOVSHvqWEDAAbcDEeaEFgvB0IQ k+aBuY9T1oTAqBw5DwLvNETitwzcToPApNw1BEFQYAD+srCgAMugcTQErLvINDgAHvFsGnughHl+ 4YAOyhsbIGaC2wbFp7raR8EyeEjsOc3IfIGHzvoTJKBy1BIAScgUwIJIboTGhJoSYgQLyZLj8rpN zmyHC0zKvHCCzwgU9EeXKCAfD6CPqhU0IFLVDQSXNEgeB8sAvHU5QPFKGT0gVKoHRaBCFOaByKgU NIUaE1zZRJc0xLFGt5QMCxvI6sQ+e4o16KIABsT6BgmJomsWgYyUdKiGV6gZPiSgViAAKjUkGMk5 O9Mxtm3QlGIUJIJoHalkTnVMVSvWaEiTaCBWMgVrWTMqBU8glIOqj5jmOgTigAE5OoEMlriC5AIQ ZXErXtXiBhtfSEkLa6BYGgYhW5Nkr29XlfIWTpCoGILU0fD9vWagRj3De6Ntad6CneCGCwXBaCZF JSDAmCcRoOd+W5fHOJ5pjNfpHkgAGOM19tbH2UJjfKoaRpOlJu+WoamkOh6pq6PLMpZNrMWxzawA DpuoguuJaHAcVYGKBmYZiS7YiRID6gYoztqZ3sDeiBj7tCIGY4Lp6CiA+j6V4mgfdCDuDuegykgY PEgiAIOag2rIdwuwYiQaB7Ogom8Qgpfg2IJnGpuedIEfJpAAIJB9buSBcGV/LgBKyBUuDyFZ0zTT oTwiNd4AHXc4hVLo9wsrdqpXB1GtvkUvS+1AA46D+mAB8g2gZT7P14AAlTHkgB4oYgggb9IV0RBl OAHOdignneLPoiP0X0SerzJT+1tHloF8CEfkL8Xz9BdGadS/d/JAxXvef6/ACBmikPgeeE0gRxz9 H7FaCsgY0nrmcR0oVdrh3PvhCaBIJsFAAPmIEDUGqj4JOFcO/xWRA4SEHguQIIzqjcqbHvBIADhn mjQee/AhsGgNnrCEkoJo8RXv8ebDEB8PHpH7KYsUCTsh4xXNsAAFcKoVgAGyEAgQzHSv8UShlDD4 VLxQIGPGLJAwaitIEEAWwtiFCbAU7Z+EVSChGZAQWL5BxoRlABHZUamIRkUGoPdSUg2KgKkFE97s VosEDi2U4IKxwADgLGMYgYTI7hNFSP0fpAxbRgOAM46gRHsECFsx+Po4BwAALHJ2O6UZRDcG5KMh IGx8seZBLAgpZCDj9G44lscvJfLTliQKWZCZiEDCANIIhozgQEGlHR1ZqZgEHk8U4actQASeEtDy XEozjhUL4QMVsvDTzYIRN8speYeyhlwRMCRkSBBmZOWUgsoSBSiIGNidJBZrwynwCafRAp4zdIXQ IfIrY4QFAAOZY4Hwmn9oTOGeU4yBy5KcJYSyPXpTooFOkDcqyZhICRLSkAvWcAApLQOE8UiBAfAU jZbZAqVUqoYRim626c0qIO0iJbmKjEMEsL2o9SyKuyqZQ2mVTzZyBSSzQiioCIDEmLVIqATWjECG 4Poi0HiID+GuR2gFXCYDMT4RWQIuQFAKGmAAzNYKxECE9WYa6SkrJcVyRivNaiYSKIcec/oJl/w9 q/LisQJBPECGvWdJC6HknKILYcTsgiHqtsES8GLdSB2GR4QIE5cCBCsmKbUgdkWepsTWPeMdl0Hk EtNWAfptQjCpGpZJBQPlWquGpNSzpLBmHoIICcE5A7a21pgPEAFTiBCwTGBA9aUD3kGuYQK5kV7n z4ukAC6hAwSNtQhbO4ZK3FW0Ljdq9YZrhBYO+NB6Jcy6XXtHKi5V67amyvSd0ttnyDWGIKKur95y VDFFwQMJozUYhYCwQIOodSBglaCZiw9sxV27siMXCAdRsYLIIM7B2CQAB1Bo3NfSMSC2Rt5hHAxL BcC4B1g4AAWMSAABKeIAAo2vkCHNeYj45hzNetnfhRuNwaBtxeTYfI+QiXjJmD7JRBcY4zwfZC3m S8tZby5l3L2X8wZhzFmPMmZczZnzRmnNWa82Ztzdm/OGcc5ZzzoSpmKKlXEulQ4BwObb5AxHecG8 hHKsSnIUMmzRC3+kSbySQP87pAV9T0DF6MYbhFQb8Q9x5Em2XkcAQocbuCTNxJO8N2mktJsrjC35 sawA5gAFzGcAGoSBamKGNTVRDXfPuGgy49RAm/irV9rg5intQiQ1IABwbhHDKGStr4xmRiBa4QPP IhDs0q6+AtoMjML3+PkILtIKOxDmh/CYOMAGyCCP7dpnkoLrCHJWefqJ1c1Ffa5dS6p1uym0A4e4 56JhBnRbTcC3cgu+29kMiExF0hAmhhE3zH0h/C3RkG4MQI1DrRBt7e2QJ2b/QPU0KDsuBKVd5RCc aQOAZBHrusfw+xuT3tT8nVlA0gwvhdEH3gQVwgEiGv2IFyvjEvXgvqdg9whz8iCdCIJy6A7y+ZQQ ehzd+hQ9Fw9hnTMgVEOBIzrI+FxDxZIEGF/HAgr1yDxJINECGJCoakEiKQNb0SiLSVIHEUC2d4ex Kig7XsUaoUR7hwUJYpkoswqIENkbJBpFqqjO88ggr7nRskpF0VviwARzUjaAgcjnO8+8kQyP69V0 U51h20ifmlIwh88/CQ8a4sxb8QQWMRRJLkGmaAABSsq0j9mxNMgs7I5sfIJNssZZQmEElvVsAE0i CyqdT6r25ApNEJlDMSj0E7hJSoKxFY82yGfZelpd1EOPiBUmXMyThaPkzz+VpAoM8CzTdlAQOtNM KHFbowBOuZaNzJwCFqHvyiDKLFhp4CCKOJnkgpMQBCmAiJMBsOiGoF+CIKbKcPTCHqBO4JVkoM6w PQPwQQQiSurwRCohpqvP7q8KzCHFvCCK4K5QSiYh9G2K2k0ktt3JAFRCCJ/QYiZBrpFPOE6rxQai DKvQeCBLHQeiaL5LYCCLij+MgCELciCO9QlCYrihiLzLkL8iGAPlArwDOL6QrCXm/sCrmLsiEB7t LjzrjLRwxiUhrhisEMJDYsCsaCBgaMdCCAzMgNpQ4w3iWA2sbiBhcMJMciCMhMhsBrYjoMkMpxAC ZMnQiIeu2hispA2gaMTiBMqw7xIRPRPxQRQxRRRxSRSxTRTxURUxVRVxWRWxXRXxYRYxZCfwSRZi JNgnKpSMeiBGCiFNKMzINChNWM+AAA5pBNzNziCAcGrNCiDNpCOrgiJtNipPGnEtuGws+iVtqCCt aNat/OkLfkrnJCFm7giECp5NkOOHYIXIQiFxtl6HHm4m+NlKiiSR2FXGXNVjgM+RsiJxakUNZCVu dt1nuHkHkgHuQgAHROGiFuNRvO1nkHHORCDDmOiOduEtlSCoft5xySKvBiDnCHjkrogHyj9yGFmx yuMGQONmzx5yROwuQnQuJPnqJF3uON/CWN2OTO2FMHxkSn5ugoHCFN2HkyeAHm1ESiHn8OjiBOZI mPUOUiHOYIEtvN5HbSkHJoAk+uhnVnNNam5NdtTnaIYnxoJj9oAuciEntCCynCWn3sFISHJnzIag ajKINkZiEOpHuooPAvZCGuPkruFnpOlOtuzCGIkx2NTlZHiusutOuIbIcEhlGO1OAySHOoKIKiBO 7HrKUO0vUTBCVPCo9jKO3o3ovIwBbIxE7JAiFvXgALuI+IUoVPLpSRriDvXIePQgADJo3IuvFEpp wHizXTYI+vETfowoxnkqcvPHbIJI9CCggzDCCI5E0vOCCzBTdCWvpiCJmv6ShPfJTDpPyCCv0CBz uv/pIPlpdCFvVJlJYPqpZPkJwPev4O4OiJWjUzyv1T4lRoePsPfMQhVjAPoPBviPwJZp+F2jNJ6g AJonJiDpWiCvjP1iUpvwioHJROgKHzpGvCUOSkdwowMv8iFKLP9vdP2vdKQwjh+0HiLP5gFKQqwJ c0WCCQIqIJkO0v9v+qFUYI1CUKWmkH/TOgSJMCWBtqVgAKhCUqkjKx6xbAAUgUn0pUpiux/iLKq0 qCaK4CVgzT1wrQaCCpFNJCGK3q4vlUvCGr5AILgwOiIQkiHLLCTuviEKwiHK/ilLCH3B7twLrQ2r EqvKOq7gAQVlHgIDhC6G3wskd0/jMwFQ0k1RmiGwjPsCesoCmMAQnLjUQLSL9BWGIosrWCBLfCB1 MDhwniBD/LkrTBm1PLbiBrdkclTLOFIxGCFC4L11PjbVQiE1Dm3iGLUUvMNM7rfiCi5m2L7LELkV cCj1TiBwtr2VoIep0roDulTgLK21TkeLkLS1b1Vi4gmi+IlBXwvEimXLqk+LriGrs1qLviHVniFr uLolArwgAU20QLErS1oilr+19LmDgxOr5QhrQrzL01vDbmjHFMaOr1mr7tWiFsRH3NK17CDAzVu1 liEi2DGK21kCCwzr9MCikQ4w5w6K6Q7MrsSw8w9WSrDiCVYRCMIp0sGsbRBxDmmVUEHr+1QxCl22 LiDQ8iCGiwoCFMXJ82QCEgomG1NtgDqVdiBMPiBtAiBMbCvshCGAfBcRMRMxNsZWTxCg6xDiFG/2 XRLQ8RNAAWuWTiE2qtorVsOCEsZWpWpiGQ3WXRGiBWtC3WT2iWwW1qj2miLg2xHxOiHJ0HDTQCHM WBrgLQJQilZQ/2yskslW0RO1dsnCBqKJ0UsiHGylpxH3NCWCzBN203PiOi1M3gXjQCSAXjECamtD wKos0gXy8CQgLLHiajTCKjRHMDrugHE1DvAiDjJj5F+ESk4nEi5zMiH3eETVRDelTiEgqFjjUKRP njdETjfUBQkSJivkgEok/XrlyhNjwhyByLQ1NCBEAEfmkk3kBALFTl5CE10iB3hwKE4Dnjo34CBj yDzLRLzGpEfqvjmXrCDkLscXyoww2LMDHE/lykCFbtnIOrZkJWDoJ3wCCkLlbtGiCkJjboHXjFUD vkUkUkOojkQAAERGjytkZEyXnl5mDkFKrYUvn3v3mkylzYXikX4FPFB0wl0E2koyhYVlOLoyA0rJ +4g33EyQvlzkkEWld4fD9k34hD238llk0mfwbyKUW4h4bmKnawW1ZijkEHwQWlQQdHwklFTXmj7Y XOTYes8CFYqDv4Cl5yAk7k8kEkuQdFL4033kzYdozl7FJlDFRIhFNYhiCYdlXQWlJ49YzijFds+l gl1mTlpo+lklUYHmLE7mfx+5KFpCFlb4vF0ZGGFlhMFIJGPl4YGiBlVlImZklRcmbFilxgAGAla4 6l5rXklQWnKmbCnmTCGmJFSmKw0lfAogbCRZj5kiMK/5SiPKqmaGSWbX1CCmAkg4t3SCLGnEfQmi CmYQq5tZxZxipZwiGM+GnxSnwVIiQU7kpkMUOxbzxipGxCENzCWNbO1tK1fDpiLUrVfCHtkgAG6G ruDYNH1x5iUtvCEG/uHR+nHHICLR+VaiGNsFcnJNtm2sjOHtGx5ScClyB58yxCHgondOICLSEHcy UneSHN10nCFHR1auLjTo+ybukTroYnQjgLY6S6ZyPyMOPR6yDyEXgCgN2SqyjLwDNPAoBjjpeuWi BS1x1oFSnoGSf3tu7jUuXm+SwuZvIalTMQd0W6QnX0P6RiDH7StESnUuWyvNbS2yx60Ssuq6nRgi dy9PXn/oTuzPZ5vldsFFZOpTXIKj9y/EzoeIfIYS2UfAATHy6jtS8TKaRogonufIaIMSuYPzXoXa cCCISiDILoVIbpek405ibIqJJTdvDoVzaPMp3EtJAqcPHlZTXIbI+bQzZpST65EzglZTniBzYo/P MCCtFzmI06giGvRva6zlVlYzsLnGPTDTTPR7iNYifTtvqvcvdp/1KOMHJ0BqUUIplJg0KUFKO00P gwJPiJMv0pmUUP7b0NDKCPh710D7yvlJytIJUUB7dPiz3vcz0T/PmJosQyoib0LUeP3AAUZiBKSK B0cGvAqazKECBAFUUUe0MUWDm0RiEJ7jYv+cLP5kSJdK03Mz7J2xdiFP/qOCYKHTHngLn7LEd2jC YqQXqcHQIySi9KfwMCDqXER8cCBKTj9WJiKqYu76sCnQL5iqeQAZyCT368ns05nxbYnqqElRoiSh nTbUp1AQnRJiQU3iSLAzqiFGRCDQYMvq2UwzrNp1eiM7YK/CRH+yywkTbUzCF1CCJTWCBQTjZ08k q091D3zCBrMp8p6PmK8sWEz1Dc7DzYFCM1DE+VjiF0GLV2m52CDLMBcq5q6iBQZjZ1MG12OF+1ur UHV1QKzu9Z3dCVULEiCdT7VMsFSrfdM9HrMVni4VPCC2644c3VjNB9cQuAALbzeLIFNi61mrSLk1 ow0OPQvCCLqVr1jCEV3rli4VwboVxrorpkT1LCD182DF23YFzWBWhCErlo1dt1qtwC7V+AAWPJ8r 3wv9BkIXz90VcMGK6d5iBVSr63+0QwuLTWZCDWJw3K6We1bjMKv3BkkVD9vi6sEYKW4iBsTMcsdW g2bx922iEAzNc2p29sKDY2WeNiG2o2XsJ2VeNMVsssPNwrhWdsceVCCATZ5iuRBCC25eZWHsM1d2 sRM2zCHxEsiCB+erJWrw8XPCC2iCBBRhRxdCDWm2s3IiBMZ2pME2viBAS+nMfb9Gxw5Q3xMCCROX Ruz0H3oxKFL3H3A+geleorI9vBmAN3MCE+2W8cpe8e8qnsHeywxe9CO8ogADPMX3UXZiMcDCkbNG w2HCvrcX/xbwiB+97iJFHLxck7gX6Z0jk3kfLiJ/Kj8/On/EhCoNfkZXnD7XxAS4D3+CLXnE5/U3 yfO/Mk3EpfFJB3x4D2GeAkSShEBXnQv3yCD+DiD4BYGYQCljtj2kCPHYx5OdC9mF9sVExDuEaEMZ zEJmn9PYVlACGYTYUWrXn4HED5F4Y4ZCGlU5NCl4qmK5na/5B/aCC4P4u9AmZ/3p+0H4k1RY5oz4 ebiK/CAI9fgCCABUkQLQWFQpYJsANttgBHtBoPcLxcLveCo9HwuCBaEx6FJtNxBNx2CxiRSuWS2X S+YQuSQSKheCRloQSOI9crmCA8HwUhD6FrBYTKUQt7zmdShc0GPD6iQWGwWZxSUzaPT2Cg+bBchQ WpS2sRcATikwugSKxyysTebNCkzyY3W7XeYRd7lG+QQbJ8kkkJhMAE0qEEgoMyQyjwqJwuzR7AQQ Jk0mwTEwS2gCZwW32ebXuCscbSLDwQyGSp0aSRGW3u+FHSYAkwXDADE6nN61tyeV6IAbLSgDBZXL 3jkcnlQtVCeF4iV4+FRmFsdjwVVKqCp1C6kyEGChAhELXTSNQrYlHh3UiETxeTkBPtADswTu6nwc uC/Ls/X9P/AC8FSd6FvGjyMNg4LrDMwaFP6d7zrujL0wDCsLQvDEMrrAyFQ5DUPxBEMRRHEkSxNE 8URTFUSGcVcXCjFcYxlGcaJEOZkoKP4/xq5Zkp8u6OR5FBmRbF8YRiJhxxouSdv0cYPLwZxmSFE5 qQJDEitjKyrR2kQ+j6jzpAgIiCmdLMjoMIiSS6u4IAggsiOXL6WoQZk4gAVctSvKkQsy5QNiCZxq GpI53yufJpNwQaChwHC3GgoCoF+DaCUGgtDFSghpUSQdFoJRoAD6V5Xiaz6V0E/VSooii1gAX6B0 qalL0PRKFD7RocTBUdVKYn4PVfSk+JfOaF1XSKCAgg4iVgghdUyAFEABQCCFPR1iAAB9epbV4AF8 XyCPagtp0/a1RAlbKmUgn4Ypag6RFPatcoIV9z1Wn6oBjZNw27b9wTIj1qoVejPJzVt83BZhfF1Y SXWMqDCgk49X24ggahrcSQoUJp41ImimWOl+LAAaR8o+sKCHvjafpzUzbX+l6QI9jmCWxVomgkAF 91cVpWhWggjVqAALZOhYm4fmrbZxnSFYsI2GJgyyPCNp2K4sVpsmyIBbFsgqlpkBSPZvUZ4nilYa lagutgAajzmhH7OAUp+bZwgmyMxtCYZaACntsy9RoLqYAZ6gur6yghmVkmm3k3sGkYhv+f6dwaV8 RCOnpEIIqI8YxjIKBQHibZ6PCIZyPURrb8oUcHOpWVJ+n6bhuIKaXSRb0tpZKjxwd31aCiZNiXTM jxpa4zHNd2gvOAAP4mIJ0PX9kABbCAhRVmcg9gswxHjnB5PO+Yj3Y9nl808ughp8bjXRdfnRsdza GgoICQPoLBn0d99Ll/muvYJjTZBWBhNBMQV+6OjbLPG4+wIjmhsPuZ49kurzAFCWOO+Ij0DhWwQH MFRgblxLCWF6f07UCyCvuWkBtV4JCXhIhYEh5oAIQH9QDCxDRJSIHlhYEyCZBD/M5c05ciD5ohRD iJEWI0R4kRFMjEmJiMiOLaRkUttxFgLjXGo7eJpHkpDEdiPpKZIiuEbLTFklzXkqOvThCoj0ZkQD 3csgEEgno1pMMedIm8bltDTGm+aOxMBpnHSEJ4fzXYpJBjhHIlzB0LxsPC4kAAzCcFMAUAqP4ZiF ReJdIZFQJIvkxTsZCPEUESlyM8PdN4AASQqGYMQYhy5GOUlaXWQQ15aEslMR6Vh2xcyVddF2VEiJ akulSjEEwnSRDci9HEhUbjHK9GdGpKsWJVkFBNAMAAJxmkeCC1MVMjiRAxHvFeYYAJWTVmsCc5wA BmzZMxNyRyHo+kKnLNUgs2CCisgSeAIymZglDlIS6c0xZ0zrGbPglwPkmSiIVPSes7KCz5aoNQa5 QipgAGguwgsnJVjEoYiejk9Z0zqodOwgrMyCFGJbLklc66RUtbqK8qhjWhAWmgSudBHqCDNCaNgA DMwPlHFhRWmhMaWEFqLT1spMJP0rpJS6ndSRXv0pQR9jNSyCTFRmKuSxBKj1FDNFgz04CYItIXTm lgZqv1gIpOCZ9NQATmJZUd+qZgsM0ozGqeZMK5PCpPQogtHJzVgrLNkZslqvkECxXUglYpxzkljW +sFXamolDqHV+tWwAWJIJZUlYZqOkrFxZay5BbNWhAADQEpozrxaFWQUa4xbOp7ILZwEtqQAHWoX AOsgAJgktGdYqzYNCCmyJYKuRwxbYKndKFgXAALOAAtraOjtxreWvGLaarlaB32CRKLgHRLQSijF GOa8k1IsW9JELi5tmbE3rtram8RBBzPFBNeeiZBBcBtBpfslloQ63vvgOYggtsBX1IVdaitpw2ku uiAC8V5arzWvTgvBWFCRX/vfg/AeAiCW7wReuMhLBig+Dbfol8tJgj5HyESTilAqQ/cdiPEtwkAB Up4T++5HsSkKs0S4ZgG4NvOUjjm0AOrE49JXJwgmLyusPxJiHKGUcpZTyplXK2V8sZZQAC/LmWi8 BUuBl4/SZq3ZbYycgPsIkAjYyYckC0ckXFdIcQQD79FNPxh6f8D+N8rj9sehWZ5ygzOiZigAPJ8z kTDYoADNpuGqEeWUSDM5K9FkicCjI7NaBU6EJAWMzd0ByEuE7MZC9KjkAWwSQQTYHwSjk1Cchdxy Zc0d0OfOtC4NCma1TqzV2lSX6DRnpLXQAAfUyNbnMggQitEs1uQrTpbapmdIkNA8eywACdpCXgqs zSU4SBPmogmkdC6f1USXaRddI0zLFgnc+yStAmljDIhZCNJFEKlsWmSJTdkON6RMmpZmvSaJXrnY mxiIm+AARaO8YiC6bOUy2NhAtw6caEVPfaxUInULtp7fBBYgtd2sU0kRCCF7QNZsieKIjeylNAQt IJXFWksqnuXf3CjIyGJ4T1kAAChnK4CTuMK2Ctc9M1UDOfKzzLFJ2Rxt5MTOkkKTEsiRKC6OO5Lq naXNSMcaRLEsvtxCCHFMsYc3MmVtdSIKX8wJtsYFF3zywlxk3nGGdSaqk9Mukb/PQmjsJteH8Z2W X0hRg2okEMUSIkpStloT74ig9R+z5nZBOdw1B+T3Ev64AAG1qz6eR8mIUgp0Nklh6gRRyxsPGke8 mag77OT3TwV7wD1IAD5EL8o9ou/grbnXP5vIlZ4iRcK72QQ6xg9EHNygbIY6DDCQ8QeQpQyBTxoe Jag0l4703fTNehQynvfOiqQhN77P1CY/W86f/1HYPnZq/CCZ0WYokw9zz/D+kR2p3zw5/X/VxbWh R0QQsTuiK6Wouu2SkTsdKziOwD60uIIxUYYieBiowOUxWQuJmD+eKQuRuiOr4IKTyIKR83OZJAor sT4qXASR4EgTABw9mP+SSiPA8JG2QSfBSUcOCa8n+5SR490TUOSGgTcIWTOJcEhBpBqLuSMRgHeI OTWIVCIWuOXB4RG3bBSIKS+VIWyieKYTqk6WEf+8MTAUeXvCAm8+izu8MEGVvBqVFBIOQGkMSU6X IXmpgosb0MwUEUJBYILDOOVDsNiJdDQXkAAVIVWYKKCV+WkdS90YYVAXmbpEGYekUWWIW1iIIXGV tC/DmJo5iLwEGXgUaS/EuLeXUsWlOIWYUXAfeMTE7CoXoXQJeVeW8W+WVAaggI8XOLU52XCF+W/F MZyUQfeWEWyya6sX2YoBWYu2czOZSI8VYUiaOWWWYLqZUY8M+ZsZe19Fm9GZQkBGDDCJhGMIKHyA 21y8yI9E09cVcVgcnGwaG4WYY5ib+bIamCDHUcKeoWKW0cZGEZuakdSZELsbiXuMsboqQbuaqbwj mbcKsbjGagBDkJea0kIM+6QJWFeqScIZ8AAbOAAcNIjHwfySE9EeQAAeUJEdcf6fGTMetHAeIFsP yCoe6IJJId+h0aOLrJYMQczJhJGdYeXJodCJEdoI8A3F+dVJ0JcgsZGdqIKCJFoIWd2c4c5Jm4ae gIUdpA4dwYYfsAUheAAh2IJKQ0Yz4OQd+gkaeUQeIw4f2IIQYRyS6goJagaXFLOgBIG/2JeFegXL i/0qi48NchahcOYOzIcJYlSxfMHLtMQOWUMR1K5MTMdMfMhMiWFL1MkRmSkIWGYkQ/o4FMqegeiR KmUmWjeOm5C58csn+OSkwOQ7RMjNCGu2XNQLsCaswNekKJQkURDNwkfNKLtHILqknMqa6r8ag0HJ OGYzKN/FIcOnmwkABOKjSlmyIqUpUmK6aIWjiH8xQJFDomowkj+ILLBMknClwo6nQpyIIH6dSokG u+moQJc1MIJPMq4FYIUn2KEQ4kMnCrbC2IVPMoIoMAAncvuPGKmOknEo0wimq1IpcABPSIKolOCk fOYIUrkqKp3DizsWROUJapvQopJQuIKp+PDFImGmmrfOasGpaGwbKcgAAqCAAAgYyyVOo2wpwpGp LIc5nMqt3RSrmN+0DQkqJRu2avYmWmksenor4rkIW1ut+syKOourusdO6ABR4qKpy2bSdRdO5Mqu xCArAuetVSpKuJdAKsVS8wbLWwlA4mCv9LEI9S8ugRg+XTGtaIIteABS8sKAAu2IKvUIKve+VSpQ jT+I8v+IUvGi0RbQgAAxGIIv4Lsviw2w7UWlrUdUeuEDaxAJbUkvkt0vOtgB8xABowXUKyOuctEt qFGJEwNQiIWCxOkxUxYx+yXTeJZU0u8RTVhO0JW0aWwvuxIv0xoJYxQloJDVmyAh+aMIKuRVcyyH 9M1OOR4R0D+CowtWcyuF+Gw1a1fWxW9W/XBXDXFXHXJXLXNXPXRXTXVXXXZXbXdXfXhXjXlXnXpX rXtXvXxXzX1X3X5X7X9X/YBYDYFYHYJYLYNYPYRYTYVYXYZYaygICAplbmRzdHJlYW0KZW5kb2Jq CjEwIDAgb2JqCjg5MjAKZW5kb2JqCjExIDAgb2JqClsgL0luZGV4ZWQgL0RldmljZVJHQiAyNTUg MTQgMCBSIF0KZW5kb2JqCjEyIDAgb2JqCjw8Ci9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRo IDk1Ci9IZWlnaHQgMTA2Ci9Db2xvclNwYWNlIDExIDAgUgovQml0c1BlckNvbXBvbmVudCA4Ci9M ZW5ndGggMTMgMCBSCj4+CnN0cmVhbQqAP+BQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRuOR2 PR+QSGRSOSSWTSeUSmVSuWS2XS+YTGZTOaTWbTecTmdRF2PF5td4uFsPZvOJ8OZqPVtNp6uBxO5z vl9vp5vB4PJ4OJ/P1/O5zO6pvudy5/WV+2ey1u0WWx22Cp9pLNPNxZst6NNVNNZqBqKtNLZNHk8G xls5mqdPqVLHlJt5ot1TopfPJ3viDWd+t5yuRqtRsu91vCVPl8PhwuFquJyM19Pp6wZ+bF6vF6Wm JPl9PlfsdeO12OpeK9WOp2u18PfkPR526dLdbrFXqlTOhyudcLxcHVLoNIqVQGRCm8zpRFGNAoxQ oZQqQ5H9utBpwm0t1xN9Lp1LOl2OxvO/TnkcJsnWbRlm0aBommZ51G8cJ0G6ah1HWbZ8tIdJznSb psm+dZ1nc2yBH3EJWl8V5YmGVxwHab5lmyaBrm2bJzm0bpdEmSx2ncbx3HUcprGYWxnmgW7fHYgx 6HuepAlERBcG0XQ4k0Po+FSTxkmAZBilMWiqnSaxgFiZZaFCdRxm8b5uHHDJwnq5DmJIS5clEUxd lQchxm2ThcE4PRUD+R5akeNxQDaZJrmaUBXlEP41j0axiGAUJZlKeZ8NehByHaco9lKPhrHGbBCl qRRGlsRY8lMO45k+Oo7EYOg1CwNBLEiQpUluUhimeZhRFyVRJlaTJamKYZ+LOgxUmSU5WmUVhRGA UBEFiRZIFASRfFwXZJEkQp2neb5eGQXxYF4WRRl8VRcmaYSDHke55jcVY4FobZaDST40juVI8FoV ZZFASZOmobZnEoUxLlEU5RGCaJjDiUY+kGWRHF6a5jzckZtHCbRjmcYJrGsYxtMcdB2nGbh00Mbh lHvCpznUZuP2KfhoHUaZ6n2eyDG2bhjmaaBWltGrfHEVxXEeUTvEeSpKFUVhWFCWJTBsPwiC6TA1 ksW5NmudBsloYRSFKWhIF4X5RrOfiBuQepclyVJaFwWBYFoWhomkaZP6iW5ol6P5VkQWZbFSYBnm CUZZkuUxXEib5ym6g0KHuYpiFWdx3nUXxgl6cpynGbRpG6YxrGkaJwGaPBJDiSpPEYYJjFkTxYEE YBpFKbZxmfi/dIafR9nudx4HCex7HktJ1nYdCinCbZwnAd5429T5e3OZpnlwzC0to/dvHufB4w+f 8KHwcpzHEcByHEc51nUeh6nrDp2nqex6nSdZzfubzYn2zHsLYgpaYAQBH4P4fg+R+j6MwPIeQ7Br DaFyNgbYux4jxHSPEeQ5SrjjNiPp3ZIEQj6GsM0ZJRRrlcH6PmAo0x3DSgRBwhw9SrjtHQOgrA7S JGtHwpgcIlRhiJHiPYd0GyBskeSmkdhqh1FOHoPIeZmIWj2H2pYhqFB8vuZyQUdI3hwDuOqQ+Eww RwC+FSNsWoxBkDJd7C6DpLxqjSGgMAXIsxXDHE6NEb4zRjDZGQrUPg2BvjXTIOsew8x7DZGUN1Eg uxrDRL6J4TorhPibFoKgVAzxjjIGsMsaI1xvjUGOo4XKPxgjQF8KIXApBaDGFeIgTYgpCHLIKM0Z QyBOCOEYMM5wxBdi5GSMsYj3R7jQHENETowhNjiHYOA0g+BvDUG+OQbA5Hhj2G0NcbI0xojVNKPg dY4xzi+FcK8YwvxejOGSMZu4wBzKZIMPofg+hSi7E/Isag3BwDaHOOQcw6BzjtHgO8eQ6DVDzHUO d9pWR2DjGmOMag6R4DqGsOIaomRdCdFeMcWr7h6RrIYK4YQrRUDBFSIUXAiA3irDosIXIfAvh+T6 KYXIjhjIrHILQUQvRSCaFUJITgkRIK+GmNwagmBUiPECJ0PQ6h4DrGQOMaAgxaCHFmMQWIpxXCnT 6KsaIuBpCtDoLcew8R7kGGMNMY4lhViTEcKcQYsxiiuSYJId8MBljdGeI4WQkRyjuHGccfArw+C9 GoL4a44xwDoGEMMYIphYCldEMYWIvxWilFgJcSwsRJiIFgIsUAxhPjHHCMogxWx/DnPoN8aY3xGi JEyJESQlhMiyE+LoZYuxICoEa9UYolxaCXD+LQRQpBjCkFmMcWA3WRCmEsKgdA6h0HHrHRwhQtxm iuGKNoYImBrCaDwLoPIvBgi/EuJASIohJiiFQJ8V5VR7DDFSNMWQpxfRwGI+ccI8x6D0HA+cW4xx YifHGKkXA7RmC4GyL0ZR1xpDUGTEmgQzRsjkGi/kfbaSCjIHAM4VA0hajCGiLoUwxRMCAqeOEdo1 hyDrHKKIW4phkDCGKPR54rhQC1eQO4fE7xaDMFyJoXQnBfDbGIJYZ4pBJizEELYZwshLDgFQJ0cw qRvj3HLaMs89Bf3UFsJsZFRFqi8EsKoaQr1Nh7GILgVQxxpjDEWNUSoyxuC4GMNcXw7B0jpGReG6 REKxDvHgPUd0Fh1QTHcOQdQ6R0DvHacp+Y87okHHcPQeOkR4kPLTO8fb4CHjzH4PUdo+6AD7HmOM eQ3x2oAHoPYdZaalI7egWkeY69OTugQPscWoxuj1G6PEfY8RvD4HENsew3x6D7o2RctI6B7DnG4P Ubg2B4DWFYNQUbMiBj2d/oEcbLIr57ImNUbA0BVC8FELYVQrtAaVIczKGg6BQDFFCKsY4qx7HKHw PDWeoB0lQHIOceY9R6L+FONaZo9x9GWIvpgbwzBrcHHznuExUh86a28RykAoxljHGKPkeQ9R3mqZ QNWCg4B0jaGmM0Vgkhpi9q0NAYwqBdidaWIITQjRGCyFKokSwlhljKGMJrnYuBdC5F+NMYoixEh2 FqMwWQ7R5joG2MfDYvxYjSGaMcbo3EYMfeAPAaQ3BsjOHENBDg6RGCMEIO/RXFe2ElFqKIVYzxiD KcsOQYwrg+4ZGAMIWYehnDIFWMgYAnBZC9FoJoV4mxVi2PWI0S4mRFsFEoJwSwfxADCbgKYSQmxv jjGaOwdYzRli8EAM8YovRojMF8LIVghZ7DYEcKAQojhQiJF8MgYYy3SCjEmJoUwohOjcGiNYUgjR HFVHf235RIRrjUHAK0UwxBairUkJsTc4xlidbEM0a44RpDXHIM8aY2BrDVGgOAbg0hwjMGXXxNI0 xqdyGSOUcI5oIMmoYccdRoCkDMGuHOHMHUFwGAUcGCGcGI8wE+E0Ewm2HFACFMFAF0EiEUkqGmHE F8F0GMfm0e+XA6JGfcHwR4kEHg2OJowqH4HYHeHoLQNiH6n4HgHOHEHWNyH0HaOINiwtA9B1B3B5 B7B9B/CBCDCFCHCJCLCNCOIm4kfkSOfcH6NiI8J6i4eQ4MHuG2HUG0hMnagKwqjUPkLK4MHw4oIa qWHYGwGmGYHEHEGwbQJOxygQK4MuK2UoHqHkHwXaH04MKmLU4dDFB6F8F6FuFcFiFIjeGIHoHa3U IIHud8kAGoZkHoUqHCHSHGQsHUkGfpDSFmFuFOEoEkEIGOGAF2ESEsDqHcd+HWHqHQZYHqGCG66I G2F0HihgHMHiHOQaHGKsgsHkHiF4GSF4Hw4OHiHgHcfEHUm4gNC6IEHgP2EiFiECGmG0GRGAfGHU n2HIHQHyHs4QIyNaHuF8GqF0HGucFcGYFqFsG2FwF+G2F+EYMiFCGKE+EsEgEGGCF8FuHEHUG+FO FkEqGUHM42gKG0HcGy0iHW36GwhQ4e4qGAFwFuGGl00iHeHGUyGGGwGK4IGoGiG2GmD2EsD0GAG0 F9BkHIEqEsEmF6FyFoEqEeqgFAFKE8VGFAEeEeFQFAEyEyFoEMFKGEE4FIGSFCFGGCE+FSF4FQFS F6FSHRBgl4F8X6FeGAF4FqfKHAFSEwEuSQHqG8GwGwWwFiGAGwFqHsH7A4IEMwE3KquanWHcHcEg EUESFyFeFoFiFWFOeWG+GIF4GeGiGUhYH3IUIaeqGWFqF6Fi36HKEmEqEkG2QcPoG0FEEiEaG0Ga GYEyEIEOE6EnJoF9MQF6ESFuGoFiFkreYUFGkIHgFgGOFeHCHIHC7Yo8FYFwGaFuHY08FqGeFyE2 F6E8FiE2FeGjM+FiEEGCftBsHQHYEoEqEuvwHmE0FuE8FuF0lKFWE6FsGKFeG+HSG+EWF6EkEcF0 Ekw2FiGEFuGKGaFgGqGQFGGUG4GeHGGIGMGWF8F8GGLSHDDSEmFYEmHQ32KKG8EgFmEgFeGqFsHw gOXYeAFgD2F2NW5IQu8eE0GwHEGyEcFYEiFgGAFaGyG8/BNZFQP8Hu1Wf8IOHGGWHMGIFCGYHC86 EMEMEWGc/gHKHYHKEQFMEGFUFqE6FiGIFemKxYGmFqEmF8Ewk4G0E+DkFEGclDCcH6GkGIGcGY9y 7YGaG3J+G6FSFcHUFuFYGUFeGWGwGcF6F2F0GuGgGoGIGKGUF6GGGSHaHWHifMHAH4RCoAHgG8G6 tMG2HIHfLWHuneG46eeEHOGYHkGoHMHgHSHwUoZQHCHiHKW6HcHkN8HciGHKHUGyYyN9EOHY0CiW 1yHOHuhOXYRwHKMeHcG+HOHw2wHGNOeGHqOrVWG2rsGCFsGOGgF6F4sQEYGuEgZuikNgNwGiF4YF QiEiFYE0GEHcGCGWHYGcF4GcGGKcG4FUGUFKGQHWGgMqHcFkGqjkFqFaHGHIHIFqFUFwHGG+HNNw F9BgHk7ZGmncLEIEHvG0HwQoSOZYNxCQIsg3XpXYIif2H2HOHsHQHIHvT0H1UmIcMxFlBWK2Hq0d VSirBVD6YukGHmE+FQEoGAFuFpDwHwzuHSF2aCQaHDDFBOGAGaF+HGoFSWGqG8GcGKHEF/FXXzZo JSG+ggDKC8CqFiFGFESQHoFEFCEsGAGKF2FaE4Ekiq26iGUyEIEgDqGm5OG4GuG6E+EeE2NOG8Nb GTZra6JBF2HkEmEFLaDSDiqWHKGGFWD+HSHKGxaMDqSQ4+HYHmHkHtL+FOFiFEbsGaGqGcGgEgDa ECF4E5QFTRa9cOJDboHoOgGQGUGUG0f0lmWSFYF/AGGYeGHwFAFoGAGcGsG+P2HgEsEoosF0GSga HA5kFeFMFCF672GrcRdgJTBa0mHknfBySOHmjSe6HyHRTcodDyH7T2HoeQHfTlBzdjeReTeVeXeZ ebedefehejekjWmWHlLXboHeLMIGLQNK0yLKfkHqWKH6IMz+HinwcfemJONId6wqz2G2GYGiGIFk FgGUGGFsFqGAFIFaFeEwFIF+EmFQG0FPDqHkGw+EqIEqHTBsEqFqEy6dYQIIGwG0GoEkEuEMM+KY 06HgHs1OgofkHkHIoSHAiSRDXgIOegW8GwGzTaHS46HgHNVdEXYEHmHKiZU208GeHIGZX/DELThK RCgHREIHh8neKkd7CdUcHIG06gSOHpd6HQKqHiHbAcTuG0G+QeHmKqf4Ni0vCc4kZlh8RDNgFsGm Qycge6HAGiGxeMHGHMrsGwGHDYJeF+F0FuGAGCFwHWHaHMFuGgcQF0EsE4F4EuDGEWDIFKFKFQEd kWEqFFKsEUEnccGPCyIKfMG8FCEzgYGnPEGoWxk7KOE6EEFAEIFEFUFEFiFqFmeQhsIQ5MGqGKF0 GFjqFjc6GSFYGQE+GwoYFOGIFGFoGGFilCF6ECEsEAGZRIf3ePXiSQGCGAF0FwFsFyG/QkGRIsGQ G2GQGgG+GeEiFqvKF8FLAGFyE8SoF8GSF/fqGWFGEuE2GKF8F+E0EYEWE2ESERFCFlTElSGYGAHE G4Z8G4GYFYGHWMFixqjgG5jKbaF1MSE4GuKWINbYHTMIF3BoGOGeGAFgF+EqNAHGJhNeFIGAFKoc HPj6F2EUE7QsFcFkFID4FKFqEWGQFkEMF6EyEAkeFcFoFgFyFWNzL+IGG0HKG2E+GGkqHOGkE0GO E+EwF4E2FCE+FGFADYFKGOE8WGESGBIllYII4kG8HIG8FUFsFOFYGKFYFIGcuAGIEuGkHAGsFAGS FRaOFiHGGYHRrRGqHXVTa4GkHIGoxCFKEqFOEaEkFgEgEWFwV+GmFeEmGEEwFA3IGmF+GkFcEIFo F6EcGQGnF6GOF6GKE89+FOUSDwE0D3OeE6HAHOG8EkcWEMF8EqG+1GGAHIGSEcEyEoGLR06oF6GW FMGkGkFsG0E6EyLyGkGtiGLKHYHaHSE4FWEiNoHfmOGiFCw0KYHDQLa4JOF4GkFjWEFGHEHKGQGa HAGSGzqCGcGkGRMeE8HYHOHcGUFylIFAGfa2nMGpA2IMZYHwHQxkHiH4HoHMHyP4HqokHWGsfJIm G6HKW8HO0wIMFWG0FYFyGoFcFaGCFFCYGvheGsHmUwHyHiKSG2G+KDVSHwGKl6GOGUGifnp8IEHW 7UGBPi+kFaFuGeFaFqHAFkGOHKGE7iFRjUGcfLDUGmGqeCHUP5U/G1GEHenvQ0G7VOHOHYNIHyQi HYFgHXoGHMFkGaHcQOGkGWGoF4ZCY/RkHUGQFwGmF0FBroHMSKIEPmG1fiFyFcG6KRygHkFeHGFu F+HEGBGQJaHc080i2UHveKH7hMLTA3SWHyZYNbhNe2K2z8MqNIJIHPVcGyHUGUHYHuHQJawqQoZx 06d7xXfSIbCcH4GQGQGNNWHEZkG22CmEGnwSHL0KWLBOKmNwHyG2HSGyG2HaGuTYHoFAFaExy8Ys IRhL0VDtbpQ0j8GqM/zXBwNzQKRCITBiHCGmGMGSxzG2tGLKKgHXL8ndCc4OxyNxYmItOXj0HUIT SWHon71L3WK2HAHWHD1vB11KFSE6E6lkGQOQHs5sD6FdKaFgE6EedMGCG+GcF1SgE9uIGSFWF4FC FeFqFMXUGOqunEGGGKG2mrBiHEG6GOGiGCFcFWFwFKE2FsEmEIFOEYDqswDaF4FUEWcmbiFeFKFm FMFWSuGNPIGEGWGvHLpyD0EWDmGJPcISKmHmGqGUE+kGHZuIGb5uFGF6vUHLu8ISHU/qGylGHYG6 G93MG6G2GbDOGVBIHkGMGKWGkuG4HEG8Flp336HkQ6GmFp4OGKGWZKG4FOEgD7ZcF0NyNE+UHmJ8 FEEaE8F0FkGE4AHmGOFkEGHcHSG3owD2TSGQEglsEyFN4oYHxkFCF2FSFYGMSuFiFCFa9PlgFQFm vS3GFQEKF4FGDjDOFYFaE+D8FiFKEGGAFqEoEcE4E4EKFAEAutLmkmEkEBnsF6GCFAESEeGSFzx2 EsFIfIG4NjLIH+NiHyFIFIEczuHMFsqoF+GRziFCFSGeGMGYnawqF8F2FwGKFoEKjEDsRD22IK/8 GIFUF0FChE7uFIFMFqFQIArl8rlqmEGhnm8Xi4W4zlmnT81WKsWYwUwsFMfHK32m+Hu9n/IZFI5J JZNJ5RKZVK3q83q2mu4W+4XY+Xy+ne7XNNnw6XI6Xw+H0wWa3245nc+32+nU53A7nG4HS6nYrVqy VexW02286T8dEy0me1mi0Got2O2WGzW26XQ75u+3G7nk1mozGOuFs02IxE4nFq3nE6Esmlu3W86F 2tWcx2AxX4/HxJXK6nUkVYrGI1mO27I429nmUz3M33HJXu930oEws1CkE+m0eon0+n3In4/X2w2+ wmMxl6rlAom82W0nVSvU2qWGqFIvj4fFE0GS2Gy1W0rVIrmo1W6ulyx1YwGgt7W2m+55X6/Z7fd7 /hIn783o8Ht839KH9+5a9fmfr4pCep5KEfJ+nqezbNyex6Hufrcvam59Hiep4nme55P2/L3ngeh4 lqcBel4chjnwfZ8twfx+FkdBck0ZZTGmaZvvwd56nyeB5nwecLngdp5Jaeyln2e8EKUfh8nwuJ+J dITIwDKEovbDSlHyfilSwnJ1HCbq2nSdZ9Sueh9I+pR2HMdZOjwUJwmgcJ9SVK8wyRJJ8HQchwHU dZtHrAZynEchvG0cJ4nkeaSyGVRFlgZZZGiex4nsyLan0+7dJKdh1HMbjrJgbx1nceBrHCcJsHGc jaqWe6hI/B5+Had0fx4dp0nabp1G8R5gkuYBxGWdp4ngcRuTwbxxwoepsG9YzjG6ZZrmwYpoH4fU USla9sWylDUnsWZaFWtZjl0Y5gkSUhKEkWxKkUXJMFqaxeDsWZIEsYJemmZZmFWPhCnEaNmGsZ5g FsXhflgck/kkTxJmaZxgL6Y45k+QJHF0SpTGcWVENsW5JEs8piHidZ4GLgxoGmWRgmIXrIn4kRPl eUg7koQI5EuQZAlcSBJlaUo6EaRprmQZ5fEuSBnloVBsGgYK9FYZZmmMVBSlFqBkEGR5DmqZhssG cROmCUA2lIPJDFwUJNFyWRpl4YZekwTpdEuRx1m8bB0nSdlmmcaJrHHvBWmcXpaGqYhunScJfHAX 7Dl0b52nDbXJSlVJGlkS4xEwMpjG8ZJDFQQxXmeUxRmkTpZmUWJVmEVRWFyVhbl2W5KlKTJWGkWp SmCWbMEyO5RD4aZwmoQBWEUdB4p8dZykEWJAlkapUFwbpbpQVxeFiUxmlWVhnl0PRSkMZptGWPZU EKoTJpCTBZEqRhaEYRJbESKxICiVBalMP5Fj6XZfi9EOJwRo1RwDXEUK0SgoRiipEuLITwcxQB/G eNoZoj3jEiFu7gSovxGhsFEGgSYthIivF4LAV4wBeCmF2K0UIuBTDUHQNUXg0xfwhEyHh/Q0hwDU DqJgNwxhtjLF4NIXoZRPhfEOMAQYrBnCocnE9KI4yNjCGSLM2o+ULDtHIOwbY8B6jsHOOQdA4xvj kGuN8bQ3R1jfHSPQdg3R5jeHUPQdYuxjiyFeLITZMxrJfHMUofSGh1jyHKOUdg3h7D5HqShMZLx5 jaHaPgdwyBpC/GAMIVY0RqDKP+SId48R1D2HwPQesox1jvHSO4dA7R2DlHaOceA6hcjYGEW8dIvx oDAHqkUrg2yuDcHkPJHxOiRD5H2Pgcw7BwDlJ8gwe0YB3RsHOOgeQ6RYjBFkL0ZovjBDVFsLsSYq BXh8G+OIZwsRaCVR4O4eY8B4iuFaK8VpehqDUGvFCfE+Z9T4NUjse49Ex0AH0PSfZIx5oMfGNNDR Kzcj8GkNMY1DxhqFHgfo/ZNx6JKHkR8eg7h1jrP+hoeg9kKjzHkPtJ9BaVEmQYPQYItBXDLGoMA3 JtyQjLHWMocI83InsJsR8eo9EkrWPibUfA1htDGNs+okYyBqjJFAKwTYwhgi3F+L4WY2BljKTqkI ew6x6DpJWP4fo/hlDaGcO4eg7z9j9KcN4YowxbiREcIZlqV0rFLoWSGYw+RLi7EUMsaIwxNiqE3F I0A1huDlGyN00pXYxjyHiO8bw4BtjOM4hodo8x1DwHcOVCw7q+y7Hqiem1K59jKGWMUZQyRhCsGM J4aCzhdREESKMQbBBaDiJiN4X43x7oXG6VsZIxhnCbE0RcUwpxiC8F8jkdozRuDNGCNcYIzBvDNF 4NQX7QxijWGaNYYYthhCSESJOgFBCSDOGUMoSQgRACxFCJ8YIuhcC0FoK2Ug9BiDaGOIgWbWhxjS HEOAcQxhaHVF+NmtY8xVCaFGOZQFJp3ihE6MAXItxTCiE6M8bozBijLFeLAYQpR0ygmKtUTQnhMq nHGKIVAqBNCMEoKYTIqxMCGEeKQS4lReC5FiOIbw3RoDbGYLEZQpELjzEyLgS6gFojWGQLZ2AshW uoGEWwa2HxjjVGkNIbLLbULXFcMEVgnheCfEJBwSQwBMC2GcLoUwiRRC1EYLoWwjxdi4EcMJYY5x NCrFAHkUIewkCACWNIbg0xRiwqmNIYGbROq3G4JMXIlBRikFULYOguBOhcE/TMa4rA9i3UgPckt3 xjinGEKkWgvxUurFMHsXojKdjlGmOIawm9PDtHaOocY1hzCvEML8dI1x1DyHePMSAlRLDWGuNo+w 8BRC+FELgYIvBNCvEsKEZgrBOjKFCKMaIqByjzrESFE4/BdCIGMM8WIyaqjCE4KYUIuhaC1FSMgV QohfifEmzraYtRvjHEcMsTw5KwiiFaKoYo1xjDRFkNYV4e5cCwGwMcXo1mCNFFeJUXQvRdk8Hwgy veYz2jA44NUcw0UQCvcI6pgYmxOicLsNYVQnBXjNGONAcg5B1ChzMIwX4lW4ihHdZMb41HhDqG6K 4bInxnjcFiKwZgpBXjGF4LoXgvRZClFkLg54pRHCnn/qgkkyR0jYHIN8dA5hwjBLOKEc28R5jRZG OwVAvBXi+GAMEcY3Bxi6hOSIdY6GSC8GgNgaw5aUD9skPfw48NlDykQOcWo6RejDHGMMeo/O0D/p FKkeEhja+goAOhUg8VQpJH3QCYyKhwD2HaNse01B+D1TBNEeI3iXDxG4NsbozRijZHAMwdYxhqjQ E4NATQqRoCoi6NoSIxA/jpHqerlBK1YTRHROUdY4R3jwHYj4dhLqgkfZanAfSDz8D+kaPEfY8UDV EJEho20iaBjXGsNUbwb4b6RIoT/KjaUYe7k5KBDUAQe5JL9xMgfT7cCIlT+r+QeJBxVb0AcgeAbR ML+0CQkobIbYbQTAUQzAXAUYcAcAb4UYR4Swc4cJVB9IeweyHYbIcYagbgjwexIpG6kb9weyg4hI eb9wkoVoTwU7TR0ocoaROofKgSkkBBAIcocgcwXZggehHgWQW4VqyQeQdwcQdL90KgcgT4VwTi0h JQe4ZIboYkBgewcgcQcYd8OaiwfxSq0jZSjqNgbhBAeQc4dI08D8QQ+IVoU4UYZYY4YpbgR4QQO4 WwUAUgZojAb4ZgXYXYUQOYXgVQQYaAZQYKEzVgUoWgxwYwS4Q4TYS4RYSYZgaQZYkrKgUgUQUoSo jARocUVoaoXoUxgwSQc4cQb4aozwaIaYagaEYYW4YoYQWgZwWqVgdYko0IawS4PQNIY4UgSIVYQo N0QAaAZAYwUapayQeASoSARKYKUAdAdIRISQQhPQdLHoQ6BwUr0odYeIcwqIZIXwdQb4ZAawYQUQ YYXISIWQWoUgUYVoTgZgZgZYUgTgTsQciA9wWBmAZ4YgZxOAeoXgU4PcQAa4WQVQPYsgXQVwWwUw VDvwZUVskgU4U4RoTQYbK4TgQQSwWo8cToaQkoaoZAUYcgbgYrrQTQWwWIUY8AUoQATDNoioS4UQ RYUQRgSKBgUQTwPoQ4W4TwTAbgZgZ4ksF4aQXQVQOQaQZARh0gRAcI0ARQTIUKXZHZQoTIQwRohI eQdgdgeISoQIRTAocwWgVIT4aIYwX4dodAdwZUmAYYXYRgT4T4Qqb4XAXoYQYhWIdgVIVwUoT4RQ TgUYRoTciMzolYajYQcocwd5LEToabygeoYgagcCXYfQcazYcZDpQod8ioX4ZQXgYAdRQAYgYwbA XAZgcAc6zokqoIeIoIeyzweaaYeIZwaQcYYLLodwdQdEwAYQTYSwUobKxoUYT4XQVgVAYowQdoko cUMAWwWgYqUQfIgQZoYYaYY4SA5wsQbAZQaAcYQYSAVYZAaYcoa4p4VQXsYoa4dBcgaIUoSwVAYI XIZgWgV4YaPAYwToWSIAcYdgn6jZPoWIWIYqFqSoX8rcz1ENERyYyIfom4fhDQj4fJBhBysoko/5 VL/CpZMiXaoRJRJQfZC5MhKwlBVxBi0pBSpc9Qm5O4dMboZz9xHge4YoWoaQdYcyitEdKQf6dsPw qInIc6obyghJPsCyjq4K0ofYdIcAdYWwTYW7kooKUjdE8YlRDSg4ezZZHRE4Wqq6xYdBI64NOM0Y kQpQjwfAeI2oe7uAbc0QaLXwcrk9FAfgeAfBAY2oeweQegcDIrAYcBOCpj+6srksA4/Yj0J0Hadl HQfKQoc4SgTQTZSj9wVIQ4VIbAZIbIlFP6dqoQm8OIcwbAaYo4dAdUKNKY96hph4ZITwVIVIQwUC Ecw4PIUoSARAgoKwUAMgRwYoUYRh/IdIc4coWoRoR5HYegbYa4ZQZwYYYAkVQocQWYYtJgaYYagI WBkoQYUYSwUgZQVYM4UgQoUIZIZSzwei3kVkTwoIe4XoXIVIZ4aYWoVq/IQQSYQwY4ZwXYRYVISa XYkAkIdT3QTAZ4VwQYWIUSGgYgXwTgTIYIU4Vx5LdIkdSQeYTAVoUYbQdwbYSgWYUQNgUYPoQgUY TISLbQbkQAONA6Y0CAkIYIVYUYcIa4aYkpDQZQagZATQWAUATYXzB4XwU4RgVwSQWgZCmhB9X5KB BIe4RR2YSYVQSYOoSwNoUQW4TQPwUoOQRwW4QgJYQgI4WAXYVYTgWYTAcM3QP4TYRZIAegYYagY4 SQWATwkQR4W4SYXQaAX4aIdQZyOT6gVQRIS4UoSIRYVwRATAW4SgYIaTh5PAZYbAZgSoh4d5DwPQ UwQoZIawYoOIUIPJ8wQYbwc4bgQwUIPykZQ9oi7gToXYTgO4RoPAUoV4VQUAXQUgRhy4qT7Qkd1Q eIN4TgN4OgSQMIMoRAKQKgRgJoWgW4WVu4WL/oagRkzQbwcyZIfAdgQgWgR4VriREyphCgeTAAQg ToYgRgOgSoMoVAZwUgTIWoSAVMayhtr5KSdweMKgcLXwcwYQYSa4YgVhkYcoSgTgTa4YbyUYfAYQ ZAYYPITIPYZQZoXYWgXIToTwVYRAugdAaIaQXwZIZgVAYgZIVykYdocYbIaAbxZ4cQbo9Icwc6bU 92HQVQXAUoSQUYPkdIcAaIbIZQZAZIWobAbQaIdwd4dZKohSkA+aTxUIZo0YXQYoYC0Ac5Y7t4e4 c9RYkqhobAbgZIbgbwZWN4YCMga7lpQAcDhTZYd4dSyYeaUgfYeocIe0GAeocgfZS4kJlo9F0obg XYbgb4YhC+Pwd4ciUSReBCfIdbXxUIeBDSZYchJSomUkHaRIfMBlFYmxS1FCsg2w1Rark6sofqXw aIioXQZ5zuRRIgjw1Lz5K+TYlAd72g1Viw9ahodAegdGA+YTMbSAYwXQUoUa5oVsOdlIlZIdKqyQ d+X4boagaQaIZoYgaYZ4ZLCgb7ywedHIkREwe4SwYoRwZobIY4ZAdElIcQapL8QEOKYc94YobAu6 yYeDIYbYZ4dgaBHRC1SN1QeClC04koY094TgZNCQY4VpasDwlKhuhoUwaAUIZocYZJapaqRJIoew bgaQbWJwa4qIboRgRoO4agaIZU45E5BOVLJazYdyfqhpIGn4e1X2ZwkYXoX5ggYwXF1QdwaIcIaY UAYI54YwXZh0ioXGgAXQbYdSLYUYSYTwXAWIWQZGGpqgTNlwTwUrHgaobIaITwX4SIb4dYbj+6sg aob4awXIZYXIXATwXIUwUwVqqgYYUoTwUQZyrYSYRgQVggV4XJtQTQUwSgTIYQSr5QX1w4SWGgVI aIb4aIlAUISoTQbwbgbqUEwSMYdYbobIaiIL4oYoUwYoU4WgZ4XIYYZxsMS4OAQwOwQQPQQoa4sY aAYwaAZwZDb4UIVIa4ZoZgbdXIU4T4S7IYa4YAaQXkEQ8QYNzIVoSITgXIUAXgZwX4bgaobgWYUc UYXYZFleoZ6zMy2AVqdgdqDIXgVx1IWoTgWQRAJYRYXrUIXUvwdKQwR4SISgeCdwbQdIbgSIWYTQ YQYYYwXwaB14ZIVgOwXQQNmAbo+WRQbQWwbYbLxQYhF4V4VEvjGITQ14YKwYPYVQPQWAZQVQYYa4 YQSAY4UoVocAYSPobATIU4ToqYdYm9TIkgSwTeDMACjYeYVIXgVCNIa1vQTAPoXQRgWAaoW4ToYQ UgTEWIYAXAYAT4PYUgSwLIVAYYV4ZQWwT/CAa4aIUwVYToXk24bAdTUYXYUgYmD4PoW4RgXwcQYo S4YIToSoTYT4aYZwasBjyQbAcoYwTYYIVATAVCVk6QdBPcESTuZwYgbIXIXwaoUIbocIX7LK7Ybg a4YkRIU4T3GAVkbwXYZikgfAbSAgpYfgdYeodoSIaleQaQUAXIaoVkNYVgWgbYUgdofNNokbktSI dAdgfSg4jwfUwSU4ywZwdFhAcFcokKsofwdIfKQgfAd4fBJD4IaxJL0IlAZGcQUobl44b4V03tag boVFgwUAWIbwViLobA8NAIb2tQZ0ToYQY4awaZgIZXDwYocpOAfOLKU4dgd791NKyYeQboeocwYA dYYoZwc4ZsFIbb1nY4eaT4ay7C/wcYj4fAZgboaQVAZ4VOh+TahtvocQbU/paAaoXQW4W8LAeZlp I79hK5lwk5DQfFE3oZKxFSlBKwfqQI/euZDXpyhisgfYf2iAk4eYdsOYcAcwhdPBJRDQ+fWmZZK1 UgegcodySWWhBwoXpXr6tplvbUz3p3pgkmWnqS04Zocm2wbQYtEeh6Aga4SIRgQwXQWoW4QF6wW4 ZIXIbQcg4wmBQYbRKFKocA9AlAngVwWYVJQoeIlY/4eJYAd4dgdzMQkgV0I4Y4VwXYdQaYbzroW4 S4XwSwTKdIMoTgMaCYZoRgVQQoPwS4OwqYdGMIYQb4bwawlCNjtweAdEiBUAdIWYXQVrk4fMIJkb 9gZ9cITgVASeWgbAcAbIZKTaZYcOoSfZloSwSIREFQbRdYPQXtJgWQTUTgWQUgb4aAWwkUGAcAZQ YwY6KgYavIgD/gUDYTEXqIPR5bjKbDrbjebK9WbhaS3XadQLgbC0dztZzbb7aZDEYjAYrBbrgcKZ RCdUaiT7YcjagcDWikTLCVKeebpc7OXSgaDCTquVaLOyAMSRSqJQh1OqpTqhSKSTNTTDzdzxmsCf r7fa7UaOYKmSbtcTTcDbUjZbCxdLpcldmrKbLSU7HUzYazTuj7fD1b7NWT5e7xcrbXLjbrDVCUOj PYLHZ93VKYUDEVa8WCtXLWvqgTiWer1eaSQ58V6XTK7UCdfb5fN02m1223rz8fqfR6bczib7JXKJ dzqbq6VyEiywXa5Wz6fb8ZjVZCkVaXXC1Vr2fD3ujYaLYUSQUTncLnYa6T7JYiNUKeNyaTCETihS zjc7iR6lQKmVpPvsUKIG6V5QFeVBLE6bhtG8uhiFuSpkmOXRxHaeBbFwVxGkWPpWl+XpHFCP5nG8 aRUE0UBWE2UxWEWSpXpceB4nquh/RsYxgk+aJmluaJpGmVJUlEZprGEVjXLoex6HqWpQFMWROk2T pDE3JJ6HcVpTjqU5WE8TROkmYhimKQ5MFKaZqmaqxBk6RJImYYhmlORhNF+V5cE2QpNHQdB1mcXx FGaYZWmwZ5WH6fp9NxRdGRrGxqGmcZ6Hmex6noeKwH2c50neZZuHQaZsHOex7n0apmGgURVF4U5V F8wx8Lodp2HkUhNliVpOFcWBUl4V9XE2ThcFeXxmmqb5z2KYhgl0W5TliYxYlyZh4q2ZRnG+YRqH Id54HouhuG4chjGocBknGdRdmYaxnG0cJcGCYhnGGXp8u6b5rm4SxMlqcpzXSXRnGmaRwtsa5tnG WpZGQXplmyVZgFyWZdlKbZoGVJJ6nwVBRmCTBIlqUJOF8ujZH2V5WmCU5bGSUxcmUbpyHOWRjmCc RxnIWmJmwZxqGMY5pHGcJynYdJ2HQc53HufB9NkeR4HcdJ8Hse1G6tq+sNvRFEuifjda3raBxsfx +LBsp963s2y69RGxt0fh5neepyG4dOzazscba3r+27Ifp+H9RGxRttmx7/sGt7HweyOjve/uiffD cRsboH2fTocryW8nedx4NMe3E8Jv+3N1RZ+7yf2s9VRuvHyeZ5nWeXObP2XYc6d/X6ZpuvHly7bG mYRjGgWpgdW25zU+UI+FGwzZ6weR4neYxjFkaRqFob5vm2dR7Hidp8Hx0/U0afPLF4YRdX9guscC fxgFIXheE4VRzQYXJnFtCpvluZhe6MOsaLMFLD3FiLAUouxai5HaOsd47R7j1HUPJjQ9Xyj4H2Os bw632l0GgNwag1hvE0eNCM2jBxqiVEqIsVItBUCgGCK0P4ohHiGFUJYLAnQyi0GeLoXA0RiiXF6K 42w3BpjPF4KoUTlRcDDGIKM5wtxrDAFMM8WYyBwjKGIN4Youhoi7FCLsU4sxki1OKOgWwkRIj6O6 1kaQ3RriJFgJUdzshSDFFOJ0wgkhaCtHEN0bo1Bli6GqNgW41xrvAIKK4VwthijDGaKIWwpRljXG a2gfguBtC6E8NoTxnxcteH24scK61zDPdgO0UYphMn1E0IYR4iBrluEKKASw7GoCNjiLEYYuB2QN EmL4VgmRbC0GwLsZDSBuDBF2K6UA6FZi1FqL8QwjhICHFSJQTwvBZikGSLJUqsYSNZGCNUYYkRZC UYCLMQInw5TrDcLgYoqg4iYDGHsTodkqCCFWLoVBthijWGWJAWAnVaDsDIJkM4mBfieEyLcSYihS B+EmK4PItRnixEAKMPgoRhiaEmLkSQzBwjODkJgQI52jteH4Mlnw3xxDZYMN8aIjRXiCMyJ4Mokw wC5GMLkS4oxNC6GEL8QAoRHjRRKHcUYhg+CkELNYRoyxvjQE2LgSIyhrjCHoPceYfBUBvEmMcSIm RdCVHuYZqwgxYCHFdGMLYlAwjNG0McPwmA0DjHQNkWY0IDUdF6NkW4rhgCseEMUfg+R9NEHMH4Uo irED5F2NEXgmxbidEUKsRgPQ6g0EmVQSApBFudHZOFrI7B2joG+OAa6FhzDmryOQcgzx0DcGiOkc w4Y+jgG6gweCFi6D3HuPQWwuSXCvEYOgdg4Bhl6GkNYV43TgjiHCNAXotBNtTHqMMYoxhTsKFqMI Xw0R1jTFwNgX44DzFgH0LIXwnxnjTF+bY0w7ReC6FOKMUsKxai4GrB8aI1RrDsbiKAXInhXizOwM MV4ohYCEYmJUao2Rai9GIJUXQuxUmmHkMoY8yxcRiGUM1w7VhcjFFMOcdQ3xiDHFIN4cYzRtjeGC Owdw3Doj6W8Oxpg97W0otNSoYYyBcCQE4Hcbg3RmjmHON54Inhai7EMncRouxbCoGmg8fkarSPPM ONYc2Xh1jlcU6seI8B5j3VIohr7gG8t7dQ4ZxYxxmvnGeLYdY7Rym2b1mM2jkh+5oHsewXbS2qld cQ2wfY3hvDVGiNEbeShx5qdC3lviNm8PtzaOQdg4hRDGE8Le8guhZirGYLEXRBhai6GGKxqg9Btw eGGMAYTrx5DQGwNgcQ5x0N6dPmzNzgsttZGmNAZaUhHCvFWKAbg46YFdbG3IeI9h8j2zOPMfWWah C+tgOQ7o9hrjMGUNIZoxB4LduCxrajZR8jgHYNtPg3B3jyHYMYbwvhi3kHIOYb5th1NCR2MCQ4zx mjKGQMcc4yB5D4HgOceA5RujhGeIkXIfh4j3HgQNw48LTDsHUOY2R3jajiHKOEdo9LRvsRs7Id46 x1DldeO42w1RtDNE0KoQcDBzijGAJdlgsJfiLDiKUMAqRhihDUIkNYjRSiYFOK4UYmRXCYHM1HYP VSurhGsMEYIt6WDIFaMUVIphjCrFOL4Vo3SHidY4MUXoyhfCrF+28UYnUdDNGhIYaoqhTCfG4W4a KkBVC1FGLMYQpBdDPFwKMX4oRZnaGmNYarVsb7gGFIEWQiRIB5FGKeqo079jOFkJYWQlxmjTGQIQ Rwhx4vQIGN8cI4VcCuEYIwQ40xrjOGUMUYQ1hnjFHQO4cwpBbCeE6L4Tg3x1jjNsO8bw8Roi2YGN oaQkRBCMFaKY14oRNOvW+V0bA5RqCpF+JV2Q6BVC6FMHESAcRVCzFeJMRYlumioE8KnwwvRgCQEQ JFlAsFSuQOrOrBphshmhQhahMBPBrBYBQhnhUBFBghHhihXhipCJKK9hQA3BWBxBkBynoh6hMhNK qhYhXiZBrhSBdhWhjhkouhmhdg+BdhGBSBtBVBbhwBfhXBohaBQibhthgBtmrB7B9B7BVhiBWtUh eA6hIg6hTBlBZBmh0hpBbBvBeL2BcBWE7BTg+hUB7B4NCh/hqNHBFhNuoBgLhhmhehFBZqIBfBNB qLphLhoBUBfBwBjlaB1M+CBhpBcBrhor+BXhXBbgwAxA0huBvhuhDBUhFB1ONC6BroMBGhohRBbh 4hkhJhaBRhjhfBmBhhKhiBcBChfuTB6hYhYhbg/hDhAsYhvO4BYBriZwAwAh5nZBqBvBlBoh4hsB 0h7B1hXhkhYhertB0hwBzNAO0BvDYnMB+FqszB3h3qVB6B6B8FJnwGmhlh4mfB4BmB1B8kLB9t5B 8B2trlFGsDuh9h6B5KuB5Elo1Hwh9B6h+mps/h2B7laFLnAh+iBhqBvhsBOBYhUBHBnhPBhhyhjh LBvhShRhwBTh1h5h0BoB3hpBfhsBUBojgnTx8CuhyhxBzBeBWhfBbheBghnqsFKh7mYhvrHi6B9G /h1h9B5B1B9h3h1B9B2h8h+l7B6lSMzR7mpnXEZGtjunLjoRYSiG3DoMsnIs3tLSiCBh4B0h2nuh 6Gth1jznLJQiunKmwoSHKHLHKN1Gmhyh2hxhwB8ByHAM2SlHDG2GvM9S0xoh6hbSInynnSmS6y7D aB5h4B5BeMGBlPzoGh3BtB1BuB5nXDbLEB7h3B1h0uLB5hvhuBrh5nojbFMhQBLhNBQhXhQnthth LBHBGNmBsB8lJs1BjJGh0k+B6B2h4h1BxB0reh3wgFKhTBUhPreh2hYBcBUBrhxBrC6DAh8TWh0u Oh0qVCBhohklrhjhkFHB/DDh4Gyh9EZh3lOB0g+BPA8Ktvuy7zuS7hshnhpBJBAg/BxhqhpitHpB ZhJh3rkhxBpBaPeBGl8n+BjhiBXBZhTBbv6g/A6g9hNuwhyuqNDFEBcCpBhhhhZoGBwBbhLA4hoh chQBfBeBJh6QuBVhWBSRDBuhMirBSBNCzBOKohhJlBUhVBhhPhUh8FKCBjAh5BaBJg1hiBZA1TLA wBghkBdExhghYBXBXwRhbBDA/hHhOBOhMBihgSQhUhYBQBABCpdhXBwBlBeBqIvB1hzEdhdhBh1L ZhUhZBQl/BxhNBLhJGqQvTu0zxYLaBthLhAhLh5Bzhym/h+BbBXBEBzn6hkIsBgBfhdB1TqBmM5p UueCrhQhFBKBpL3hzG5DbBxhtBeUEBPTkMFhShLhxByBxhEBNBXTUB10xBEBkU9hPhEhKiQhuBOB EBKhRBHBSBRhQhXBnhjhUs+DSh6BQBSBMBkBfhYBIhPhPhGBPBBBgBjhcBZBPo7hDBIwbhbhdBVh bBNBCVNBQBZBiBYhKhehZBJhfhbhKBWhZBGBchdhZ1lhYhOBeBbA7hHgzB0swhnhlhhHLRx00V5O qh0OphaBWBhCBrWh2hTBPBbBlhdvShtBxNHBwCBh2h1BzhtBoBnhwhsBshkBkhrBSBUBjBkmgjbK VTJNomNBvOGDuB9BwByxmsaKAC7O/hrhrTCElljh1BWudBDg/BLhUBOBWHm0WLEBdBjhpjuB8hhB jhhhjU9lnhihQBYqWBqhthzqUNch4EfhxBThODVhBBKhgBbhihclXBShTBghlFjpMBeBUBqBcBMB IBPxztrFKw8V522W223ISMlj0BpK5huBwykW3jah4m4BvB5hyMzUzW8XA3BXB3CXC3DXD3EXE3FX F3GXG3HXH3IXI3JXJ3KXK3LXL3MXM3NXN3OXO3PXP3QXQ3RXR3SXS3TXTiBiAgplbmRzdHJlYW0K ZW5kb2JqCjEzIDAgb2JqCjE0NTU4CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+ PgpzdHJlYW0K////HFfg+0u+8iM08AEc2EoD3xcxehfbtPQV/NpbK6wfUMh3MMTC77fmI6foQIAy Q2BKddphUY5WZoswwbfd4QelWThqHCchAkvJ6otJHc+qZ0WEyZYTH/yeUL5WLaBd0/mVPRW8XhgI KAOUcSFjHImooFI+tHI7UsP6qPCbBsOVnAGrWWDDYYjH9froWBZyAbbEQGo3fL36d2brEmyvqAiw U2EQF8OZ3riTxxCpORJf/lLKNs+IMEbuHFlbywFkfFTGjWuJJkpBuRFSYktlwkm3jX+GFbDNBMwm YJgnxRV8i6PnFMkxVoNDqOaODanYxTZXTEwIGlHVQLJtaHeD5AImzBfw/m1zQRZa0CQDqOo6/zeH B1HY3JGLSvoCzt4E9Ksc5amJWeqgs7rEtmKv8GLmeGo3UEfJ3JLD3mCi41VO/zr3iZPiKUad7v0A ne5ihGbNu7cUhZOmSXEG7FRcOlSWMt0pFAZwsvVtspNbFRfC4tN591gMnaJ9pI7SAMkml/sDwQ8K McEAn3ST+4mrvWx+NmPXQwF5waYIk6fRuj/MvgDcyTKeydESXM2cB4sJhsJtXQVv18YV31q9sBX8 fdP8WZ0u92YACsPOp8tZsFEbHa8hjIbnomVCXxZXXJMrWe3Ih+UviO/yV5e9sEcPzGW+7fFE1ZOq GPPAcE9UnKhBZTAmlLkWhxCtRMH0U45ZEnxLVlLfAGrSwdsiFXfLVtz8fHG2k/jHQD2INZEXj6OT 2/nmuvpQjbsrsNGjeyeAd6TxLTfp9Hgmfa63lT1bKRhVD9NPX2ALixDcL4wErwSpoDLhiSdasKUI aDpFw2NeGHIyaNKSdF2jUYwvVjs0/9xm4WWNOxYyQ35tiULQ6FtCGsQVrThyUIr/gOA7tOAXG8F9 qfyT3D8SSchVGbCwXMt0cXit5Mk35EkYH/74Nxq5tcO2SZ/1W+i+sAJvYV461tCzg7R8u5jF07jE zPDehqWiPO9BMkoq8PssYF2LmjNbTbcQynKpj0ZiVBJSM5j4CmVuZHN0cmVhbQplbmRvYmoKMTUg MCBvYmoKNzY4CmVuZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEw IDAwMDAwIG4gCjAwMDAwMDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAw MjkzIDAwMDAwIG4gCjAwMDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAw MDAwNTk4IDAwMDAwIG4gCjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAow MDAwMDA5ODQ1IDAwMDAwIG4gCjAwMDAwMDk4NjYgMDAwMDAgbiAKMDAwMDAwOTkxNyAwMDAwMCBu IAowMDAwMDI0NjE0IDAwMDAwIG4gCjAwMDAwMjQ2MzYgMDAwMDAgbiAKMDAwMDAyNTQ1OSAwMDAw MCBuIAp0cmFpbGVyCjw8Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0 eHJlZgoyNTQ3OQolJUVPRgo= --------------020807010003020808050700-- From nemo-bounces@ietf.org Sat Jun 30 05:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZMZ-000570-3X; Sat, 30 Jun 2007 05:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZMX-00054w-Io for nemo@ietf.org; Sat, 30 Jun 2007 05:35:29 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ZLl-0002RF-5R for nemo@ietf.org; Sat, 30 Jun 2007 05:35:29 -0400 Received: from [163.117.203.82] (unknown [163.117.203.82])by smtp.uc3m.es (Postfix) with ESMTP id 4A87B259E1; Sat, 30 Jun 2007 11:34:36 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Sat, 30 Jun 2007 11:34:51 +0200 To: (Mobile Platform Internet Mailing List) X-Mailer: Apple Mail (2.624) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-20.3947 TC:1F TRN:46 TV:3.6.1039(15268.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF NEMO WG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: [nemo] Re: [MPI]Comments on draft-eddy-nemo-aero-reqs-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org catching up with this.... El 07/06/2007, a las 20:10, Wesley Eddy escribi=F3: > > I understand that the MIPv6 basic RO security isn't IPsec based, but I > don't see this as a good reason not to require the NEMO RO to be > securable through IPsec. The MIPv6 RO security wasn't built on IPsec > because it was felt that the needed PKI structure didn't exist. With > recent work like BTNS, I believe this concern could be revisited. I am not sure BTNS could provide the security required by a nemo ro=20 solution. BAsically BTNS is an unathenticated mode of using IKE/IPSec.=20= The whole point of RO security is proving address/prefix ownership,=20 which is exactly what btns lacks. I mean, btns approach is basically a=20= leap of faith approach, where basically it makes sure that the=20 communication peer remains the same that the one contacted at the=20 begining of the communication. But in nemo RO this is not enough,=20 basically becasue the one that initiated the contact maybe an attakcer=20= trying to hijack a prefix. so, i seriously doubt btns could do the work=20= needed for securing nemo ro.... Regards, marcelo > RO > security based on BTNS seems reasonable to me (for both MIPv6 and=20 > NEMO), > since it could ensure that communications through the HA are with > identical parties as those over the RO path, and it leverages the > existing IPsec mechanisms. > > I would like to hear other opinions about this. Particularly, answers > to the questions "Why *not* require securability via IPsec?" would be > helpful. > > --=20 > Wesley M. Eddy > Verizon Federal Network Systems > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > From tvzia@learfield.com Sat Jun 30 07:38:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bHw-0002hX-7b for nemo-archive@lists.ietf.org; Sat, 30 Jun 2007 07:38:52 -0400 Received: from [12.6.89.241] (helo=olawf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4bHi-0002bm-A3 for nemo-archive@lists.ietf.org; Sat, 30 Jun 2007 07:38:52 -0400 Received: from usgwh ([64.65.201.235]) by olawf with Microsoft SMTPSVC(6.0.3790.0); Sat, 30 Jun 2007 07:39:15 -0400 Message-ID: <468640E3.8030105@learfield.com> Date: Sat, 30 Jun 2007 07:39:15 -0400 From: Underwood User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: journal-BWLAJD.pdf Content-Type: multipart/mixed; boundary="------------020402020607030208040200" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 --------------020402020607030208040200 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020402020607030208040200 Content-Type: application/pdf; name="journal-BWLAJD.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="journal-BWLAJD.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDQyMSAxODldCi9Dcm9w Qm94IFswIDAgNDIxIDE4OV0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo0MjEgMCAwIDE4OSAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDQyMQovSGVpZ2h0 IDE4OQovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp0Jb0EO8vYE6LcEMUmR tPrlAJwEYFhhtbiqUgjGkZbskII8utcIq8DqsltsTsLArNdjhiI99MVzMQEWpOJ0CqMEtpQgoiht 9vrqlIXEQ3SgExsWvMCfEiYzGLdzg+ZleQhRizN1gWiieWtkTx1/0F6jGm019gVhLbGWpJAGFglb uMDAUNWq1x0r4cEqt3xF9YHBAHPRpYhex3gAzcCqcZI9zzsELCNq9Z08D3O7gdRYx3t5QAXviOou Gm1PKg2+h2kuVitED7rcoW0T5Nkiy3v8girvQwyovYgYoMUhxaom8jbIocqCru5iBOKWp0D+gZ0G 8dDPuggwjigz7noE64AMOgQts+AEIIfCTzPM6TwgAzLMxSLcasIfBvG8/sYGBB8LwdDSBBuJMJRq hKtvFHT/QGAEnsMAD2RKYz9OjDLMuLDyxITEqMLQAUHq5Mspxs58JCSwjDLRKSHhugRBIHD6BRCd DouCLbaPpF7cIa2IATRGyBztDCCT6hLTC2LAsLi4L8SHLS4xDLiFxYAE9ABR0/AA6j6xfSUYytJ7 sv626By5NAoLmYACBvWtOoOuLpuDQT9x9H8g0ugg/1DGUb0UJJBFrISFV1QFS1HGzd0s9a12HIZ1 OSpsRxUgdAxgABlT9BKB2AiLfBkgcnrDa0RoE6duxeLY7mUv6GQNFwACUgj8PTYTSwRZ8nvxIjP2 shQbhkEQLnVdVG1FSbU0heVWoG67soNa1X3cgYnUWhNQ25Z7tXpkMWXwADoVYAC147hOFuqtWIR5 brn183onWBVjg5OpV2PBGFBXDcEX4rOKILJjzGSw6M9tu0C4togV+IRk7Yy67YAUWC9/ITUlSrNi krThnCBWpFKFFrWuEaVFq5T1Pun26vN+P7TsXRTgwATxdLq4cgevIHoSzoTrFPIGdW9yygl0Icq+ vMySj8QTaWyO02VDVbHNS6FoUAFrsCHb3FmPa2AEkLnIR0UJF+ooZqa32IQQlCTWsl5dhiFNjqAx GVyPOt1VUhGMRsDILfVFIHhZanKP65xDu7w6BkS8+ByOBvtts7+OhMkaauSDNVNiD3xvEQoH2Xad qhLY7hRMdMzcLn+rfq9Rnv1uRLcIncE3W+6W1hjzWlSlVT4ol6RCXqqWew4cO6VwCCUYQQtYjjz6 OcL+gAADoHskIS6x4ADLlithacVcshonQPySuzl4ht1rC1S6Qd0rFE+PNYA18g7n0gEDeIVdq0DU rmhNgMBPqoU/qBf04NqRsgRKwUEaCGiJTyKMWYeJ/DxIfMUUWcl8KnjcQrUfCgmjvX9r1eAYRqZB V8Q/JMkB8iKmeKFLC+Y80O2oK4jKRxB8TYZlzOAs5HUYl6N8L1BAGQ9FEPibap9ohqozkGSGW9Qh ZIfxZaoh6LZPTaRiNuedAhElIEzUIYeLcmZOlEg8U1QMpUCRvlUSOS8rZYSxIfKyWS6RaqoIrK8h MjSMy0lrL+YBNC1CNgayoiTmCGRqI092YMzZnExOg8UhiQioyKIOMoJxlSBOREocVvswyGy6mfOO chIZpB3mKQMywN2FHpmostwzYRjAENNNhQ5knIr7jHDqKi30NmeUNDGctA6CEffCzWYh20SQPUW4 kbySEXMzXhIggQQjitjfcpShItWVQaoLR+kBFYzlvLjA1RMHi6ouoiQeZhAj5JPNYghbjhZkUhpt TchMandMbVcs8ETe0noumZHxPJAn7IuVuu5IpBZlU4qdU9fBvINFkOgdugBgVFwAndQ+ejZXiCNP 7Io/QQnwLuTpTyp9aa0gCYYkKsi0hKBHdLSQgc6S5q2ovVtfDwlXUPD+GJGcaps1yEE4lplarEVO QfWwgdFnPvJhqo9WgAKkkMPCMaXyG5uEFmlYmz1n7QWhtFaO0lpbTWntRam1Vq7WWttda+2FsbZW ztpbW21t7cW5t1bu3lvbfW/uBcG4Vw7iXFuNce5FyblXLrUJSC7/ZWh3dokG5lxy+BHNhLAWsVrK lFqbdUpCayESnaPGgjl3SH0eJIx4Wod1JKSIEAIyT6qPFZZOWub14CmuFpcjpMaS6REFnFZ0uBBo PXfwASd9TWTCXtVIFgZ4gr5LolOVs1Rb8CX6KIYO7Z+woF+RfReALN8EYLQaswh92MDKLwWQgehB ipiNHVeoi6V7yLQfOAAejjDeoSi8ytwGP8NFImIcY9KoUIQXR8optQNz8XvVIAIEWFGjLgCde2fl XzEAAGMOVFyRobvpIY9tjk2QRDKaEexzSEzrEHX4dQJWEoP30MZPazmQylPFPkcFKtlHkG9m6dM6 h1MJGMUXdh3mdjp5an4OodQR6Y3iugQtwBAgZMeKzmjK+JyJP2y5XnJk2cO6DziABtgTsVEG0rng ojxS3vdmRMZrKtdRMrIEJ6+JAgCAEL8mAhBa1WUtm3BeZJBrDGWPlLwhkUH5EEyaotGpZHtgy12f fBGrCfBiRhlot5qEXUxfDs9OxviyKkWBrw1Dgs7omIMrPYZCW1ZVxwlimJFsvEExohLBe0Kealnh RPbBRpsr0f6W9F2kHUkDvVjZrO60r8H4VEiHVmBvb1XxjRJeTSpb4OxlviOKbIkEMO2nBLfMfuVA AhXgMpd0chQW8BO0p2wHsEbDidRr192citrIiy/Ctw4XLS5Xk06YupM+axi7/ZTp2o9UHldBFgcj ILAEJOnEF71aGS14lj+b59gQlQAnCQAcWy51PhvG+n9pInZntVaWLoWaoPjG/be6EWgbvLoS9r+X xWT2zuvfyGPp7wjghUVyC948B4kiRW+9tGZDjDW3h/FeTIoEfRyBoNbqhuQY3kZvKefIbo7yxBLD bKv6QWH1GPQerIQWhwpb22a/IMu9DfrPbMcHwkFlR8syRnTKlfDPt/AO8nyb87ejjhGSRukrlJfT i97+F5+La1HCnvWzk4AkuENnG699H6O/0D/e/F+P8n5fzfn/R+n9X6/2ft/d+/+H8f5fz/p/X+39 /8f5/1/v/n/f/P/wAQAv2ivoLvgiDPYoNrer0H3HviHthCMMhL9HKKumVodqiD7OsNPMBCdQHilK yCFvfiIO/CIl6rXrxCNI3wCkpFDEJJcJ2CFQRiLQTvSAlHcH6JwrAFsiotQDLDpCGDQGPDIAbrqD DHmJxCCNri1OdJ0Nrmsu3koKinXN1mUQkKAGpQXwaiKJrH/CTwRvTO0CQIXokkbKzovKODopxQYi KpoqetdEmL2kawhpqJpwjC8q2hvKLLKJsp6HdQfPamAoGsxJ3qHjUpHiCQjIQiEwKEbpwCFkFF+q uQ2uyluj3IXofm4qzQmC0C8FaEmoAOgiFOeCEuMJzEIiGphp0CPrFkukri2rCo+jQQmCGE7Q5lyK +D0xEHQrDRYkbi8toH0wniDniLMEkE0ksQ8ptnzo6QLxJuxr2OzksKHw5DDxhq/QpQpiGlbuop4G Li1q/LAKjiCnQHEkSIrErIsPtxgRohymPHhxhpko1E8DxQZuMkmiGvwRiJrFlCDCzALrCl4w/COw jKjw8DiizR+x/i1xGm0RgEXDdw5F3LLxCCGhKPYyFQqvtQFuRJHnNJmDhkrknyLGwmsDoE7I1EhO anaGlmVxRQkNjCIOsSVGlj0QiN5p4iBRLSDm2RloSQ/q7w3kFOouajNHhQDPwCBGFRXvgxOMWiES ZMuNFrMCCD3CDIcSKq5iRPoK2FlOpIMk7qlFRGDnRm/jwkFRbvoCEF+RyIdPtlWOsCEmTD+nCisx wwxyvvIwqQ/j6oPDeQhtBGkDfppx+CBsyMCiCFOmPDqOHm/KjCDK3iCKBIeKeEaymEmEVzEmKiIQ xMqrDIbqrixlyDwQNo0QPjeiBKBCPOeS6QdQxyEDzQZjREajworC1xpiITSyvCBHtjzj2SSM/tfy UwhmyuROxiCKxuOG9AlI6HLKezKjePgK0SaiDxVmVIzSKlmIfS3SXRMtnTAiBthOKF9yrnZPIj+p JCCDWFOi1wDSpzHTkCETejiyWzvRzwbyVnDuczTS7iOIVTzkdEIIXjCnXxQzum9F0mwGkThCHTqj CSrq6yHwkKOPtIbkGkau3ufz2mykhB8MqykvIlOqrDPxfFkAlHNL2utu5myjTRjFyPEOp0TzfTfy 8F3G0yIQKvDMcvD0Gz9sEsi0JS9F8uP0ZvWiDTqiFEWJiTQTmOSq0EHTiGb0diO0augtgS6LzGpl siDvXkNnEBBBniyNNutiFlWNPUOUBO9QmiMBBB1SpCMjinEQkMr0hiSkry0K60xOXwIsazewGD9M i05EoUfUMz7vZoGlarvknnEsOOaRbRDRJUDDDUOQuyXJjQxNipBMuBvEJHEu7wmmsQjvykrmVUvP gyii3jRVLQaUMPZUgU/wkFazpS5qcR3KTQBCXBayk00rTERU7LkNVpy0orVwviWglUvrP0syqzGP AVdCNseCaVNLCzOxTCSx/z4CXpfHC0LqyrypdiJQhzpCJRSJYT2CNhahBDJKX0+CVj8VmT6CREgh yqm12iJp0Uksy0zxRnQHCmeJlCo0zCC1kPJCIsi0FCJ1h172Digkgh0PaRmuijsN5VBCGPdVzD/B KHIssCVWE0wiCWFvaEnwjz4iFGjVwRkiIjLDAoUvPF3IfRUkrNaUXEqGwEnuSDwMimVDighUNsym DiJD8Vak9tFp1VMBvRgksvnl02YDfGcEhiYGPG6VzDki2sG2kvckXC1qY2cm1KXPLV1CFoz0stlE REoy5ngHkNUDUGsIAMnMq2KWZWqEN1vjDmvWcAAAhH1W0B1OrOzGOFXWKkIV9WO2F0Hp5lBBa27t aKXW9Mi0lymiCk8MPzcksl72GM1lnzSvEWkC3ozPTD5RP2PUlkwTcXFWRXJ1DNx3OWjCUGsD8I2H +k0C+2Lm/0iq6isTMkvLr1U2BOJOUt4WrHh26J6AxG6laiww7VMWCWno2UeINNK2risXhq8gb3jO VPIW+mb23REoNVDPcyIw2jRFFi8DHjt06wYE7pDy7TQiDxRJT3F0cXT2YlDz3gsXuDsr8XeIRXyL 20+XEz9CWmsEWIzLti0NJjUIzxu38MgEU1QWn0m1pS2Oz2rpijWNJo60gPG4BVCT8zfpjFWC0Ltl Jr/sYTeyZD8KwS9KXruDNTvOeHAC62aVekntJ3evUVWVk3bEN2f4SUUvdmOLtpiGLCoshS31f3yk ssxCXx7WXNZsGsYvSTfkamsF8HioPR6DtSHtoOaU2iD0EMEpHxzTi3ay84aEVqmPBNyTjUCxzi1w nkDDRVfkVvn2XIPKrCo04El0GsOs/Q21TkNs1FUXYjCQFm6CCWAknlOxRDVDoDUEm3907C3nEoPT awEnFKmHsZAgnTn4r4AiWCsqquczFzTjJsnENruR2kTWLtNiHWvMSVelF4uxoHh0gOZwG2TYxLKF F0w4Tnk5RjCtA4gX8BjAj5UrvoNYolFYTRmgAIYmjC3lVqvr8oM5VC5C+XJCD46UNEuPStRZnSqq OZh5br/5jKcq+5eWYIdLpD0x3C35iNOXxC6oUMT4kCUsQF03TuY13AlL5TxMfTviDvRVxCNHS5X2 WHaBykkTcDSWML3HHiCzeWasGVACCZ9ZmJs0ZthMZNHl/wGw4WtmpWMiBBn6KDJ30msMvBjXRiLI PDfYtEDX+iFXEMZOFNNr4DUi/YROp4mnjL5QEMbaD2mzjZh6AjYDg0aiWHMFfDr6Vihhn2+ErIVi 84p0HknHckVV5wQCKZFjzJvIPLyFJam2AinIrkr3qGD6PCZ6r1bP7uasOU9CmGp44a1JWqvoGkKw 1CfpT64mbxha+CfMja5V3YyCSPuiPMF6LCBNVtLs3a+ie09a7iH1nCh29wKiSM4spbFCjkDVyCMy 3iQ0IazplWAuhqlNGQK5hF+0RC3N2OeiEYHigPijf7NiKjphPbLLws7khOLFtiN3VSYC+7OziXpO MiDtV3qkNl6J/Ubp4NIMvF25rbHlHlwbYUmkW7oY1Df69CBH9BavNCD7fwOqDFcR77diJa0idKPK vqwDD7fuxIM1v1X3HZLWmDEJ64cPI71OK7CDsyu74ppI3r1b02sH6DobeuM7DtbObEqNEN1ML7/E RESmcuM6zkrL+WmODp67pnx78s9lZ6ApTtogsOuOPCC7u7vOwkRNnWrWeiCjqHIu3teuI3oiCzwi 2t6qaiMvNZoiybc7fk9ujoIOXji0U3Jua7YN0NU3/NoudpfOkSVsbsaJGpGMr4f1Hz77gMmaPX90 8bqvw307qOx72OL25NP6jYNwKugNdDUMBg7zwtdOjcbxoMAJu16l74uR7t0NI8O2CsVsTOaOuceE KoxWVwKpiSpOyCQEBufWWOKDWcTosOoz58gTo8eOADfDi70iFFiOOzhsDbGcRisnQaJM9MjxHONa 90l8jb7VMVHj5CwqGYNUmMD4V8uob70msOW5KcZsEuY0GzLczOAEoc2bcp3FHcr9TNAYIcXdhln1 2YIYeiQOsN1Y0RJb2C5ACGO2S8R49ua3l2uI/30sMusWH9Ot8EmW99AH39BZbxcc8QYEh8hbh5bO toc9acvU583ERExu5qUO0ZQy0p+ORByteCFjDj+uYla3Yxsd67Gc2DEdHOv6nOz95uUM+4BDtxvb wCMQntk6PuaCyD+9cGVchkr2Zl0l+NkHAnrX44wz8Wi1YW/Z53Y9JF9yasQHBJG9heWZr51OMkOD UE7L3Y2dKd07pnC9b+eIN79jdSZeSUl3/YuXOEn+PyJrxjsFli0FOof1+nXUTsf71tICodyPT9Zd Yd1DtdbCTt6jM1Op+dhEkETgBO+iFVnEa2LgbsHWOvwJ6z5iEu+2ip3ACYZiPi3z5+XUbC0NLlOs +jB75vmtEU4+uq++BEK+/Dstz+DZG6/3tkAhlPXU766d3DNyIfAha/E2ZeZu7uUT4DB5KmV+3djR pjLSQKXe7aQJG8FlWZVbZCUKLl+XOCFzcDUB1IVlb2EifAbwmRHiEcVD+qm7CEI0IJ9V8De74wkD jiOfkWgN4EQWkxkWuPLTa22fjYzeV2Fnhip9+XFMhJGmYsZC24jOn/IiJRRfnvVmSGYgANHgjkOJ B24CKCAMAAQOCQWDQeEQmFQuGQ2Gt6HRGJROIkeLEd1QNGwYnRSPR+GGKJrUkyCPk4nMqRQMsI11 EeTQ11S+MzGYsAxGJlJSOyBlTagUGCRuhR+BUWCzidTyBrVjASMRmawQLgBKQaj0iiz2Io071qwT ZvMZjV6p2GFgSCyuPje0W+BltGy2XzBawt8XAAWqwgQxMClQOuABjAA71NGs8AIKDWy9W2KUTH5O EYOvwsRAAnX6C3KWwW73PJQmfwidk684QAWahs8lACqwO+ACswvR5SCYBgZ6NzCFSWQRCG5mEbzQ He5w3S42C3ljcgATTV4qBiK3QzfR8CbrbQaiYzrYPAXKDXeDySUQ2RaeC8jDwOzgDiXrHQTLgDsg ABAIL+GBt03bJIsWpaughT6v+pSdgAfBvLG6CaHURoBII+Ytu9Aj8vugqUJygifiwLbaqC2q7ou7 0NoGnMPIWwaCQigcKIG67aN08j8QHAqQoQwCcwWvMHsM+CMv2hzzI+ZS5xEhThII30Jv2/rZRE7k nIOlo7wIq6Ft1HyBwbB6NvjGS9R6nSCSa0cioG2LNypEqCSO4qECwtYAQWgaIPuiyCTJGkat2Yzz Ry+8slqRpGwuAEVs83MvJA2baC3QRaw029EC3FcDqWyyzJhGU1s0Ak3oHSiBvy4tNIJEMqtK1LCv hPiGvHQUnQJFKD0Y28OTyjVTuzGT5togtYOPRCvIY5L/oG08wSE6MYsov8eoHLYASa6NgTY8Lts6 rs5tzYaCI7bD7ti/SC0io8M1k1aCsktlFCPaacJBYTAIJYtTqxG9FR5MyCwc58xItc7YW4rNAzkh LRX8AELpfcM7y++1kVnACm0rE+GUzVSEJWnrhNG2MyM0pKDoujFduYgiVwUpjhMu+LJqOtlOsOI4 oWigk/xGhWHKIxyYMctSuLHF8+oLYVvIM/N/TqxtZZ8iOS2tcUrIMY0RYchFUAAWqUWc9yz5K66j vGhmuRVFTfPq80GsJXCEatq78Z+glMoUgQxAIu+QoKmudKpk7yoLr2WX3Rd05NsTJ6FZam4DuLJB qKD91DuqFrJrTdo1jsPPygVBCTsOK0SYAa6TiXM7tfPVrWnNUbUhXBTZwnXcIsnZ5ag9/PTmPKct y8E4xzSEXgkXZa+4Fr2whODbrfWs63ZWur/h9a5M+y49R4U2HVKr/0nDKGahtccXnfHRs1uDH0TF aV5zKnfITEQodqgf8IY3Z0Wxhr538viLu8xa5z2HkECgOUYw6gBO1KyStAgtR0B/Ky85dyi0WAAC gkshzDl9MJJwDd5kEzxjoIWWw3z80CPagK3gYD9yCv3Xw/t/g3oTQHd4fVC6I0XEIWKzo2qCCCv9 hM1NrDV05JpC3BwwkDIYFJDFCJWbTIMLtKzAQvSSmHBiC2nVfzCzcFaGAH9/sMTdxMhEIJOTPjPR LLZFx8xDENh/IKmSJYwACJ/Fqg6OhC43QZCwiFYacjUlBj4YCPpEo4tfIbGQsZGYZR3jDJOShSIj SVLCAIQRryPvUcQQ8yiSpMSURFImBkm5RyplVKuVkrZXSvlhLGWUs5JmoJMdc2I5Yhm4jBLSVj0p fEeaXDN18qZiTBKALVuhEy+S4duUKHpBJEkTXpMgrUhSgRCjCgQJINy1N0CgfWC0mJwlIbATYSgN wZNLKDMAiR5ijzqgRM8oZI27kefuTmS5DDllFS3OwrZRWSlwLK6dfyiFDOcIJOuBpuZ9yToGw+Ij eHeM/ncRKO4BJ0laQQ2Gca73Im0o0QMeidlcsfUWnhSRHG4LFBulQhoMoETan4WBRUyybEqdEQ2l 5AlFKGX9OkGQ9KInFUwR5MFBXX1ApEVeocGn9SqT/Bg3aDiBy6V8ipjziiTIbNrUSJ6eUHP+UTVx arWUCD4PTO9h5AlrUNINWMcpjnPosJSaAWtapbGEUTUctMdatOdV6XF2BETUVWM62ikLu641jpAx 1FRpyVEMLKXKsqASvHmRFRqqZCBvVzi4RtC9WyETYpA3gjahocVClgiOBs4Q/1YSaStTDHqcUYIT ZyoaMgxWxscAC0FlqTMthrR9hhTY0UyIMOWsbzl4IfduN41KDS/xLbSQUt1YLYWDuAu92ZKXrvNr 1IWJamCjlEl6Qe31iIMWWtGh+25BLyOePGZK9Nnk7XugyQiG5B4z3mqzPCPEsGFg3BEBe19VyIWI i4lSN5MXdsOOuyW2VFXcEEEoJQv0YyJlZSy4uk9KCDqRatDevV4I5MnnTgeuEiXnNqR9hktUY3+j 4kLTqrJFJ82xTRViA8QSGYnNLeV089SIzTIhXOYpjcaEcp0hcol5zDF3iZKw25tVzkix9Z8P8+k4 4Qe5h5wifyV3Mt/MVohEzRmjdnUVa64IAGcABf2Fj9ViI1s4cScuPCCzTpCswq2G4yIcxQR7A2CJ y3cABHReN9yBv9hXoDIzV25QxcktimhmsNNuM0T1Edimv0Xkq1xzgW6Rox0Tm+aWS2JkOtooiiju GHGxb5ey4GXbw6hL8me3FSyEI0fw86fUMyno+J6X8nglNHQ4NWRtORsyq1Rgsz4xxbEttgmjdc6q 51I5J1xMdj4wNklNJRji+l1jMaIb5qqq8JyEk9hWi7WFp5VLHyqllrRBlhXNvYgjYpDiuWCrbeUy 7nI8E9wQOoYyTa5TTiWU4ik/co8EKwAQJ2BnJMBHLrhvHENrH8oAd7ABqw774d9xhNFzbhwH2KTo rgItk6RInwbizqrBoOl1pnTXINrno5Eysg/F8Dql4yQm9K59lML4FYSVd1d5kU4VYjhpnSyJGPQZ td+RT7FOqDocQTMy4XmbU1uSvTjOlyRS1zr/C1sZcy8YThePkYn9vjHLiBWU/6iU2Tlyxb2DXGUk WSz+FirTWLQATlU9CFjeCFAMo2psV+G8lY3wfkyC3M43K3YYW86eW88R5znOvP+j9J6X03p5X7L9 R6v1nrLOpMaz60h3QPZe19sXp++biQeiIJFj2nulIEGixPgo3t/jfHLf252vqiF9cXqQuQIjSSaK k+UFrnwyKZ+W/8j7n3SbPmx9VEjpKG6KJUmRqhKyaEFEJKs4gkZSIiU6HJwhHMt1kx870XOpjPvf 9/8IigsGMQQQcxOKok2syz+IakWUQFqBuBukK6enm7WXGJQCc/kIUPc1CwkCSlQrOOQMkWcvQKcL Y/4Yoww//BRBSINAc/cymIQKmkLAsOIk4+YIHBKMESOiSIPAEDEfu/4Sa2yRma+OgSOsyFqHU/4s yCcR0+lBYZFCMgANUXHBVCpBQCwSzAc3o0sMq/III/o9e6KMYNGQ2s6w+fOAE6i8AKIOuPvB0MXB KLvByOuYE3mSOrC3ZCrDy+4l6nGncOFAqOqk0CU9pBsKcG8LuZKTkVwX0PNB676IWRlDW0mMW0UM UQ2TrAbAesRCNAEcBD1E++Qbk9eblDQ4WrUXHAuOGAvB+IKOobAQKNGmwvRB4qiV43oT+S3BuIy/ onOPvCyIHA+kYnnFBGI9q/oKaPcYW0q9y7AI8MG/4Ge+krXAShvCMzkMqIMTJCxEyrOTQa+EEAEC VGi07FgMvFlGLHQ9uYXAqR0mCQ2NSHRA/DMvxFsIHEGQMAAT+ZDEPEo06I6PNCwxs8BHTIJIKkoQ bHildGTINIZIbIdIfIhIjIlInIpIrItIvIxIzI1I3I5I7I9I/JBJDJFJHJJJLJNJPJRJTJVJXJZJ bJdJfJhJjJlJnJpJrJtJvJxJzJ1J3J5J7J9J/KBKDKFKHKJKLKNKPKRKTKVKXKZKbKdKfKhKjKlK nKpKrKtKvKwJAICACmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKODI2NQplbmRvYmoKMTEgMCBv YmoKWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAxNCAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwK L0ZpbHRlciBbIC9MWldEZWNvZGUgXQovV2lkdGggMTA2Ci9IZWlnaHQgNDgKL0NvbG9yU3BhY2Ug MTEgMCBSCi9CaXRzUGVyQ29tcG9uZW50IDgKL0xlbmd0aCAxMyAwIFIKPj4Kc3RyZWFtCoA/4FA4 JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGH9G35HX2/H3H5BHY2/n7JZRKIHJZE/ZdGYE93w+Xc8Xb Ln5K42+30+oY+Z69HrQ3k84rJXs9HnLpPG3m9nlMIJJn6/J7A5xQqK93lTJLDJTG5c9nm9ITSHu9 Hk9nhX6lb4nH32uGMul4zGEtWEtFWr1uz2i1WWymc2mo03C23C+ny+4G+Jmsb03G44qA+Xk9Hi8X m73e8nc2nI3nq93rnJvVYG43E6b8t3I6W8zGsuHM53Gs1ttnS4mWy146HI3YG7Hg7WEyV6wl8wHM 5nU7XY7nHiXY63O7ng7pDjoE63Y7VstVW33A2WwzWEu18rXQ7OE53Cvl0sWq122wF4wnE4G+aRmG aeB4ng8xsu0dZqGobxtGsbjHnwexdGAVpjmeYBtnIbh5NOcBxnGdp3Hebptm6452HC6rwnUZ5sF6 ZBmmHAJnmMZRgH4qqmF8YpcF0ZBYns0yeHyecinoeh7HfESlHmcBvG+eqhLgjKenyVRZE6bJvGqV BZEuTpTkcUpYFGUZVlYTJOFGWRaF1HKBpCfJpGgbBlGEappmkbpZl4V5RFeTBbF0UhKlORJeGMWR FE+P5zHWcyBs2eEAmabTDGaZxfG6bRsFmVlEGSaZXlgWpkGWYyBnad51GCYZYF6XpWlmYZfF2Yhj EGQpFlOU5SD2Pg0mmahmIGbhsnGTJIlsYRgGSW5aFYURTEWWhcFGYBiFiQQ/i2WJclmXpgmMWxbl 6WBaFsZhomaOo+jSWRXlKUZSFiX5dmagZ7nuexnGaYJgGAVhjGeYJynQcBXFwVBjGWYhXlkXESG2 ZZmGYaRqGkWpdFCXhdFaS5GFURpDk7fR8KYZRjlmV5VkmaRqmObBtGgTRUk6TpSFONA2kCWlylwW 5bnOcx0SmjCQn4XBbGKYJiGIaBrGIYJjlqbpxZmbZpmOad+4uex8Hu1ZvGyYBcwqXpbF4WBbmgZ5 p5kcBjGYZJjGcYZpmyZhJk8QB1HScqSnGcxxFoXJdnW8CynieqyHGbUUnEdZomkcB1HQdyBnyfK0 noeDtnUaJvmuZ5uGwMhDjzQpQkgSRLmubLiIFJR3nEcJ0HKcp2m4axwnCcRvnIdBwngd50mya5kn Sdp0cWehznSdDAGn552FMVxazwZxeGAWJtmwbKBo6fh5sydp4HSXpkliaZt7caZkGMZBcnEdRzfE X5gGOY5lmsbpsjPHIOYb45RujjGyNYcRLiUDUG6NAXoyxaCuF0KAXIwhYCtF0KgXAyReCIFCJ4ZA 0hpjoPe0YmBJXBjjFyKkVA5T+jyQGkEe75B6jsSUMYaIyRzjtHMR8fRnx4jVG6N4ZQzxsjbG2OIo ZXHGDoHMOMdI4xvj2iodo8LxB1juHbCYhRTBzDuHQPAtRkB7lMi5Gcgr4h9E8i4SUno+EkD1iASU e7m0cD9jQW93zvhvjfGinYXoqhTnrFqKwVothci8GCJATomxdjCGCNIwwxBnDGFOL2CLEGnDNF2i 8VAsxfjHGELwZ0HBeCzFMKoTgkkPuCHOOePMsZZSzlpLUio5ngiwFWLQWQsRfCsFYL0bQzBnjmHC N4aAzhlSIFqq0ZonhQC1GKMoZoo1PDVGoNAYbHRfH0YgLBJw5IqD3QnJYTQo1HjjHcdiW07Z3Tvn hCYpjYB8GMH0PY0pHScR3jwQJ8TjGTkvIQVZzcVC3D/J6Ps0o+SqRmnjQ+iFEaJUTopRWi1F6MUZ o1RujlHSHjidu1AZi+h7PhRxQcgxKCcQKI2Q+BUCiGDiiSNWSVDiLT6H2UCe49acj7X0PqfRJx+n dKoPkmc9qPVJooMN/AvBfC4koMEZg1RkDDRqNkbI4XYDrGqNkcw80RDqPMM8ZQ22KjSHO4hxA7R1 DaGyPF3DYB7joHSOkcI5KQOWHKOdSYzhvohKMQIbcDBnDHGpFoeI0xpjaHUeAeEJCqEJp0MwaA3B gC+GgL4UgqxqC6LyKEX4xRdDQGlEaSAwRujUGsOWI43hnDQqVbGiAyJui9l6Mg/QzWuC2F+XoZAx xeDDGg3IbojxICwEGHARQuBRC4F4KwX4jRNieD2JMSQw1RjTfxAYbQuRaC0GLKIaY132DgHCJQT4 pD3xbIENEZ43xijEGsNkaQ3hbi5GKKEVwsReLeSUPGOo+SDDvHiO9iwzBdjAF+05bItRmCFEMKwX AnhYC+FMLoXAqRdCXFCKiV6LH42yxFO8b7ghojRGgPEdQ6h4DyHkN4cg4xkjSGiwYcsVB7CsFkL0 QQiRQqWHKOQcA5hdivF4K0VAtLFjcFqMMYY6DwDrRCNxfo0GKmZHkcYd7Xx8EDG+OIdw1xuDqHeO 3AqqhiC/GQLDHb7BuP8GoQYno+moDVGGMsZIpxZinGWxe8I0pqDYyCOwZQxJJDYG9eYckWXMYj0d LF8QrhTC7wTfUcY5BijDFwvsepVBni+GI/Uc40RpjgFOKoXqQR8wKn0SAfZTC5FhSmVQ7p3adEJK Y+KnU/CmUsH9HfWWj9hR5fEKQUYrhdi1F4NgaI1xoDLGhXgdGZR6DYGmNA1g3BkC9GOJcSgrHoXs 2HuPclGSmDNe+OGvY44hjDFqLlg46GZjgGQM8ZY1RuDKxiOcYG3CyFm3LwHgVGiWEhJLTDgfCeFc L4Zw3h3D+IcR4kQiBTwIn5CK5gApJVR+Oac2TJxg9nxEsJARolJOqVE75KQUsPLeXco5dyklRBTI GMKBSYfZkB7JVc0Pig74kkUl5Zy8gRjI4DxHdzHpVLSEbBKnyeE/UOn8zIJq6lBDs5inx0wwZAtB YCnFqKgTY0mmI2FwL0XQshhDCGPPYpmdxmoeHMeEd4391DtHWOocTgymkGmMOLpA6x4Dsb9CRaIq m5jSFIKwXOUh3mPqMKUVgoRhDFGALAV54xaeXFuLEc0LhsjRGQOEbg0xxO/SeOIWIr3uC3GMKAWA qhhylLsL8cJ/hc9oaGOkgY6R1DnGsNYaA3hqMEhYPomZA66DuGOMkag5Hni7GMMQbg2okVYgCOMZ w0RnQkHONDFB1x0pOG4OAbA1RTiVEWLMWothZeMQaN4WQtRjjgHEOcbZ5jnjnGmM0Zb5DLroonp2 AbZHIdpgw0AdggyALvLwSg456JwcqYwb4boooeSPocosoeywAdAcYdQZIXAWIdAbp2IiDOYVAVIV j7gZ4UYUAU4TATQUQXJV4XQWAXKDIVQYwXwWDVwpgVIVo9oWQYYXITwUoQwNYPgTgSgTQQ4RIR6c akwfhfp2AbQcDtAYr0QZQRgQAQYXIWSFYVIWbRIcQgadYdoRwPgQYT4TATrFBjIWoXC0gawZ4Z4a r94WYXyRAZT+YZJexdYagV7ZRMYWQRgR4UQQIL4NoXQVYWQUQTATh34cIgb+wcQuwXr04cwWAWIY g0CwIf4crEoXQV4WgZTPpiAYIYrNQXgVIWIZ4ZgZwVQVQVoaD/wYo5ocAcAcjzAXYaQZYaYSQQQR QXYVgUkWwX4XBjQMIMIPoT4UCVAUoVwZSRRMgVLwbcSfAerfoYIzwecGYYQZw5JOAoASoRgSIS4T ITrg4lwbzMQZ4YoZgWgU4VLZ7PAZIZRxAdQXZRAW4WoZYV4VQWsWgaqmwhhHIZI2gZQZIZobY9C0 gaL/YbjGCugd6sAdzqwjaKQ1o2I5QYYYgVwW4Y59IViaxzSoBHAcQbgboYBoIdQ6bO4bjIIdoch4 CGAea1IazworAjquwco64d4zQecawyAfIoYeoZpdQbocKL4codYeI8BCIfAeZAjdS8zIYbIZIaB4 QchGgZwpTgAf4ziuDz6o54AdononIgUmoc0pJ4gz7FsoIeQe4zYeR8wZpZobga4bAZ4YgYoepIpA geJJAfAbwcIdZzoeaehVYdwaaaYcKIY7CuocQcgZoXAYAdZgwgYdauoWwUwVAdaEgdMzTuwckcQf QZDIwuoYwkod6LIYIWgYxLYbgXYVYXAbbfAVgVwXpPIawc8yT3wdQaQbAcBvAcjq4hqnBHBpBzYm Yxrmq8gbAdR3BfafBfaxodxgxAaKwcwdIsKLQeQXoW4ZYcocYc4XYWAXR5cBQgQkIxhfZ8RfQe4n inyeppDjhfQfMGpTQZ4a6cYmQfLaUqQeYaIZYZ40AdykiNb5Ae6e4ewfI3ocofJIIgZ54d4YZZpI 4eodp5TMoeB8QkbkMop4IcoooekpI8I94aZHZwYdAW4X4aUDESaAYZ5OkCh3wbgb47YdiwYacrwZ YZwa0wgdAcQbwcqexfYe78odQoAfgmQfQkqJYV66BTgcB2Ydjz6KjkIez/IcweItYa4aob4c8XKJ AcoX4ZL/IcjwiGzmIjAboawb8KYWIXQZ4QC6rJAWgWYXYZRlhWwYAZD0RdQZcuxcQW4XgaIUoUQT YSYRgQzThVIdweQVIUwXkVwa4WYVMgIZoaogaEQbQTq9AaBW4SoSIRzzAWQUIVQXB/YYRBgbR3Yb oTASoWYYgZIbUJAT5n0jwVoXga5/oUYToV0VIYwaBUx2ocK/YWgVCDQQAPQOQaQZwZYgZhoaQUIS xK4XIZgToTQVDTIZQabZoawaYboPgOoR0UQXETQVgXwX4X4UYVQYMfgXIQoNIOIXBhISgTYWww4b 4gZ74cAWAVgXSUoaAY4YYZsxwbwWwUYVLUQXQXQXpEocgXIYIaL3wdi54WIW4V4XYVITwWYRgRoV zmtAIas/YZQYoaAUASYU4QgOYQoYQXAX5U6URcTMod4ZQYbtgWYXQT4SQUYOYNQRgOYPQUATIT4X Id4eAerhAiwqgaoaobAYIYIXpWgZYQgQQUYX6UhTZsYaIcAYoXpmAX5GyZp2ocCkgYpuoWRtJKsK IaoZQagcAbocoZIYQZZ+poogUmYdBlIawZAYgZ4TYQoSIVwVYVRSwboaQZoaAWQVIWQa4wZDwcpJ wbwQoQoSoW4XAZYWQVYXZv4c5uwbIYIXwaQWIVQXQ4YcIbAbAagdBoYVYVAVx3sMggUvMq4YC+JH YTgTK8AYq7QW9VhFoToQQT9v56YcYdAagZoZ6QoVtrgZYYQYwcaF1uwaA8IqIgRgweJ3wdIaZdQX ovodh5UQIZgc42LvIdpKIe4Vlzo9AbhaCaQXYWwV1PEzoUCowfAeRxYUaQYZoZRdYYAaoWxgQbAa R47ZoV5UYbwbAa8V4a5WAY0Akd5jIW6YJdBNgZossAIiyOAegXlhYXwWYXAbiJAdg6YoVI4ewryo WFgpolB8weMgghAkSnSg4YgY4bQZwZgbIbjfAdoc4dEiKFOEw64/rMCV4cj84ep4iY4bY6aMFKyN YkRHGKjX09kdTXqeofRKIegbhi4soekyQc8s6hKob5FLss9JopgeEBwk58Ilyo6g4pjAJ8TjmLCg 4kqoIlzdgcQ481jIQd18UdQfwdDFkoYkyhuPKNYcNH4cIbQcyl7XwrDXofsks4wiQktYxobIjU7Z IWYT4UwUoSQUQS4XgYoYq3gZAXAXwY4VQVwYJpAkr91diqQZ4awa4VbtDRaKLS4XAVQVgSoSgSjH AgYWIWwYITgUEELBx78phR0UAcsKocSrobcXAcCXoVDTQXYRoNwOoXoX62xc0OpYRSzKTRof7L4d gTQUgY7Z4a8lYYYa1VwSsWQapJ9Z4ZgdI595QZwooeYWQXh+aJ4Wg5YU884TIUAYI24eAZb6V8wd Jc5bAZoaIT79iKAdb5WIARQRQRYalXqDAV4bIb4bQgZI4fBogd4bYbgc4WAUgWl5VqD8s7YdduQb auqWCfwkKc4TwVYW9YJigV4XAYZpB8gewU9fIaIYoaoXwvRYQbYT4VwWR/ga7JtM4bwcwZIYBZgY AYKtOfRR4iqtLvA7RqAbIaoawbYUwTIUgUIS4TQT4TwTwQYSQSoR8GIPQQQTQoQewkppgZ7/wawT 9YAOoPARYZmjyDQXQU4VoWgSwSYTsrwgYbNuR54dZh5PqaWG4ZxnwZQZGHYXgW4ZDAgeQVRcoWYY QYYTOgxTgbzAoeQYZpoRoSYSxg1vIf+VYZYLgMwRYSoTIWoS4SIVkhIaQUe1QZWw4S+gwZYw4VL3 I6ocdxoWb4QaYQISwSIPwR4R4UgVAXMhQa9owWCSAaAVW7hf4ZZmTEpomySJIQ4QARwZkVAQ4QIQ IXEZEzJ8wToUwWoSYTgWANwOQTIVAUwXu44w4aQbYYpUIZIaJB4mJxh1YTZPwUpnIU4PARgSRr8u RDgSATL9gW68LQwXoXYZAOIOoRoVq/gYGw54IdwPQQYR2ttjwToUS4AXuTEjAcTS7L85gxofRAge Y6QdwcxDz4KJMph74cTkYjaAIdAVQXYYNHx/oaobbFweg24dQecv0KobpIOFWSgkqGAeQ8AzwzYd w7QkSNYfjgqoIluFwfwb4bAbgXRaQcpFL5AfKxwwl1lqBoY4zLAzMoZgzMwsrwR2YdqbIbGP2eUC ikF1YcJ54dwc6xqvYdAVAW4WSqYbJcoYgalAhVYdhYzdWyrwgcAagbQdz3yBWKQcQcrvSvYa4a9M Icwdr/MyTveHj/Bys1dLp3ocwtQebIQcQaHU2LwbBpCygaz84bBI4e7AgeZ44bkz7wRxakgT4VIU IWAVIUgWRM0vVTYiOKTIwV4XwXgWqvAchvytoZwbwV4VwYRW4YYUITYQMCgbaQIV+ml2kT4dMrYw 0XIbwVDtLxkGoU4VYYhjUVYWhsYceaxEIdR+AX4bb616AZKtg5AYQZGlQa1QQX1yd1YcYawdkpwh NpIdFewTYYIWxwqTqxodsxgZqGAeDtgW4a4cQaxVLAoXwZoZA7QeIXoWe7tPwbTUo+4aYTwTAP2z oYoUoSoTnT4gY6AcoUgWwTqqYZgSwUwR4TgUN/gTgURQYVoYQWIXdXsEqoQZx9/HIb+EgcHIIgdp IdwTgUoQruzOIgR3wcSIYcC4YZoWgUoYQagwoXNdpFLZm47mwVQSgUIXAV4Xqg8rAXsTYXR64WwS QRQSRrgaTdgcgekimGU44qoYQZRaAX4UoXgY6R4YYXoYwXgYgW5McHQYgTYS4TkXAbo8wbHO4gZv wcoXIXIVT4oYgW1hQWIYYWhBwbIUwVYVwTwUIV9t4aQXwV15xTg3YWIZwZ4ZD9gVxBQaj94WgY60 UV4Xw/obIQwTgQAXkyg8wayozoQghsZEmEiagY1G4ao9hiI8wSISoPJtYUQgD/gTreDqVa+VbRaz TOZzOyPRKVWafVjNYzKTKUTLCYy5SCdObmdLggT/dDocSrViWajWZi7YSyWzKXbXbrbX67XqvUyu aDQaklfr+fq9Ya3YTHXK3XSzY7LZUlcjjbyLSh0abTY0laLcaahni+XzDbTWbjSZLOX65VjVZzUX C6VDsdroT6dTSxVS0f19krZa7KbTibKiXKtQSaSahUqrVCmWryeDykuVy2Xkt9fzlcDabLdaLjcz gcjibDndLmez1er4fD2d7tdr62m1y78fj7dLrc2sejsczkeb1eT6fb6eLxd7sdjve72e7tdToej0 edGYbrdbqbDSZrjcDcarSbblczlcblcvTdK7WyiajYZjZbjRfD3emakrpc7neJ5OUeB4nmeZ4Gaa ZknEcp0Gm7pxNGkp7teYRglccRyG6bxrmacJxnG5h3HhER3HYdbXOid5ztwfaSnqex6GYahjnGdB wROeR7Hmfbcnk5Z7tYd53soyxtm+bBeGAXJnmOYhxG+bKSn247dnOfJ8ns4x9Hy2kXHoe0vysfTn ntEhznq6p2HUdTaHydZ2nTIJ5HmeR6O1IUAHQdZxnWd51nCc5wt9Ah7H7QrMUPREvnoaZrmiyZ4F oXxYGybxtTyc01HKbRyGyaxtG0dK6UQkpwnCb5XloX83HgcJvHPER5GmbRsHVErwG1IJ2GGZhnzo ehXluYJsG8cSSnjASFmuWxbl8YJimGbxwG/PJ0N2dJimYY54noeJkGsZRqM6ZRomgcZyHQVZZl4Z RlGYYRgFi555pKcz+liXxVGwbrPnFXDlTpHp4ncbrOUKfx3zmdsRGeapuHm6pxHCaxzHM019Oqey hUKm1QO2k5xQUbxgGgZRfGSZmNH8axqGqahnmIZBeFtRpoFoWphOmeLMr6bBtGoaZnSacZuHUeB0 pLL57liVZVGkZRgGEWhYkwRhJL0UpPk8UxblyXxtG8oNR7FsTXntpxjmwbJsj+P4+FiXBbFQWhXF KVxQDaRgwmMrRzHW6jVnq57Lm48RkGKWxsGxmpYFyYJfGKUpYFUVhclqPRDD0ZpnmSWZhlobJwG2 NZBDuVheFrnZ+tyfhrGiZBhvcZ5mGYa5p3CqZQlcVqRHQXpkF6azCFiYRYGIZpjkgUhSMWUo2j4P 7RHKkp0HKcRqmaZBSFGUg8jyQxeGCYJbF+Xhu9CYplGEdLpFIppM7oKQ4DYXpjmSP5FkEYZgl66R 1SsPlYyAxACGEQKIVoqhZC6FiLAWwpROi1FELQYYuCSm0H2IARglxJCWE4IkQIcxYioEyL0Wwrhu jXGuxofouhejAFMK0U4qhYCiZGL1Yx1RNivFKSIcgqxZCyEmJAQ4ynYC2FWJ4VgrBSjcLK2OJyhx 2m8GKLcU6bxzDSGiMwdw7x4EnHWNUbI2CKCnFALAVIuRii+GuNsag2knmaM0NYa43BKiUE+Z4aox xdirG2o0XouxaFPGYGsNwehgDAGOMMZ4xh1DuHSNFlw6E0qIQEO8eo8x4jaGgMYZowxbG+kQMGLx ux1juR6Moa4xxxKAGa61P45hpjRG8a4fRJTZDoGMLoVcmiaRJQ8OUarDRvjeG+KkWAr5VjkE+LMU gvRki8FILYVg4EFivFcMgao2BwqINYPUXguBajQGmNI8w7HzDfGQNMZY4x0zbIEPx1QmBWimE6KM VgzBnDYNEOZGo2x1jkJIQIzQ4hwDrliqAc46htqmaQj8VQtxRjCGUL8cBohnjSG5FseRqRupnHkZ Id0T6RGVo+PEarKzqj0SkPtLY/EvD5UKP01Y8xsjaG2M8ag0Edj7KGP2dq/SgDZGqNcdqIaPnDNZ HAvqWx9TEG7SkkqtR1HJkwtupVVx/ISHuw8eZmqVo7H6gVPp6KR1lpEZpFw9jcD8rNW1sSWx8j4r jW6Jxmh7D5NaPke5+q6V9MqMoY4zhPGNKgModQ6R0jNGkNcToqxhDWGsOES4hRMi5FSLMXotRcNJ KkNIaQxRViwFaJ0VQqRUi7O8M5Vo3xwrSF6LoXQwxjjQEcJMWDfh3klGCLEXYrLBjRGcNAXwrhfr fGkhUXIyhdDCE8KAVzc5mCaE8NK4Ltj6DdScN8clfruXdu9d+8F4a+jfVkNMZ42RgC6GONRGI7DU J9HaxQdQhhFihGCMMagxBcjNOIPUkqPR5FHIuMYZ46hvjiGCLMsYuhjVCG1LEaQsBUCpDmG8Nw6b DklGeM6mw0TADNGvFQXDlRijUGcNcXorhbiwE4SsRoow8BwEULMUQrhNiJEmODHRzB23ix9j/IGQ chKIH1XJLQ+hxDjVrJJ1VMShl9OePfJtV2dxwONPCeFeDVj2rlVpCR6ByjCFyLseiciSnDrucY54 +B0DeHGiQeJ0B9VFHiOUb87B0DuYi9Qbo4xmjEGca4fFfMh6F0NofRGidFaL0Zo3R2j9IaR0lpPS mldLaX0xpnTWm9Oad09p/UGodRaj1JqXU2p9UapvEQEKZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9i ago3Mjc2CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+PgpzdHJlYW0K////vAZ5 klKMty6zJldEYIxkIbJvDql3ioR1cnH0uJCC6kyJY9/b8JcJpL1h6B7uTD+hvE5KNNjOqUtAnQPQ IO0dqlH9hUKUj+ZS8c9w3xywgNj+yg3XmbYi2VQmqnUUyB9mxaWoWjSPrCVeHQV7zYVTzFBho+oX xsNs7G7hATcAZ/ylEFfanwP//iEEee+KzbvbLl7FRiSJshH3kxIvk3osOYqDEymHEiioF6GXoW5T fZ2yQuPWy5Xowyn78rx1HvX/oQgpKRtR0TPzadVhvFL/bpTiRV94LiOhKRVenjRUndZdx/94GNGr CzuBbffTbGZnT6zHyNvqagQAyKM0HEEKeQgK8iHbniwWH5oO8wd1W1ciIh/9DYkBDlKlQ2/mTunu WNsPM3o8SZnWWI3ezeg17wtV7Rne7ycxlGqgeriJaBBleETftI55i+YGabTunqP585ES0oA6AxSl pI5eLfduknCzciRB67Ao8Rnc4Lh/2qsQ7X6RJ4KlzCY0KlQsmeecTVnBjkVxtjeKkhdCEvLuI99s tQbvWtMVj/5qu5hRV+WrGHTwiisnFL4/V9AxRvQQs6kXogTrt5PqIk6Cc6ZnH7/cD0kHN17Fd7aW qPyLua800VE5vQnMpysbKZ/Ckb6Cbc7MdQYrOn3h0SbeXN+NkLHfym7plxUVsz+1ddBz+D5CxLNI 7+7F0b/srxvMPax9HXbsBw4BHMFA0TYRRS5Qh/ME0OPylrSygmTNTqF6zL/xuMb/uuLA+7T3DPkm XYEZYVL8U+ixBWoV07m2TYV1Pj47Pvge/vPS9QDMG11ONL6gMRKJ4hj09+ytrjkzJHhyYLdqfrVe UateHsa8bft7Di2Olw+miweSObbMbdpF3zr8SrmyqApdBykjxJYfQKRMzjxcdMhkBwEa1G/0Gk8v F5noyULzJkodSg6zak5Yth2VE5Jdd5lfkW7OhogdtZ+3nmn6kZBEr9tTY0Whu/y/UQ9RrobqDRhZ 3J7i+lOCsvLrrIR78DNWQ5ac5VKYCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKNzY4CmVuZG9i agp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAwMDAwIG4gCjAwMDAw MDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkzIDAwMDAwIG4gCjAw MDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAwNTk4IDAwMDAwIG4g CjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAwMDA5MTkwIDAwMDAw IG4gCjAwMDAwMDkyMTEgMDAwMDAgbiAKMDAwMDAwOTI2MiAwMDAwMCBuIAowMDAwMDE2Njc3IDAw MDAwIG4gCjAwMDAwMTY2OTggMDAwMDAgbiAKMDAwMDAxNzUyMSAwMDAwMCBuIAp0cmFpbGVyCjw8 Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJlZgoxNzU0MQolJUVP Rgo= --------------020402020607030208040200-- From mext-bounces@ietf.org Sat Jun 30 13:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gSh-0008GV-Ma; Sat, 30 Jun 2007 13:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gSg-0008GN-S7 for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4gSZ-0001Wn-Vf for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 61E561986A7 for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1E6D119866D for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Message-ID: <46868E73.3080705@piuha.net> Date: Sat, 30 Jun 2007 20:10:11 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [MEXT] test X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing a list problem, please ignore. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext