From owner-seamoby@diameter.org Wed Aug 1 10:38:08 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06038 for ; Wed, 1 Aug 2001 10:38:08 -0400 (EDT) Received: (qmail 4677 invoked by alias); 1 Aug 2001 14:26:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4671 invoked by uid 200); 1 Aug 2001 14:26:48 -0000 Received: (qmail 4666 invoked by uid 500); 1 Aug 2001 14:26:44 -0000 Date: Wed, 1 Aug 2001 07:26:44 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Issues list finally updated Message-ID: <20010801072644.L18712@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, I have updated the issues list, and want to make sure that I've done it properly. If you notice anything that doesn't seem right, please let me know. I've created an "Update" section on each issue. Currently, the issues that appear to need to be discussed in London are 2, 4, 5 and 7. PatC From owner-seamoby@diameter.org Sun Aug 5 19:31:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24145 for ; Sun, 5 Aug 2001 19:31:04 -0400 (EDT) Received: (qmail 5246 invoked by alias); 5 Aug 2001 23:20:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5239 invoked by uid 200); 5 Aug 2001 23:20:11 -0000 Received: (qmail 5234 invoked from network); 5 Aug 2001 23:20:09 -0000 Received: from unknown (HELO imnet00.imnetpia.com) (root@211.237.39.111) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Aug 2001 23:20:09 -0000 Received: from parkjh ([211.237.39.96]) by imnet00.imnetpia.com (8.9.3/8.9.3) with SMTP id IAA14487 for ; Mon, 6 Aug 2001 08:31:02 +0900 Message-ID: <001d01c11e06$d830fa10$6027edd3@parkjh> From: =?ks_c_5601-1987?B?udrA58ir?= To: Subject: [seamoby] Date: Mon, 6 Aug 2001 08:32:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA24145 auth a4b5bcd7 subscribe seamoby parkjh@imnetpia.com From owner-seamoby@diameter.org Mon Aug 6 04:09:32 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18986 for ; Mon, 6 Aug 2001 04:09:32 -0400 (EDT) Received: (qmail 7643 invoked by alias); 6 Aug 2001 07:57:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7637 invoked by uid 200); 6 Aug 2001 07:57:42 -0000 Received: (qmail 7632 invoked by uid 500); 6 Aug 2001 07:57:41 -0000 Date: Mon, 6 Aug 2001 00:57:41 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Reminder on MORE BOF at Seamoby Meeting Message-ID: <20010806005740.O7242@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, Just a reminder that the first 60 minutes of today's Seamoby meeting will consist of the MORE (Mobile Operator REquirements) BOF, chaired by James Kempf and Paul Reynolds See you all then, PatC From owner-seamoby@diameter.org Wed Aug 8 17:55:00 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22278 for ; Wed, 8 Aug 2001 17:54:59 -0400 (EDT) Received: (qmail 17661 invoked by alias); 8 Aug 2001 21:43:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17654 invoked by uid 200); 8 Aug 2001 21:43:51 -0000 Received: (qmail 17649 invoked from network); 8 Aug 2001 21:43:50 -0000 Received: from thumper.research.telcordia.com (128.96.41.1) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Aug 2001 21:43:50 -0000 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f78LsbY07793 for ; Wed, 8 Aug 2001 17:54:37 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@host217-33-137-115.ietf.ignite.net [217.33.137.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA07748 for ; Wed, 8 Aug 2001 17:56:51 -0400 (EDT) Date: Wed, 08 Aug 2001 17:50:49 -0400 Message-ID: <87ofpq43wm.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: seamoby@cdma-2000.org Subject: [seamoby] Consideration on L3 paging area User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk I've noticed that the definition of "paging area" is ambiguous in the DMHA requirement document. Actually, it is not clear to me whether the paging area mentions L3 paging area or L2 paging area. I want to interpret it as the L3 paging area instead of L2 paging area in order to be more generic. Otherwise, the Tracking Agent and Paging Agent defined in section 5 (Functional Architecture) cannot exist if underlying L2 technologies do not have L2 paging (thus there is no L2 paging area), which seems to be unnecessarily restrictive. The notion of L3 paging area would also be useful for separation of L2 dependent stuff from DMHA protocol, which would simplify the DMHA protocol specification and increase the degree of freedom in implementation. If such an interpretation is allowed, the next issue is what the mapping between L3 paging area and L2 paging area should be. It seems that the mapping is entirely implementation issue, and I want to make it out of the scope of DMHA specification. Comments? Yoshihiro Ohba From owner-seamoby@diameter.org Thu Aug 9 03:39:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16604 for ; Thu, 9 Aug 2001 03:39:44 -0400 (EDT) Received: (qmail 19506 invoked by alias); 9 Aug 2001 07:28:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19500 invoked by uid 200); 9 Aug 2001 07:28:39 -0000 Received: (qmail 19495 invoked from network); 9 Aug 2001 07:28:38 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Aug 2001 07:28:38 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16323; Thu, 9 Aug 2001 01:39:55 -0600 (MDT) Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00994; Thu, 9 Aug 2001 00:39:50 -0700 (PDT) From: James Kempf Message-Id: <200108090739.AAA00994@heliopolis.eng.sun.com> Date: Thu, 9 Aug 2001 00:39:17 -0700 To: "Yoshihiro Ohba" , Reply-To: Subject: Re: [seamoby] Consideration on L3 paging area X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Yoshi, > > >I've noticed that the definition of "paging area" is ambiguous in the >DMHA requirement document. Actually, it is not clear to me whether >the paging area mentions L3 paging area or L2 paging area. > >I want to interpret it as the L3 paging area instead of L2 paging area >in order to be more generic. Otherwise, the Tracking Agent and Paging >Agent defined in section 5 (Functional Architecture) cannot exist if >underlying L2 technologies do not have L2 paging (thus there is no L2 >paging area), which seems to be unnecessarily restrictive. The notion >of L3 paging area would also be useful for separation of L2 dependent >stuff from DMHA protocol, which would simplify the DMHA protocol >specification and increase the degree of freedom in implementation. > Yes, that was the intent. L3 paging is of little interest unless it allows more flexibility, for example, dynamically configured paging areas. If paging areas are strictly tied to L2, this is not possible. >If such an interpretation is allowed, the next issue is what the >mapping between L3 paging area and L2 paging area should be. It seems >that the mapping is entirely implementation issue, and I want to make >it out of the scope of DMHA specification. > I agree that it should be an implementation issue. The same goes for the mapping of the actual implementation of paging signalling. How or even whether it is mapped to a paging channel depends on the underlying L2 protocol. The specification should just make it possible. jak From owner-seamoby@diameter.org Thu Aug 9 08:30:12 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21792 for ; Thu, 9 Aug 2001 08:30:10 -0400 (EDT) Received: (qmail 20749 invoked by alias); 9 Aug 2001 12:18:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20743 invoked by uid 200); 9 Aug 2001 12:18:10 -0000 Received: (qmail 20738 invoked from network); 9 Aug 2001 12:18:08 -0000 Received: from ebene.inrialpes.fr (194.199.18.70) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Aug 2001 12:18:08 -0000 Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f79CQJb14282; Thu, 9 Aug 2001 14:26:20 +0200 (MEST) Message-ID: <3B728255.A5D0DC7C@inrialpes.fr> Date: Thu, 09 Aug 2001 14:30:14 +0200 From: Pars MUTAF X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: James.Kempf@Sun.COM CC: Yoshihiro Ohba , seamoby@cdma-2000.org Subject: Re: [seamoby] Consideration on L3 paging area References: <200108090739.AAA00994@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello; In my opinion (humble), the following decisions make a "location tracking strategy" (or whatever you want to call it): - Use L2 or L3 paging areas? Or use underlying location tracking strategy? - Paging areas are contigiuous or not? Overlaping or not? etc. - Who initiates paging? A home agent? an hierarchical agent?, a last hop router? etc. - How the paging areas are configured? By the operator? Automatically? - What is the paging algorithm? Sequential polling? Multicast style? etc... - Does a DMH send registrations upon every paging area crossing or not? - and that kind of staff that you know all... So, I completely agree with you: the above items are out of the scope of the DMHA protocol. But, I don't agree that this is an implementation issue. How can the DM capable hosts, paging agents etc. can agree on an implementation issue? This is not clear. Formulated as follows, it is more clear for me: The DMHA protocol should be flexible in support of more than one location tracking strategies. DM capable hosts and paging/tracking/monitoring agents can agree on a particular strategy (which is assigned a number), using a message exchange supported by the DMHA protocol, in a TLV formatted option, for example. And, each strategy can have its own message types and codes for its specific functionalities... Clearly, this would be an obvious advantage of IP paging over current systems: "location or administrative domain or even time dependent location tracking strategies". In addition, there is extensive research on zillions of strategies, and so far there is not a convincing winner... Someone can discover *in the futur* a new strategy, convince others by simulation and benchmarking results, or even on real IP mobility expericence... then everyone may prefer this new strategy (the ONE). When this happens, the DMHA protocol should be able to support it. So, I want to imagine that a particular Location Tracking Strategy: "MY-LTS over DMHA" will be proposed as a separate I-D ... (but, one should first design the DMHA protocol :-). In this case the network administrator will ask: which LTS should I buy? That's his/her business... Comments? Thanks... Regards, pars James Kempf wrote: > Yoshi, > > > > > > >I've noticed that the definition of "paging area" is ambiguous in the > >DMHA requirement document. Actually, it is not clear to me whether > >the paging area mentions L3 paging area or L2 paging area. > > > >I want to interpret it as the L3 paging area instead of L2 paging area > >in order to be more generic. Otherwise, the Tracking Agent and Paging > >Agent defined in section 5 (Functional Architecture) cannot exist if > >underlying L2 technologies do not have L2 paging (thus there is no L2 > >paging area), which seems to be unnecessarily restrictive. The notion > >of L3 paging area would also be useful for separation of L2 dependent > >stuff from DMHA protocol, which would simplify the DMHA protocol > >specification and increase the degree of freedom in implementation. > > > > Yes, that was the intent. L3 paging is of little interest unless it > allows more flexibility, for example, dynamically configured paging > areas. If paging areas are strictly tied to L2, this is not possible. > > >If such an interpretation is allowed, the next issue is what the > >mapping between L3 paging area and L2 paging area should be. It seems > >that the mapping is entirely implementation issue, and I want to make > >it out of the scope of DMHA specification. > > > > I agree that it should be an implementation issue. The same goes for > the mapping of the actual implementation of paging signalling. How > or even whether it is mapped to a paging channel depends on the > underlying L2 protocol. The specification should just make it possible. > > jak From owner-seamoby@diameter.org Thu Aug 9 11:24:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27059 for ; Thu, 9 Aug 2001 11:24:19 -0400 (EDT) Received: (qmail 21964 invoked by alias); 9 Aug 2001 15:12:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21958 invoked by uid 200); 9 Aug 2001 15:12:31 -0000 Received: (qmail 21953 invoked from network); 9 Aug 2001 15:12:29 -0000 Received: from thumper.research.telcordia.com (128.96.41.1) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Aug 2001 15:12:29 -0000 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f79FNGY17555; Thu, 9 Aug 2001 11:23:18 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@host217-33-137-115.ietf.ignite.net [217.33.137.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA09280; Thu, 9 Aug 2001 11:25:29 -0400 (EDT) Date: Thu, 09 Aug 2001 11:19:26 -0400 Message-ID: <87r8ulp8g1.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: Pars MUTAF Cc: James.Kempf@sun.com, seamoby@cdma-2000.org Subject: Re: [seamoby] Consideration on L3 paging area In-Reply-To: <3B728255.A5D0DC7C@inrialpes.fr> References: <200108090739.AAA00994@heliopolis.eng.sun.com> <3B728255.A5D0DC7C@inrialpes.fr> User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Perhaps some sort of capability notification or negotiation would be necessary for DMHA protocol to be flexibile. Yoshihiro Ohba At Thu, 09 Aug 2001 14:30:14 +0200, Pars MUTAF wrote: > > > Hello; > > In my opinion (humble), the following > decisions make a "location tracking strategy" > (or whatever you want to call it): > > - Use L2 or L3 paging areas? Or use underlying > location tracking strategy? > > - Paging areas are contigiuous or not? Overlaping > or not? etc. > > - Who initiates paging? A home agent? > an hierarchical agent?, a last hop router? etc. > > - How the paging areas are configured? > By the operator? Automatically? > > - What is the paging algorithm? Sequential polling? > Multicast style? etc... > > - Does a DMH send registrations upon every > paging area crossing or not? > > - and that kind of staff that you know all... > > > So, I completely agree with you: the above items > are out of the scope of the DMHA protocol. > > But, I don't agree that this is an implementation issue. > How can the DM capable hosts, paging agents etc. can > agree on an implementation issue? This is not clear. > > Formulated as follows, it is more clear for me: > > The DMHA protocol should be flexible in support > of more than one location tracking strategies. DM > capable hosts and paging/tracking/monitoring > agents can agree on a particular strategy (which is > assigned a number), using a message exchange > supported by the DMHA protocol, in a TLV formatted > option, for example. And, each strategy can have its own > message types and codes for its specific functionalities... > > Clearly, this would be an obvious advantage of IP paging > over current systems: "location or administrative domain > or even time dependent location tracking strategies". > > In addition, there is extensive research on zillions > of strategies, and so far there is not a convincing winner... > Someone can discover *in the futur* a new strategy, convince > others by simulation and benchmarking results, or even on > real IP mobility expericence... then everyone may prefer > this new strategy (the ONE). When this happens, the DMHA > protocol should be able to support it. > > So, I want to imagine that a particular Location Tracking > Strategy: "MY-LTS over DMHA" will be proposed as a > separate I-D ... (but, one should first design the DMHA > protocol :-). > > In this case the network administrator will ask: > which LTS should I buy? That's his/her business... > > Comments? Thanks... > > Regards, > pars > > > > > > James Kempf wrote: > > > Yoshi, > > > > > > > > > > >I've noticed that the definition of "paging area" is ambiguous in the > > >DMHA requirement document. Actually, it is not clear to me whether > > >the paging area mentions L3 paging area or L2 paging area. > > > > > >I want to interpret it as the L3 paging area instead of L2 paging area > > >in order to be more generic. Otherwise, the Tracking Agent and Paging > > >Agent defined in section 5 (Functional Architecture) cannot exist if > > >underlying L2 technologies do not have L2 paging (thus there is no L2 > > >paging area), which seems to be unnecessarily restrictive. The notion > > >of L3 paging area would also be useful for separation of L2 dependent > > >stuff from DMHA protocol, which would simplify the DMHA protocol > > >specification and increase the degree of freedom in implementation. > > > > > > > Yes, that was the intent. L3 paging is of little interest unless it > > allows more flexibility, for example, dynamically configured paging > > areas. If paging areas are strictly tied to L2, this is not possible. > > > > >If such an interpretation is allowed, the next issue is what the > > >mapping between L3 paging area and L2 paging area should be. It seems > > >that the mapping is entirely implementation issue, and I want to make > > >it out of the scope of DMHA specification. > > > > > > > I agree that it should be an implementation issue. The same goes for > > the mapping of the actual implementation of paging signalling. How > > or even whether it is mapped to a paging channel depends on the > > underlying L2 protocol. The specification should just make it possible. > > > > jak > > From owner-seamoby@diameter.org Thu Aug 9 19:07:08 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07075 for ; Thu, 9 Aug 2001 19:07:07 -0400 (EDT) Received: (qmail 23349 invoked by alias); 9 Aug 2001 22:55:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23342 invoked by uid 200); 9 Aug 2001 22:55:36 -0000 Received: (qmail 23337 invoked from network); 9 Aug 2001 22:55:34 -0000 Received: from boreas.isi.edu (128.9.160.161) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Aug 2001 22:55:34 -0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f79N6sv04576; Thu, 9 Aug 2001 16:06:54 -0700 (PDT) Message-Id: <200108092306.f79N6sv04576@boreas.isi.edu> To: IETF-Announce: ; Subject: [seamoby] RFC 3154 on Paging Requirements Cc: rfc-ed@ISI.EDU, seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 09 Aug 2001 16:06:54 -0700 From: RFC Editor Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3154 Title: Requirements and Functional Architecture for an IP Host Alerting Protocol Author(s): J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu Status: Informational Date: August 2001 Mailbox: James.Kempf@Sun.COM, pars.mutaf@inria.fr, claude.castelluccia@inria.fr, nnakajima@tari.toshiba.com, yohba@tari.toshiba.com, ramjee@bell-labs.com, Yousuf.Saifullah@nokia.com, Behcet.Sarikaya@usa.alcatel.com, xiaofeng.xu@usa.alcatel.com Pages: 16 Characters: 31534 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-seamoby-paging-requirements-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3154.txt This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This document is a product of the Context Transfer, Handoff Candidate discovery and Dormant Mode Host Alerting Working Group of the of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010809160323.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3154 --OtherAccess Content-Type: Message/External-body; name="rfc3154.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010809160323.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Fri Aug 10 04:10:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01067 for ; Fri, 10 Aug 2001 04:10:08 -0400 (EDT) Received: (qmail 24563 invoked by alias); 10 Aug 2001 07:58:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24557 invoked by uid 200); 10 Aug 2001 07:58:25 -0000 Received: (qmail 24546 invoked from network); 10 Aug 2001 07:58:22 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Aug 2001 07:58:22 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18314; Fri, 10 Aug 2001 02:09:42 -0600 (MDT) Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19909; Fri, 10 Aug 2001 01:09:34 -0700 (PDT) From: James Kempf Message-Id: <200108100809.BAA19909@heliopolis.eng.sun.com> Date: Fri, 10 Aug 2001 09:08:33 +0-100 To: "Pars MUTAF" , Cc: , "Yoshihiro Ohba" Reply-To: Subject: Re: [seamoby] Consideration on L3 paging area X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pars, > >Hello; > >In my opinion (humble), the following >decisions make a "location tracking strategy" >(or whatever you want to call it): > >- Use L2 or L3 paging areas? Or use underlying > location tracking strategy? > >- Paging areas are contigiuous or not? Overlaping > or not? etc. > >- Who initiates paging? A home agent? > an hierarchical agent?, a last hop router? etc. > >- How the paging areas are configured? > By the operator? Automatically? > >- What is the paging algorithm? Sequential polling? > Multicast style? etc... > >- Does a DMH send registrations upon every > paging area crossing or not? > >- and that kind of staff that you know all... > > >So, I completely agree with you: the above items >are out of the scope of the DMHA protocol. > Most of these are policy questions, some involve whether MIP is the mobility protocol or not (it may be GPRS for example). >But, I don't agree that this is an implementation issue. >How can the DM capable hosts, paging agents etc. can >agree on an implementation issue? This is not clear. > It's an implementation question in that a particular radio link protocol either will or will not provide L2 support for paging. If it doesn't, then the implementer of DMHA on that radio link must use regular IP packets over the traffic channel (there may be only one, like 802.11) rather than leveraging paging support. Also, the radio link may provide some support (for example, a paging channel) without others (for example, L2 support for location tracking). >Formulated as follows, it is more clear for me: > >The DMHA protocol should be flexible in support >of more than one location tracking strategies. DM >capable hosts and paging/tracking/monitoring >agents can agree on a particular strategy (which is >assigned a number), using a message exchange >supported by the DMHA protocol, in a TLV formatted >option, for example. And, each strategy can have its own >message types and codes for its specific functionalities... > Not necessarily. I think at L3 the DMHA protocol needs to specify how location tracking of a dormant mode moble node is done. It cannot rely on the mobility protocol to do this, because a mobile node in dormant mode does not require routing information to be propagated, which is what the mobility protocols for active dormant mode mobiles are designed to do. A dormant mode mobile does, however, require its location to be tracked by paging, for purposes of locating it should routing information need to be reestablished. >Clearly, this would be an obvious advantage of IP paging >over current systems: "location or administrative domain >or even time dependent location tracking strategies". > I agree. >In addition, there is extensive research on zillions >of strategies, and so far there is not a convincing winner... >Someone can discover *in the futur* a new strategy, convince >others by simulation and benchmarking results, or even on >real IP mobility expericence... then everyone may prefer >this new strategy (the ONE). When this happens, the DMHA >protocol should be able to support it. > >So, I want to imagine that a particular Location Tracking >Strategy: "MY-LTS over DMHA" will be proposed as a >separate I-D ... (but, one should first design the DMHA >protocol :-). > >In this case the network administrator will ask: >which LTS should I buy? That's his/her business... > >Comments? Thanks... > The point of having an L3 location mechanism is that it can tie into various L2 mechanism. Also, it should be possible to configure the L3 mechanism with various location policies. Separating the mechanism from the policy would allow the use of various mechanisms as you propose. But I do not think this requires us to punt on the mechanism, rather the contrary. jak From owner-seamoby@diameter.org Mon Aug 13 12:58:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24807 for ; Mon, 13 Aug 2001 12:58:55 -0400 (EDT) Received: (qmail 2114 invoked by alias); 13 Aug 2001 16:46:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2108 invoked by uid 200); 13 Aug 2001 16:46:47 -0000 Received: (qmail 2103 invoked from network); 13 Aug 2001 16:46:45 -0000 Received: from netmail2.alcatel.com (128.251.168.51) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Aug 2001 16:46:45 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA00038 for ; Mon, 13 Aug 2001 11:58:18 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f7DGwH902541 for ; Mon, 13 Aug 2001 11:58:18 -0500 (CDT) Message-ID: <3B7807C5.A0B34DFB@usa.alcatel.com> Date: Mon, 13 Aug 2001 12:00:53 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: Re: [seamoby] Consideration on L3 paging area References: <200108090739.AAA00994@heliopolis.eng.sun.com> <3B728255.A5D0DC7C@inrialpes.fr> <87r8ulp8g1.wl@catfish.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Let me throw away my 2 cents. What RFC 3154 refers to should be Layer 3 paging areas not Layer 2. We have no business in Layer 2 paging areas. Hopefully by the time IETF's paging protocol gets deployed in all IP networks, we are going to have only Layer 3 paging areas. On terminology, DMHA does not correctly capture what we understand as paging, it only captures part of the paging on the link for host alerting but not finding where the mobile host is. So Layer 3 paging protocol or the like is to be used. Yoshihiro Ohba wrote: > Perhaps some sort of capability notification or negotiation would be > necessary for DMHA protocol to be flexibile. > > Yoshihiro Ohba > > At Thu, 09 Aug 2001 14:30:14 +0200, > Pars MUTAF wrote: > > > > > > Hello; > > > > In my opinion (humble), the following > > decisions make a "location tracking strategy" > > (or whatever you want to call it): > > > > - Use L2 or L3 paging areas? Or use underlying > > location tracking strategy? > > > > - Paging areas are contigiuous or not? Overlaping > > or not? etc. > > > > - Who initiates paging? A home agent? > > an hierarchical agent?, a last hop router? etc. > > > > - How the paging areas are configured? > > By the operator? Automatically? > > > > - What is the paging algorithm? Sequential polling? > > Multicast style? etc... > > > > - Does a DMH send registrations upon every > > paging area crossing or not? > > > > - and that kind of staff that you know all... > > > > > > So, I completely agree with you: the above items > > are out of the scope of the DMHA protocol. > > > > But, I don't agree that this is an implementation issue. > > How can the DM capable hosts, paging agents etc. can > > agree on an implementation issue? This is not clear. > > > > Formulated as follows, it is more clear for me: > > > > The DMHA protocol should be flexible in support > > of more than one location tracking strategies. DM > > capable hosts and paging/tracking/monitoring > > agents can agree on a particular strategy (which is > > assigned a number), using a message exchange > > supported by the DMHA protocol, in a TLV formatted > > option, for example. And, each strategy can have its own > > message types and codes for its specific functionalities... > > > > Clearly, this would be an obvious advantage of IP paging > > over current systems: "location or administrative domain > > or even time dependent location tracking strategies". > > > > In addition, there is extensive research on zillions > > of strategies, and so far there is not a convincing winner... > > Someone can discover *in the futur* a new strategy, convince > > others by simulation and benchmarking results, or even on > > real IP mobility expericence... then everyone may prefer > > this new strategy (the ONE). When this happens, the DMHA > > protocol should be able to support it. > > > > So, I want to imagine that a particular Location Tracking > > Strategy: "MY-LTS over DMHA" will be proposed as a > > separate I-D ... (but, one should first design the DMHA > > protocol :-). > > > > In this case the network administrator will ask: > > which LTS should I buy? That's his/her business... > > > > Comments? Thanks... > > > > Regards, > > pars > > > > > > > > > > > > James Kempf wrote: > > > > > Yoshi, > > > > > > > > > > > > > > >I've noticed that the definition of "paging area" is ambiguous in the > > > >DMHA requirement document. Actually, it is not clear to me whether > > > >the paging area mentions L3 paging area or L2 paging area. > > > > > > > >I want to interpret it as the L3 paging area instead of L2 paging area > > > >in order to be more generic. Otherwise, the Tracking Agent and Paging > > > >Agent defined in section 5 (Functional Architecture) cannot exist if > > > >underlying L2 technologies do not have L2 paging (thus there is no L2 > > > >paging area), which seems to be unnecessarily restrictive. The notion > > > >of L3 paging area would also be useful for separation of L2 dependent > > > >stuff from DMHA protocol, which would simplify the DMHA protocol > > > >specification and increase the degree of freedom in implementation. > > > > > > > > > > Yes, that was the intent. L3 paging is of little interest unless it > > > allows more flexibility, for example, dynamically configured paging > > > areas. If paging areas are strictly tied to L2, this is not possible. > > > > > > >If such an interpretation is allowed, the next issue is what the > > > >mapping between L3 paging area and L2 paging area should be. It seems > > > >that the mapping is entirely implementation issue, and I want to make > > > >it out of the scope of DMHA specification. > > > > > > > > > > I agree that it should be an implementation issue. The same goes for > > > the mapping of the actual implementation of paging signalling. How > > > or even whether it is mapped to a paging channel depends on the > > > underlying L2 protocol. The specification should just make it possible. > > > > > > jak > > > > Regards, -- Behcet From owner-seamoby@diameter.org Mon Aug 13 19:29:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00224 for ; Mon, 13 Aug 2001 19:29:58 -0400 (EDT) Received: (qmail 9632 invoked by alias); 13 Aug 2001 23:18:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9626 invoked by uid 200); 13 Aug 2001 23:18:42 -0000 Received: (qmail 9621 invoked by uid 500); 13 Aug 2001 23:18:40 -0000 Date: Mon, 13 Aug 2001 16:18:40 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Update on Issues from IETF meeting Message-ID: <20010813161840.A9564@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, Although I need to put together the minutes from the London meeting last week, I'd like to send out the results from our Issues discussion, and request any comments before we move on. There are four pending issues: Issue 2: This issue has to do with the adoption of the proposed requirement 4.3. The consensus in the meeting was to adopt the requirement with some minor wordsmithing. Issue 4: This issue had to do with new terminology for proactive and reactive Issue 7: Remove the terminology proactive and reactive After some intense discussion on the issue, it was decided to remove proactive and reactive, and instead adopt a very simple requirement similar to: "Context Transfer may occur prior to, during or after a handover." Nearly complete consensus on this approach. Issue 5: This issue was a request to support multi-phasic CTs The text proposed at the meeting was: "4.9 Context information MAY be transferred in phases, allowing for time critical state to be sent first, and non-time critical state to be sent later. The cost of building and sending smaller packets is less, as well as parsing and processing by the receiver. " The consensus at the meeting was to adopt the text, but a comment was made that how one defines time critical is an issue since anything could be send in the initial CT message. Each CT profile would need to specify whether it is time-critical. If someone has any comments on the above, I'd like to hear them now. As you know, decisions aren't made at meetings, and the list is still the preferred medium to provide comments. If I hear no objections by 8/21, these changes will be included in the next revision of the draft will be send to WG last call. Thanks, PatC From owner-seamoby@diameter.org Mon Aug 13 22:06:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02742 for ; Mon, 13 Aug 2001 22:06:41 -0400 (EDT) Received: (qmail 10967 invoked by alias); 14 Aug 2001 01:53:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10961 invoked by uid 200); 14 Aug 2001 01:53:26 -0000 Received: (qmail 10953 invoked from network); 14 Aug 2001 01:53:24 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 01:53:24 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7E242p05413 for ; Mon, 13 Aug 2001 22:04:02 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 13 Aug 2001 22:04:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 22:04:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EF0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Mon, 13 Aug 2001 22:04:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12465.7400C970" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12465.7400C970 Content-Type: text/plain; charset="iso-8859-1" Pat: > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: August 13, 2001 19:19 > To: seamoby@cdma-2000.org > Subject: [seamoby] Update on Issues from IETF meeting > > > All, > > Although I need to put together the minutes from the London > meeting last week, > I'd like to send out the results from our Issues discussion, > and request any > comments before we move on. > > There are four pending issues: > > Issue 2: This issue has to do with the adoption of the > proposed requirement 4.3. > > The consensus in the meeting was to adopt the requirement > with some minor wordsmithing. > > Issue 4: This issue had to do with new terminology for > proactive and reactive > Issue 7: Remove the terminology proactive and reactive > > After some intense discussion on the issue, it was > decided to remove > proactive and reactive, and instead adopt a very simple > requirement > similar to: > > "Context Transfer may occur prior to, during or after a > handover." "And in any parallel space-time continuum." > > Nearly complete consensus on this approach. > I did not put my hand up. I was too amazed. > Issue 5: This issue was a request to support multi-phasic CTs > > The text proposed at the meeting was: > "4.9 Context information MAY be transferred in phases, > allowing for > time critical state to be sent first, and non-time > critical state > to be sent later. Similar to the change to proactive and reactive: we do not need the second phrase (the part starting with "allowing for . . . "). The second phrase describes one application of multiphase, not a requirement for it (NB: for proactive, the order is reversed, so the requirement is actually incorrect as it is worded). So, yes to: "4.9 Context information MAY be transferred in phases." Note that we have a requirement that the context must be labelled. > > The cost of building and sending smaller packets is > less, as well > as parsing and processing by the receiver. " This is editorial, and subject to debate (hmmm, smaller packets are easier to build and send? Does this means that ATM is more efficient ;^} ) > > The consensus at the meeting was to adopt the text, but > a comment was > made that how one defines time critical is an issue > since anything > could be send in the initial CT message. > > Each CT profile would need to specify whether it is time-critical. Why? We need a protocol model to better understand the requirements for time-critical state transfer (if there are any) and any need for synchronization. > > If someone has any comments on the above, I'd like to hear > them now. As you > know, decisions aren't made at meetings, and the list is > still the preferred > medium to provide comments. If I hear no objections by 8/21, > these changes > will be included in the next revision of the draft will be > send to WG last call. Comments provided. > > Thanks, Your welcome. Gary > > PatC > ------_=_NextPart_001_01C12465.7400C970 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

Pat:

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: August 13, 2001 19:19
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Update on Issues from IETF meeting
>
>
> All,
>
> Although I need to put together the minutes from the London
> meeting last week,
> I'd like to send out the results from our Issues discussion,
> and request any
> comments before we move on.
>
> There are four pending issues:
>
> Issue 2: This issue has to do with the adoption of the
> proposed requirement 4.3.
>
>       The consensus in the meeting was to adopt the requirement
>       with some minor wordsmithing.
>
> Issue 4: This issue had to do with new terminology for
> proactive and reactive
> Issue 7: Remove the terminology proactive and reactive
>
>       After some intense discussion on the issue, it was
> decided to remove
>       proactive and reactive, and instead adopt a very simple
> requirement
>       similar to:
>
>       "Context Transfer may occur prior to, during or after a
> handover."

"And in any parallel space-time continuum."

>
>       Nearly complete consensus on this approach.
>

I did not put my hand up. I was too amazed.

> Issue 5: This issue was a request to support multi-phasic CTs
>
>       The text proposed at the meeting was:
>       "4.9 Context information MAY be transferred in phases,
> allowing for
>       time critical state to be sent first, and non-time
> critical state
>       to be sent later.

Similar to the change to proactive and reactive: we do not need
the second phrase (the part starting with "allowing for . . . ").
The second phrase describes one application of multiphase, not
a requirement for it (NB: for proactive, the order is reversed,
so the requirement is actually incorrect as it is worded).

So, yes to:
"4.9 Context information MAY be transferred in phases."

Note that we have a requirement that the context must be labelled.

>
>       The cost of building and sending smaller packets is
> less, as well
>       as parsing and processing by the receiver. "

This is editorial, and subject to debate (hmmm, smaller packets are
easier to build and send? Does this means that ATM is more efficient
;^} )

>
>       The consensus at the meeting was to adopt the text, but
> a comment was
>       made that how one defines time critical is an issue
> since anything
>       could be send in the initial CT message.
>
>     Each CT profile would need to specify whether it is time-critical.

Why? We need a protocol model to better understand the requirements for
time-critical state transfer (if there are any) and any need for synchronization.

>
> If someone has any comments on the above, I'd like to hear
> them now. As you
> know, decisions aren't made at meetings, and the list is
> still the preferred
> medium to provide comments. If I hear no objections by 8/21,
> these changes
> will be included in the next revision of the draft will be
> send to WG last call.

Comments provided.

>
> Thanks,

Your welcome.
Gary
>
> PatC
>

------_=_NextPart_001_01C12465.7400C970-- From owner-seamoby@diameter.org Tue Aug 14 09:21:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03442 for ; Tue, 14 Aug 2001 09:21:36 -0400 (EDT) Received: (qmail 15987 invoked by alias); 14 Aug 2001 13:08:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15981 invoked by uid 200); 14 Aug 2001 13:08:41 -0000 Received: (qmail 15973 invoked from network); 14 Aug 2001 13:08:35 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 13:08:36 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7EDJJp28623 for ; Tue, 14 Aug 2001 09:19:19 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 14 Aug 2001 09:19:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 09:19:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Tue, 14 Aug 2001 09:19:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C124C3.B1932E00" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C124C3.B1932E00 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, August 13, 2001 7:19 PM To: seamoby@cdma-2000.org Subject: [seamoby] Update on Issues from IETF meeting All, Although I need to put together the minutes from the London meeting last week, I'd like to send out the results from our Issues discussion, and request any comments before we move on. There are four pending issues: Issue 2: This issue has to do with the adoption of the proposed requirement 4.3. The consensus in the meeting was to adopt the requirement with some minor wordsmithing. Issue 4: This issue had to do with new terminology for proactive and reactive Issue 7: Remove the terminology proactive and reactive After some intense discussion on the issue, it was decided to remove proactive and reactive, and instead adopt a very simple requirement similar to: "Context Transfer may occur prior to, during or after a handover." Nearly complete consensus on this approach. [Hamid] I will not raise my hand for this one. I do not understand the rationale why the proactive and reactive terms are being removed. There are clear advantages of performing a context transfer prior to the traffic re-direction. What we want to achieve with context transfer? Just dumping some information from one AR to the other and we do not even care how it can be used for seamless handover. Issue 5: This issue was a request to support multi-phasic CTs The text proposed at the meeting was: "4.9 Context information MAY be transferred in phases, allowing for time critical state to be sent first, and non-time critical state to be sent later. [Hamid] I guess ct in phases is ok but how can the receiver of the context process the time-critical information if it had not received the other part of it.?. I guess the order is reverse. The non-time critical should be transferred first. The cost of building and sending smaller packets is less, as well as parsing and processing by the receiver. " The consensus at the meeting was to adopt the text, but a comment was made that how one defines time critical is an issue since anything could be send in the initial CT message. Each CT profile would need to specify whether it is time-critical. [Hamid] what is ct profile??? I do not know this term. If someone has any comments on the above, I'd like to hear them now. As you know, decisions aren't made at meetings, and the list is still the preferred medium to provide comments. If I hear no objections by 8/21, these changes will be included in the next revision of the draft will be send to WG last call. Thanks, PatC ------_=_NextPart_001_01C124C3.B1932E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Update on Issues from IETF meeting

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
Sent: Monday, August 13, 2001 7:19 PM
To: seamoby@cdma-2000.org
Subject: [seamoby] Update on Issues from IETF = meeting


All,

Although I need to put together the minutes from the = London meeting last week,
I'd like to send out the results from our Issues = discussion, and request any
comments before we move on.

There are four pending issues:

Issue 2: This issue has to do with the adoption of = the proposed requirement 4.3.

        The = consensus in the meeting was to adopt the requirement
        with some = minor wordsmithing.

Issue 4: This issue had to do with new terminology = for proactive and reactive
Issue 7: Remove the terminology proactive and = reactive

        After some = intense discussion on the issue, it was decided to remove
        proactive = and reactive, and instead adopt a very simple requirement
        similar = to:

        "Context Transfer may occur prior to, during or after a = handover."

        Nearly = complete consensus on this approach.


[Hamid] I will not raise my hand for this one. I do = not understand the rationale why the proactive and reactive terms are = being removed. There are clear advantages of performing a context = transfer prior to the traffic re-direction. What we want to achieve = with context transfer? Just dumping some information from one AR to the = other and we do not even care how it can be used for seamless handover. =


Issue 5: This issue was a request to support = multi-phasic CTs

        The text = proposed at the meeting was:
        "4.9 = Context information MAY be transferred in phases, allowing for
        time = critical state to be sent first, and non-time critical state
        to be = sent later.

[Hamid] I guess ct in phases is ok but how can the = receiver of the context process the time-critical information if it had = not received the other part of it.?. I guess the order is reverse. The = non-time critical should be transferred first.

        The cost = of building and sending smaller packets is less, as well
        as = parsing and processing by the receiver. "

        The = consensus at the meeting was to adopt the text, but a comment was=
        made that = how one defines time critical is an issue since anything
        could be = send in the initial CT message.

    Each CT profile would need to = specify whether it is time-critical.

[Hamid] what is ct profile??? I do not know this = term.


If someone has any comments on the above, I'd like to = hear them now. As you
know, decisions aren't made at meetings, and the = list is still the preferred
medium to provide comments. If I hear no objections = by 8/21, these changes
will be included in the next revision of the draft = will be send to WG last call.

Thanks,

PatC

------_=_NextPart_001_01C124C3.B1932E00-- From owner-seamoby@diameter.org Tue Aug 14 10:20:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05636 for ; Tue, 14 Aug 2001 10:20:19 -0400 (EDT) Received: (qmail 16689 invoked by alias); 14 Aug 2001 14:08:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16683 invoked by uid 200); 14 Aug 2001 14:08:04 -0000 Received: (qmail 16678 invoked from network); 14 Aug 2001 14:08:01 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 14:08:01 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 10:19:05 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054747@ftmail> From: George Tsirtsis To: seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: [seamoby] Comments on CT Reqs draft Date: Tue, 14 Aug 2001 10:18:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk All, Here are some comments on the current CT requirements draft. We quote text from the draft to make this easier to read and try to suggest alternative text when possible. Comment 1 ----------- "4.9 All context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of the context transfer. The total context associated with the MN's traffic is composed of various types of feature context. To effect a rapid transfer, the context information has to be readily available when the AR begins the transfer. " This does not make sense as stated. What initiates the gathering of all the relevant context to be transferred? Or you just mean that all relevant context is in close proximity to the CT code (i.e.: same box)? By saying the context MUST be ready when CT is initiated we just defer the potential for delay, we do not eliminate it...i.e.: one may not initiate CT until it has gathered all context but the gathering process could take very long time. We suggest something like the following: "CT should not be slowed down by a process or feature inability to make appropriate context available to CT. CT SHOULD be able to transfer context as it becomes available. Comment 2 ---------- "4.10 The context information provided for transfer MUST be reliable. The context to be transferred must not only be readily available for transfer, but the sending AR must ensure that the information is sound. The context transfer solution may provide mechanisms to support reliable transfer of context, but the effectiveness of context transfer in enhancing handover between ARs would very likely be compromised by attempts to transfer malformed context." This again makes no sense to the casual reader! How does CT "evaluate" the soundness of a protocol specific context. Consider that the effectiveness of context transfer in enhancing handover between ARs would also very likely be compromised by attempts to ensure that the information is sound. Please remove this totally unreasonable requirement or explain what you mean. If people feel strongly about this it should as a minimum be watered down like this: "The sender SHOULD make all reasonable efforts to ensure the data is sound since transfer of invalid data may be more damaging than transfer of no data at all" Comment 3 ---------- "5.1.1 The context transfer protocol MUST be capable of transferring all of the different types of feature context necessary to support the MN's traffic at a receiving AR." I would like to propose to clarify this further: "CT MUST be generic and feature agnostic, i.e.: CT MUST allow new features to be defined and transported without having to change CT itself." Comment 4 ----------- "5.4.1 Proactive context transfer MUST be completed before the handover of the Mobile Node's traffic to the receiving AR completes." Does this make sense after the removal of the proactive/reactive concept from this doc. Even if it does make sense there is no way to ensure such a thing. You can only try and have mechanisms so you can recover when things go wrong. E.g.: there might not be any connectivity between old and new AR. This is a SHOULD not a MUST. Comment 5 ---------- "5.4.3 A context transfer MUST complete with a minimum number of protocol exchanges between the source AR and the rest of the ARs. " This is a SHOULD..protocol engineering is a trade-off and this is one of the basic variables (signaling level). The requirements document may decair its preference to low signaling levels but must not mandate it...At the end of the day a slightly slower more concrete CT may be better than a faster flakey CT! Comment 6 ----------- "5.4.4 The context transfer protocol design MUST minimize the amount of processing required at the sending and receiving Access Routers." As above..this is a SHOULD not a MUST...Minimization implies the existence of some optimization function with constraints. Who sets the constraints? If they are set by each implementor according to their fancy, then all these protocols can claim compliance with the above. Comment 7 ----------- "5.4.5 The Context Transfer protocol MUST meet the timing constraints required by all the feature contexts." Again, CT SHOULD attempt to comply with timing constrains and have ways to recover if it does not...nothing is for certain here...Maybe change with something like this: "The Context Transfer protocol SHOULD strive to comply with the the timing constraints imposed by the different feature contexts. The CT protocol MUST provide ways to recover and allow the handoff to complete normally when the timing constrains are not met." Comment 8 ----------- "5.6.2 The context transfer protocol MUST include methods for exchanging information with the handover process. Both context transfer and handover require information on the AR candidates for handover. The context transfer entities may, in the process of establishing and supporting context transfer, acquire information that would be useful to the handover process in determining the new forwarding path: for example, the outcome of an admission control decision at a receiving AR." The text here is very nebulus, so as a minimum a concrete example should be given. "For example, if during the CT process one newAR appears to be able to support the MN's QoS requirements better than the other, then CT SHOULD be able to make this information known the handoff process." Regards George Tsirtsis Michaela Vandermeer Alan O'Neill From owner-seamoby@diameter.org Tue Aug 14 10:23:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05724 for ; Tue, 14 Aug 2001 10:23:55 -0400 (EDT) Received: (qmail 17195 invoked by alias); 14 Aug 2001 14:12:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17189 invoked by uid 200); 14 Aug 2001 14:12:42 -0000 Received: (qmail 17184 invoked from network); 14 Aug 2001 14:12:39 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 14:12:39 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 10:23:45 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054748@ftmail> From: George Tsirtsis To: seamoby@cdma-2000.org Subject: [seamoby] Who defines protocol specific context and how is transported? Date: Tue, 14 Aug 2001 10:23:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Here is one more issue that we consider important and thus post separately... The requirements draft says: "5.1.2 The context transfer protocol design MUST define a standard representation for conveying context information that will be interpreted uniformly and perspicuously by different implementations." Who defines the protocol specific info but also the way it is forwarded between ARs? Protocol specific groups MUST be involved in this process. SEAMOBY MUST NOT make the mistake to try to define feature specific context descriptions without the concent and active participation of the appropriate WGs. The initial CT protocol proposals MAY use examples of framing feature context but then the appropriate WG MUST not only be consulted but design the protocol specific transfer whenever possible. One way would be to define CT as a protocol that carries opague objects with various modes e.g:reliable/unrelaible or before/during/after handoff. Seamoby should then go to each WG affected (e.g.: RSVP, RHOC, AAA etc) and define the actual context, timing and reliability requirements. This is the only way for the experts in its area to: 1. Provide feedback to the basic CT mechanism/protocol from their prespective 2. Evaluate the relative merits of CT vs re-establishment of state at newAR (it is not always obvious that CT is going to be beneficial) 3. Define the timing and reliability requirements of protocol specific state Regards George (and Scott, Vince, Alan, Matt and Michaela) From owner-seamoby@diameter.org Tue Aug 14 10:26:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05745 for ; Tue, 14 Aug 2001 10:26:03 -0400 (EDT) Received: (qmail 17255 invoked by alias); 14 Aug 2001 14:12:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17249 invoked by uid 200); 14 Aug 2001 14:12:48 -0000 Received: (qmail 17209 invoked by uid 500); 14 Aug 2001 14:12:43 -0000 Date: Tue, 14 Aug 2001 07:12:43 -0700 From: Pat Calhoun To: Hamid Syed Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010814071243.J16567@charizard.diameter.org> Mail-Followup-To: Hamid Syed , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com>; from hmsyed@nortelnetworks.com on Tue, Aug 14, 2001 at 09:19:05AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk > Issue 4: This issue had to do with new terminology for proactive and > reactive > Issue 7: Remove the terminology proactive and reactive > > After some intense discussion on the issue, it was decided to remove > proactive and reactive, and instead adopt a very simple requirement > similar to: > > "Context Transfer may occur prior to, during or after a handover." > > Nearly complete consensus on this approach. > > > [Hamid] I will not raise my hand for this one. I do not understand the > rationale why the proactive and reactive terms are being removed. There are > clear advantages of performing a context transfer prior to the traffic > re-direction. What we want to achieve with context transfer? Just dumping > some information from one AR to the other and we do not even care how it can > be used for seamless handover. But I think that we all agreed that pro/re were modes, and did not change the protocol in any way. It really came down to implementation, and how CT would be invoked by the mobility management subsystem. So, what the very complex text was really trying to state was that Ct can occur at any time, and since the text wasn't really specifying a requirement per se, the group felt that the above wording was clearer (and I tend to agree). > Issue 5: This issue was a request to support multi-phasic CTs > > The text proposed at the meeting was: > "4.9 Context information MAY be transferred in phases, allowing for > time critical state to be sent first, and non-time critical state > to be sent later. > > [Hamid] I guess ct in phases is ok but how can the receiver of the context > process the time-critical information if it had not received the other part > of it.?. I guess the order is reverse. The non-time critical should be > transferred first. Right, well Gary sent out text earlier that I like even more "4.9 Context transfer MAY occur in phases" That was we get away from defining why, and ... > The consensus at the meeting was to adopt the text, but a comment > was > made that how one defines time critical is an issue since anything > could be send in the initial CT message. > > Each CT profile would need to specify whether it is time-critical. ... we don't have to worry about comments like these :) Thanks, PatC From owner-seamoby@diameter.org Tue Aug 14 15:15:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13342 for ; Tue, 14 Aug 2001 15:15:34 -0400 (EDT) Received: (qmail 20155 invoked by alias); 14 Aug 2001 18:57:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20149 invoked by uid 200); 14 Aug 2001 18:57:55 -0000 Received: (qmail 20143 invoked from network); 14 Aug 2001 18:57:52 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 18:57:52 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7EJ8Wp20591 for ; Tue, 14 Aug 2001 15:08:34 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 14 Aug 2001 15:08:38 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 15:08:40 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EF3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Tue, 14 Aug 2001 15:08:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C124F4.851DAFE0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C124F4.851DAFE0 Content-Type: text/plain; charset="iso-8859-1" George: Most of these comments seem to be editorial. As you seem to have figured out the intended meaning in most cases, I suggest that they do make sense to the casual reader. The intent here cannot be to define bullet proof requirements (such a document could easily consume 100s of pages). More comments below: Gary > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Tuesday, August 14, 2001 10:19 AM > To: seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: [seamoby] Comments on CT Reqs draft > > > All, > > Here are some comments on the current CT requirements draft. > We quote text > from the draft to make this easier to read and try to suggest > alternative > text when possible. > > > > Comment 1 > ----------- > "4.9 All context information to be transferred MUST be > available at the > AR performing the transfer, prior to the initiation of the context > transfer. > > The total context associated with the MN's traffic is composed of > various types of feature context. To effect a rapid transfer, the > context information has to be readily available when the AR begins > the transfer. " > > This does not make sense as stated. What initiates the > gathering of all the > relevant context to be transferred? Or you just mean that all relevant > context is in close proximity to the CT code (i.e.: same > box)? By saying the > context MUST be ready when CT is initiated we just defer the > potential for > delay, we do not eliminate it...i.e.: one may not initiate CT > until it has > gathered all context but the gathering process could take > very long time. > We suggest something like the following: > "CT should not be slowed down by a process or feature > inability to make > appropriate context available to CT. CT SHOULD be able to > transfer context > as it becomes available. Your suggestion is syntactically incorrect, and thus harder to understand. The intent is as you surmised: to require that the context be at the AR, and not elsewhere when the transfer is to be initiated. There are many finer points that could be made, but with markedly diminishing importance. > > Comment 2 > ---------- > "4.10 The context information provided for transfer MUST be reliable. > > The context to be transferred must not only be readily > available for > transfer, but the sending AR must ensure that the > information is sound. > > The context transfer solution may provide mechanisms to > support reliable > transfer of context, but the effectiveness of context transfer in > enhancing > handover between ARs would very likely be compromised by > attempts to > transfer malformed context." > > This again makes no sense to the casual reader! How does CT > "evaluate" the > soundness of a protocol specific context. Consider that the > effectiveness of > context transfer in enhancing handover between ARs would also > very likely be > compromised by attempts to ensure that the information is > sound. Please The requirement says nothing about CT evaluating the soundness of the context. The requirement actual says the opposite: that the context must itself be reliable, for ct will do nothing to compensate for unreliable context. > remove this totally unreasonable requirement or explain what > you mean. If It is not unreasonable. It is an absolute requirement, and there was general agreement (please refer to the archives for the complete discussion). > people feel strongly about this it should as a minimum be > watered down like > this: > "The sender SHOULD make all reasonable efforts to ensure the > data is sound > since transfer of invalid data may be more damaging than > transfer of no data > at all" > > Comment 3 > ---------- > "5.1.1 The context transfer protocol MUST be capable of > transferring all > of the different types of feature context necessary to > support the > MN's traffic at a receiving AR." > > I would like to propose to clarify this further: > "CT MUST be generic and feature agnostic, i.e.: CT MUST allow > new features > to be defined and transported without having to change CT itself." This is an entirely different requirement. Your version is trying to "future proof" ct. 5.1.1 is concerned with the current features available at an AR. Future proof statements such as the one above are, IMHO, motherhood, as everything has to agree, and yet there is no way of ensuring that a solution is future proof. > > > > Comment 4 > ----------- > "5.4.1 Proactive context transfer MUST be completed before > the handover > of the Mobile Node's traffic to the receiving AR completes." > > Does this make sense after the removal of the > proactive/reactive concept > from this doc. Even if it does make sense there is no way to > ensure such a > thing. You can only try and have mechanisms so you can > recover when things > go wrong. E.g.: there might not be any connectivity between > old and new AR. > This is a SHOULD not a MUST. I agree. But if you read the minutes of the last IETF meeting, this statement will be changed - probably deleted, as "proactive" and "reactive" are being removed from the draft. > > Comment 5 > ---------- > "5.4.3 A context transfer MUST complete with a minimum number > of protocol > exchanges between the source AR and the rest of the ARs. " > > This is a SHOULD..protocol engineering is a trade-off and > this is one of the > basic variables (signaling level). The requirements document > may decair its > preference to low signaling levels but must not mandate > it...At the end of > the day a slightly slower more concrete CT may be better than a faster > flakey CT! In truth, this is a non-requirement. "minimum" is one of those ambiguous words, that cannot be measured without a reference with the requirement does not specify. In essence, given that the reliability requirements for ct are met (which are tbd), then all this requirement says is that there shouldn't be any "excess" exchanges. Again, there is no measure to determine what exchanges might be "excess". Probably the only real application of this requirement is if we end up comparing two protocols that are identical in every way but one has more exchanges. Might happen. At this point, this requirement is unlikely to be deleted, and it has no impact as it is stated. > > > Comment 6 > ----------- > "5.4.4 The context transfer protocol design MUST minimize the > amount of > processing required at the sending and receiving Access > Routers." > > As above..this is a SHOULD not a MUST...Minimization implies > the existence > of some optimization function with constraints. Who sets the > constraints? If > they are set by each implementor according to their fancy, > then all these > protocols can claim compliance with the above. The language could be improved, but the requirement is accurate: the protocol MUST not introduce excess processing. You are right, the "minimization" requirement has no basis for determining compliance. > > > Comment 7 > ----------- > "5.4.5 The Context Transfer protocol MUST meet the timing constraints > required by all the feature contexts." > > Again, CT SHOULD attempt to comply with timing constrains and > have ways to > recover if it does not...nothing is for certain here...Maybe > change with > something like this: > "The Context Transfer protocol SHOULD strive to comply with > the the timing > constraints imposed by the different feature contexts. The CT > protocol MUST > provide ways to recover and allow the handoff to complete > normally when the > timing constrains are not met." Sorry, but if a protocol meets the requirements, whether through a clean design or through "recovery", then it meets this requirement. "strive" is an anthropomorphic term that doesn't belong in a requirement. Also, you have specified two requirements in place of one. The requirement remains a MUST. The fact is that everyone one of the requirements is likely to fail under some conditions, and the protocol is going to have to have some reasonable recovery mechanisms. It would take years for us to gain consensus on all the necessary recovery mechanisms. > > > Comment 8 > ----------- > "5.6.2 The context transfer protocol MUST include methods for > exchanging > information with the handover process. > > Both context transfer and handover require information on the > AR candidates for handover. The context transfer entities > may, in the > process of establishing and supporting context transfer, acquire > information that would be useful to the handover process in > determining the new forwarding path: for example, the outcome of an > admission control decision at a receiving AR." > > > The text here is very nebulus, so as a minimum a concrete > example should be > given. "For example, if during the CT process one newAR > appears to be able > to support the MN's QoS requirements better than the other, > then CT SHOULD > be able to make this information known the handoff process." Why? Here is a good example where the meaning of the requirement was in fact clear to you. Are you pre-supposing that other readers have less of a grasp of English, or a lower IQ? As the prime audience for this document is actually the people who participated in the writing, it would seem reasonable that they would derive the same meaning as you did. > > > > Regards > > George Tsirtsis > Michaela Vandermeer > Alan O'Neill Cheerio, Gary > ------_=_NextPart_001_01C124F4.851DAFE0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Comments on CT Reqs draft

George:

  Most of these comments seem to be editorial. As you seem
to have figured out the intended meaning in most cases, I suggest
that they do make sense to the casual reader. The intent here cannot
be to define bullet proof requirements (such a document could easily
consume 100s of pages).

  More comments below:

Gary

> -----Original Message-----
> From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
> Sent: Tuesday, August 14, 2001 10:19 AM
> To: seamoby@cdma-2000.org
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: [seamoby] Comments on CT Reqs draft
>
>
> All,
>
> Here are some comments on the current CT requirements draft.
> We quote text
> from the draft to make this easier to read and try to suggest
> alternative
> text when possible.
>
> 
>
> Comment 1
> -----------
> "4.9 All context information to be transferred MUST be
> available at the
>    AR performing the transfer, prior to the initiation of the context
>    transfer.
> 
>    The total context associated with the MN's traffic is composed of
>    various types of feature context. To effect a rapid transfer, the
>    context information has to be readily available when the AR begins
>    the transfer. "
> 
> This does not make sense as stated. What initiates the
> gathering of all the
> relevant context to be transferred? Or you just mean that all relevant
> context is in close proximity to the CT code (i.e.: same
> box)? By saying the
> context MUST be ready when CT is initiated we just defer the
> potential for
> delay, we do not eliminate it...i.e.: one may not initiate CT
> until it has
> gathered all context but the gathering process could take
> very long time.
> We suggest something like the following:
> "CT should not be slowed down by a process or feature
> inability to make
> appropriate context available to CT. CT SHOULD be able to
> transfer context
> as it becomes available.

Your suggestion is syntactically incorrect, and thus harder to understand.
The intent is as you surmised: to require that the context be at the AR,
and not elsewhere when the transfer is to be initiated. There are many
finer points that could be made, but with markedly diminishing importance.

>
> Comment 2
> ----------
> "4.10 The context information provided for transfer MUST be reliable.
>
>    The context to be transferred must not only be readily
> available for
>    transfer, but the sending AR must ensure that the
> information is sound.
>   
>    The context transfer solution may provide mechanisms to
> support reliable
>    transfer of context, but the effectiveness of context transfer in
> enhancing
>    handover between ARs would very likely be compromised by
> attempts to
>    transfer malformed context."
>
> This again makes no sense to the casual reader! How does CT
> "evaluate" the
> soundness of a protocol specific context. Consider that the
> effectiveness of
> context transfer in enhancing handover between ARs would also
> very likely be
> compromised by attempts to ensure that the information is
> sound. Please

The requirement says nothing about CT evaluating the soundness
of the context. The requirement actual says the opposite: that
the context must itself be reliable, for ct will do nothing to
compensate for unreliable context.

> remove this totally unreasonable requirement or explain what
> you mean. If

It is not unreasonable. It is an absolute requirement, and there
was general agreement (please refer to the archives for the complete
discussion).

> people feel strongly about this it should as a minimum be
> watered down like
> this:
> "The sender SHOULD make all reasonable efforts to ensure the
> data is sound
> since transfer of invalid data may be more damaging than
> transfer of no data
> at all"
>
> Comment 3
> ----------
> "5.1.1 The context transfer protocol MUST be capable of
> transferring all
>       of the different types of feature context necessary to
> support the
>       MN's traffic at a receiving AR."
>
> I would like to propose to clarify this further:
> "CT MUST be generic and feature agnostic, i.e.: CT MUST allow
> new features
> to be defined and transported without having to change CT itself."

This is an entirely different requirement. Your version is trying to
"future proof" ct. 5.1.1 is concerned with the current features available
at an AR. Future proof statements such as the one above are, IMHO, motherhood,
as everything has to agree, and yet there is no way of ensuring that a
solution is future proof.

>
>
>
> Comment 4
> -----------
> "5.4.1 Proactive context transfer MUST be completed before
> the handover
>       of the Mobile Node's traffic to the receiving AR completes."
>
> Does this make sense after the removal of the
> proactive/reactive concept
> from this doc. Even if it does make sense there is no way to
> ensure such a
> thing. You can only try and have mechanisms so you can
> recover when things
> go wrong. E.g.: there might not be any connectivity between
> old and new AR.
> This is a SHOULD not a MUST.

I agree. But if you read the minutes of the last IETF meeting, this
statement will be changed - probably deleted, as "proactive" and "reactive"
are being removed from the draft.

>
> Comment 5
> ----------
> "5.4.3 A context transfer MUST complete with a minimum number
> of protocol
>       exchanges between the source AR and the rest of the ARs. "
>
> This is a SHOULD..protocol engineering is a trade-off and
> this is one of the
> basic variables (signaling level). The requirements document
> may decair its
> preference to low signaling levels but must not mandate
> it...At the end of
> the day a slightly slower more concrete CT may be better than a faster
> flakey CT!

In truth, this is a non-requirement. "minimum" is one of those ambiguous
words, that cannot be measured without a reference with the requirement
does not specify.

In essence, given that the reliability requirements for ct are met (which
are tbd), then all this requirement says is that there shouldn't be any
"excess" exchanges. Again, there is no measure to determine what exchanges
might be "excess".

Probably the only real application of this requirement is if we end up
comparing two protocols that are identical in every way but one has more
exchanges. Might happen.

At this point, this requirement is unlikely to be deleted, and it has
no impact as it is stated.

>
>
> Comment 6
> -----------
> "5.4.4 The context transfer protocol design MUST minimize the
> amount of
>       processing required at the sending and receiving Access
> Routers."
>
> As above..this is a SHOULD not a MUST...Minimization implies
> the existence
> of some optimization function with constraints. Who sets the
> constraints? If
> they are set by each implementor according to their fancy,
> then all these
> protocols can claim compliance with the above.

The language could be improved, but the requirement is accurate:
the protocol MUST not introduce excess processing. You are right,
the "minimization" requirement has no basis for determining compliance.

>
>
> Comment 7
> -----------
> "5.4.5 The Context Transfer protocol MUST meet the timing constraints
>       required by all the feature contexts."
>
> Again, CT SHOULD attempt to comply with timing constrains and
> have ways to
> recover if it does not...nothing is for certain here...Maybe
> change with
> something like this:
> "The Context Transfer protocol SHOULD strive to comply with
> the the timing
> constraints imposed by the different feature contexts. The CT
> protocol MUST
> provide ways to recover and allow the handoff to complete
> normally when the
> timing constrains are not met."

Sorry, but if a protocol meets the requirements, whether through
a clean design or through "recovery", then it meets this requirement.
"strive" is an anthropomorphic term that doesn't belong in a requirement.
Also, you have specified two requirements in place of one.

The requirement remains a MUST. The fact is that everyone one of the
requirements is likely to fail under some conditions, and the protocol
is going to have to have some reasonable recovery mechanisms. It would
take years for us to gain consensus on all the necessary recovery mechanisms.

>
>
> Comment 8
> -----------
> "5.6.2 The context transfer protocol MUST include methods for
> exchanging
>       information with the handover process.
>
>    Both context transfer and handover require information on the
>    AR candidates for handover. The context transfer entities
> may, in the 
>    process of establishing and supporting context transfer, acquire 
>    information that would be useful to the handover process in 
>    determining the new forwarding path: for example, the outcome of an
>    admission control decision at a receiving AR."
>
>
> The text here is very nebulus, so as a minimum a concrete
> example should be
> given.  "For example, if during the CT process one newAR
> appears to be able
> to support the MN's QoS requirements better than the other,
> then CT SHOULD
> be able to make this information known the handoff process."

Why? Here is a good example where the meaning of the requirement was
in fact clear to you. Are you pre-supposing that other readers have less
of a grasp of English, or a lower IQ? As the prime audience for this
document is actually the people who participated in the writing, it
would seem reasonable that they would derive the same meaning as you did.

>
>
>
> Regards
>
> George Tsirtsis
> Michaela Vandermeer
> Alan O'Neill

Cheerio,
Gary
>

------_=_NextPart_001_01C124F4.851DAFE0-- From owner-seamoby@diameter.org Tue Aug 14 18:50:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16558 for ; Tue, 14 Aug 2001 18:50:39 -0400 (EDT) Received: (qmail 22249 invoked by alias); 14 Aug 2001 22:36:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22243 invoked by uid 200); 14 Aug 2001 22:36:34 -0000 Received: (qmail 22236 invoked from network); 14 Aug 2001 22:36:30 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 22:36:30 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 18:47:31 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605474D@ftmail> From: George Tsirtsis To: "'Gary Kenward'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Tue, 14 Aug 2001 18:47:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, August 14, 2001 8:09 PM To: 'George Tsirtsis'; seamoby@cdma-2000.org Cc: Alan O'Neill; Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft George: Most of these comments seem to be editorial. As you seem to have figured out the intended meaning in most cases, I suggest that they do make sense to the casual reader. The intent here cannot be to define bullet proof requirements (such a document could easily consume 100s of pages). GT> Sure and that is not my intent. Throughout your comments I see that you are resisting almost all change and I assume this is because of fear of opening another endless discussion, which is also not my intent. My only intent is to have a small number of very clear requirements that I can work with and develop a protocol that I can also implement. More comments below: Gary > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Tuesday, August 14, 2001 10:19 AM > To: seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: [seamoby] Comments on CT Reqs draft > > > All, > > Here are some comments on the current CT requirements draft. > We quote text > from the draft to make this easier to read and try to suggest > alternative > text when possible. > > > > Comment 1 > ----------- > "4.9 All context information to be transferred MUST be > available at the > AR performing the transfer, prior to the initiation of the context > transfer. > > The total context associated with the MN's traffic is composed of > various types of feature context. To effect a rapid transfer, the > context information has to be readily available when the AR begins > the transfer. " > > This does not make sense as stated. What initiates the > gathering of all the > relevant context to be transferred? Or you just mean that all relevant > context is in close proximity to the CT code (i.e.: same > box)? By saying the > context MUST be ready when CT is initiated we just defer the > potential for > delay, we do not eliminate it...i.e.: one may not initiate CT > until it has > gathered all context but the gathering process could take > very long time. > We suggest something like the following: > "CT should not be slowed down by a process or feature > inability to make > appropriate context available to CT. CT SHOULD be able to > transfer context > as it becomes available. Your suggestion is syntactically incorrect, and thus harder to understand. The intent is as you surmised: to require that the context be at the AR, and not elsewhere when the transfer is to be initiated. There are many finer points that could be made, but with markedly diminishing importance. GT> Gary it does not make sense. My point here is that the requirement relates to timing considerations which are covered by other requirements in this spec...weather the context is in or out of the AR it is a mute point and a protocol should not be held accountable for not doing it this way. > > Comment 2 > ---------- > "4.10 The context information provided for transfer MUST be reliable. > > The context to be transferred must not only be readily > available for > transfer, but the sending AR must ensure that the > information is sound. > > The context transfer solution may provide mechanisms to > support reliable > transfer of context, but the effectiveness of context transfer in > enhancing > handover between ARs would very likely be compromised by > attempts to > transfer malformed context." > > This again makes no sense to the casual reader! How does CT > "evaluate" the > soundness of a protocol specific context. Consider that the > effectiveness of > context transfer in enhancing handover between ARs would also > very likely be > compromised by attempts to ensure that the information is > sound. Please The requirement says nothing about CT evaluating the soundness of the context. The requirement actual says the opposite: that the context must itself be reliable, for ct will do nothing to compensate for unreliable context. GT> I totaly agree with what you state above (which I wish it was the real text) but the spec says and I repeat "... The context to be transferred must not only be readily available for transfer, but the sending AR must ensure that the information is sound." it then also says..."...the effectiveness of context transfer in enhancing handover between ARs would very likely be compromised by attempts to transfer malformed context". If the requirement is only about reliability of transfer then that is what it should state. > remove this totally unreasonable requirement or explain what > you mean. If It is not unreasonable. It is an absolute requirement, and there was general agreement (please refer to the archives for the complete discussion). GT> No, the requirement is that the CT protocol MUST support reliable transfer which is fine...it is not about the AR checking the soundness of the context...the text is confusing. > people feel strongly about this it should as a minimum be > watered down like > this: > "The sender SHOULD make all reasonable efforts to ensure the > data is sound > since transfer of invalid data may be more damaging than > transfer of no data > at all" > > Comment 3 > ---------- > "5.1.1 The context transfer protocol MUST be capable of > transferring all > of the different types of feature context necessary to > support the > MN's traffic at a receiving AR." > > I would like to propose to clarify this further: > "CT MUST be generic and feature agnostic, i.e.: CT MUST allow > new features > to be defined and transported without having to change CT itself." This is an entirely different requirement. Your version is trying to "future proof" ct. 5.1.1 is concerned with the current features available at an AR. Future proof statements such as the one above are, IMHO, motherhood, as everything has to agree, and yet there is no way of ensuring that a solution is future proof. GT> I do not agree. A number of protocols satisfy the above requirement..e.g.: diameter. But if you thing that my suggestion is describing a different requirement then it is clear that I did not understand 5.1.1. Please illuminate. > > > > Comment 4 > ----------- > "5.4.1 Proactive context transfer MUST be completed before > the handover > of the Mobile Node's traffic to the receiving AR completes." > > Does this make sense after the removal of the > proactive/reactive concept > from this doc. Even if it does make sense there is no way to > ensure such a > thing. You can only try and have mechanisms so you can > recover when things > go wrong. E.g.: there might not be any connectivity between > old and new AR. > This is a SHOULD not a MUST. I agree. But if you read the minutes of the last IETF meeting, this statement will be changed - probably deleted, as "proactive" and "reactive" are being removed from the draft. GT> That is what I asked first ... and yes I was in the meeting which only talked about 4.4 and 4.5, hence the question...glad you agree. > > Comment 5 > ---------- > "5.4.3 A context transfer MUST complete with a minimum number > of protocol > exchanges between the source AR and the rest of the ARs. " > > This is a SHOULD..protocol engineering is a trade-off and > this is one of the > basic variables (signaling level). The requirements document > may decair its > preference to low signaling levels but must not mandate > it...At the end of > the day a slightly slower more concrete CT may be better than a faster > flakey CT! In truth, this is a non-requirement. "minimum" is one of those ambiguous words, that cannot be measured without a reference with the requirement does not specify. In essence, given that the reliability requirements for ct are met (which are tbd), then all this requirement says is that there shouldn't be any "excess" exchanges. Again, there is no measure to determine what exchanges might be "excess". Probably the only real application of this requirement is if we end up comparing two protocols that are identical in every way but one has more exchanges. Might happen. At this point, this requirement is unlikely to be deleted, and it has no impact as it is stated. GT> Why not? You say that this is not really a requirement...yet it is a MUST in the requirements document. > > > Comment 6 > ----------- > "5.4.4 The context transfer protocol design MUST minimize the > amount of > processing required at the sending and receiving Access > Routers." > > As above..this is a SHOULD not a MUST...Minimization implies > the existence > of some optimization function with constraints. Who sets the > constraints? If > they are set by each implementor according to their fancy, > then all these > protocols can claim compliance with the above. The language could be improved, but the requirement is accurate: the protocol MUST not introduce excess processing. You are right, the "minimization" requirement has no basis for determining compliance. GT> So, again what is the point of mute requirements? get them out of the way and we will have a much better document. > > > Comment 7 > ----------- > "5.4.5 The Context Transfer protocol MUST meet the timing constraints > required by all the feature contexts." > > Again, CT SHOULD attempt to comply with timing constrains and > have ways to > recover if it does not...nothing is for certain here...Maybe > change with > something like this: > "The Context Transfer protocol SHOULD strive to comply with > the the timing > constraints imposed by the different feature contexts. The CT > protocol MUST > provide ways to recover and allow the handoff to complete > normally when the > timing constrains are not met." Sorry, but if a protocol meets the requirements, whether through a clean design or through "recovery", then it meets this requirement. "strive" is an anthropomorphic term that doesn't belong in a requirement. Also, you have specified two requirements in place of one. The requirement remains a MUST. The fact is that everyone one of the requirements is likely to fail under some conditions, and the protocol is going to have to have some reasonable recovery mechanisms. It would take years for us to gain consensus on all the necessary recovery mechanisms. GT> The point is that on one hand there is no way for any protocol to ensure that timing requirements are met while on the other hand you miss the obvious requirement of failsafe. BTW, I did not request consensus on the recovery mechanisms just the requirement for the protocol not to fail the handoff when it self fails. Then again I would be happy if you changed that MUST to SHOULD since no one can satisfy the MUST. > > > Comment 8 > ----------- > "5.6.2 The context transfer protocol MUST include methods for > exchanging > information with the handover process. > > Both context transfer and handover require information on the > AR candidates for handover. The context transfer entities > may, in the > process of establishing and supporting context transfer, acquire > information that would be useful to the handover process in > determining the new forwarding path: for example, the outcome of an > admission control decision at a receiving AR." > > > The text here is very nebulus, so as a minimum a concrete > example should be > given. "For example, if during the CT process one newAR > appears to be able > to support the MN's QoS requirements better than the other, > then CT SHOULD > be able to make this information known the handoff process." Why? GT> Because I give you a valid example that you actually agree with instead the mumble jumble of the current one but never mind...this is not important so forget about it. Here is a good example where the meaning of the requirement was in fact clear to you. Are you pre-supposing that other readers have less of a grasp of English, or a lower IQ? GT> I am not even going to respond to this...you must be very tired since I do not think you really want to be offensive. I just regret that I am causing you pain... As the prime audience for this document is actually the people who participated in the writing, it would seem reasonable that they would derive the same meaning as you did. GT> Gary, a general point. I can understand if I make a point and you disagree...in which case we have to discuss further. I do not, however, understand when you agree with me and yet say "....oh no, we can not change the doc now...too late", unless of course the rest of the group feels the same way. - Comments 4, 5, 6 we agree on and unless there are others that disagree we should change - Comment 2 I think we agree on but not sure yet - Comment 1, 3, 7 we do not seam to agree on - Comment 8 is not important Regards George From owner-seamoby@diameter.org Tue Aug 14 19:07:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16823 for ; Tue, 14 Aug 2001 19:07:52 -0400 (EDT) Received: (qmail 22941 invoked by alias); 14 Aug 2001 22:56:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22935 invoked by uid 200); 14 Aug 2001 22:56:28 -0000 Received: (qmail 22929 invoked from network); 14 Aug 2001 22:56:26 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 22:56:26 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA21674; Tue, 14 Aug 2001 16:07:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7EN7WT17305; Tue, 14 Aug 2001 16:07:32 -0700 X-mProtect: Tue, 14 Aug 2001 16:07:32 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdamcHkB; Tue, 14 Aug 2001 16:07:31 PDT Message-ID: <3B79AF33.B620A3@iprg.nokia.com> Date: Tue, 14 Aug 2001 16:07:31 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Syed CC: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid, Hamid Syed wrote: > > > Issue 4: This issue had to do with new terminology for proactive and > reactive > Issue 7: Remove the terminology proactive and reactive > > After some intense discussion on the issue, it was decided to > remove > proactive and reactive, and instead adopt a very simple > requirement > similar to: > > "Context Transfer may occur prior to, during or after a > handover." > > Nearly complete consensus on this approach. > > [Hamid] I will not raise my hand for this one. I do not understand the > rationale why the proactive and reactive terms are being removed. > There are clear advantages of performing a context transfer prior to > the traffic re-direction. Right. The new text allows for that isn't it ? You could do CT prior to, during or after a handover. > Each CT profile would need to specify whether it is time-critical. > > [Hamid] what is ct profile??? I do not know this term. > It could be something that identifies and defines the particular feature context. Regards, -Rajeev > > If someone has any comments on the above, I'd like to hear them now. > As you > know, decisions aren't made at meetings, and the list is still the > preferred > medium to provide comments. If I hear no objections by 8/21, these > changes > will be included in the next revision of the draft will be send to WG > last call. > > Thanks, > > PatC From owner-seamoby@diameter.org Tue Aug 14 19:26:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17051 for ; Tue, 14 Aug 2001 19:26:15 -0400 (EDT) Received: (qmail 23606 invoked by alias); 14 Aug 2001 23:14:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23600 invoked by uid 200); 14 Aug 2001 23:14:25 -0000 Received: (qmail 23592 invoked from network); 14 Aug 2001 23:14:23 -0000 Received: from femail8.sdc1.sfba.home.com (24.0.95.88) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 23:14:23 -0000 Received: from cr851003a ([24.157.232.166]) by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010814232555.KERF15794.femail8.sdc1.sfba.home.com@cr851003a>; Tue, 14 Aug 2001 16:25:55 -0700 Message-ID: <010701c12518$7ec3f9a0$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "Hamid Syed" , "'Pat Calhoun'" Cc: References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> Subject: Re: [seamoby] Update on Issues from IETF meeting Date: Tue, 14 Aug 2001 19:26:07 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01C124F6.F7353A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0104_01C124F6.F7353A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Update on Issues from IETF meetingTake a look at ROHC WG = Profiles. Each compression profile describes how to compress a = protocol: TCP compression Profile UDP compression Profile . . .=20 For CT we could have: TCP context profile UDP context profile . . . - Kulwinder. ----- Original Message -----=20 From: Hamid Syed=20 To: 'Pat Calhoun'=20 Cc: seamoby@cdma-2000.org=20 Sent: Tuesday, August 14, 2001 9:19 AM Subject: RE: [seamoby] Update on Issues from IETF meeting Each CT profile would need to specify whether it is time-critical. = [Hamid] what is ct profile??? I do not know this term. ------=_NextPart_000_0104_01C124F6.F7353A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Update on Issues from IETF = meeting
Take a look at ROHC WG Profiles.  = Each=20 compression profile describes how to compress a protocol:
 
TCP compression Profile
UDP compression Profile . . . =
 
For CT we could have:
 
TCP context profile
UDP context profile . . = .
 
- Kulwinder.
 
----- Original Message -----
From:=20 Hamid Syed
Sent: Tuesday, August 14, 2001 = 9:19=20 AM
Subject: RE: [seamoby] Update = on Issues=20 from IETF meeting

    Each CT profile would need to = specify=20 whether it is time-critical.

[Hamid] what is ct profile??? I do not know this=20 term.

------=_NextPart_000_0104_01C124F6.F7353A60-- From owner-seamoby@diameter.org Tue Aug 14 19:43:13 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17306 for ; Tue, 14 Aug 2001 19:43:12 -0400 (EDT) Received: (qmail 24299 invoked by alias); 14 Aug 2001 23:31:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24293 invoked by uid 200); 14 Aug 2001 23:31:27 -0000 Received: (qmail 24288 invoked from network); 14 Aug 2001 23:31:24 -0000 Received: from femail11.sdc1.sfba.home.com (24.0.95.107) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 23:31:24 -0000 Received: from cr851003a ([24.157.232.166]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010814234256.LWQW22307.femail11.sdc1.sfba.home.com@cr851003a>; Tue, 14 Aug 2001 16:42:56 -0700 Message-ID: <011501c1251a$ddfe6a20$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "George Tsirtsis" , "'Gary Kenward'" , Cc: "Alan O'Neill" , "Michaela Vanderveen" References: <8C92E23A3E87FB479988285F9E22BE4605474D@ftmail> Subject: Re: [seamoby] Comments on CT Reqs draft Date: Tue, 14 Aug 2001 19:43:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "George Tsirtsis" To: "'Gary Kenward'" ; Cc: "Alan O'Neill" ; "Michaela Vanderveen" Sent: Tuesday, August 14, 2001 6:47 PM Subject: RE: [seamoby] Comments on CT Reqs draft > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 14, 2001 8:09 PM > To: 'George Tsirtsis'; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > > > Comment 1 > > ----------- > > "4.9 All context information to be transferred MUST be > > available at the > > AR performing the transfer, prior to the initiation of the context > > transfer. > > > > The total context associated with the MN's traffic is composed of > > various types of feature context. To effect a rapid transfer, the > > context information has to be readily available when the AR begins > > the transfer. " > > > > This does not make sense as stated. What initiates the > > gathering of all the > > relevant context to be transferred? Or you just mean that all relevant > > context is in close proximity to the CT code (i.e.: same > > box)? By saying the > > context MUST be ready when CT is initiated we just defer the > > potential for > > delay, we do not eliminate it...i.e.: one may not initiate CT > > until it has > > gathered all context but the gathering process could take > > very long time. > > We suggest something like the following: > > "CT should not be slowed down by a process or feature > > inability to make > > appropriate context available to CT. CT SHOULD be able to > > transfer context > > as it becomes available. > Your suggestion is syntactically incorrect, and thus harder to understand. > The intent is as you surmised: to require that the context be at the AR, > and not elsewhere when the transfer is to be initiated. There are many > finer points that could be made, but with markedly diminishing importance. > > GT> Gary it does not make sense. My point here is that the requirement > relates to timing considerations which are covered by other requirements in > this spec...weather the context is in or out of the AR it is a mute point > and a protocol should not be held accountable for not doing it this way. > This requirement defines the scope of context transfer protocol. It states that the context carried by this protocol will be transferred by this protocol between Peer Access Routers _only_. Only the characteristics of transferring context between Peer Access Routers will be considered in this protocol. For example, we have ruled out the transfer of PDP context, and BTS context. 1. Also, the protocol will not introduce additional messaging to bring in context from somewhere else. 2. The time required by some implementations to bring in the context from somewhere else will not be included in the explicitly or implicitly in the protocol design. This requirement does not exclude a _particular_ implementation from storing the context anywhere it chooses. It only excludes that implementation decision from affecting the protocol design. At least, that is my recollection of the debate on the Design Team. - Kulwinder. From owner-seamoby@diameter.org Tue Aug 14 19:46:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17346 for ; Tue, 14 Aug 2001 19:46:43 -0400 (EDT) Received: (qmail 24857 invoked by alias); 14 Aug 2001 23:35:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24851 invoked by uid 200); 14 Aug 2001 23:35:19 -0000 Received: (qmail 24844 invoked from network); 14 Aug 2001 23:35:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 23:35:14 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA24861; Tue, 14 Aug 2001 16:46:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7ENkKA26846; Tue, 14 Aug 2001 16:46:20 -0700 X-mProtect: Tue, 14 Aug 2001 16:46:20 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdo26icE; Tue, 14 Aug 2001 16:46:18 PDT Message-ID: <3B79B84B.54EC164D@iprg.nokia.com> Date: Tue, 14 Aug 2001 16:46:19 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: Hamid Syed , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> <010701c12518$7ec3f9a0$a6e89d18@slnt1.on.wave.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Kulwinder, Kulwinder Atwal wrote: > Take a look at ROHC WG Profiles. Each compression profile describes > how to compress a protocol: TCP compression Profile > > > Rajeev: as far as I am aware, a TCP compression profile has not been > defined yet. > UDP compression Profile . . . For CT we could have: TCP context > profileUDP context profile . . . > Rajeev: In general, it could be profiles for HC/QoS/... Indeed, we > have made an attempt to define some of these for HC and QoS in our > draft contributions to the group. > > Regards, > > -Rajeev > > > > > > > > > - Kulwinder. > > ----- Original Message ----- > From: Hamid Syed > To: 'Pat Calhoun' > Cc: seamoby@cdma-2000.org > Sent: Tuesday, August 14, 2001 9:19 AM > Subject: RE: [seamoby] Update on Issues from IETF meeting > Each CT profile would need to specify whether it is > time-critical. > > [Hamid] what is ct profile??? I do not know this term. > From owner-seamoby@diameter.org Tue Aug 14 20:07:04 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17649 for ; Tue, 14 Aug 2001 20:07:02 -0400 (EDT) Received: (qmail 25615 invoked by alias); 14 Aug 2001 23:55:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25609 invoked by uid 200); 14 Aug 2001 23:55:32 -0000 Received: (qmail 25601 invoked from network); 14 Aug 2001 23:55:29 -0000 Received: from femail21.sdc1.sfba.home.com (24.0.95.146) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Aug 2001 23:55:29 -0000 Received: from cr851003a ([24.157.232.166]) by femail21.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010815000702.LCWG26086.femail21.sdc1.sfba.home.com@cr851003a>; Tue, 14 Aug 2001 17:07:02 -0700 Message-ID: <012b01c1251e$392d4800$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "Rajeev Koodli" Cc: "Hamid Syed" , "'Pat Calhoun'" , References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> <010701c12518$7ec3f9a0$a6e89d18@slnt1.on.wave.home.com> <3B79B84B.54EC164D@iprg.nokia.com> Subject: Re: [seamoby] Update on Issues from IETF meeting Date: Tue, 14 Aug 2001 20:07:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Rajeev Koodli" To: "Kulwinder Atwal" Cc: "Hamid Syed" ; "'Pat Calhoun'" ; Sent: Tuesday, August 14, 2001 7:46 PM Subject: Re: [seamoby] Update on Issues from IETF meeting > > Hello Kulwinder, > > Kulwinder Atwal wrote: > > > Take a look at ROHC WG Profiles. Each compression profile describes > > how to compress a protocol: TCP compression Profile > > > > > > Rajeev: as far as I am aware, a TCP compression profile has not been > > defined yet. No, but I hear it is being worked on. I saw some presentations at Minniapolis. > > UDP compression Profile . . . For CT we could have: TCP context > > profileUDP context profile . . . > > Rajeev: In general, it could be profiles for HC/QoS/... I don't see how one could have single profile for HC when each HC Profile has a different context. For example, RTP has a sequence number, while UDP does not. Unless the intent is to create "mini-profiles" on a protocol basis. There is no guarrantee that each MN will, at any one time, have all contexts active. How do you specify which HC profiles are active, or not per MN? - Kulwinder. Indeed, we > > have made an attempt to define some of these for HC and QoS in our > > draft contributions to the group. > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > > > > > > - Kulwinder. > > > > ----- Original Message ----- > > From: Hamid Syed > > To: 'Pat Calhoun' > > Cc: seamoby@cdma-2000.org > > Sent: Tuesday, August 14, 2001 9:19 AM > > Subject: RE: [seamoby] Update on Issues from IETF meeting > > Each CT profile would need to specify whether it is > > time-critical. > > > > [Hamid] what is ct profile??? I do not know this term. > > > > From owner-seamoby@diameter.org Tue Aug 14 21:17:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18971 for ; Tue, 14 Aug 2001 21:17:33 -0400 (EDT) Received: (qmail 26591 invoked by alias); 15 Aug 2001 01:06:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26585 invoked by uid 200); 15 Aug 2001 01:06:03 -0000 Received: (qmail 26578 invoked from network); 15 Aug 2001 01:05:59 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 01:05:59 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA00201; Tue, 14 Aug 2001 18:17:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7F1H6r28376; Tue, 14 Aug 2001 18:17:06 -0700 X-mProtect: Tue, 14 Aug 2001 18:17:06 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmdtlwf; Tue, 14 Aug 2001 18:17:04 PDT Message-ID: <3B79CD8C.163EE040@iprg.nokia.com> Date: Tue, 14 Aug 2001 18:17:00 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: Hamid Syed , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <9FBD322B7824D511B36900508BF93C9C1CD18D@zcard031.ca.nortel.com> <010701c12518$7ec3f9a0$a6e89d18@slnt1.on.wave.home.com> <3B79B84B.54EC164D@iprg.nokia.com> <012b01c1251e$392d4800$a6e89d18@slnt1.on.wave.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder Atwal wrote: > > > > > > Rajeev: as far as I am aware, a TCP compression profile has not been > > > defined yet. > > No, but I hear it is being worked on. I saw some presentations at > Minniapolis. > > > > UDP compression Profile . . . For CT we could have: TCP context > > > profileUDP context profile . . . > > > Rajeev: In general, it could be profiles for HC/QoS/... > > I don't see how one could have single profile for HC when each HC Profile > has a different context. > For example, RTP has a sequence number, while UDP does not. > Rajeev: I didn't imply that a single profile would suffice for HC (or QoS). You certainly need more than one. Would you be willing to review draft-koodli-seamoby-hc-relocate-01.txt ? :-) You will find discussion on this as well as a CT profile for IP/UDP/RTP HC. Regards, -Rajeev From owner-seamoby@diameter.org Wed Aug 15 02:03:19 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05229 for ; Wed, 15 Aug 2001 02:03:18 -0400 (EDT) Received: (qmail 28080 invoked by alias); 15 Aug 2001 05:51:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28074 invoked by uid 200); 15 Aug 2001 05:51:54 -0000 Received: (qmail 28069 invoked from network); 15 Aug 2001 05:51:51 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 05:51:51 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7F63q312682 for ; Wed, 15 Aug 2001 09:03:52 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 15 Aug 2001 09:03:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVTJ3Y>; Wed, 15 Aug 2001 09:03:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094174@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: G.Tsirtsis@flarion.com, seamoby@cdma-2000.org Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? Date: Wed, 15 Aug 2001 09:03:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi George, > Here is one more issue that we consider important and thus post > separately... > > The requirements draft says: > "5.1.2 The context transfer protocol design MUST define a standard > representation for conveying context information that will be > interpreted uniformly and perspicuously by different > implementations." > > Who defines the protocol specific info but also the way it is > forwarded between ARs? My proposal would be to devise a general packet structure for context transfer. An IANA registry could be setup to provide Context Transfer Payload IDs. These would be used in the CT Packet to identify the payload. The payload itself will most likely be a blob to the CTP (Context Transfer Payload) but of significance to the application who needs it. I think that defining the Payloads could be done in seperate drafts, commented on in relevant working groups. Perhaps some consideration on timing, security, etc. should be addressed in the payload drafts. John From owner-seamoby@diameter.org Wed Aug 15 04:01:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10710 for ; Wed, 15 Aug 2001 04:01:05 -0400 (EDT) Received: (qmail 28743 invoked by alias); 15 Aug 2001 07:49:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28737 invoked by uid 200); 15 Aug 2001 07:49:07 -0000 Received: (qmail 28732 invoked from network); 15 Aug 2001 07:49:06 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 07:49:06 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 04:00:09 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605474F@ftmail> From: George Tsirtsis To: "'Kulwinder Atwal'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 04:00:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Kulwinder Atwal [mailto:katwal2200@home.com] Sent: Wednesday, August 15, 2001 12:43 AM To: George Tsirtsis; 'Gary Kenward'; seamoby@cdma-2000.org Cc: Alan O'Neill; Michaela Vanderveen Subject: Re: [seamoby] Comments on CT Reqs draft ----- Original Message ----- From: "George Tsirtsis" To: "'Gary Kenward'" ; Cc: "Alan O'Neill" ; "Michaela Vanderveen" Sent: Tuesday, August 14, 2001 6:47 PM Subject: RE: [seamoby] Comments on CT Reqs draft > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 14, 2001 8:09 PM > To: 'George Tsirtsis'; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > > > Comment 1 > > ----------- > > "4.9 All context information to be transferred MUST be > > available at the > > AR performing the transfer, prior to the initiation of the context > > transfer. > > > > The total context associated with the MN's traffic is composed of > > various types of feature context. To effect a rapid transfer, the > > context information has to be readily available when the AR begins > > the transfer. " > > > > This does not make sense as stated. What initiates the > > gathering of all the > > relevant context to be transferred? Or you just mean that all relevant > > context is in close proximity to the CT code (i.e.: same > > box)? By saying the > > context MUST be ready when CT is initiated we just defer the > > potential for > > delay, we do not eliminate it...i.e.: one may not initiate CT > > until it has > > gathered all context but the gathering process could take > > very long time. > > We suggest something like the following: > > "CT should not be slowed down by a process or feature > > inability to make > > appropriate context available to CT. CT SHOULD be able to > > transfer context > > as it becomes available. > Your suggestion is syntactically incorrect, and thus harder to understand. > The intent is as you surmised: to require that the context be at the AR, > and not elsewhere when the transfer is to be initiated. There are many > finer points that could be made, but with markedly diminishing importance. > > GT> Gary it does not make sense. My point here is that the requirement > relates to timing considerations which are covered by other requirements in > this spec...weather the context is in or out of the AR it is a mute point > and a protocol should not be held accountable for not doing it this way. > This requirement defines the scope of context transfer protocol. It states that the context carried by this protocol will be transferred by this protocol between Peer Access Routers _only_. Only the characteristics of transferring context between Peer Access Routers will be considered in this protocol. GT> That is fine. For example, we have ruled out the transfer of PDP context, and BTS context. 1. Also, the protocol will not introduce additional messaging to bring in context from somewhere else. 2. The time required by some implementations to bring in the context from somewhere else will not be included in the explicitly or implicitly in the protocol design. This requirement does not exclude a _particular_ implementation from storing the context anywhere it chooses. GT> Or an implementation could go and pick it up from anywhere it exists at the time it is needed and as long as that does not affect the CT protocol itself then it should not matter, yes? My impression is that the requirement as stated does not allow for that option, hence the comment. It only excludes that implementation decision from affecting the protocol design. At least, that is my recollection of the debate on the Design Team. GT> Thanks George From owner-seamoby@diameter.org Wed Aug 15 04:07:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10762 for ; Wed, 15 Aug 2001 04:07:48 -0400 (EDT) Received: (qmail 29260 invoked by alias); 15 Aug 2001 07:56:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29254 invoked by uid 200); 15 Aug 2001 07:56:32 -0000 Received: (qmail 29249 invoked from network); 15 Aug 2001 07:56:31 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 07:56:31 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 04:07:40 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054750@ftmail> From: George Tsirtsis To: "'john.loughney@nokia.com'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? Date: Wed, 15 Aug 2001 04:07:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk John, Something along these lines sounds good to me too. I just want to make sure we are all on the same page before people submit protocol proposals. Thanks George -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, August 15, 2001 7:03 AM To: G.Tsirtsis@flarion.com; seamoby@cdma-2000.org Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? Hi George, > Here is one more issue that we consider important and thus post > separately... > > The requirements draft says: > "5.1.2 The context transfer protocol design MUST define a standard > representation for conveying context information that will be > interpreted uniformly and perspicuously by different > implementations." > > Who defines the protocol specific info but also the way it is > forwarded between ARs? My proposal would be to devise a general packet structure for context transfer. An IANA registry could be setup to provide Context Transfer Payload IDs. These would be used in the CT Packet to identify the payload. The payload itself will most likely be a blob to the CTP (Context Transfer Payload) but of significance to the application who needs it. I think that defining the Payloads could be done in seperate drafts, commented on in relevant working groups. Perhaps some consideration on timing, security, etc. should be addressed in the payload drafts. John From owner-seamoby@diameter.org Wed Aug 15 06:29:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11889 for ; Wed, 15 Aug 2001 06:29:41 -0400 (EDT) Received: (qmail 29944 invoked by alias); 15 Aug 2001 10:18:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29938 invoked by uid 200); 15 Aug 2001 10:18:16 -0000 Received: (qmail 29933 invoked from network); 15 Aug 2001 10:18:14 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 10:18:14 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7FAUG315562 for ; Wed, 15 Aug 2001 13:30:16 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 15 Aug 2001 13:29:50 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVTXLL>; Wed, 15 Aug 2001 13:29:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094183@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: G.Tsirtsis@flarion.com, seamoby@cdma-2000.org Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? Date: Wed, 15 Aug 2001 13:29:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi George, > Something along these lines sounds good to me too. I just > want to make sure we are all on the same page before people > submit protocol proposals. The best way forward on this would be to write a draft ... Perhaps we should. John From owner-seamoby@diameter.org Wed Aug 15 09:29:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19458 for ; Wed, 15 Aug 2001 09:29:02 -0400 (EDT) Received: (qmail 31548 invoked by alias); 15 Aug 2001 13:16:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31542 invoked by uid 200); 15 Aug 2001 13:16:37 -0000 Received: (qmail 31534 invoked from network); 15 Aug 2001 13:16:32 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 13:16:32 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FDQxp07449 for ; Wed, 15 Aug 2001 09:27:00 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 15 Aug 2001 09:27:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 09:27:10 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EFA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Kulwinder Atwal'" , "Hamid Syed" , "'Pat Calhoun'" Cc: seamoby Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Wed, 15 Aug 2001 09:27:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1258D.FB096D40" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1258D.FB096D40 Content-Type: text/plain; charset="iso-8859-1" Hamid's point, which is valid, is that there has been no requirement identified, no framework defined, nor even a wg discussion on "ct profiles". While they may have a purpose, I haven't heard of one yet. I believe that Pat used the term accidentally. Unless someone can articulate a requirement for using context profiles, perhaps it is best that we defer this discussion until a need does actually appear. Gary -----Original Message----- From: Kulwinder Atwal [mailto:katwal2200@home.com] Sent: Tuesday, August 14, 2001 7:26 PM To: Syed, Hamid [WDLN2:AN22:EXCH]; 'Pat Calhoun' Cc: seamoby Subject: Re: [seamoby] Update on Issues from IETF meeting Take a look at ROHC WG Profiles. Each compression profile describes how to compress a protocol: TCP compression Profile UDP compression Profile . . . For CT we could have: TCP context profile UDP context profile . . . - Kulwinder. ----- Original Message ----- From: Hamid Syed To: 'Pat Calhoun' Cc: seamoby@cdma-2000.org Sent: Tuesday, August 14, 2001 9:19 AM Subject: RE: [seamoby] Update on Issues from IETF meeting Each CT profile would need to specify whether it is time-critical. [Hamid] what is ct profile??? I do not know this term. ------_=_NextPart_001_01C1258D.FB096D40 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting
Hamid's point, which is valid, is that there has been no requirement identified,
no framework defined, nor even a wg discussion on "ct profiles". While they
may have a purpose, I haven't heard of one yet.
 
I believe that Pat used the term accidentally. Unless someone can articulate a
requirement for using context profiles, perhaps it is best that we defer this
discussion until a need does actually appear.
 
Gary
-----Original Message-----
From: Kulwinder Atwal [mailto:katwal2200@home.com]
Sent: Tuesday, August 14, 2001 7:26 PM
To: Syed, Hamid [WDLN2:AN22:EXCH]; 'Pat Calhoun'
Cc: seamoby
Subject: Re: [seamoby] Update on Issues from IETF meeting

Take a look at ROHC WG Profiles.  Each compression profile describes how to compress a protocol:
 
TCP compression Profile
UDP compression Profile . . .
 
For CT we could have:
 
TCP context profile
UDP context profile . . .
 
- Kulwinder.
 
----- Original Message -----
From: Hamid Syed
Sent: Tuesday, August 14, 2001 9:19 AM
Subject: RE: [seamoby] Update on Issues from IETF meeting

    Each CT profile would need to specify whether it is time-critical.

[Hamid] what is ct profile??? I do not know this term.

------_=_NextPart_001_01C1258D.FB096D40-- From owner-seamoby@diameter.org Wed Aug 15 10:03:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21246 for ; Wed, 15 Aug 2001 10:03:28 -0400 (EDT) Received: (qmail 32079 invoked by alias); 15 Aug 2001 13:52:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32073 invoked by uid 200); 15 Aug 2001 13:52:16 -0000 Received: (qmail 32068 invoked from network); 15 Aug 2001 13:52:15 -0000 Received: from netmail.alcatel.com (128.251.168.50) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 13:52:15 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA25937; Wed, 15 Aug 2001 09:03:53 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f7FE3r911484; Wed, 15 Aug 2001 09:03:53 -0500 (CDT) Message-ID: <3B7A7248.AE8DA56F@usa.alcatel.com> Date: Wed, 15 Aug 2001 08:59:52 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: George Tsirtsis , seamoby@cdma-2000.org Subject: Re: [seamoby] Comments on CT Reqs draft References: <8C92E23A3E87FB479988285F9E22BE4605474D@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi George, George Tsirtsis wrote: > GT> Sure and that is not my intent. Throughout your comments I see that you > are resisting almost all change and I assume this is because of fear of > opening another endless discussion, which is also not my intent. My only > intent is to have a small number of very clear requirements that I can work > with and develop a protocol that I can also implement. Do you plan to make your implementation of CT public? Same question for FMIPv6? This would help the community a lot. Regards, -- Behcet From owner-seamoby@diameter.org Wed Aug 15 10:10:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21573 for ; Wed, 15 Aug 2001 10:10:53 -0400 (EDT) Received: (qmail 32619 invoked by alias); 15 Aug 2001 13:59:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32613 invoked by uid 200); 15 Aug 2001 13:59:40 -0000 Received: (qmail 32602 invoked by uid 500); 15 Aug 2001 13:59:36 -0000 Date: Wed, 15 Aug 2001 06:59:36 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Kulwinder Atwal'" , Hamid Syed , "'Pat Calhoun'" , seamoby Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010815065936.A32584@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Kulwinder Atwal' , Hamid Syed , 'Pat Calhoun' , seamoby References: <9FBD322B7824D511B36900508BF93C9C9F5EFA@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5EFA@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Aug 15, 2001 at 09:27:07AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Aug 15, 2001 at 09:27:07AM -0400, Gary Kenward wrote: > Hamid's point, which is valid, is that there has been no requirement > identified, > no framework defined, nor even a wg discussion on "ct profiles". While they > may have a purpose, I haven't heard of one yet. > > I believe that Pat used the term accidentally. Unless someone can articulate > a > requirement for using context profiles, perhaps it is best that we defer > this > discussion until a need does actually appear. No, I didn't. I *simply* tried to articulate a comment that was made in regards to the consensus, so that it wasn't lost. It was NOT WG consensus, and I hope I didn't make it sound like it was. Perhaps we can just kill this thread, and concentrate on the issues at hand. PatC From owner-seamoby@diameter.org Wed Aug 15 10:12:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21622 for ; Wed, 15 Aug 2001 10:12:40 -0400 (EDT) Received: (qmail 599 invoked by alias); 15 Aug 2001 14:01:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 592 invoked by uid 200); 15 Aug 2001 14:01:12 -0000 Received: (qmail 570 invoked from network); 15 Aug 2001 14:01:09 -0000 Received: from netmail2.alcatel.com (128.251.168.51) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 14:01:09 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA18645; Wed, 15 Aug 2001 09:12:48 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f7FECm913159; Wed, 15 Aug 2001 09:12:48 -0500 (CDT) Message-ID: <3B7A745E.8CF39237@usa.alcatel.com> Date: Wed, 15 Aug 2001 09:08:47 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: G.Tsirtsis@flarion.com, seamoby@cdma-2000.org Subject: Re: [seamoby] Who defines protocol specific context and how is transported? References: <0C1353ABB1DEB74DB067ADFF749C4EEF094183@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit John, George, There has been too much bashing of the requirements document of CT, I think this is unfortunate. In London I was talking to the colleagues who submitted drafts to solve mipv6 security problem, they stated (at least informally to me) that they (at least one of them to be precise) have not read the security requirements document at all! I agree with John, let's go to the solutions phase. In fact there is already one draft-koodli-seamoby-ctv6-01.txt. john.loughney@nokia.com wrote: > Hi George, > > > Something along these lines sounds good to me too. I just > > want to make sure we are all on the same page before people > > submit protocol proposals. > > The best way forward on this would be to write a draft ... > > Perhaps we should. > > John Kind regards, -- Behcet From owner-seamoby@diameter.org Wed Aug 15 10:20:15 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21864 for ; Wed, 15 Aug 2001 10:20:14 -0400 (EDT) Received: (qmail 1215 invoked by alias); 15 Aug 2001 14:08:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1209 invoked by uid 200); 15 Aug 2001 14:08:41 -0000 Received: (qmail 1203 invoked from network); 15 Aug 2001 14:08:39 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 14:08:39 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA07614; Wed, 15 Aug 2001 07:19:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7FEJmO12126; Wed, 15 Aug 2001 07:19:48 -0700 X-mProtect: Wed, 15 Aug 2001 07:19:48 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdYgXzea; Wed, 15 Aug 2001 07:19:46 PDT Message-ID: <3B7A84F3.639E69CA@iprg.nokia.com> Date: Wed, 15 Aug 2001 07:19:31 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > Issue 4: This issue had to do with new terminology for proactive and reactive > Issue 7: Remove the terminology proactive and reactive > > After some intense discussion on the issue, it was decided to remove > proactive and reactive, and instead adopt a very simple requirement > similar to: > > "Context Transfer may occur prior to, during or after a handover." > > Nearly complete consensus on this approach. It is very simple indeed, but I am not sure I understand WHERE is the requirement. If I don't require anything, my context transfer actually MUST happen prior to, during or after the handover. I can't see when else. By requiring that 'CT MAY occur at any time', are you planning for disruptions in the time continuum? Serioulsy, removing the terminology is not the same as removing the concept. It looks to me like the baby was thrown away with the bath water. You mention some 'intense discussion', could you elaborate to enlighten those who were not present, thanks, Cedric. > > > Issue 5: This issue was a request to support multi-phasic CTs > > The text proposed at the meeting was: > "4.9 Context information MAY be transferred in phases, allowing for > time critical state to be sent first, and non-time critical state > to be sent later. > > The cost of building and sending smaller packets is less, as well > as parsing and processing by the receiver. " > > The consensus at the meeting was to adopt the text, but a comment was > made that how one defines time critical is an issue since anything > could be send in the initial CT message. > > Each CT profile would need to specify whether it is time-critical. > > If someone has any comments on the above, I'd like to hear them now. As you > know, decisions aren't made at meetings, and the list is still the preferred > medium to provide comments. If I hear no objections by 8/21, these changes > will be included in the next revision of the draft will be send to WG last call. > > Thanks, > > PatC From owner-seamoby@diameter.org Wed Aug 15 10:26:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22054 for ; Wed, 15 Aug 2001 10:26:09 -0400 (EDT) Received: (qmail 1762 invoked by alias); 15 Aug 2001 14:14:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1756 invoked by uid 200); 15 Aug 2001 14:14:04 -0000 Received: (qmail 1747 invoked by uid 500); 15 Aug 2001 14:14:01 -0000 Date: Wed, 15 Aug 2001 07:14:01 -0700 From: Pat Calhoun To: Cedric Westphal Cc: Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010815071401.A1591@charizard.diameter.org> Mail-Followup-To: Cedric Westphal , Pat Calhoun , seamoby@cdma-2000.org References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7A84F3.639E69CA@iprg.nokia.com>; from cedric@IPRG.nokia.com on Wed, Aug 15, 2001 at 07:19:31AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > Serioulsy, removing the terminology is not the same as removing the concept. As far as I can tell, proactive vs. reactive was essentially stating when CT would occur. This, as you state, is not a requirement, and therefore adding something as simple as what proposed seems to do the same thing with the least amount of friction. > It looks to me like the baby was thrown away with the bath water. You mention some > 'intense discussion', could you elaborate to enlighten those who were not present, Here are the rough minutes for this particular discussion: Issues 4 & 7 ------------- 4 - Proactive v.s. Reactive. 7 - Remove pro and re from doc. Theo: Why remove? Two modes are too limited, may be more than two modes, putting in reqs will limit to two modes. Theo: two classes of sets of modes, other distincitions necessary. Charlie: Don't know yet, revisit issue later. Move on better understood reqs. Table it. John Longherty: Talk about protocol modes, examples rather than modes. Useful to discuss in terms of examples of how a protocol may work, but not normative. Allison: Design space to consider, potental to classify. Don't put in as requirement. Majiv: Misunderstanding. Timing req. originally there, to define timing req need to dig deeper, need to define in relation to handover, not supposed to be modes. Solution covers both, but solutions don't have to cover modes. Remove if expected to be a mode. Gary: Mode is the problem, not proactive and reactive. Mode is the issue, capability is more deescriptive. Protocol operate on two kinds of capabilities. Not bit in header, happens in different time relative to handoff. Hemant: Do we need to define temporal characteristics? Depends on when trigger was sent. Theo: Shift from mode to timing. Timing in which you act. CT tends to revolve around time restriction. Dismiss timing, then revisit. Rajeev: Mode -> capabilities won't solve. MN attaches to new router, is context there or not? Pro - there, Re - not there. Too much confusion, put in appendix. three options 1) Use word capabilities 2) Remove 3) Move to appendix. Need to consider revise or keep current text. Rajeev: Proposed text. If context there when MN attaches to new router, pro. If there after, re. Majeev: Timing requirements in req. doc? Will it delay handover? May want to define pro and re, if not, triggers may be needed. Confusing based on starting event and ending event. Rajeev: Presentation, is a distinction. Majeev: Does there need to be a timing requirement? Henrik: Cedric's text makes me least happy. Way it says it is difficult, don't know discussion says that you implement two modes. Other than that, OK. Gary: Timing requirement is in current doc, section 5, req for pro and re, current reqs are wrong, specifies a too tight timing req, needs to be fixed. No happy with delegating to appendix, important part of CT and for seamlessness. Pat: Advisory. Gary: No, it must be a requrimenet, proactive, there when packets arrive at new AR. Lose and be back in same debate. ????: QoS guy, how would a router react if first packet had a code point and the QoS was not there? Would drop. So there is a timing req. Pat: Some environments where you don't have handoff notification, in others, can. ???: Some networks have it. Rajeev: Always try to get context transfereed prior to handover. Not removing possibility of moving context. When you invoke CT. Henrik: Important to have capability to do flexibly, as early and late. Shouldn't be an appendix. Gopal: Can push or pull context, pro or re depends on timing. John Logherty: Local API issue. Gary: Makes a difference. Multiphasic, only time is just at time that handover is happening. Later, state isn't there for packet to be forwarded. Other phases, might want to transfer. Static, won't change. Value in concepts, landscape for people to work on solutions. Rajeev: Proactive mode, previous router initiates. Reactive, new router initiates. Both routers should be able to initiate. Proactive in either direction. Is context on new router? Pat: options 1) leave as is. 2) use word capabilities. 3) remove text from doc -5 4) remove text to appendix -5 5) state that CT before, during, or after handover. - many. 5) wins. Thanks, PatC From owner-seamoby@diameter.org Wed Aug 15 11:12:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23281 for ; Wed, 15 Aug 2001 11:12:33 -0400 (EDT) Received: (qmail 2536 invoked by alias); 15 Aug 2001 15:01:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2530 invoked by uid 200); 15 Aug 2001 15:01:05 -0000 Received: (qmail 2525 invoked from network); 15 Aug 2001 15:01:03 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 15:01:03 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26545; Wed, 15 Aug 2001 08:12:38 -0700 (PDT) Received: from awe171-106 (awe195-8.AWE.Sun.COM [192.29.195.8]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA17280; Wed, 15 Aug 2001 08:12:33 -0700 (PDT) Message-Id: <200108151512.IAA17280@heliopolis.eng.sun.com> Date: Wed, 15 Aug 2001 08:03:23 -0700 (PDT) From: kempf Reply-To: kempf Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? To: G.Tsirtsis@flarion.com, seamoby@cdma-2000.org, john.loughney@nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NI0xp/BTc1t+GUWJQ6J3SQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk John, Not so clear that this would be the right approach. The different context features might require different containers, and different transports (reliable v.s. unreliable). I do agree that it is a good goal, though. Would certainly simplify matters. jak >Delivered-To: seamoby-list@charizard.diameter.org >From: john.loughney@nokia.com >To: G.Tsirtsis@flarion.com, seamoby@cdma-2000.org >Subject: RE: [seamoby] Who defines protocol specific context and how is tr ansported? >Date: Wed, 15 Aug 2001 09:03:20 +0300 > >Hi George, > >> Here is one more issue that we consider important and thus post >> separately... >> >> The requirements draft says: >> "5.1.2 The context transfer protocol design MUST define a standard >> representation for conveying context information that will be >> interpreted uniformly and perspicuously by different >> implementations." >> >> Who defines the protocol specific info but also the way it is >> forwarded between ARs? > >My proposal would be to devise a general packet structure for context >transfer. An IANA registry could be setup to provide Context Transfer >Payload IDs. These would be used in the CT Packet to identify the >payload. The payload itself will most likely be a blob to the >CTP (Context Transfer Payload) but of significance to the application >who needs it. > >I think that defining the Payloads could be done in seperate drafts, >commented on in relevant working groups. Perhaps some consideration >on timing, security, etc. should be addressed in the payload drafts. > >John From owner-seamoby@diameter.org Wed Aug 15 11:32:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23798 for ; Wed, 15 Aug 2001 11:31:51 -0400 (EDT) Received: (qmail 3070 invoked by alias); 15 Aug 2001 15:09:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3064 invoked by uid 200); 15 Aug 2001 15:09:02 -0000 Received: (qmail 3059 invoked from network); 15 Aug 2001 15:08:37 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 15:08:37 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FFJGp25674 for ; Wed, 15 Aug 2001 11:19:16 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 15 Aug 2001 11:19:25 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 11:19:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EFC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 11:19:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1259D.ABA9F520" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1259D.ABA9F520 Content-Type: text/plain; charset="iso-8859-1" George: > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Tuesday, August 14, 2001 6:47 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 14, 2001 8:09 PM > To: 'George Tsirtsis'; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > George: > Most of these comments seem to be editorial. As you seem > to have figured out the intended meaning in most cases, I suggest > that they do make sense to the casual reader. The intent here cannot > be to define bullet proof requirements (such a document could easily > consume 100s of pages). > > GT> Sure and that is not my intent. Throughout your comments > I see that you > are resisting almost all change and I assume this is because > of fear of > opening another endless discussion, which is also not my > intent. My only > intent is to have a small number of very clear requirements > that I can work > with and develop a protocol that I can also implement. I will not resist changes that improve the possibility that we will create a good ct solution. But, as I said, the majority of changes seem to be aimed at clarifying text when the text was generally clear. Past experience has shown that word smithing the requirements are not simple changes. > > More comments below: > Gary > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Tuesday, August 14, 2001 10:19 AM > > To: seamoby@cdma-2000.org > > Cc: Alan O'Neill; Michaela Vanderveen > > Subject: [seamoby] Comments on CT Reqs draft > > > > > > All, > > > > Here are some comments on the current CT requirements draft. > > We quote text > > from the draft to make this easier to read and try to suggest > > alternative > > text when possible. > > > > > > > > Comment 1 > > ----------- > > "4.9 All context information to be transferred MUST be > > available at the > > AR performing the transfer, prior to the initiation of > the context > > transfer. > > > > The total context associated with the MN's traffic is > composed of > > various types of feature context. To effect a rapid > transfer, the > > context information has to be readily available when the > AR begins > > the transfer. " > > > > This does not make sense as stated. What initiates the > > gathering of all the > > relevant context to be transferred? Or you just mean that > all relevant > > context is in close proximity to the CT code (i.e.: same > > box)? By saying the > > context MUST be ready when CT is initiated we just defer the > > potential for > > delay, we do not eliminate it...i.e.: one may not initiate CT > > until it has > > gathered all context but the gathering process could take > > very long time. > > We suggest something like the following: > > "CT should not be slowed down by a process or feature > > inability to make > > appropriate context available to CT. CT SHOULD be able to > > transfer context > > as it becomes available. > Your suggestion is syntactically incorrect, and thus harder > to understand. > The intent is as you surmised: to require that the context be > at the AR, > and not elsewhere when the transfer is to be initiated. There > are many > finer points that could be made, but with markedly > diminishing importance. > > GT> Gary it does not make sense. My point here is that the requirement > relates to timing considerations which are covered by other > requirements in > this spec...weather the context is in or out of the AR it is > a mute point > and a protocol should not be held accountable for not doing > it this way. Actually, Kulwinder answered this better then I did. The issue is not timing, it is scope and ordering. > > > > > Comment 2 > > ---------- > > "4.10 The context information provided for transfer MUST be > reliable. > > > > The context to be transferred must not only be readily > > available for > > transfer, but the sending AR must ensure that the > > information is sound. > > > > The context transfer solution may provide mechanisms to > > support reliable > > transfer of context, but the effectiveness of context > transfer in > > enhancing > > handover between ARs would very likely be compromised by > > attempts to > > transfer malformed context." > > > > This again makes no sense to the casual reader! How does CT > > "evaluate" the > > soundness of a protocol specific context. Consider that the > > effectiveness of > > context transfer in enhancing handover between ARs would also > > very likely be > > compromised by attempts to ensure that the information is > > sound. Please > The requirement says nothing about CT evaluating the soundness > of the context. The requirement actual says the opposite: that > the context must itself be reliable, for ct will do nothing to > compensate for unreliable context. > > > GT> I totaly agree with what you state above (which I wish it > was the real > text) but the spec says and I repeat "... The context to be > transferred must > not only be readily available for transfer, but the sending > AR must ensure > that the information is sound." it then also says..."...the > effectiveness of > context transfer in enhancing handover between ARs would > very likely be > compromised by attempts to transfer malformed context". If > the requirement > is only about reliability of transfer then that is what it > should state. None of the quotes you provide refer to "CT evaluating the soundness of context". The way this requirement is written is that it requires on the implementer of an AR to ensure that the context provided to CT is reliable. The only thing "wrong" with this, if there is anything wrong, is that it appears to state the obvious. However, it also states clearly that ct will not fix corrupted context. I just don't see how you come to your conclusion. > > > > > remove this totally unreasonable requirement or explain what > > you mean. If > It is not unreasonable. It is an absolute requirement, and there > was general agreement (please refer to the archives for the complete > discussion). > > GT> No, the requirement is that the CT protocol MUST support reliable > transfer which is fine...it is not about the AR checking the > soundness of > the context...the text is confusing. NO. This is not a requirement for reliable transfer. That particular issue was a subject of great debate and has been deferred - c.f. section 5.2. The text says nothing about reliable transfer. It simply says that if the context is corrupted to begin with, it will be delivered to the receiving AR corrupted. > > > > people feel strongly about this it should as a minimum be > > watered down like > > this: > > "The sender SHOULD make all reasonable efforts to ensure the > > data is sound > > since transfer of invalid data may be more damaging than > > transfer of no data > > at all" > > > > > Comment 3 > > ---------- > > "5.1.1 The context transfer protocol MUST be capable of > > transferring all > > of the different types of feature context necessary to > > support the > > MN's traffic at a receiving AR." > > > > I would like to propose to clarify this further: > > "CT MUST be generic and feature agnostic, i.e.: CT MUST allow > > new features > > to be defined and transported without having to change CT itself." > This is an entirely different requirement. Your version is trying to > "future proof" ct. 5.1.1 is concerned with the current > features available > at an AR. Future proof statements such as the one above are, IMHO, > motherhood, > as everything has to agree, and yet there is no way of > ensuring that a > solution is future proof. > > > GT> I do not agree. A number of protocols satisfy the above > requirement..e.g.: diameter. But if you thing that my suggestion is > describing a different requirement then it is clear that I did not > understand 5.1.1. Please illuminate. The intent of 5.1.1 is that the ct solution should work for all the *known* features required to support a forwarding service. As it is, this is an ambitious statement, for we, as a wg, may or may not know all of these known features. What we do believe are feature contexts to transfer are HC, AAA, encryption, QoS, and perhaps policy. Our knowledge of the ct issues and benefits for these features is very limited, and will remain so until we start attempting to define ct solutions.\ That's all 5.1.1 states. It does not state that the ct solution should handle all future feature contexts. Like I stated, IMHO, you can include this requirement, but it's kind of like saying "I will invest only in stocks that increase in value" - a good principle, but very hard to act upon. > > > > > > > > > Comment 4 > > ----------- > > "5.4.1 Proactive context transfer MUST be completed before > > the handover > > of the Mobile Node's traffic to the receiving AR completes." > > > > Does this make sense after the removal of the > > proactive/reactive concept > > from this doc. Even if it does make sense there is no way to > > ensure such a > > thing. You can only try and have mechanisms so you can > > recover when things > > go wrong. E.g.: there might not be any connectivity between > > old and new AR. > > This is a SHOULD not a MUST. > I agree. But if you read the minutes of the last IETF meeting, this > statement will be changed - probably deleted, as "proactive" > and "reactive" > are being removed from the draft. > > GT> That is what I asked first ... and yes I was in the > meeting which only > talked about 4.4 and 4.5, hence the question...glad you agree. > > > > > > Comment 5 > > ---------- > > "5.4.3 A context transfer MUST complete with a minimum number > > of protocol > > exchanges between the source AR and the rest of the ARs. " > > > > This is a SHOULD..protocol engineering is a trade-off and > > this is one of the > > basic variables (signaling level). The requirements document > > may decair its > > preference to low signaling levels but must not mandate > > it...At the end of > > the day a slightly slower more concrete CT may be better > than a faster > > flakey CT! > In truth, this is a non-requirement. "minimum" is one of > those ambiguous > words, that cannot be measured without a reference with the > requirement > does not specify. > In essence, given that the reliability requirements for ct > are met (which > are tbd), then all this requirement says is that there > shouldn't be any > "excess" exchanges. Again, there is no measure to determine > what exchanges > might be "excess". > Probably the only real application of this requirement is if > we end up > comparing two protocols that are identical in every way but > one has more > exchanges. Might happen. > At this point, this requirement is unlikely to be deleted, and it has > no impact as it is stated. > > GT> Why not? You say that this is not really a > requirement...yet it is a > MUST in the requirements document. *shrug* I'm just the editor. > > > > > > > > Comment 6 > > ----------- > > "5.4.4 The context transfer protocol design MUST minimize the > > amount of > > processing required at the sending and receiving Access > > Routers." > > > > As above..this is a SHOULD not a MUST...Minimization implies > > the existence > > of some optimization function with constraints. Who sets the > > constraints? If > > they are set by each implementor according to their fancy, > > then all these > > protocols can claim compliance with the above. > The language could be improved, but the requirement is accurate: > the protocol MUST not introduce excess processing. You are right, > the "minimization" requirement has no basis for determining > compliance. > > GT> So, again what is the point of mute requirements? get > them out of the > way and we will have a much better document. Again, *shrug*. The phrase "mostly harmless" comes to mind. We have had extensive discussions in the working group over these requirements, and a consensus was determined. We have to live with this consensus, otherwise no progress will be made. If there was a real problem (e.g. logical fallacy or misconception), then it would be worth opening an issue. But I don't believe it's worth revisiting the debate over whether the use of words like "fast", "smooth", "faster", "minimal", etc. are useful in requirements. As you know, if this was a rigorous requirements document (e.g. a DoD requirements document), such words would not be permitted. > > > > > > > > Comment 7 > > ----------- > > "5.4.5 The Context Transfer protocol MUST meet the timing > constraints > > required by all the feature contexts." > > > > Again, CT SHOULD attempt to comply with timing constrains and > > have ways to > > recover if it does not...nothing is for certain here...Maybe > > change with > > something like this: > > "The Context Transfer protocol SHOULD strive to comply with > > the the timing > > constraints imposed by the different feature contexts. The CT > > protocol MUST > > provide ways to recover and allow the handoff to complete > > normally when the > > timing constrains are not met." > Sorry, but if a protocol meets the requirements, whether through > a clean design or through "recovery", then it meets this requirement. > "strive" is an anthropomorphic term that doesn't belong in a > requirement. > Also, you have specified two requirements in place of one. > The requirement remains a MUST. The fact is that everyone one of the > requirements is likely to fail under some conditions, and the > protocol > is going to have to have some reasonable recovery mechanisms. > It would > take years for us to gain consensus on all the necessary recovery > mechanisms. > > GT> The point is that on one hand there is no way for any > protocol to ensure > that timing requirements are met while on the other hand you miss the > obvious requirement of failsafe. BTW, I did not request > consensus on the > recovery mechanisms just the requirement for the protocol not > to fail the > handoff when it self fails. Then again I would be happy if > you changed that > MUST to SHOULD since no one can satisfy the MUST. These are requirements. Even in rigorous requirements excercises it is fully acceptable to outline the desired goals ("MUST"), while realizing there are exceptional conditions where these "MUST"s will be violated. Again, it's an issue that I believe is a result of the lack of rigor in this particular requirements specification process (and, no, I'm not suggesting more rigor). Personally, I'm happy with MUST. > > > > > > > > Comment 8 > > ----------- > > "5.6.2 The context transfer protocol MUST include methods for > > exchanging > > information with the handover process. > > > > Both context transfer and handover require information on the > > AR candidates for handover. The context transfer entities > > may, in the > > process of establishing and supporting context transfer, > acquire > > information that would be useful to the handover process in > > determining the new forwarding path: for example, the > outcome of an > > admission control decision at a receiving AR." > > > > > > The text here is very nebulus, so as a minimum a concrete > > example should be > > given. "For example, if during the CT process one newAR > > appears to be able > > to support the MN's QoS requirements better than the other, > > then CT SHOULD > > be able to make this information known the handoff process." > Why? > > GT> Because I give you a valid example that you actually > agree with instead > the mumble jumble of the current one but never mind...this is > not important > so forget about it. > > Here is a good example where the meaning of the requirement was > in fact clear to you. Are you pre-supposing that other > readers have less > of a grasp of English, or a lower IQ? > > GT> I am not even going to respond to this...you must be very > tired since I > do not think you really want to be offensive. I just regret that I am > causing you pain... > > As the prime audience for this > document is actually the people who participated in the writing, it > would seem reasonable that they would derive the same meaning > as you did. > > GT> Gary, a general point. I can understand if I make a point and you > disagree...in which case we have to discuss further. I do > not, however, > understand when you agree with me and yet say "....oh no, we > can not change > the doc now...too late", unless of course the rest of the > group feels the > same way. Ok. The process is that you submit an issue to the wg list for each change that you would have identified. Then we discuss each issue for one or two months, and Pat tries to gauge a consensus. If there is no clear consensus on the list, then Pat will ask for an email humm. My views on your issues have nothing to do with this process. You are fully welcome to submit the issues. My opinion, however, is that, yes, we certainly have not created a perfect document, and many of the requirements could be worded better, could have better explanatory text, and, there are definitely many requirements missing. But, in my view, it is not worth the pain and effort to continue polishing up descriptions that have been actively reviewed and discussed for 3 months now. This is just my view, and no I'm not tired, I just want to move on to the protocol design sometime this millenium. > > - Comments 4, 5, 6 we agree on and unless there are others > that disagree we > should change > - Comment 2 I think we agree on but not sure yet > - Comment 1, 3, 7 we do not seam to agree on > - Comment 8 is not important We (you and I) don't form a consensus. Unless I'm mistaken, the process outlined above is still in place. If you feel strongly about these 9 issues, then you should submit them (he says reluctantly). Sorry for seeming obnoxious. Gary > > > Regards > George > ------_=_NextPart_001_01C1259D.ABA9F520 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Comments on CT Reqs draft

George:

> -----Original Message-----
> From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
> Sent: Tuesday, August 14, 2001 6:47 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: RE: [seamoby] Comments on CT Reqs draft
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, August 14, 2001 8:09 PM
> To: 'George Tsirtsis'; seamoby@cdma-2000.org
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: RE: [seamoby] Comments on CT Reqs draft
>
>
> George:
>   Most of these comments seem to be editorial. As you seem
> to have figured out the intended meaning in most cases, I suggest
> that they do make sense to the casual reader. The intent here cannot
> be to define bullet proof requirements (such a document could easily
> consume 100s of pages).
>
> GT> Sure and that is not my intent. Throughout your comments
> I see that you
> are resisting almost all change and I assume this is because
> of fear of
> opening another endless discussion, which is also not my
> intent. My only
> intent is to have a small number of very clear requirements
> that I can work
> with and develop a protocol that I can also implement.

I will not resist changes that improve the possibility that we
will create a good ct solution. But, as I said, the majority of
changes seem to be aimed at clarifying text when the text was
generally clear. Past experience has shown that word smithing
the requirements are not simple changes.
 
>
>   More comments below:
> Gary
> > -----Original Message-----
> > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
> > Sent: Tuesday, August 14, 2001 10:19 AM
> > To: seamoby@cdma-2000.org
> > Cc: Alan O'Neill; Michaela Vanderveen
> > Subject: [seamoby] Comments on CT Reqs draft
> >
> >
> > All,
> >
> > Here are some comments on the current CT requirements draft.
> > We quote text
> > from the draft to make this easier to read and try to suggest
> > alternative
> > text when possible.
> >
> > 
> >
> > Comment 1
> > -----------
> > "4.9 All context information to be transferred MUST be
> > available at the
> >    AR performing the transfer, prior to the initiation of
> the context
> >    transfer.
> > 
> >    The total context associated with the MN's traffic is
> composed of
> >    various types of feature context. To effect a rapid
> transfer, the
> >    context information has to be readily available when the
> AR begins
> >    the transfer. "
> > 
> > This does not make sense as stated. What initiates the
> > gathering of all the
> > relevant context to be transferred? Or you just mean that
> all relevant
> > context is in close proximity to the CT code (i.e.: same
> > box)? By saying the
> > context MUST be ready when CT is initiated we just defer the
> > potential for
> > delay, we do not eliminate it...i.e.: one may not initiate CT
> > until it has
> > gathered all context but the gathering process could take
> > very long time.
> > We suggest something like the following:
> > "CT should not be slowed down by a process or feature
> > inability to make
> > appropriate context available to CT. CT SHOULD be able to
> > transfer context
> > as it becomes available.
> Your suggestion is syntactically incorrect, and thus harder
> to understand.
> The intent is as you surmised: to require that the context be
> at the AR,
> and not elsewhere when the transfer is to be initiated. There
> are many
> finer points that could be made, but with markedly
> diminishing importance.
>
> GT> Gary it does not make sense. My point here is that the requirement
> relates to timing considerations which are covered by other
> requirements in
> this spec...weather the context is in or out of the AR it is
> a mute point
> and a protocol should not be held accountable for not doing
> it this way.

Actually, Kulwinder answered this better then I did. The issue is
not timing, it is scope and ordering.

>
> >
> > Comment 2
> > ----------
> > "4.10 The context information provided for transfer MUST be
> reliable.
> >
> >    The context to be transferred must not only be readily
> > available for
> >    transfer, but the sending AR must ensure that the
> > information is sound.
> >   
> >    The context transfer solution may provide mechanisms to
> > support reliable
> >    transfer of context, but the effectiveness of context
> transfer in
> > enhancing
> >    handover between ARs would very likely be compromised by
> > attempts to
> >    transfer malformed context."
> >
> > This again makes no sense to the casual reader! How does CT
> > "evaluate" the
> > soundness of a protocol specific context. Consider that the
> > effectiveness of
> > context transfer in enhancing handover between ARs would also
> > very likely be
> > compromised by attempts to ensure that the information is
> > sound. Please
> The requirement says nothing about CT evaluating the soundness
> of the context. The requirement actual says the opposite: that
> the context must itself be reliable, for ct will do nothing to
> compensate for unreliable context.
>
>
> GT> I totaly agree with what you state above (which I wish it
> was the real
> text) but the spec says and I repeat "... The context to be
> transferred must
> not only be readily available for transfer, but the sending
> AR must ensure
> that the information is sound." it then also says..."...the
> effectiveness of
> context transfer in  enhancing handover between ARs would
> very likely be
> compromised by attempts to  transfer malformed context". If
> the requirement
> is only about reliability of transfer then that is what it
> should state.

None of the quotes you provide refer to "CT evaluating the soundness
of context". The way this requirement is written is that it
requires on the implementer of an AR to ensure that the context provided
to CT is reliable. The only thing "wrong" with this, if there is
anything wrong, is that it appears to state the obvious. However,
it also states clearly that ct will not fix corrupted context.

I just don't see how you come to your conclusion.

>
>
>
> > remove this totally unreasonable requirement or explain what
> > you mean. If
> It is not unreasonable. It is an absolute requirement, and there
> was general agreement (please refer to the archives for the complete
> discussion).
>
> GT> No, the requirement is that the CT protocol MUST support reliable
> transfer which is fine...it is not about the AR checking the
> soundness of
> the context...the text is confusing.

NO. This is not a requirement for reliable transfer. That particular
issue was a subject of great debate and has been deferred - c.f. section
5.2.

The text says nothing about reliable transfer. It simply says that if
the context is corrupted to begin with, it will be delivered to the receiving
AR corrupted.

>
>
> > people feel strongly about this it should as a minimum be
> > watered down like
> > this:
> > "The sender SHOULD make all reasonable efforts to ensure the
> > data is sound
> > since transfer of invalid data may be more damaging than
> > transfer of no data
> > at all"
> >
>
> > Comment 3
> > ----------
> > "5.1.1 The context transfer protocol MUST be capable of
> > transferring all
> >       of the different types of feature context necessary to
> > support the
> >       MN's traffic at a receiving AR."
> >
> > I would like to propose to clarify this further:
> > "CT MUST be generic and feature agnostic, i.e.: CT MUST allow
> > new features
> > to be defined and transported without having to change CT itself."
> This is an entirely different requirement. Your version is trying to
> "future proof" ct. 5.1.1 is concerned with the current
> features available
> at an AR. Future proof statements such as the one above are, IMHO,
> motherhood,
> as everything has to agree, and yet there is no way of
> ensuring that a
> solution is future proof.
>
>
> GT> I do not agree. A number of protocols satisfy the above
> requirement..e.g.: diameter. But if you thing that my suggestion is
> describing a different requirement then it is clear that I did not
> understand 5.1.1. Please illuminate.

The intent of 5.1.1 is that the ct solution should work for all the
*known* features required to support a forwarding service. As it is,
this is an ambitious statement, for we, as a wg, may or may not know
all of these known features. What we do believe are feature contexts
to transfer are HC, AAA, encryption, QoS, and perhaps policy. Our
knowledge of the ct issues and benefits for these features is very limited,
and will remain so until we start attempting to define ct solutions.\

That's all 5.1.1 states. It does not state that the ct solution should
handle all future feature contexts. Like I stated, IMHO, you can include
this requirement, but it's kind of like saying "I will invest only in
stocks that increase in value" - a good principle, but very hard to
act upon.

>
> >
> >
> >
> > Comment 4
> > -----------
> > "5.4.1 Proactive context transfer MUST be completed before
> > the handover
> >       of the Mobile Node's traffic to the receiving AR completes."
> >
> > Does this make sense after the removal of the
> > proactive/reactive concept
> > from this doc. Even if it does make sense there is no way to
> > ensure such a
> > thing. You can only try and have mechanisms so you can
> > recover when things
> > go wrong. E.g.: there might not be any connectivity between
> > old and new AR.
> > This is a SHOULD not a MUST.
> I agree. But if you read the minutes of the last IETF meeting, this
> statement will be changed - probably deleted, as "proactive"
> and "reactive"
> are being removed from the draft.
>
> GT> That is what I asked first ... and yes I was in the
> meeting which only
> talked about 4.4 and 4.5, hence the question...glad you agree.
>
>
> >
> > Comment 5
> > ----------
> > "5.4.3 A context transfer MUST complete with a minimum number
> > of protocol
> >       exchanges between the source AR and the rest of the ARs. "
> >
> > This is a SHOULD..protocol engineering is a trade-off and
> > this is one of the
> > basic variables (signaling level). The requirements document
> > may decair its
> > preference to low signaling levels but must not mandate
> > it...At the end of
> > the day a slightly slower more concrete CT may be better
> than a faster
> > flakey CT!
> In truth, this is a non-requirement. "minimum" is one of
> those ambiguous
> words, that cannot be measured without a reference with the
> requirement
> does not specify.
> In essence, given that the reliability requirements for ct
> are met (which
> are tbd), then all this requirement says is that there
> shouldn't be any
> "excess" exchanges. Again, there is no measure to determine
> what exchanges
> might be "excess".
> Probably the only real application of this requirement is if
> we end up
> comparing two protocols that are identical in every way but
> one has more
> exchanges. Might happen.
> At this point, this requirement is unlikely to be deleted, and it has
> no impact as it is stated.
>
> GT> Why not? You say that this is not really a
> requirement...yet it is a
> MUST in the requirements document.

*shrug* I'm just the editor.

>
>
> >
> >
> > Comment 6
> > -----------
> > "5.4.4 The context transfer protocol design MUST minimize the
> > amount of
> >       processing required at the sending and receiving Access
> > Routers."
> >
> > As above..this is a SHOULD not a MUST...Minimization implies
> > the existence
> > of some optimization function with constraints. Who sets the
> > constraints? If
> > they are set by each implementor according to their fancy,
> > then all these
> > protocols can claim compliance with the above.
> The language could be improved, but the requirement is accurate:
> the protocol MUST not introduce excess processing. You are right,
> the "minimization" requirement has no basis for determining
> compliance.
>
> GT> So, again what is the point of mute requirements? get
> them out of the
> way and we will have a much better document.

Again, *shrug*. The phrase "mostly harmless" comes to mind.

We have had extensive discussions in the working group over these
requirements, and a consensus was determined. We have to live with
this consensus, otherwise no progress will be made. If there was a real
problem (e.g. logical fallacy or misconception), then it would be worth
opening an issue. But I don't believe it's worth revisiting the debate
over whether the use of words like "fast", "smooth", "faster", "minimal",
etc. are useful in requirements. As you know, if this was a rigorous requirements
document (e.g. a DoD requirements document), such words would not be permitted.

>
>
> >
> >
> > Comment 7
> > -----------
> > "5.4.5 The Context Transfer protocol MUST meet the timing
> constraints
> >       required by all the feature contexts."
> >
> > Again, CT SHOULD attempt to comply with timing constrains and
> > have ways to
> > recover if it does not...nothing is for certain here...Maybe
> > change with
> > something like this:
> > "The Context Transfer protocol SHOULD strive to comply with
> > the the timing
> > constraints imposed by the different feature contexts. The CT
> > protocol MUST
> > provide ways to recover and allow the handoff to complete
> > normally when the
> > timing constrains are not met."
> Sorry, but if a protocol meets the requirements, whether through
> a clean design or through "recovery", then it meets this requirement.
> "strive" is an anthropomorphic term that doesn't belong in a
> requirement.
> Also, you have specified two requirements in place of one.
> The requirement remains a MUST. The fact is that everyone one of the
> requirements is likely to fail under some conditions, and the
> protocol
> is going to have to have some reasonable recovery mechanisms.
> It would
> take years for us to gain consensus on all the necessary recovery
> mechanisms.
>
> GT> The point is that on one hand there is no way for any
> protocol to ensure
> that timing requirements are met while on the other hand you miss the
> obvious requirement of failsafe. BTW, I did not request
> consensus on the
> recovery mechanisms just the requirement for the protocol not
> to fail the
> handoff when it self fails. Then again I would be happy if
> you changed that
> MUST to SHOULD since no one can satisfy the MUST.

These are requirements. Even in rigorous requirements excercises it is
fully acceptable to outline the desired goals ("MUST"), while realizing
there are exceptional conditions where these "MUST"s will be violated.
Again, it's an issue that I believe is a result of the lack of rigor
in this particular requirements specification process (and, no, I'm not
suggesting more rigor).

Personally, I'm happy with MUST.


>
>
> >
> >
> > Comment 8
> > -----------
> > "5.6.2 The context transfer protocol MUST include methods for
> > exchanging
> >       information with the handover process.
> >
> >    Both context transfer and handover require information on the
> >    AR candidates for handover. The context transfer entities
> > may, in the 
> >    process of establishing and supporting context transfer,
> acquire 
> >    information that would be useful to the handover process in 
> >    determining the new forwarding path: for example, the
> outcome of an
> >    admission control decision at a receiving AR."
> >
> >
> > The text here is very nebulus, so as a minimum a concrete
> > example should be
> > given.  "For example, if during the CT process one newAR
> > appears to be able
> > to support the MN's QoS requirements better than the other,
> > then CT SHOULD
> > be able to make this information known the handoff process."
> Why?
>
> GT> Because I give you a valid example that you actually
> agree with instead
> the mumble jumble of the current one but never mind...this is
> not important
> so forget about it.
>
> Here is a good example where the meaning of the requirement was
> in fact clear to you. Are you pre-supposing that other
> readers have less
> of a grasp of English, or a lower IQ?
>
> GT> I am not even going to respond to this...you must be very
> tired since I
> do not think you really want to be offensive. I just regret that I am
> causing you pain...
>
> As the prime audience for this
> document is actually the people who participated in the writing, it
> would seem reasonable that they would derive the same meaning
> as you did.
>
> GT> Gary, a general point. I can understand if I make a point and you
> disagree...in which case we have to discuss further. I do
> not, however,
> understand when you agree with me and yet say "....oh no, we
> can not change
> the doc now...too late", unless of course the rest of the
> group feels the
> same way.

Ok. The process is that you submit an issue to the wg list for each
change that you would have identified. Then we discuss each issue
for one or two months, and Pat tries to gauge a consensus. If there
is no clear consensus on the list, then Pat will ask for an email humm.

My views on your issues have nothing to do with this process. You are
fully welcome to submit the issues.

My opinion, however, is that, yes, we certainly have not created a perfect
document, and many of the requirements could be worded better, could have
better explanatory text, and, there are definitely many requirements missing.
But, in my view, it is not worth the pain and effort to continue polishing
up descriptions that have been actively reviewed and discussed for 3 months
now.

This is just my view, and no I'm not tired, I just want to move on to the
protocol design sometime this millenium.

>
> - Comments 4, 5, 6 we agree on and unless there are others
> that disagree we
> should change
> - Comment 2 I think we agree on but not sure yet
> - Comment 1, 3, 7 we do not seam to agree on
> - Comment 8 is not important

We (you and I) don't form a consensus. Unless I'm mistaken, the process
outlined above is still in place. If you feel strongly about these
9 issues, then you should submit them (he says reluctantly).

Sorry for seeming obnoxious.

Gary

>
>
> Regards
> George
>

------_=_NextPart_001_01C1259D.ABA9F520-- From owner-seamoby@diameter.org Wed Aug 15 11:51:33 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24325 for ; Wed, 15 Aug 2001 11:51:31 -0400 (EDT) Received: (qmail 3144 invoked by alias); 15 Aug 2001 15:11:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3137 invoked by uid 200); 15 Aug 2001 15:11:36 -0000 Received: (qmail 3129 invoked from network); 15 Aug 2001 15:11:31 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 15:11:31 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA13286; Wed, 15 Aug 2001 08:22:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7FFMO915184; Wed, 15 Aug 2001 08:22:24 -0700 X-mProtect: Wed, 15 Aug 2001 08:22:24 -0700 Nokia Silicon Valley Messaging Protection Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd4bzBAa; Wed, 15 Aug 2001 08:22:20 PDT Message-ID: <3B7A9390.5ECD9B0C@iprg.nokia.com> Date: Wed, 15 Aug 2001 08:21:52 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat, thanks for the minutes. It seems it was indeed pretty intense. However... Pat Calhoun wrote: > > Serioulsy, removing the terminology is not the same as removing the concept. > > As far as I can tell, proactive vs. reactive was essentially stating when CT > would occur. This, as you state, is not a requirement, ...what I state is that saying 'CT may happen prior to, during or after handoff' is not a requirement, it is just stating the obvious. CT must happen prior to, during or after handoff, not because you require it, but because basic laws of physics. Stating whether or not CT could complete before or after handoff is to me a requirement. Cedric. > and therefore adding > something as simple as what proposed seems to do the same thing with the least > amount of friction. > > > It looks to me like the baby was thrown away with the bath water. You mention some > > 'intense discussion', could you elaborate to enlighten those who were not present, > > Here are the rough minutes for this particular discussion: > > > Issues 4 & 7 > ------------- > > 4 - Proactive v.s. Reactive. > > 7 - Remove pro and re from doc. > > Theo: Why remove? > Two modes are too limited, may be more than two > modes, putting in reqs will limit to two modes. > > Theo: two classes of sets of modes, other distincitions > necessary. > > Charlie: Don't know yet, revisit issue later. Move > on better understood reqs. Table it. > > John Longherty: Talk about protocol modes, examples > rather than modes. Useful to discuss in terms of > examples of how a protocol may work, but not > normative. > > Allison: Design space to consider, potental to > classify. Don't put in as requirement. > > Majiv: Misunderstanding. Timing req. originally > there, to define timing req need to dig deeper, > need to define in relation to handover, not > supposed to be modes. Solution covers both, > but solutions don't have to cover modes. > Remove if expected to be a mode. > > Gary: Mode is the problem, not proactive and reactive. > Mode is the issue, capability is more deescriptive. > Protocol operate on two kinds of capabilities. > Not bit in header, happens in different time relative > to handoff. > > Hemant: Do we need to define temporal characteristics? > Depends on when trigger was sent. > > Theo: Shift from mode to timing. Timing in which > you act. CT tends to revolve around time > restriction. Dismiss timing, then revisit. > > Rajeev: Mode -> capabilities won't solve. > MN attaches to new router, is context there or not? > Pro - there, Re - not there. Too much confusion, > put in appendix. > > three options > > 1) Use word capabilities > 2) Remove > 3) Move to appendix. > > Need to consider revise or keep current text. > > Rajeev: Proposed text. If context there when MN > attaches to new router, pro. If there after, re. > > Majeev: Timing requirements in req. doc? Will > it delay handover? May want to define pro and > re, if not, triggers may be needed. Confusing > based on starting event and ending event. > > Rajeev: Presentation, is a distinction. > > Majeev: Does there need to be a timing > requirement? > > Henrik: Cedric's text makes me least happy. > Way it says it is difficult, don't know > discussion says that you implement two > modes. Other than that, OK. > > Gary: Timing requirement is in current doc, > section 5, req for pro and re, current > reqs are wrong, specifies a too tight > timing req, needs to be fixed. > No happy with delegating to appendix, important > part of CT and for seamlessness. > > Pat: Advisory. > > Gary: No, it must be a requrimenet, proactive, > there when packets arrive at new AR. > Lose and be back in same debate. > > ????: QoS guy, how would a router react > if first packet had a code point and > the QoS was not there? Would drop. > So there is a timing req. > > Pat: Some > environments where you don't have > handoff notification, in others, > can. > > ???: Some networks have it. > > Rajeev: Always try to get context transfereed > prior to handover. Not removing possibility > of moving context. When you invoke CT. > > Henrik: Important to have capability to do flexibly, > as early and late. Shouldn't be an appendix. > > Gopal: Can push or pull context, pro or re depends > on timing. > > John Logherty: Local API issue. > > Gary: Makes a difference. Multiphasic, only time > is just at time that handover is happening. Later, > state isn't there for packet to be forwarded. > Other phases, might want to transfer. Static, > won't change. Value in concepts, landscape for > people to work on solutions. > > Rajeev: Proactive mode, previous router initiates. > Reactive, new router initiates. Both routers should > be able to initiate. Proactive in either direction. > Is context on new router? > > Pat: options > > 1) leave as is. > 2) use word capabilities. > 3) remove text from doc -5 > 4) remove text to appendix -5 > 5) state that CT before, during, or after > handover. - many. > > 5) wins. > > > Thanks, > > PatC From owner-seamoby@diameter.org Wed Aug 15 11:55:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24414 for ; Wed, 15 Aug 2001 11:55:28 -0400 (EDT) Received: (qmail 3220 invoked by alias); 15 Aug 2001 15:14:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3214 invoked by uid 200); 15 Aug 2001 15:14:54 -0000 Received: (qmail 3197 invoked from network); 15 Aug 2001 15:14:26 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 15:14:26 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FFOlp26461 for ; Wed, 15 Aug 2001 11:24:47 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 15 Aug 2001 11:24:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 11:24:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EFD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'Kulwinder Atwal'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 11:24:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1259E.65BDE9D0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1259E.65BDE9D0 Content-Type: text/plain; charset="iso-8859-1" *snip* > > For example, we have ruled out the transfer of PDP context, > and BTS context. > We have? I thought we had only decided that such L2 context would have to be transferred opaquely (which would imply the timing requirements/reliability/security requirements for the transfer might be difficult to pin down, but so be it). Gary ------_=_NextPart_001_01C1259E.65BDE9D0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Comments on CT Reqs draft

*snip*

>
> For example, we have ruled out the transfer of PDP context,
> and BTS context.
>

We have? I thought we had only decided that such L2 context would
have to be transferred opaquely (which would imply the timing
requirements/reliability/security requirements for the transfer
might be difficult to pin down, but so be it).

Gary

------_=_NextPart_001_01C1259E.65BDE9D0-- From owner-seamoby@diameter.org Wed Aug 15 12:10:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24722 for ; Wed, 15 Aug 2001 12:10:20 -0400 (EDT) Received: (qmail 3416 invoked by alias); 15 Aug 2001 15:24:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3410 invoked by uid 200); 15 Aug 2001 15:24:14 -0000 Received: (qmail 3370 invoked from network); 15 Aug 2001 15:21:57 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 15:21:57 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FFUtp27450 for ; Wed, 15 Aug 2001 11:30:55 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 15 Aug 2001 11:30:49 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 11:30:51 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5EFE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Cedric Westphal'" , Pat Calhoun Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Wed, 15 Aug 2001 11:30:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1259F.425837B0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1259F.425837B0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1259F.425837B0" ------_=_NextPart_001_01C1259F.425837B0 Content-Type: text/plain; charset="iso-8859-1" Cedric: If I may: we proposed for options for issue 4 (and issue 7, which I felt was related). I have attached the powerpoint slides for you. One of the options was your revised wording, which unfortunately, did not get enough review before the meeting, and was too long to digest during the meeting. The indication in the meeting was that people preferred the wording Pat email. However, consensus can only be established on the wg email list. Gary > -----Original Message----- > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > Sent: Wednesday, August 15, 2001 10:20 AM > To: Pat Calhoun > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > Pat Calhoun wrote: > > > Issue 4: This issue had to do with new terminology for > proactive and reactive > > Issue 7: Remove the terminology proactive and reactive > > > > After some intense discussion on the issue, it was > decided to remove > > proactive and reactive, and instead adopt a very > simple requirement > > similar to: > > > > "Context Transfer may occur prior to, during or > after a handover." > > > > Nearly complete consensus on this approach. > > It is very simple indeed, but I am not sure I understand > WHERE is the requirement. > If I don't require anything, my context transfer actually > MUST happen prior to, > during or after the handover. I can't see when else. By > requiring that 'CT MAY occur > at any time', are you planning for > disruptions in the time continuum? > > Serioulsy, removing the terminology is not the same as > removing the concept. > It looks to me like the baby was thrown away with the bath > water. You mention some > 'intense discussion', could you elaborate to enlighten those > who were not present, > thanks, > > Cedric. > > > > > > > > > Issue 5: This issue was a request to support multi-phasic CTs > > > > The text proposed at the meeting was: > > "4.9 Context information MAY be transferred in > phases, allowing for > > time critical state to be sent first, and non-time > critical state > > to be sent later. > > > > The cost of building and sending smaller packets is > less, as well > > as parsing and processing by the receiver. " > > > > The consensus at the meeting was to adopt the text, > but a comment was > > made that how one defines time critical is an issue > since anything > > could be send in the initial CT message. > > > > Each CT profile would need to specify whether it is > time-critical. > > > > If someone has any comments on the above, I'd like to hear > them now. As you > > know, decisions aren't made at meetings, and the list is > still the preferred > > medium to provide comments. If I hear no objections by > 8/21, these changes > > will be included in the next revision of the draft will be > send to WG last call. > > > > Thanks, > > > > PatC > > ------_=_NextPart_001_01C1259F.425837B0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

Cedric:

  If I may: we proposed for options for issue 4 (and issue 7, which
I felt was related). I have attached the powerpoint slides for you. One of
the options was your revised wording, which unfortunately, did not get enough
review before the meeting, and was too long to digest during the meeting.

  The indication in the meeting was that people preferred the wording
Pat email. However, consensus can only be established on the wg email
list.

Gary



> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Wednesday, August 15, 2001 10:20 AM
> To: Pat Calhoun
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
> Pat Calhoun wrote:
>
> > Issue 4: This issue had to do with new terminology for
> proactive and reactive
> > Issue 7: Remove the terminology proactive and reactive
> >
> >         After some intense discussion on the issue, it was
> decided to remove
> >         proactive and reactive, and instead adopt a very
> simple requirement
> >         similar to:
> >
> >         "Context Transfer may occur prior to, during or
> after a handover."
> >
> >         Nearly complete consensus on this approach.
>
> It is very simple indeed, but I am not sure I understand
> WHERE is the requirement.
> If I don't require anything, my context transfer actually
> MUST happen prior to,
> during or after the handover. I can't see when else. By
> requiring that 'CT MAY occur
> at any time', are you planning for
> disruptions in the time continuum?
>
> Serioulsy, removing the terminology is not the same as
> removing the concept.
> It looks to me like the baby was thrown away with the bath
> water. You mention some
> 'intense discussion', could you elaborate to enlighten those
> who were not present,
> thanks,
>
> Cedric.
>
>
>
> >
> >
> > Issue 5: This issue was a request to support multi-phasic CTs
> >
> >         The text proposed at the meeting was:
> >         "4.9 Context information MAY be transferred in
> phases, allowing for
> >         time critical state to be sent first, and non-time
> critical state
> >         to be sent later.
> >
> >         The cost of building and sending smaller packets is
> less, as well
> >         as parsing and processing by the receiver. "
> >
> >         The consensus at the meeting was to adopt the text,
> but a comment was
> >         made that how one defines time critical is an issue
> since anything
> >         could be send in the initial CT message.
> >
> >     Each CT profile would need to specify whether it is
> time-critical.
> >
> > If someone has any comments on the above, I'd like to hear
> them now. As you
> > know, decisions aren't made at meetings, and the list is
> still the preferred
> > medium to provide comments. If I hear no objections by
> 8/21, these changes
> > will be included in the next revision of the draft will be
> send to WG last call.
> >
> > Thanks,
> >
> > PatC
>
>

  ------_=_NextPart_001_01C1259F.425837B0-- ------_=_NextPart_000_01C1259F.425837B0 Content-Type: application/vnd.ms-powerpoint; name="Issue 4 & 7.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Issue 4 & 7.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAKQAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////PgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA/v////7///89AAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAD+/////v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAPCvUopkH8EB KgAAAEADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA/k0AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsAAAAQIgAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOACAAAAAAAADwDo A/wkAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID YgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB5gAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAApEELATDYEgAY2BIA7KAHMAgAAAAAAAAAMNgSAFdvDTAA1AQSEAC3D0QA AABDAG8AdQByAGkAZQByACAATgBlAHcAAABtAGEAbgAAAKRBCwEw2BIAGNgSAOygBzAIAAAAAAAA ADDYEgBXbw0wANQEMQAApA8KAAAAgABgAAAA/////wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoA AAAHAAAAAgAJEAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAH AAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2AD AAAAAAAFAACABIAEAAAAAA8ACwSsAAAADwAA8KQAAAAAAAbwWAAAAAQkAAAKAAAAMgAAAAcAAAAB AAAABwAAAAIAAABKAAAAAwAAAAQAAAAEAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAHAAAABAAAAAgA AAAEAAAACQAAAAQAAABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACA AAAAAA8A0Ad7AQAAHwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsAAQABDwD6A2cAAAAA AP4DAwAAAAEBAAAA/QM0AAAASAAAAGQAAABIAAAAZAAAAOygBzAIAAAAAAAAACTYEgAAAAAAAAAA AKb8//+g////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAHBDwAAAAAAP0D NAAAACEAAABkAAAAIQAAAGQAAACufw0w4NsSAAAAAACQQgsBAAAAAAAAAAAAAAAAAAAAAAABEgAf ABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAK5/DTDg2xIAAAAAAJBCCwEAAAAAAAAAAAAA AAAAAAAAAAESAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAgEPAAAAAAA/QM0AAAAQgAA AGQAAABCAAAAZAAAAFDYEgAugQ0w4NsSAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8A8A/3IAAA AADzAxQAAAADAAAABgAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8iAAAASXNzdWUgNCAm IDc6IFByb2FjdGl2ZSAmIFJlYWN0aXZlIAAAoQ8kAAAAIwAAAAAAAAAAAA0AAAAAAAAAFAAAAAEA AAABAAIAAAAAAAAAAACqDxQAAAAhAAAABgAAAAkEAAACAAAAAAAAABAAnw8EAAAAAQAAAAAAqg8K AAAAAQAAAAEAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP KgAAAElzc3VlIDQgJiA3OiBQcm9hY3RpdmUgJiBSZWFjdGl2ZQtvcHRpb24gMgAAoQ8cAAAAKwAA AAAAAAAAAA0AAAAAAAAAHgAAAAEAAAABAAAAqg8UAAAAKgAAAAYAAAAJBAAAAQAAAAAAAAAQAJ8P BAAAAAEAAAAAAKgPPAEAAA1SZWFjdGl2ZSBDVDogVGhlIGNvbnRleHQgdHJhbnNmZXIgcHJvY2Vz cyB3aGljaCB0YWtlcyBwbGFjZSBzdWJzZXF1ZW50IAt0byBhcnJpdmFsIG9mIGEgTU4ncyBwYWNr ZXQgYXQgdGhlIHRhcmdldCBBUiALC1Byb2FjdGl2ZSAoSSBwcmVmZXIgQ2hhcmxpZSdzIFByZWRp Y3RpdmUgYmV0dGVyKSBDVDogVGhlIGNvbnRleHQgdHJhbnNmZXIgC3Byb2Nlc3MgaW4gd2hpY2gg dGhlIHJlcXVpcmVkIGNvbnRleHRzIGFyZSBpbiBwbGFjZSBhdCB0aGUgdGFyZ2V0IEFSIAtwcmlv ciB0byB0aGUgYXJyaXZhbCBvZiBNTidzIHBhY2tldCBhdCB0YXJnZXQgQVIuIA0AAKEPHgAAADwB AAAAAAEAAAAAAAEAAAAAAAAAAAA9AQAAAAAAAAAAqg9YAAAAAQAAAAcAAAAAAAkEAABXAAAAAAAA AAUAAAABAAAAAwAqAAAAAAAAAAEAAAAGAAAACQQAAAMAAAABAAAAAwCVAAAAAAAAAAUAAAABAAAA AwAYAAAAAAAAAAAA8wMUAAAABgAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKgAA AElzc3VlIDQgJiA3OiBQcm9hY3RpdmUgJiBSZWFjdGl2ZQtvcHRpb24gMwAAoQ8cAAAAKwAAAAAA AAAAAA0AAAAAAAAAHgAAAAEAAAABAAAAqg8UAAAAKgAAAAYAAAAJBAAAAQAAAAAAAAAQAJ8PBAAA AAEAAAAAAKAP2gYAADQALgA0ACAAVABoAGUAIABjAG8AbgB0AGUAeAB0ACAAdAByAGEAbgBzAGYA ZQByACAAZgByAGEAbQBlAHcAbwByAGsAIABNAFUAUwBUACAAcwB1AHAAcABvAHIAdAAgAHAAcgBv AGEAYwB0AGkAdgBlACAAYwBvAG4AdABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAuAA0ANAAuADUA IABUAGgAZQAgAGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABmAHIAYQBtAGUAdwBv AHIAawAgAE0AVQBTAFQAIABzAHUAcABwAG8AcgB0ACAAcgBlAGEAYwB0AGkAdgBlACAAYwBvAG4A dABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAuAA0ADQAgACAAIABJAHQAIABpAHMAIAB1AHMAZQBm AHUAbAAgAHQAbwAgAGMAbwBuAHMAaQBkAGUAcgAgAHQAdwBvACAAYwBvAG0AcABsAGUAbQBlAG4A dABhAHIAeQAsACAAbgBvAG4AIABlAHgAYwBsAHUAcwBpAHYAZQAgAG0AbwBkAGUAcwAgAG8AZgAg AG8AcABlAHIAYQB0AGkAbwBuACAAZgBvAHIAIABjAG8AbgB0AGUAeAB0ACAAdAByAGEAbgBzAGYA ZQByADoAIABwAHIAbwBhAGMAdABpAHYAZQAgAGEAbgBkACAAcgBlAGEAYwB0AGkAdgBlAC4ADQAN ACAAIAAgAFQAaABlACAAYwBvAG4AdABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAgAHAAcgBvAGMA ZQBzAHMAIABpAHMAIABzAGEAaQBkACAAdABvACAAYgBlACAAcAByAG8AYQBjAHQAaQB2AGUAIAB3 AGgAZQBuACAAdABoAGUAIAByAGUAcQB1AGkAcgBlAGQAIABjAG8AbgB0AGUAeAB0AHMAIABhAHIA ZQAgAHIAZQBxAHUAZQBzAHQAZQBkACAAdABvACAAYgBlACAAaQBuACAAcABsAGEAYwBlACAAYQB0 ACAAdABoAGUAIAB0AGEAcgBnAGUAdAAgAEEAUgAgACAAcAByAGkAbwByACAAdABvACAAdABoAGUA IABhAHIAcgBpAHYAYQBsACAAbwBmACAATQBOACcAcwAgAHAAYQBjAGsAZQB0ACAAYQB0ACAAdABh AHIAZwBlAHQAIABBAFIALgANAA0AIAAgACAAVwBpAHQAaAAgAHAAcgBvAGEAYwB0AGkAdgBlACAA YwBvAG4AdABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAsACAAdABoAGUAIABpAGQAZQBhACAAaQBz ACAAdABvACAAbQBhAGsAZQAgAHQAaABlACAAYwBvAG4AdABlAHgAdAAgAGEAdgBhAGkAbABhAGIA bABlACAAdABvACAAYQBuACAAQQBSACAAYgBlAGYAbwByAGUAIABpAHQAIABpAHMAIABuAGUAZQBk AGUAZAAuACAAVABoAGkAcwAgAG0AZQBhAG4AcwAgAHQAaABhAHQAIAB0AGgAZQAgAGMAbwBuAHQA ZQB4AHQAIABpAHMAIABhAHYAYQBpAGwAYQBiAGwAZQAgAGEAdAAgAHQAaABlACAAQQBSACAAYgBl AGYAbwByAGUAIABpAHQAIABpAHMAIAByAGUAcQB1AGkAcgBlAGQAIAB0AG8AIABmAG8AcgB3AGEA cgBkACAAdABoAGUAIABmAGkAcgBzAHQAIABwAGEAYwBrAGUAdAAgAGEAcgByAGkAdgBhAGwAIABp AG4AIAB0AGgAZQAgAE0ATgAnAHMAIAB0AHIAYQBmAGYAaQBjAC4AIABQAHIAbwBhAGMAdABpAHYA ZQAgAGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABpAHMAIABjAG8AdQBwAGwAZQBk ACAAdABvACAAbQBvAGIAaQBsAGUAIABoAGEAbgBkAG8AdgBlAHIAIABvAG4AbAB5ACAAYgB5ACAA dABoAGUAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIAB0AGgAYQB0ACAAdABoAGUAIABjAG8AbgB0 AGUAeAB0ACAAYgBlACAAaQBuACAAcABsAGEAYwBlACAAYgBlAGYAbwByAGUAIAB0AGgAZQAgAGgA YQBuAGQAbwB2AGUAcgAgAG8AZgAgAHQAaABlACAATQBOACcAcwAgAHQAcgBhAGYAZgBpAGMAIABp AHMAIABjAG8AbQBwAGwAZQB0AGUALgANAA0ACQAJAAkAKABjAG8AbgB0AGkAbgB1AGUAZAAmICkA AAChDyAAAABuAwAAAAABEAAAAABaAGADAAAAAAAADgAAAAAAAgAOAAAAqg8UAAAAbQMAAAYAAAAJ BAAAAQAAAAAAAAAAAPMDFAAAAAcAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDyEA AABJc3N1ZSA0ICYgNzogUHJvYWN0aXZlICYgUmVhY3RpdmUAAKEPHAAAACIAAAAAAAAAAAANAAAA AAAAABUAAAABAAAAAQAAAKoPFAAAACEAAAAGAAAACQQAAAEAAAAAAAAAEACfDwQAAAABAAAAAACg D0oHAAAgACAAIABUAGgAZQAgAGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABpAHMA IABzAGEAaQBkACAAdABvACAAYgBlACAAcgBlAGEAYwB0AGkAdgBlACAAdwBoAGUAbgAgAGkAdAAg AGkAcwAgAG4AbwB0ACAAcAByAG8AYQBjAHQAaQB2AGUALgANAA0AIAAgACAAVABoAGUAIABpAGQA ZQBhACAAaQBzACAAdABoAGEAdAAgAGkAbgAgAGEAIAByAGUAYQBjAHQAaQB2AGUAIABjAG8AbgB0 AGUAeAB0ACAAdAByAGEAbgBzAGYAZQByACwAIABuAG8AIABnAHUAYQByAGEAbgB0AGUAZQAgAGkA cwAgAG0AYQBkAGUAIABhAHMAIAB0AG8AIAB3AGgAZQBuACAAdABoAGUAIABjAG8AbgB0AGUAeAB0 ACAAdwBpAGwAbAAgAGIAZQAgAGkAbgAgAHAAbABhAGMAZQAgAGEAdAAgAG4AZQB3AEEAUgAuACAA VABoAGUAIABjAG8AbgB0AGUAeAB0ACAAdAByAGEAbgBzAGYAZQByACAAcAByAG8AYwBlAHMAcwAg AHIAZQBhAGMAdABzACAAdABvACAAdABoAGUAIABoAGEAbgBkAG8AdgBlAHIALAAgAGIAdQB0ACAA aABhAHMAIABuAG8AIABjAG8AbgB0AHIAbwBsACAAbwB2AGUAcgAgAG8AcgAgAGsAbgBvAHcAbABl AGQAZwBlACAAbwBmACAAdABoAGUAIABoAGEAbgBkAG8AdgBlAHIAIAB0AG8AIABlAG4AcwB1AHIA ZQAgAHQAaABhAHQAIABpAHQAIABpAHMAIABpAG4AIABwAGwAYQBjAGUAcwAgAGIAZQBmAG8AcgBl ACAAdABoAGUAIABhAHIAcgBpAHYAYQBsACAAbwBmACAATQBOACcAcwAgAHAAYQBjAGsAZQB0ACAA YQB0ACAAdABoAGUAIAB0AGEAcgBnAGUAdAAgAEEAUgAuAA0ADQAgAFIAZQBhAGMAdABpAHYAZQAg AGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABpAHMAIABjAG8AdQBwAGwAZQBkACAA dABvACAAbQBvAGIAaQBsAGUAIABoAGEAbgBkAG8AdgBlAHIAIABvAG4AbAB5ACAAYgB5ACAAdABo AGUAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIAB0AGgAYQB0ACAAcwBvAG0AZQAgAGgAYQBuAGQA bwB2AGUAcgAgAGUAdgBlAG4AdAAgAGkAcwB0AHIAaQBnAGcAZQByAGkAbgBnACAAdABoAGUAIABy AGUAYQBjAHQAaQBvAG4ALgAgAFIAZQBhAGMAdABpAHYAZQAgAGMAbwBuAHQAZQB4AHQAIAB0AHIA YQBuAHMAZgBlAHIAIAAgAGMAbwBtAHAAbABlAHQAZQBzACAAYQBzACAAcwBvAG8AbgAgAGEAcwAg AHAAbwBzAHMAaQBiAGwAZQAsACAAYgB1AHQAIABpAHQAcwAgAGMAbwBtAHAAbABlAHQAaQBvAG4A IABpAHMAIABpAG4AZABlAHAAZQBuAGQAZQBuAHQAIABvAGYAIAB0AGgAZQAgAGgAYQBuAGQAbwB2 AGUAcgAgAHAAcgBvAGMAZQBzAHMALgANAA0AIAAgACAARABlAHAAZQBuAGQAaQBuAGcAIAB1AHAA bwBuACAAdABoAGUAIABuAGUAdAB3AG8AcgBrACAAYwBvAG4AZgBpAGcAdQByAGEAdABpAG8AbgAs ACAAdABoAGUAIABNAE4AJwBzACAAdgBlAGwAbwBjAGkAdAB5ACAAYQBuAGQAIAB0AGgAZQAgAGIA ZQBoAGEAdgBpAG8AcgBvAGYAIAB0AGgAZQAgAG0AbwBiAGkAbABpAHQAeQAgAHMAbwBsAHUAdABp AG8AbgAsACAAYQAgAHIAZQBhAGMAdABpAHYAZQAgAGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMA ZgBlAHIAIABtAGEAeQAgAG8AcgAgAG0AYQB5ACAAbgBvAHQAIABjAG8AbQBwAGwAZQB0AGUAIABx AHUAaQBjAGsAbAB5ACAAZQBuAG8AdQBnAGgAIABmAG8AcgAgAHQAaABlACAAbgBlAHcAIABmAG8A cgB3AGEAcgBkAGkAbgBnACAAQQBSACAAdABvACAAcAByAG8AdgBpAGQAZQAgAGEAIABjAG8AbgBz AGkAcwB0AGUAbgB0ACAAcwBlAHIAdgBpAGMAZQAgAHQAbwAgAHQAaABlACAAZgBpAHIAcwB0ACAA cABhAGMAawBlAHQAcwAgAG8AZgAgAHQAaABlACAAcgBlAC0AZABpAHIAZQBjAHQAZQBkACAAdABy AGEAZgBmAGkAYwAuAA0ADQAJAAkACQAoAGMAbwBuAHQAaQBuAHUAZQBkACYgKQAAAKEPKgAAAKYD AAAAAAEQAAAAAFoAAwAAAAAAAQABAJMDAAAAAAAAEAAAAAAAAgAQAAAAqg9iAAAAvQAAAAYAAAAJ BAAABgAAAAcAAAADAAkEAAAqAQAABgAAAAkEAAAMAAAABwAAAAMACQQAAMwAAAAGAAAACQQAAAoA AAAHAAAAAwAJBAAA1gAAAAYAAAAJBAAAAQAAAAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAQBAAAA AAAAAACfDwQAAAAAAAAAAACoDyEAAABJc3N1ZSA0ICYgNzogUHJvYWN0aXZlICYgUmVhY3RpdmUA AKEPHAAAACIAAAAAAAAAAAANAAAAAAAAABUAAAABAAAAAQAAAKoPFAAAACEAAAAGAAAACQQAAAEA AAAAAAAAEACfDwQAAAABAAAAAACgDxgJAAAgACAAIABJAG4AIABtAGEAbgB5ACAAcwBpAHQAdQBh AHQAaQBvAG4AcwAgAHQAaABlAHIAZQAgAGkAcwAgAG4AbwAgAGYAbwByAGUAdwBhAHIAbgBpAG4A ZwAgAGEAdgBhAGkAbABhAGIAbABlACAAbwBmACAAYQAgAGgAYQBuAGQAbwB2AGUAcgAgAGEAbgBk ACAAYwBvAG4AdABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAgAG0AdQBzAHQAIABiAGUAIABpAG4A aQB0AGkAYQB0AGUAZAAgAHMAaQBtAHAAbAB5ACAAYgBlAGMAYQB1AHMAZQAgAHQAaABlACAAcgBl AC0AZABpAHIAZQBjAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAgAE0ATgAnAHMAIAB0AHIAYQBmAGYA aQBjACAAaQBzACAAaQBuACAAcAByAG8AZwByAGUAcwBzACAAYQBuAGQAIAB0AGgAZQAgAEEAUgAg AG4AZQBlAGQAcwAgAHQAaABlACAAZgBvAHIAdwBhAHIAZABpAG4AZwAgAGMAbwBuAHQAZQB4AHQA IABpAG0AbQBlAGQAaQBhAHQAZQBsAHkALgAgAEIAZQBjAGEAdQBzAGUAIABvAGYAIAB0AGgAZQAg AHAAaAB5AHMAaQBjAGEAbAAgAGMAbwBuAHMAdAByAGEAaQBuAHQAcwAsACAAdABoAGUAcwBlACAA cwBpAHQAdQBhAHQAaQBvAG4AcwAgAGMAYQBuACAAbgBlAHYAZQByACAAYgBlACAAYwBvAG0AcABs AGUAdABlAGwAeQAgAGEAdgBvAGkAZABlAGQALgAgAFQAaAB1AHMALAAgAGkAZgAgAGMAbwBuAHQA ZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABpAHMAIAB0AG8AIABiAGUAIAAgAHAAZQByAGYAbwBy AG0AZQBkACAAYQB0ACAAYQBsAGwALAAgAHQAaABlACAAZgB1AG4AZABhAG0AZQBuAHQAYQBsACAA bQBvAGQAZQAgAG8AZgAgAG8AcABlAHIAYQB0AGkAbwBuACAAbQB1AHMAdAAgAGIAZQAgAHIAZQBh AGMAdABpAHYAZQAuAA0ADQAgACAAIABUAGgAZQAgAHAAcgBvAGEAYwB0AGkAdgBlACAAbQBvAGQA ZQAgAG8AZgAgAGMAbwBuAHQAZQB4AHQAIAB0AHIAYQBuAHMAZgBlAHIAIABpAHMAIABhAG4AIABh AHQAdABlAG0AcAB0ACAAdABvACAAZgB1AHIAdABoAGUAcgAgAHIAZQBkAHUAYwBlACAAYQBuAHkA IABkAGkAcwByAHUAcAB0AGkAbwBuACAAbwBmACAAdABoAGUAIABzAGUAcgB2AGkAYwBlACAAcABy AG8AdgBpAGQAZQBkACAAdABvACAAIAB0AGgAZQAgAE0ATgAnAHMAIAB0AHIAYQBmAGYAaQBjACAA YgB5ACAAbQBhAGsAaQBuAGcAIAB0AGgAZQAgAGMAbwBuAHQAZQB4AHQAIABhAHYAYQBpAGwAYQBi AGwAZQAgAHQAbwAgAGEAbgAgAEEAUgAgAHAAcgBpAG8AcgAgAHQAbwAgAGkAdAAgAGIAZQBpAG4A ZwAgAG4AZQBlAGQAZQBkACAAZgBvAHIAIABmAG8AcgB3AGEAcgBkAGkAbgBnAC4AIABUAGgAaQBz ACAAaQBtAHAAbABpAGUAcwAgAHQAaABhAHQAIABzAG8AbQBlACAAbgBlAHQAdwBvAHIAawAgAGUA dgBlAG4AdAAgAHcAaQBsAGwAIABvAGMAYwB1ACAAYQB0ACAAdABoAGUAIABJAFAAIABsAGUAdgBl AGwAIAB0AG8AIABpAG4AZABpAGMAYQB0AGUAIAB0AGgAZQAgAHAAbwB0AGUAbgB0AGkAYQBsACAA ZgBvAHIAIABhACAAaABhAG4AZABvAHYAZQByACwAIABwAHIAaQBvAHIAIAB0AG8AIAB0AGgAZQAg AGgAYQBuAGQAbwB2AGUAcgAgAGIAZQBpAG4AZwAgAGkAbgBpAHQAaQBhAHQAZQBkACAAKABjAC4A ZgAuACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIAA0AC4AMQAgAGEAbgBkACAANAAuADIAKQAu ACAAVABoAGkAcwAgAGUAdgBlAG4AdAAgAHcAbwB1AGwAZAAgAHQAcgBpAGcAZwBlAHIAIABhACAA cAByAG8AYQBjAHQAaQB2AGUAIABjAG8AbgB0AGUAeAB0ACAAdAByAGEAbgBzAGYAZQByACAAaQBm ACAAdABoAGUAcgBlACAAaQBzACAAYwBvAG4AZgBpAGQAZQBuAGMAZQAgAHQAaABlACAAYwBvAG4A dABlAHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAgAGMAYQBuACAAYwBvAG0AcABsAGUAdABlACAAYgBl AGYAbwByAGUAIAB0AGgAZQAgAGEAcgByAGkAdgBhAGwAIABvAGYAIABNAE4AJwBzACAAcABhAGMA awBlAHQAIABhAHQAIAB0AGgAZQAgAHQAYQByAGcAZQB0ACAAQQBSAC4ADQBUAGgAZQByAGUAIABj AGEAbgAgAGIAZQAgAG4AbwAgAGcAdQBhAHIAYQBuAHQAZQBlACAAdABoAGEAdAAgAHQAaABpAHMA IABlAHYAZQBuAHQAIAB3AGkAbABsACAAbwBjAGMAdQByACAAbwByACAAdABoAGEAdAAgAHQAaABp AHMAIABjAG8AbgBmAGkAZABlAG4AYwBlACAAdwBpAGwAbAAgAGIAZQAgAGEAYwBxAHUAaQByAGUA ZAAsACAAYQBuAGQAIAB0AGgAdQBzACwAIABhACAAcgBlAGEAYwB0AGkAdgBlACAAYwBvAG4AdABl AHgAdAAgAHQAcgBhAG4AcwBmAGUAcgAgAGkAcwAgAGEAbAB3AGEAeQBzACAAcgBlAHEAdQBpAHIA ZQBkACAAYQBzACAAYQAgAGMAbwBuAHQAaQBuAGcAZQBuAGMAeQAuAA0ADQAJAAkACQAoAGMAbwBu AHQAaQBuAHUAZQBkACYgKQAAAKEPKgAAAI0EAAAAAAEQAAAAAFoAAwAAAAAAAQABAH0EAAAAAAAA DQAAAAAAAgAOAAAAqg88AAAAAwAAAAcAAAAAAAkEAACmAgAABgAAAAkEAAAEAAAABwAAAAMACQQA AN8BAAAGAAAACQQAAAEAAAAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8hAAAASXNzdWUgNCAmIDc6IFByb2FjdGl2ZSAmIFJlYWN0aXZlAAChDxwAAAAiAAAA AAAAAAAADQAAAAAAAAAVAAAAAQAAAAEAAACqDxQAAAAhAAAABgAAAAkEAAABAAAAAAAAABAAnw8E AAAAAQAAAAAAqA9EAgAAVGhpcyBhbHNvIG1lYW5zIHRoYXQgYSBjb250ZXh0IHRyYW5zZmVyIHRo YXQgYmVnaW5zIGluIHByb2FjdGl2ZSBtb2RlIG1heSwgYXMgYSByZXN1bHQgb2YgdGhlIE1OIG1v dmluZyBvciBvdGhlciBjaGFuZ2VzIHRvIHRoZSB3aXJlbGVzcyBlbnZpcm9ubWVudCwgYmUgcmVx dWlyZWQgdG8gY29tcGxldGUgaW4gcmVhY3RpdmUgbW9kZS4gSWYgdGhlIHRhcmdldCBBUiBzdGF5 cyB0aGUgc2FtZSwgdGhlbiB0aGUgc2FtZSBwcm9hY3RpdmUgY29udGV4dCB0cmFuc2ZlciBhdHRl bXB0IHNob3VsZCBldm9sdmUgaW50byBhIHJlYWN0aXZlIGNvbnRleHQgdHJhbnNmZXIgYXR0ZW1w dC4NDSAgIEFzIHRoZSBwcm9hY3RpdmUgbW9kZSBvZiBjb250ZXh0IHRyYW5zZmVyIGlzIGFuIGVu aGFuY2VtZW50LCB0aGVyZSBtYXkgYmVzaXR1YXRpb25zIHdoZXJlIHRoZSByZWFjdGl2ZSBtb2Rl IGlzIGNvbnNpZGVyZWQgYSBzdWZmaWNpZW50IHNvbHV0aW9uLiBXaGlsZSBpdCBpcyByZXF1aXJl ZCB0aGF0IHRoZSBjb250ZXh0IHRyYW5zZmVyIHByb3RvY29sIHN1cHBvcnQgcHJvYWN0aXZlIG1v ZGUsIGl0cyB1c2UgaXMgb3B0aW9uYWwuDQAAoQ8eAAAARAIAAAAAAQAAAAAAAQAAAAAAAAAAAEUC AAAAAAAAAACqDy4AAACVAQAABgAAAAkEAAAMAAAABwAAAAMACQQAAKIAAAAGAAAACQQAAAIAAAAA AAAAAADqAwAAAAAPAPgDmggAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAA AAAAAP8A////AAAAAAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoA YADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAACA gIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/AP8A AAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD/ /T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAAD AAAQAKMPdgAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAAA AP///////xIAAAAAAQAAgAUAABMg1AEgAQAAAACABQAAIiDQAkACAAAAAIAFAAATIPADYAMAAAAA gAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAA AAcAAAD//+8AAAAAAP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEA AAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwA AAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABAAAQAAAAAAAAACABAAAgAAAAAAAAAC ABAAAwAAAAAAAAACABAABAAAAAAAAAACABAAgACjDz4AAAAFAAAAAAAAAAAAAgAOAAEAAAAAAAAA AgAOAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAOAAQAAAAAAAAAAgAOAA8ADATaBAAADwAC8NIEAAAQ AAjwCAAAAAYAAAAGBAAADwAD8GoEAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAAQAAAUAAAAPAATw0gAAABIACvAIAAAAAgQAAAAKAACTAAvwNgAAAH8AAQAFAIAARG0L AYcAAQAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAgAGwAdAU cAIPABHwEAAAAAAAwwsIAAAAAAAAAAEACwEPAA3wVAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAQ2xp Y2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAAqg8KAAAAIQAAAAEA AAAAAA8ABPAWAQAAEgAK8AgAAAADBAAAAAoAAIMAC/AwAAAAfwABAAUAgACckgsBgQEEAAAIgwEA AAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAADQArAB0BQADw8AEfAQAAAAAADDCwgA AAABAAAAAgALAQ8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0byBlZGl0IE1hc3Rl ciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRo IGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAAAFMAAAAB AAAAAAAPAATwugAAABIACvAIAAAABAQAAAAKAACDAAvwMAAAAH8AAQAFAIAAUJoLAYEBBAAACIMB AAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA+wAWAGgBAPABHwEAAAAAAAwwsI AAAAAgAAAAcBCwEPAA3wQgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAA AAACAAAAAAACAA4AAAD3DwgAAAAAAAAAA01bAg8ABPC4AAAAEgAK8AgAAAAFBAAAAAoAAIMAC/Aw AAAAfwABAAUAgADYmQsBgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgA AABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQILAQ8ADfBAAAAAAACfDwQAAAAEAAAAAACg DwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAA8ABPC4AAAA EgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAcqgsBgQEEAAAIgwEAAAAIvwEBABEAwAEB AAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgDyAQ0BSAEA8AEfAQAAAAAADDCwgAAAAEAAAACAILAQ8A DfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAO AAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyACAAug8cAAAARABlAGYAYQB1AGwAdAAgAEQAZQBzAGkAZwBuAA8A 7gOWFQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwERhUAAA8AAvA+FQAAIAAI 8AgAAAAdAAAASQgAAA8AA/DWFAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAAAIAAAFAAAADwAE8HIAAAASAArwCAAAAAIIAAAgAgAAUwAL8B4AAAB/AAAABACAAIz1CwG/ AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAACABsAHQFBACDwAR8BAAAAAAAMMLCAAAAAAAAAANAAsB DwAN8AwAAAAAAJ4PBAAAAAAAAAAPAAPw4BIAAA8ABPBuAAAAAQAJ8BAAAABQAQAAUAQAAKAUAABH DwAAAgAK8AgAAABJCAAAAQIAAAMAC/AAAAAAIwAi8SYAAACfAwEAAACgwxoAAAAFAAgABAAnAQAA bgIAAG8CAABuAgAAbgIAAAAAEPAIAAAAUARQAaAURw8PAATw2wAAABIACvAIAAAAQQgAAAIKAACj AAvwPAAAAH8AAAAEAIAAKMoLAb8AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAEC AgAACD8CAAACAAAAD/AQAAAAUAEAANkMAAAoAgAARw8AAA8ADfBnAAAAAACfDwQAAAAHAAAAAACo DwEAAAA0AAChDxgAAAACAAAAAAABAAAAAAACAAAAAQACAAEAEgAAAKoPFAAAAAEAAAAGAAAACQQA AAEAAAAAAAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPDbAAAAEgAK8AgAAAA/CAAAAgoAAKMA C/A8AAAAfwAAAAQAgADgrwsBvwAAAAIAgQEEAAAIgwEAAAAIvwEBABUAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABQAQAAawoAACgCAADZDAAADwAN8GcAAAAAAJ8PBAAAAAcAAAAAAKgP AQAAADMAAKEPGAAAAAIAAAAAAAEAAAAAAAIAAAABAAIAAQASAAAAqg8UAAAAAQAAAAYAAAAJBAAA AQAAAAAAAAAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8NsAAAASAArwCAAAAD0IAAACCgAAowAL 8DwAAAB/AAAABACAAATBCwG/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAABAgIA AAg/AgAAAgAAAA/wEAAAAFABAADlBwAAKAIAAGsKAAAPAA3wZwAAAAAAnw8EAAAABwAAAAAAqA8B AAAAMgAAoQ8YAAAAAgAAAAAAAQAAAAAAAgAAAAEAAgABABIAAACqDxQAAAABAAAABgAAAAkEAAAB AAAAAAAAAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATw2wAAABIACvAIAAAAOwgAAAIKAACjAAvw PAAAAH8AAAAEAIAADOoLAb8AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAA CD8CAAACAAAAD/AQAAAAUAEAAHcFAAAoAgAA5QcAAA8ADfBnAAAAAACfDwQAAAAHAAAAAACoDwEA AAAxAAChDxgAAAACAAAAAAABAAAAAAACAAAAAQACAAEAEgAAAKoPFAAAAAEAAAAGAAAACQQAAAEA AAAAAAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPC2AAAAEgAK8AgAAAA5CAAAAgoAAKMAC/A8 AAAAfwAAAAQAgADkABECvwAAAAIAgQEEAAAIgwEAAAAIvwEBABUAwAEBAAAI/wEAAAgAAQICAAAI PwIAAAIAAAAP8BAAAABQAQAAUAQAACgCAAB3BQAADwAN8EIAAAAAAJ8PBAAAAAcAAAAAAKEPGAAA AAEAAAAAAAEAAAAAAAEAAAAFAAIABQASAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATw9AAAABIA CvAIAAAANggAAAIKAACjAAvwPAAAAH8AAAAEAIAAfA5LA78AAAACAIEBBAAACIMBAAAACL8BAQAV AMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAEAsAANkMAACgFAAARw8AAA8ADfCAAAAA AACfDwQAAAAHAAAAAACgDxwAAAAoAHMAZQBlACAAEyAwADAAIAB0AGUAeAB0ACkAAAChDxYAAAAP AAAAAAABAAAAAAAPAAAAAAACABIAAACqDxQAAAAOAAAABgAAAAkEAAABAAAAAAAAAAAApg8OAAAA +AAAAAAAIAFAAmADgAQPAATw6wAAABIACvAIAAAANAgAAAIKAACjAAvwPAAAAH8AAAAEAIAA6GVL A78AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAA KAIAANkMAAAQCwAARw8AAA8ADfB3AAAAAACfDwQAAAAHAAAAAACoDxEAAABLZWVwIGN1cnJlbnQg dGV4dAAAoQ8YAAAAEgAAAAAAAQAAAAAAEgAAAAEAAgABABIAAACqDxQAAAARAAAABgAAAAkEAAAB AAAAAAAAAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATwFgEAABIACvAIAAAALQgAAAIKAACjAAvw PAAAAH8AAAAEAIAAlNdLA78AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAA CD8CAAACAAAAD/AQAAAAEAsAAHcFAACgFAAA5QcAAA8ADfCiAAAAAACfDwQAAAAHAAAAAACoDz4A AABSZW1vdmUgcHJvYWN0aXZlIGFuZCByZWFjdGl2ZSBtb2RlcyBmcm9tIHJlcXVpcmVtZW50cyBk b2N1bWVudAAAoQ8WAAAAPwAAAAAAAQAAAAAAPwAAAAAAAgASAAAAqg8UAAAAPgAAAAYAAAAJBAAA AQAAAAAAAAAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8BgBAAASAArwCAAAACsIAAACCgAAowAL 8DwAAAB/AAAABACAAKAtWwK/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAABAgIA AAg/AgAAAgAAAA/wEAAAACgCAAB3BQAAEAsAAOUHAAAPAA3wpAAAAAAAnw8EAAAABwAAAAAAqA80 AAAASXNzdWUgNzogU2VjdGlvbiA0LjQgJiA0LjUgYXJlIHBvdGVudGlhbGx5IGxpbWl0aW5nIAAA oQ8iAAAANQAAAAAAAQAAAAAAMwAAAAEAAgABABIAAgAAAAAAAgASAAAAqg8UAAAACQAAAAYAAAAJ BAAALAAAAAAAAAAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8OgAAAASAArwCAAAACQIAAACCgAA owAL8DwAAAB/AAAABACAAEhBSwO/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAAB AgIAAAg/AgAAAgAAAA/wEAAAABALAABQBAAAoBQAAHcFAAAPAA3wdAAAAAAAnw8EAAAABwAAAAAA qA8OAAAAUmVjb21tZW5kYXRpb24AAKEPGAAAAA8AAAAAAAEAAAAAAA8AAAAFAAIABQASAAAAqg8U AAAADgAAAAYAAAAJBAAAAQAAAAAAAAAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8OAAAAASAArw CAAAACIIAAACCgAAowAL8DwAAAB/AAAABACAADB7WwK/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDA AQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAACgCAABQBAAAEAsAAHcFAAAPAA3wbAAAAAAA nw8EAAAABwAAAAAAqA8GAAAAT3B0aW9uAAChDxgAAAAHAAAAAAABAAAAAAAHAAAABQACAAUAEgAA AKoPFAAAAAYAAAAGAAAACQQAAAEAAAAAAAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPAhAQAA EgAK8AgAAAANCAAAAgoAAKMAC/A8AAAAfwAAAAQAgACs9gsBvwAAAAIAgQEEAAAIgwEAAAAIvwEB ABUAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAAQCwAAawoAAKAUAADZDAAADwAN8K0A AAAAAJ8PBAAAAAcAAAAAAKgPLwAAAFRleHQgc3VibWl0dGVkIGJ5IENlZHJpYyBXZXN0cGhhbA0o c2VlIHNsaWRlIDMpAAChDxYAAAAwAAAAAAABAAAAAAAwAAAAAAACABIAAACqDy4AAAAZAAAABgAA AAkEAAAJAAAABwAAAAMACQQAAA0AAAAGAAAACQQAAAEAAAAAAAAAAACmDw4AAAD4AAAAAAAgAUAC YAOABA8ABPDtAAAAEgAK8AgAAAAMCAAAAgoAAKMAC/A8AAAAfwAAAAQAgADQoRECvwAAAAIAgQEE AAAIgwEAAAAIvwEBABUAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAAoAgAAawoAABAL AADZDAAADwAN8HkAAAAAAJ8PBAAAAAcAAAAAAKgPEwAAAFJldmlzZSBjdXJyZW50IHRleHQAAKEP GAAAABQAAAAAAAEAAAAAABQAAAABAAIAAQASAAAAqg8UAAAAEwAAAAYAAAAJBAAAAQAAAAAAAAAA AKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8AYBAAASAArwCAAAAAsIAAACCgAAowAL8DwAAAB/AAAA BACAAARpEQK/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAA AA/wEAAAABALAADlBwAAoBQAAGsKAAAPAA3wkgAAAAAAnw8EAAAABwAAAAAAqA8uAAAAUmVkZWZp bmUgcHJvYWN0aXZlIGFuZCByZWFjdGl2ZQ0oc2VlIHNsaWRlIDIpDQAAoQ8WAAAALwAAAAAAAQAA AAAALwAAAAAAAgASAAAAqg8UAAAALgAAAAYAAAAJBAAAAQAAAAAAAAAAAKYPDgAAAPgAAAAAACAB QAJgA4AEDwAE8PsAAAASAArwCAAAAAoIAAACCgAAowAL8DwAAAB/AAAABACAAMxcEQK/AAAAAgCB AQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAACgCAADlBwAA EAsAAGsKAAAPAA3whwAAAAAAnw8EAAAABwAAAAAAqA8zAAAASXNzdWUgNDogQ2xlYXIsIHVuYW1i aWd1b3VzIGRlZmluaXRpb25zIGFyZSBtaXNzaW5nAAChDyIAAAA0AAAAAAABAAAAAAAzAAAAAQAC AAEAEgABAAAAAAACABIAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPBgAAAAQgEK8AgAAAAOCAAA AgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGfbwAA1wEBAAAA/wEIAAoAAQICAAAIPwIAAAIAvwIA AAgAAAAP8BAAAABQAQAAUAQAAKAUAABQBAAADwAE8FoAAABCAQrwCAAAABEIAAACCgAAcwAL8CoA AAC/AQAAEADAAQEAAAjLAZwxAAD/AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAFABAABr CgAAoBQAAGsKAAAPAATwYAAAAEIBCvAIAAAAEggAAAIKAACDAAvwMAAAAL8BAAAQAMABAQAACMsB n28AANcBAQAAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQAAAAUAEAAEcPAACgFAAARw8A AA8ABPBgAAAAQgEK8AgAAAATCAAAAgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGfbwAA1wEBAAAA /wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAABQAQAAUAQAAFABAABHDwAADwAE8FoAAABC AQrwCAAAABQIAAACCgAAcwAL8CoAAAC/AQAAEADAAQEAAAjLAZwxAAD/AQgACgABAgIAAAg/AgAA AgC/AgAACAAAAA/wEAAAABALAABQBAAAEAsAAEcPAAAPAATwYAAAAEIBCvAIAAAAFQgAAAIKAACD AAvwMAAAAL8BAAAQAMABAQAACMsBn28AANcBAQAAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAA D/AQAAAAoBQAAFAEAACgFAAARw8AAA8ABPBaAAAAQgEK8AgAAAAjCAAAAgoAAHMAC/AqAAAAvwEA ABAAwAEBAAAIywGcMQAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAABQAQAAdwUAAKAU AAB3BQAADwAE8FoAAABCAQrwCAAAACwIAAACCgAAcwAL8CoAAAC/AQAAEADAAQEAAAjLAZwxAAD/ AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAFABAADlBwAAoBQAAOUHAAAPAATwWgAAAEIB CvAIAAAANQgAAAIKAABzAAvwKgAAAL8BAAAQAMABAQAACMsBnDEAAP8BCAAKAAECAgAACD8CAAAC AL8CAAAIAAAAD/AQAAAAUAEAANkMAACgFAAA2QwAAA8ABPBaAAAAQgEK8AgAAAA6CAAAAgoAAHMA C/AqAAAAvwEAABAAwAEBAAAIywGcMQAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAAAo AgAAUAQAACgCAABHDwAADwAE8DwBAACiDArwCAAAADEIAAAACgAAgwAL8DAAAACAAMjcSwO/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHgCowFgFQwEDwAN 8NwAAAAAAJ8PBAAAAAQAAAAAAKgPkAAAAFRleHQgaW4gLTAwIHZlcnNpb24gZGVzY3JpYmluZyBw cm9hY3RpdmUgYW5kIHJlYWN0aXZlIG1vZGVzIG9mIG9wZXJhdGlvbiBmb3IgY3QgbXVzdCBiZSBy ZXZpc2VkLiBBZmZlY3RzIHJlcXVpcmVtZW50cyA0LjQsIDQuNSwgNS40LjEgYW5kIDUuNC4yLgAA oQ8UAAAAkQAAAAAAAAAAAJEAAAAAAAIAEgAAAKoPFAAAAJAAAAAGAAAACQQAAAEAAAAAAAAADwAE 8EgAAAASAArwCAAAAAEIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCy srIADwDuAwICAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASyAQAADwAC8KoB AAAwAAjwCAAAAAMAAAADDAAADwAD8EIBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAAwAAAUAAAAPAATweAAAABIACvAIAAAAAgwAACACAABjAAvwJAAAAAQAAAAAAH8A AAAEAIAAWL5bAr8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAU8AEPABHwEAAAAAAAwwsI AAAAAAAAAA0AWwIPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCKAAAAEgAK8AgAAAADDAAAIAIAAGMA C/AkAAAABAAAAAAAfwAAAAQAgADQeksDvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADQArAB0BQA Dw8AEfAQAAAAAADDCwgAAAABAAAADgBLAw8ADfAeAAAAAACeDwQAAAABAAAAAACmDwoAAAAQAwAA 2QD2AUIBDwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCU Ad69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkA MzPMAMzM/wCysrIADwDuAxACAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADATA AQAADwAC8LgBAABAAAjwCAAAAAMAAAAEEAAADwAD8FABAAAPAATwKAAAAAEACfAQAAAAAAAAAAAA AAAAAAAAAAAAAAIACvAIAAAAABAAAAUAAAAPAATwfgAAABIACvAIAAAAAhAAACACAABzAAvwKgAA AAQAAAAAAH8AAAAEAIAANEOcAb8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAAgAGwAdAU 8AEPABHwEAAAAAAAwwsIAAAAAAAAAA0AnAEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCSAAAAEgAK 8AgAAAADEAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgACAOpwBvwEAAAEA/wEAAAEAAQMDBAAA iAMAAAAAAAAQ8AgAAADQArAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAADgCcAQ8ADfAgAAAAAACe DwQAAAABAAAAAACmDwwAAAAYAwAAAAABANYBIgEPAATwSAAAABIACvAIAAAAARAAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DEAIAAAIA7wMYAAAAAQAAAA0O AAAAAAAAAAAAgAAAAAAHAAAADwAMBMABAAAPAALwuAEAAHAACPAIAAAAAwAAAAMcAAAPAAPwUAEA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAHAAABQAAAA8ABPB+AAAA EgAK8AgAAAACHAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgADAFJACvwEAAAEA/wEAAAEAAQMC BAAAiAMAAAAAAAAQ8AgAAACAAbAB0BTwAQ8AEfAQAAAAAADDCwgAAAAAAAAADQDlAQ8ADfAMAAAA AACeDwQAAAAAAAAADwAE8JIAAAASAArwCAAAAAMcAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACA APghkAK/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAANACsAHQFJAPDwAR8BAAAAAAAMML CAAAAAEAAAAOAJACDwAN8CAAAAAAAJ4PBAAAAAEAAAAAAKYPDAAAABgDAAAAAAEA1gEiAQ8ABPBI AAAAEgAK8AgAAAABHAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKy AA8A7gMOAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwEvgEAAA8AAvC2AQAA gAAI8AgAAAADAAAAAyAAAA8AA/BOAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAgAAAFAAAADwAE8H4AAAASAArwCAAAAAIgAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAA BACAAIwa5QG/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAIABsAHQFPABDwAR8BAAAAAA AMMLCAAAAAAAAAANAOUBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwkAAAABIACvAIAAAAAyAAACAC AABzAAvwKgAAAAQAAAAAAH8AAAAEAIAADAHlAb8BAAABAP8BAAABAAEDAwQAAIgDAAAAAAAAEPAI AAAA0AKwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A5QEPAA3wHgAAAAAAng8EAAAAAQAAAAAA pg8KAAAAGAIAAAAA9wFDAQ8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gMOAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAA AAcAAAAPAAwEvgEAAA8AAvC2AQAAkAAI8AgAAAADAAAAAyQAAA8AA/BOAQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE8H4AAAASAArwCAAAAAIkAAAg AgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAHC55QG/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDw CAAAAIABsAHQFPABDwAR8BAAAAAAAMMLCAAAAAAAAAANAOUBDwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwkAAAABIACvAIAAAAAyQAACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAELvlAb8BAAABAP8B AAABAAEDAwQAAIgDAAAAAAAAEPAIAAAA0AKwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A5QEP AA3wHgAAAAAAng8EAAAAAQAAAAAApg8KAAAAGAIAAAAA9wFDAQ8ABPBIAAAAEgAK8AgAAAABJAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAAchcoAAAAAQBAAAAA AAAEJQAApi0AAERDAAAGAEAATkUAAGZHAAB+SQAAlEsAAAAA9Q8cAAAAAgEAAO0OAAMAAAAAqk0A AAEAAAAJAAAAAQC7AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA AAD+/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5 rjAAAACwAgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAADAAAAABgAAAMgAAAAHAAAA 0AAAAAgAAADYAAAACQAAAOAAAAAKAAAA6AAAABcAAADwAAAACwAAAPgAAAAQAAAAAAEAABMAAAAI AQAAFgAAABABAAANAAAAGAEAAAwAAABOAgAAAgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93 AAAeAAAAEAAAAE5vcnRlbCBOZXR3b3JrcwADAAAA/k0AAAMAAAA1AAAAAwAAAAYAAAADAAAAAAAA AAMAAAAAAAAAAwAAAAAAAAADAAAA7Q4JAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAkAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAwAAABDb3VyaWVyIE5ldwAPAAAARGVmYXVsdCBE ZXNpZ24AIwAAAElzc3VlIDQgJiA3OiBQcm9hY3RpdmUgJiBSZWFjdGl2ZSAAKwAAAElzc3VlIDQg JiA3OiBQcm9hY3RpdmUgJiBSZWFjdGl2ZSBvcHRpb24gMgArAAAASXNzdWUgNCAmIDc6IFByb2Fj dGl2ZSAmIFJlYWN0af7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAOAhAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACUAAAACAAAAKgAAAAJAAAAvAAAABIAAADI AAAACgAAAOgAAAAMAAAA9AAAAA0AAAAAAQAADwAAAAwBAAARAAAAFAEAAAIAAADkBAAAHgAAACMA AABJc3N1ZSA0ICYgNzogUHJvYWN0aXZlICYgUmVhY3RpdmUgAGkeAAAACQAAAEdLRU5XQVJEACA3 Oh4AAAAJAAAAR0tFTldBUkQAIDc6HgAAAAIAAAAzAEVOHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQ b2ludABlICZAAAAAcJxEhQYAAABAAAAAIGUDBV4fwQFAAAAAkAFIimQfwQEDAAAA9AIAAEcAAADC IAAA/////wMAAAAIAIkQZwwAAAEACQAAA1kQAAAIAGcAAAAAABEAAAAmBg8AGAD/////AAAQAAAA AAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFACg AAsBMgAAAP//TwAUAAAATQBpAGkACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMA AAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwUAAAAE AQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQEABAAAAC0B AAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcAAAD8AgAA////AAAABAAAAC0BAgAEAAAA8AEA AAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAAAAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAA CAAAACYGDwAGAP////8BABwAAAD7AgAAAAAAAAAAAAAAAAAAAAAAAADJEgAvZ/V3QAAAAKoEChGP SfV3mEn1dwEAAAAAADAABAAAAC0BAwAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7Au3/AAAAAAAA kAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgCPSfV3mEn1dwEAAAAAADAABAAAAC0BBAAEAAAA8AED AAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgqnAlIADgAAAEF1 Z3VzdCA3LCAyMDAxDQAJAAkACQAIAAUABQAJAAUABQAJAAkACgAJAAUAAAAuAQEAAAAFAAAAAgEC AAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP// //8BAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAIBAgAAAAcAAAD8AgEAAAAAAAAABAAAAC0BAwAE AAAALQEBAAcAAAAbBFkAeQMwAEgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAA HAAAAPsC4P8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAI9J9XeYSfV3AQAAAAAAMAAE AAAALQEFAAQAAADwAQQABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABsA AAAyCk8A/gANAAAASXNzdWUgNCAmIDc6IAALAAwADAAQAA4ACAAQAAgAGQAIABAACQAIAAUAAAAu AQEAAAAFAAAAAgECAAAAHAAAAPsC4P8AAAAAAAC8AgAAAAAAQAASVGltZXMgTmV3IFJvbWFuAI9J 9XeYSfV3AQAAAAAAMAAEAAAALQEEAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEY AAAABQAAAAIBAQAAACUAAAAyCk8AoQEUAAAAUHJvYWN0aXZlICYgUmVhY3RpdmUUAA4AEAAQAA4A CwAJABAADgAIABsACAAXAA4AEAAOAAsACQAQAA4ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgEC AAAAEAAAACYGDwAWAP////8AADUAAAC1AAAAdAMAAJACAAAEAAAALQEDAAQAAAAtAQEABwAAABsE jQJdACQCOAAEAAAALQECAAQAAAAtAQAABQAAAAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLo/wAAAAAA ALwCAAAAAABAABJUaW1lcyBOZXcgUm9tYW4Aj0n1d5hJ9XcBAAAAAAAwAAQAAAAtAQUABAAAAPAB BAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKQAJCAAEAAAA0 AAwABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAwAEAAAALQEBAAcAAAAbBCUC XQC9ATgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAU AgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCtgBQgABAAAAMwAMAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BAQAHAAAAGwS+AV0AUQE4AAQAAAAtAQIABAAA AC0BAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA AAACAQEAAAAJAAAAMgptAUIAAQAAADIADAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAE AAAALQEDAAQAAAAtAQEABwAAABsEUgFdAOkAOAAEAAAALQECAAQAAAAtAQAABQAAAAkCAAAAAgUA AAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKBQFC AAEAAAAxAAwABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAwAEAAAALQEBAAcA AAAbBOoAXQC4ADgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAIBAgAA AAQAAAAtAQMABAAAAC0BAQAHAAAAGwSNAnEDJALYAQQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAAC BQAAABQCAAAAABwAAAD7Auj/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgCPSfV3mEn1 dwEAAAAAADAABAAAAC0BBAAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA AAACAQEAAAAPAAAAMgpAAuIBBQAAAChzZWUgAAgACQALAAsABgAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpAAg8CAQAAAJYA DAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAAC AQEAAAATAAAAMgpAAhsCCAAAADAwIHRleHQpDAAMAAYABwALAAwABwAIAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BAQAHAAAAGwSNAtkBJAJcAAQAAAAtAQIABAAA AC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7Auj/AAAAAAAAvAIAAAAAAEAAElRpbWVzIE5l dyBSb21hbgCPSfV3mEn1dwEAAAAAADAABAAAAC0BBQAEAAAA8AEEAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAAAhAAAAMgpAAmYAEQAAAEtlZXAgY3VycmVudCB0ZXh0bxMA CwALAA0ABgALAA0ACwAKAAsADQAIAAYACAALAAwACAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAC AQIAAAAEAAAALQEDAAQAAAAtAQEABwAAABsEUgFxA+kA2AEEAAAALQECAAQAAAAtAQAABQAAAAkC AAAAAgUAAAAUAgAAAAAcAAAA+wLo/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4Aj0n1 d5hJ9XcBAAAAAAAwAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA AAAFAAAAAgEBAAAAPQAAADIKBQHiASQAAABSZW1vdmUgcHJvYWN0aXZlIGFuZCByZWFjdGl2ZSBt b2RlcyAQAAsAEgAMAAwACwAGAAwACAAMAAsACwAHAAYADAALAAYACwAMAAwABgAIAAoACwALAAcA BgAMAAsABgASAAwADAALAAkABgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAAAuAAAAMgoiAeIBGgAAAGZyb20gcmVxdWlyZW1lbnRzIGRv Y3VtZW50CAAIAAwAEgAGAAgACwAMAAwABgAIAAsAEgALAAwABwAJAAYADAAMAAsADAASAAsADAAH AAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BAQAHAAAAGwRSAdkB 6QBcAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7Auj/AAAAAAAAvAIA AAAAAEAAElRpbWVzIE5ldyBSb21hbgCPSfV3mEn1dwEAAAAAADAABAAAAC0BBQAEAAAA8AEEAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAVAAAAMgoFAWYACQAAAElzc3Vl IDc6IAAJAAkACQANAAsABgAMAAgABgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAA FAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAoAAAAMgoFAbkAFgAAAFNlY3Rpb24gNC40ICYgNC41 IGFyZSANAAsACwAIAAcADAANAAYADAAGAAwABgAUAAYADAAGAAwABgAMAAsACwAGAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACUAAAAy CiIBZgAUAAAAcG90ZW50aWFsbHkgbGltaXRpbmcNAAwACAALAA0ACAAHAAwABwAHAAwABgAHAAcA EwAHAAgABwANAAwABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAwAEAAAALQEB AAcAAAAbBOoAcQO4ANgBBAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABwAAAAyCtQA4gEOAAAAUmVjb21tZW5k YXRpb24RAAsACwAMABQAEwALAA0ADQAMAAgABwAMAA0ABQAAAC4BAQAAAAUAAAACAQIAAAAIAAAA +gIGAAEAAAAAAAACBAAAAC0BBAAEAAAALQEDAAUAAAAUAtgA4wEFAAAAEwLYAJQCBAAAAC0BAQAH AAAA/AIAAAAAAAAAAAQAAAAtAQYABQAAAAkCAAAAAgcAAAAbBNoAlgLXAOIBBQAAAAIBAgAAAAQA AAAtAQMABAAAAC0BAQAHAAAAGwTqANkBuABcAAQAAAAtAQYABAAAAC0BAQAFAAAACQIAAAACBQAA ABQC2ACUAgUAAAAJAgAAAAIFAAAAFALYAJQCBQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgrUAGYA BgAAAE9wdGlvbhMADQAIAAcADAANAAUAAAAuAQEAAAAFAAAAAgECAAAABAAAAC0BBAAEAAAALQED AAUAAAAUAtgAZwAFAAAAEwLYAK0ABAAAAC0BAQAEAAAALQEGAAUAAAAJAgAAAAIHAAAAGwTaAK8A 1wBmAAUAAAACAQIAAAAEAAAALQEDAAQAAAAtAQEABwAAABsEJQJxA70B2AEEAAAALQEGAAQAAAAt AQEABQAAAAkCAAAAAgUAAAAUAtgArQAcAAAA+wLo/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcg Um9tYW4Aj0n1d5hJ9XcBAAAAAAAwAAQAAAAtAQcABAAAAPABBQAFAAAACQIAAAACBQAAABQC2ACt AAUAAAAuARgAAAAFAAAAAgEBAAAALQAAADIK2AHiARkAAABUZXh0IHN1Ym1pdHRlZCBieSBDZWRy aWMgdA4ACwAMAAcABgAJAAwADAATAAYABwAHAAsADAAGAAwADAAGABAACwAMAAgABgALAAYABQAA AC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQC2ACtAAUAAAAuARgAAAAFAAAAAgEBAAAA EwAAADIK2AHdAggAAABXZXN0cGhhbBcACwAJAAcADAAMAAsABgAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAAJAgAAAAIFAAAAFALYAK0ABQAAAC4BGAAAAAUAAAACAQEAAAAbAAAAMgr7AeIBDQAAAChz ZWUgc2xpZGUgMykACAAJAAsACwAGAAkABgAGAAwACwAGAAwACAAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAACAQIAAAAEAAAALQEDAAQAAAAtAQEABwAAABsEJQLZAb0BXAAEAAAALQEGAAQAAAAtAQEA BQAAAAkCAAAAAgUAAAAUAtgArQAcAAAA+wLo/wAAAAAAALwCAAAAAABAABJUaW1lcyBOZXcgUm9t YW4Aj0n1d5hJ9XcBAAAAAAAwAAQAAAAtAQUABAAAAPABBwAFAAAACQIAAAACBQAAABQC2ACtAAUA AAAuARgAAAAFAAAAAgEBAAAAJAAAADIK2AFmABMAAABSZXZpc2UgY3VycmVudCB0ZXh0ZxEACwAL AAcACQALAAYACwANAAsACwALAA0ACAAGAAgACwAMAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA AgECAAAABAAAAC0BAwAEAAAALQEBAAcAAAAbBL4BcQNRAdgBBAAAAC0BBgAEAAAALQEBAAUAAAAJ AgAAAAIFAAAAFALYAK0AHAAAAPsC6P8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAI9J 9XeYSfV3AQAAAAAAMAAEAAAALQEHAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAtgArQAFAAAALgEY AAAABQAAAAIBAQAAADYAAAAyCm0B4gEfAAAAUmVkZWZpbmUgcHJvYWN0aXZlIGFuZCByZWFjdGl2 ZQAQAAsADAALAAgABgAMAAsABgAMAAgADAALAAsABwAGAAwACwAGAAsADAAMAAYABwALAAsACgAH AAYADAALAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAtgArQAFAAAALgEYAAAA BQAAAAIBAQAAABsAAAAyCo8B4gENAAAAKHNlZSBzbGlkZSAyKQAIAAkACwALAAYACQAGAAYADAAL AAYADAAIAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BAQAHAAAA GwS+AdkBUQFcAAQAAAAtAQYABAAAAC0BAQAFAAAACQIAAAACBQAAABQC2ACtABwAAAD7Auj/AAAA AAAAvAIAAAAAAEAAElRpbWVzIE5ldyBSb21hbgCPSfV3mEn1dwEAAAAAADAABAAAAC0BBQAEAAAA 8AEHAAUAAAAJAgAAAAIFAAAAFALYAK0ABQAAAC4BGAAAAAUAAAACAQEAAAAxAAAAMgptAWYAHAAA AElzc3VlIDQ6IENsZWFyLCB1bmFtYmlndW91cyAJAAkACQANAAsABgAMAAgABgARAAcACwAMAAsA BgAGAA0ADQANABMADQAHAAwADQANAA0ACQAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAA AgUAAAAUAtgArQAFAAAALgEYAAAABQAAAAIBAQAAACoAAAAyCokBZgAXAAAAZGVmaW5pdGlvbnMg YXJlIG1pc3NpbmcADQALAAcABwANAAcACAAHAAwADQAJAAYADAALAAsABgATAAcACgAJAAcADQAM AAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AAA1AAAAtQAAAHQD AAC8AAAABAAAAC0BAQAHAAAA/AIAAAAAAAAAAAQAAAAtAQcABQAAAAYBAgAAAAwAAAAkAwQANwC3 ADcAugBxA7oAcQO3AAUAAAAGAQEAAAAEAAAALQEBAAQAAAAtAQYABAAAAPABBwAIAAAAJgYPAAYA /////wEAEAAAACYGDwAWAP////8AADcAAAC7AQAAcgMAAL4BAAAIAAAA+gIAAAEAAAAAAAAABAAA AC0BBwAEAAAALQEDAAgAAAAlAwIAOAC8AXADvAEEAAAALQEBAAQAAADwAQcABAAAAC0BBgAIAAAA JgYPAAYA/////wEAEAAAACYGDwAWAP////8AADUAAACJAgAAdAMAAJACAAAEAAAALQEBAAcAAAD8 AgAAAAAAAAAABAAAAC0BBwAFAAAABgECAAAADAAAACQDBAA3AIsCNwCOAnEDjgJxA4sCBQAAAAYB AQAAAAQAAAAtAQEABAAAAC0BBgAEAAAA8AEHAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA//// /wAANQAAALUAAAA8AAAAkAIAAAQAAAAtAQEABwAAAPwCAAAAAAAAAAAEAAAALQEHAAUAAAAGAQIA AAAMAAAAJAMEADoAtwA3ALcANwCNAjoAjQIFAAAABgEBAAAABAAAAC0BAQAEAAAALQEGAAQAAADw AQcACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AADXAQAAtwAAANoBAACOAgAACAAAAPoC AAABAAAAAAAAAAQAAAAtAQcABAAAAC0BAwAIAAAAJQMCANgBuADYAYwCBAAAAC0BAQAEAAAA8AEH AAQAAAAtAQYACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AABtAwAAtQAAAHQDAACQAgAA BAAAAC0BAQAHAAAA/AIAAAAAAAAAAAQAAAAtAQcABQAAAAYBAgAAAAwAAAAkAwQAcgO3AG8DtwBv A40CcgONAgUAAAAGAQEAAAAEAAAALQEBAAQAAAAtAQYABAAAAPABBwAIAAAAJgYPAAYA/////wEA EAAAACYGDwAWAP////8AADcAAADoAAAAcgMAAOsAAAAIAAAA+gIAAAEAAAAAAAAABAAAAC0BBwAE AAAALQEDAAgAAAAlAwIAOADpAHAD6QAEAAAALQEBAAQAAADwAQcABAAAAC0BBgAIAAAAJgYPAAYA /////wEAEAAAACYGDwAWAP////8AADcAAABQAQAAcgMAAFMBAAAIAAAA+gIAAAEAAAAAAAAABAAA AC0BBwAEAAAALQEDAAgAAAAlAwIAOABRAXADUQEEAAAALQEBAAQAAADwAQcABAAAAC0BBgAIAAAA JgYPAAYA/////wEAEAAAACYGDwAWAP////8AADcAAAAjAgAAcgMAACYCAAAIAAAA+gIAAAEAAAAA AAAABAAAAC0BBwAEAAAALQEDAAgAAAAlAwIAOAAkAnADJAIEAAAALQEBAAQAAADwAQcABAAAAC0B BgAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP////8AAFsAAAC3AAAAXgAAAI4CAAAIAAAA+gIA AAEAAAAAAAAABAAAAC0BBwAEAAAALQEDAAgAAAAlAwIAXAC4AFwAjAIEAAAALQEBAAQAAADwAQcA BAAAAC0BBgAIAAAAJgYPAAYA/////wEACAAAACYGDwAGAP////8BAAQAAAAtAQMABAAAAC0BAQAH AAAAGwSuAJEDaQBGAAQAAAAtAQYABAAAAC0BAQAFAAAACQIAAAACBQAAABQC2ACtABwAAAD7Auj/ AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgCPSfV3mEn1dwEAAAAAADAABAAAAC0BBwAE AAAA8AEFAAUAAAAJAgAAAAIFAAAAFALYAK0ABQAAAC4BGAAAAAUAAAACAQEAAAATAAAAMgqFAFAA CAAAAFRleHQgaW4gDgALAAwABwAGAAYADAAGAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAA AgUAAAAUAtgArQAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCoUAmgABAAAALQAIAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAtgArQAFAAAALgEYAAAABQAAAAIBAQAAAGcAAAAy CoUAogBAAAAAMDAgdmVyc2lvbiBkZXNjcmliaW5nIHByb2FjdGl2ZSBhbmQgcmVhY3RpdmUgbW9k ZXMgb2Ygb3BlcmF0aW9uIAwADAAGAAwACwAIAAkABgAMAAwABgAMAAsACQALAAkABgAMAAYADQAL AAYADAAIAAwACwALAAcABgAMAAsABgALAAwADAAGAAgACwALAAsABwAGAAwACwAGABIADAAMAAsA CQAGAAwACAAGAAwADAALAAgACwAHAAYADAAMAAYABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQC2ACtAAUAAAAuARgAAAAFAAAAAgEBAAAAGQAAADIKhQARAwwAAABmb3IgY3QgbXVz dCAIAAwACAAGAAsABwAGABIADAAJAAcABgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIF AAAAFALYAK0ABQAAAC4BGAAAAAUAAAACAQEAAABgAAAAMgqiAFAAOwAAAGJlIHJldmlzZWQuIEFm ZmVjdHMgcmVxdWlyZW1lbnRzIDQuNCwgNC41LCA1LjQuMSBhbmQgNS40LjIuAAwACwAGAAgACwAM AAYACQALAAwABgAGABEACAAIAAsACwAHAAkABgAIAAsADAAMAAYACAALABIACwAMAAcACQAGAAwA BgAMAAYABgAMAAYADAAGAAYADAAGAAwABgAMAAYACwAMAAwABgAMAAYADAAGAAwABgAFAAAALgEB AAAABQAAAAIBAgAAAAUAAAACAQIAAAAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAEAAAA8AEGABwA AAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAAAAAKAAAABAAAAAAABAAAAAEAAAAAADAABAAA AC0BBAAEAAAA8AEHAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD///// AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZlIG9w dGlvbiAzACIAAABJc3N1ZSA0ICYgNzogUHJvYWN0aXZlICYgUmVhY3RpdmUAIgAAAElzc3VlIDQg JiA3OiBQcm9hY3RpdmUgJiBSZWFjdGl2ZQAiAAAASXNzdWUgNCAmIDc6IFByb2FjdGl2ZSAmIFJl YWN0aXZlAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAACAAAAHgAAABAAAABEZXNpZ24g VGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIAAAABQAAABfwJHj2k0AAAgA9AMDAEsDR0tFTldB UkQIAAAARwBLAEUATgBXAEEAUgBEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIA cgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAA OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C1259F.425837B0-- From owner-seamoby@diameter.org Wed Aug 15 12:31:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25338 for ; Wed, 15 Aug 2001 12:31:15 -0400 (EDT) Received: (qmail 3932 invoked by alias); 15 Aug 2001 15:41:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3923 invoked by uid 200); 15 Aug 2001 15:41:07 -0000 Received: (qmail 3914 invoked by uid 500); 15 Aug 2001 15:41:05 -0000 Date: Wed, 15 Aug 2001 08:41:05 -0700 From: Pat Calhoun To: Cedric Westphal Cc: Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010815084105.A3622@charizard.diameter.org> Mail-Followup-To: Cedric Westphal , Pat Calhoun , seamoby@cdma-2000.org References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7A9390.5ECD9B0C@iprg.nokia.com>; from cedric@IPRG.nokia.com on Wed, Aug 15, 2001 at 08:21:52AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > Pat, > > thanks for the minutes. It seems it was indeed pretty intense. > However... > > Pat Calhoun wrote: > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > would occur. This, as you state, is not a requirement, > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > is not a requirement, it is just stating the obvious. CT must happen prior to, > during or after handoff, not because you require it, but because basic laws of > physics. And most people felt that the pro/re text also didn't reflect any requirements. > > Stating whether or not CT could complete before or after handoff is to me a > requirement. So how would you propose changing the text so it reads as an actualy requirement? PatC From owner-seamoby@diameter.org Wed Aug 15 13:00:08 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26109 for ; Wed, 15 Aug 2001 12:59:58 -0400 (EDT) Received: (qmail 5922 invoked by alias); 15 Aug 2001 16:44:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5916 invoked by uid 200); 15 Aug 2001 16:44:12 -0000 Received: (qmail 5907 invoked from network); 15 Aug 2001 16:43:57 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 16:43:57 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FGsWp07434 for ; Wed, 15 Aug 2001 12:54:32 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 15 Aug 2001 12:54:16 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 12:54:17 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F00@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Cedric Westphal'" , Pat Calhoun Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Wed, 15 Aug 2001 12:54:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C125AA.E85FB920" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C125AA.E85FB920 Content-Type: text/plain; charset="iso-8859-1" Cedric: Given those same laws of physics, how can there be a realistic requirement stating that CT complete at some specific time, even relative to handoff (ignoring the fact that we don't have a temporal definition of handoff either)? Stating what is obvious to some is often required in requirements to ensure that the obvious isn't lost. This is why I prefer to refer to a proactive capability requirement for ct: CT MUST be able to respond to events that warn of a possible handoff to an AR, and CT MUST be able to transfer context to prepare the newAR with the appropriate context for proper forwarding of the MNs traffic. Ideally, the latter means proactive CT SHOULD be complete before the arrival of the first packet at the new AR. Reactive starts sometime after the handover is initiated, and completes as soon as it can... But then, here we go again... Gary > -----Original Message----- > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > Sent: Wednesday, August 15, 2001 11:22 AM > To: Pat Calhoun > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > Pat, > > thanks for the minutes. It seems it was indeed pretty intense. > However... > > Pat Calhoun wrote: > > > > Serioulsy, removing the terminology is not the same as > removing the concept. > > > > As far as I can tell, proactive vs. reactive was > essentially stating when CT > > would occur. This, as you state, is not a requirement, > > ...what I state is that saying 'CT may happen prior to, > during or after handoff' > is not a requirement, it is just stating the obvious. CT must > happen prior to, > during or after handoff, not because you require it, but > because basic laws of > physics. > > Stating whether or not CT could complete before or after > handoff is to me a > requirement. > > Cedric. > > > > and therefore adding > > something as simple as what proposed seems to do the same > thing with the least > > amount of friction. > > > > > > > It looks to me like the baby was thrown away with the > bath water. You mention some > > > 'intense discussion', could you elaborate to enlighten > those who were not present, > > > > Here are the rough minutes for this particular discussion: > > > > > > Issues 4 & 7 > > ------------- > > > > 4 - Proactive v.s. Reactive. > > > > 7 - Remove pro and re from doc. > > > > Theo: Why remove? > > Two modes are too limited, may be more than two > > modes, putting in reqs will limit to two modes. > > > > Theo: two classes of sets of modes, other distincitions > > necessary. > > > > Charlie: Don't know yet, revisit issue later. Move > > on better understood reqs. Table it. > > > > John Longherty: Talk about protocol modes, examples > > rather than modes. Useful to discuss in terms of > > examples of how a protocol may work, but not > > normative. > > > > Allison: Design space to consider, potental to > > classify. Don't put in as requirement. > > > > Majiv: Misunderstanding. Timing req. originally > > there, to define timing req need to dig deeper, > > need to define in relation to handover, not > > supposed to be modes. Solution covers both, > > but solutions don't have to cover modes. > > Remove if expected to be a mode. > > > > Gary: Mode is the problem, not proactive and reactive. > > Mode is the issue, capability is more deescriptive. > > Protocol operate on two kinds of capabilities. > > Not bit in header, happens in different time relative > > to handoff. > > > > Hemant: Do we need to define temporal characteristics? > > Depends on when trigger was sent. > > > > Theo: Shift from mode to timing. Timing in which > > you act. CT tends to revolve around time > > restriction. Dismiss timing, then revisit. > > > > Rajeev: Mode -> capabilities won't solve. > > MN attaches to new router, is context there or not? > > Pro - there, Re - not there. Too much confusion, > > put in appendix. > > > > three options > > > > 1) Use word capabilities > > 2) Remove > > 3) Move to appendix. > > > > Need to consider revise or keep current text. > > > > Rajeev: Proposed text. If context there when MN > > attaches to new router, pro. If there after, re. > > > > Majeev: Timing requirements in req. doc? Will > > it delay handover? May want to define pro and > > re, if not, triggers may be needed. Confusing > > based on starting event and ending event. > > > > Rajeev: Presentation, is a distinction. > > > > Majeev: Does there need to be a timing > > requirement? > > > > Henrik: Cedric's text makes me least happy. > > Way it says it is difficult, don't know > > discussion says that you implement two > > modes. Other than that, OK. > > > > Gary: Timing requirement is in current doc, > > section 5, req for pro and re, current > > reqs are wrong, specifies a too tight > > timing req, needs to be fixed. > > No happy with delegating to appendix, important > > part of CT and for seamlessness. > > > > Pat: Advisory. > > > > Gary: No, it must be a requrimenet, proactive, > > there when packets arrive at new AR. > > Lose and be back in same debate. > > > > ????: QoS guy, how would a router react > > if first packet had a code point and > > the QoS was not there? Would drop. > > So there is a timing req. > > > > Pat: Some > > environments where you don't have > > handoff notification, in others, > > can. > > > > ???: Some networks have it. > > > > Rajeev: Always try to get context transfereed > > prior to handover. Not removing possibility > > of moving context. When you invoke CT. > > > > Henrik: Important to have capability to do flexibly, > > as early and late. Shouldn't be an appendix. > > > > Gopal: Can push or pull context, pro or re depends > > on timing. > > > > John Logherty: Local API issue. > > > > Gary: Makes a difference. Multiphasic, only time > > is just at time that handover is happening. Later, > > state isn't there for packet to be forwarded. > > Other phases, might want to transfer. Static, > > won't change. Value in concepts, landscape for > > people to work on solutions. > > > > Rajeev: Proactive mode, previous router initiates. > > Reactive, new router initiates. Both routers should > > be able to initiate. Proactive in either direction. > > Is context on new router? > > > > Pat: options > > > > 1) leave as is. > > 2) use word capabilities. > > 3) remove text from doc -5 > > 4) remove text to appendix -5 > > 5) state that CT before, during, or after > > handover. - many. > > > > 5) wins. > > > > > > Thanks, > > > > PatC > > ------_=_NextPart_001_01C125AA.E85FB920 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

Cedric:

 Given those same laws of physics, how can there be a realistic
requirement stating that CT complete at some specific time, even
relative to handoff (ignoring the fact that we don't have a temporal
definition of handoff either)?

 Stating what is obvious to some is often required in requirements
to ensure that the obvious isn't lost.

 This is why I prefer to refer to a proactive capability requirement
for ct: CT MUST be able to respond to events that warn of a possible
handoff to an AR, and CT MUST be able to transfer context to prepare
the newAR with the appropriate context for proper forwarding of the
MNs traffic. Ideally, the latter means proactive CT SHOULD be complete
before the arrival of the first packet at the new AR.

 Reactive starts sometime after the handover is initiated, and completes
as soon as it can...

 But then, here we go again...

Gary

> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Wednesday, August 15, 2001 11:22 AM
> To: Pat Calhoun
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
> Pat,
>
> thanks for the minutes. It seems it was indeed pretty intense.
> However...
>
> Pat Calhoun wrote:
>
> > > Serioulsy, removing the terminology is not the same as
> removing the concept.
> >
> > As far as I can tell, proactive vs. reactive was
> essentially stating when CT
> > would occur. This, as you state, is not a requirement,
>
> ...what I state is that saying 'CT may happen prior to,
> during or after handoff'
> is not a requirement, it is just stating the obvious. CT must
> happen prior to,
> during or after handoff, not because you require it, but
> because basic laws of
> physics.
>
> Stating whether or not CT could complete before or after
> handoff is to me a
> requirement.
>
> Cedric.
>
>
> > and therefore adding
> > something as simple as what proposed seems to do the same
> thing with the least
> > amount of friction.
>
> >
>
> > > It looks to me like the baby was thrown away with the
> bath water. You mention some
> > > 'intense discussion', could you elaborate to enlighten
> those who were not present,
> >
> > Here are the rough minutes for this particular discussion:
> >
> > <minutes>
> > Issues 4 & 7
> > -------------
> >
> > 4 - Proactive v.s. Reactive.
> >
> > 7 - Remove pro and re from doc.
> >
> > Theo: Why remove?
> > Two modes are too limited, may be more than two
> > modes, putting in reqs will limit to two modes.
> >
> > Theo: two classes of sets of modes, other distincitions
> > necessary.
> >
> > Charlie: Don't know yet, revisit issue later. Move
> > on better understood reqs. Table it.
> >
> > John Longherty: Talk about protocol modes, examples
> > rather than modes. Useful to discuss in terms of
> > examples of how a protocol may work, but not
> > normative.
> >
> > Allison: Design space to consider, potental to
> > classify. Don't put in as requirement.
> >
> > Majiv: Misunderstanding. Timing req. originally
> > there, to define timing req need to dig deeper,
> > need to define in relation to handover, not
> > supposed to be modes. Solution covers both,
> > but solutions don't have to cover modes.
> > Remove if expected to be a mode.
> >
> > Gary: Mode is the problem, not proactive and reactive.
> > Mode is the issue, capability is more deescriptive.
> > Protocol operate on two kinds of capabilities.
> > Not bit in header, happens in different time relative
> > to handoff.
> >
> > Hemant: Do we need to define temporal characteristics?
> > Depends on when trigger was sent.
> >
> > Theo: Shift from mode to timing. Timing in which
> > you act. CT tends to revolve around time
> > restriction. Dismiss timing, then revisit.
> >
> > Rajeev: Mode -> capabilities won't solve.
> > MN attaches to new router, is context there or not?
> > Pro - there, Re - not there. Too much confusion,
> > put in appendix.
> >
> > three options
> >
> > 1) Use word capabilities
> > 2) Remove
> > 3) Move to appendix.
> >
> > Need to consider revise or keep current text.
> >
> > Rajeev: Proposed text. If context there when MN
> > attaches to new router, pro. If there after, re.
> >
> > Majeev: Timing requirements in req. doc? Will
> > it delay handover? May want to define pro and
> > re, if not, triggers may be needed. Confusing
> > based on starting event and ending event.
> >
> > Rajeev: Presentation, is a distinction.
> >
> > Majeev: Does there need to be a timing
> > requirement?
> >
> > Henrik: Cedric's text makes me least happy.
> > Way it says it is difficult, don't know
> > discussion says that you implement two
> > modes. Other than that, OK.
> >
> > Gary: Timing requirement is in current doc,
> > section 5, req for pro and re, current
> > reqs are wrong, specifies a too tight
> > timing req, needs to be fixed.
> > No happy with delegating to appendix, important
> > part of CT and for seamlessness.
> >
> > Pat: Advisory.
> >
> > Gary: No, it must be a requrimenet, proactive,
> > there when packets arrive at new AR.
> > Lose and be back in same debate.
> >
> > ????: QoS guy, how would a router react
> > if first packet had a code point and
> > the QoS was not there? Would drop.
> > So there is a timing req.
> >
> > Pat: Some
> > environments where you don't have
> > handoff notification, in others,
> > can.
> >
> > ???: Some networks have it.
> >
> > Rajeev: Always try to get context transfereed
> > prior to handover. Not removing possibility
> > of moving context. When you invoke CT.
> >
> > Henrik: Important to have capability to do flexibly,
> > as early and late. Shouldn't be an appendix.
> >
> > Gopal: Can push or pull context, pro or re depends
> > on timing.
> >
> > John Logherty: Local API issue.
> >
> > Gary: Makes a difference. Multiphasic, only time
> > is just at time that handover is happening. Later,
> > state isn't there for packet to be forwarded.
> > Other phases, might want to transfer. Static,
> > won't change. Value in concepts, landscape for
> > people to work on solutions.
> >
> > Rajeev: Proactive mode, previous router initiates.
> > Reactive, new router initiates. Both routers should
> > be able to initiate. Proactive in either direction.
> > Is context on new router?
> >
> > Pat: options
> >
> > 1) leave as is.
> > 2) use word capabilities.
> > 3) remove text from doc -5
> > 4) remove text to appendix -5
> > 5) state that CT before, during, or after
> > handover. - many.
> >
> > 5) wins.
> > </minutes>
> >
> > Thanks,
> >
> > PatC
>
>

------_=_NextPart_001_01C125AA.E85FB920-- From owner-seamoby@diameter.org Wed Aug 15 13:08:20 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26331 for ; Wed, 15 Aug 2001 13:08:20 -0400 (EDT) Received: (qmail 6075 invoked by alias); 15 Aug 2001 16:47:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6069 invoked by uid 200); 15 Aug 2001 16:47:23 -0000 Received: (qmail 6062 invoked from network); 15 Aug 2001 16:47:19 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 16:47:19 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA22020; Wed, 15 Aug 2001 09:58:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7FGwOh14499; Wed, 15 Aug 2001 09:58:24 -0700 X-mProtect: Wed, 15 Aug 2001 09:58:24 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtgleYc; Wed, 15 Aug 2001 09:58:21 PDT Message-ID: <3B7AAA15.9BEF4D83@iprg.nokia.com> Date: Wed, 15 Aug 2001 09:57:57 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> <20010815084105.A3622@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > Pat, > > > > thanks for the minutes. It seems it was indeed pretty intense. > > However... > > > > Pat Calhoun wrote: > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > would occur. This, as you state, is not a requirement, > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > during or after handoff, not because you require it, but because basic laws of > > physics. > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > Stating whether or not CT could complete before or after handoff is to me a > > requirement. > > So how would you propose changing the text so it reads as an actualy requirement? Together with Gary, we did propose some text. I did not see much objection on the list about the wording, except some worries about the use of the word 'mode'. Also, I like John's proposal in Issue 7, which if I understand it well, is to look at the requirements from the context point of view, and not from the protocol point of view. Basically, looking at the container first to design the crane, and not design a crane and see if the containers fit. Cheers, Cedric. > > > PatC From owner-seamoby@diameter.org Wed Aug 15 13:10:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26423 for ; Wed, 15 Aug 2001 13:10:46 -0400 (EDT) Received: (qmail 6208 invoked by alias); 15 Aug 2001 16:50:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6202 invoked by uid 200); 15 Aug 2001 16:50:06 -0000 Received: (qmail 6194 invoked from network); 15 Aug 2001 16:50:03 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 16:50:03 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 13:01:03 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605475E@ftmail> From: George Tsirtsis To: "'Gary Kenward'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 13:01:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, August 15, 2001 4:19 PM To: 'George Tsirtsis'; seamoby@cdma-2000.org Cc: Alan O'Neill; Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft ...*big snip*... Ok. The process is that you submit an issue to the wg list for each change that you would have identified. Then we discuss each issue for one or two months, and Pat tries to gauge a consensus. If there is no clear consensus on the list, then Pat will ask for an email humm. My views on your issues have nothing to do with this process. You are fully welcome to submit the issues. GT> Why do we need to discuss this for 1 or 2 months? I sent an e-mail to see what the WG feels about issues that concerned me while reading this draft. If someone things that my points are invalid then lets hear it...you have agreed with some and disagreed with others...lets hear a few more opinions and then make a decision. I do not know why it has to be harder than this. My opinion, however, is that, yes, we certainly have not created a perfect document, and many of the requirements could be worded better, could have better explanatory text, and, there are definitely many requirements missing. But, in my view, it is not worth the pain and effort to continue polishing up descriptions that have been actively reviewed and discussed for 3 months now. This is just my view, and no I'm not tired, I just want to move on to the protocol design sometime this millenium. > > - Comments 4, 5, 6 we agree on and unless there are others > that disagree we > should change > - Comment 2 I think we agree on but not sure yet > - Comment 1, 3, 7 we do not seam to agree on > - Comment 8 is not important We (you and I) don't form a consensus. Unless I'm mistaken, the process outlined above is still in place. If you feel strongly about these 9 issues, then you should submit them (he says reluctantly). GT> How did this process degenerate to such level of paperwork?...It does not have to be this way you know. I would very much like to know what everyone else things. Myself and Gary here seam to agree on comments 4,5 and 6...anyone disagree? .....and yes if you want me to submit the issues as required by this peculiar local process I will do so but I would rather know what the WG things first. Thanks George From owner-seamoby@diameter.org Wed Aug 15 13:15:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26596 for ; Wed, 15 Aug 2001 13:14:57 -0400 (EDT) Received: (qmail 7114 invoked by alias); 15 Aug 2001 17:00:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7107 invoked by uid 200); 15 Aug 2001 17:00:05 -0000 Received: (qmail 7077 invoked from network); 15 Aug 2001 16:59:59 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 16:59:59 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FHAZp09572 for ; Wed, 15 Aug 2001 13:10:35 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 15 Aug 2001 13:10:49 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 13:10:52 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , seamoby@cdma-2000.org Cc: "Alan O'Neill" , Michaela Vanderveen Subject: RE: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 13:10:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C125AD.39291C50" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C125AD.39291C50 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Wednesday, August 15, 2001 1:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, August 15, 2001 4:19 PM > To: 'George Tsirtsis'; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: RE: [seamoby] Comments on CT Reqs draft > > > ...*big snip*... > Ok. The process is that you submit an issue to the wg list for each > change that you would have identified. Then we discuss each issue > for one or two months, and Pat tries to gauge a consensus. If there > is no clear consensus on the list, then Pat will ask for an > email humm. > My views on your issues have nothing to do with this process. You are > fully welcome to submit the issues. > > > GT> Why do we need to discuss this for 1 or 2 months? I sent > an e-mail to > see what the WG feels about issues that concerned me while > reading this > draft. If someone things that my points are invalid then lets > hear it...you > have agreed with some and disagreed with others...lets hear a few more > opinions and then make a decision. I do not know why it has > to be harder > than this. I was being fasicious. Of course, we have been discussing proactive/reactive for nearly six months now. Good luck. Gary > > > My opinion, however, is that, yes, we certainly have not > created a perfect > document, and many of the requirements could be worded > better, could have > better explanatory text, and, there are definitely many requirements > missing. > But, in my view, it is not worth the pain and effort to > continue polishing > up descriptions that have been actively reviewed and > discussed for 3 months > now. > This is just my view, and no I'm not tired, I just want to > move on to the > protocol design sometime this millenium. > > > > - Comments 4, 5, 6 we agree on and unless there are others > > that disagree we > > should change > > - Comment 2 I think we agree on but not sure yet > > - Comment 1, 3, 7 we do not seam to agree on > > - Comment 8 is not important > We (you and I) don't form a consensus. > Unless I'm mistaken, the process > outlined above is still in place. If you feel strongly about these > 9 issues, then you should submit them (he says reluctantly). > > GT> How did this process degenerate to such level of > paperwork?...It does > not have to be this way you know. I would very much like to know what > everyone else things. Myself and Gary here seam to agree on > comments 4,5 and > 6...anyone disagree? .....and yes if you want me to submit > the issues as > required by this peculiar local process I will do so but I > would rather know > what the WG things first. > > Thanks > George > ------_=_NextPart_001_01C125AD.39291C50 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Comments on CT Reqs draft

> -----Original Message-----
> From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
> Sent: Wednesday, August 15, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: RE: [seamoby] Comments on CT Reqs draft
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Wednesday, August 15, 2001 4:19 PM
> To: 'George Tsirtsis'; seamoby@cdma-2000.org
> Cc: Alan O'Neill; Michaela Vanderveen
> Subject: RE: [seamoby] Comments on CT Reqs draft
>
>
> ...*big snip*...
> Ok. The process is that you submit an issue to the wg list for each
> change that you would have identified. Then we discuss each issue
> for one or two months, and Pat tries to gauge a consensus. If there
> is no clear consensus on the list, then Pat will ask for an
> email humm.
> My views on your issues have nothing to do with this process. You are
> fully welcome to submit the issues.
>
>
> GT> Why do we need to discuss this for 1 or 2 months? I sent
> an e-mail to
> see what the WG feels about issues that concerned me while
> reading this
> draft. If someone things that my points are invalid then lets
> hear it...you
> have agreed with some and disagreed with others...lets hear a few more
> opinions and then make a decision. I do not know why it has
> to be harder
> than this.

I was being fasicious. Of course, we have been discussing proactive/reactive
for nearly six months now.

Good luck.

Gary

>
>
> My opinion, however, is that, yes, we certainly have not
> created a perfect
> document, and many of the requirements could be worded
> better, could have
> better explanatory text, and, there are definitely many requirements
> missing.
> But, in my view, it is not worth the pain and effort to
> continue polishing
> up descriptions that have been actively reviewed and
> discussed for 3 months
> now.
> This is just my view, and no I'm not tired, I just want to
> move on to the
> protocol design sometime this millenium.
> >
> > - Comments 4, 5, 6 we agree on and unless there are others
> > that disagree we
> > should change
> > - Comment 2 I think we agree on but not sure yet
> > - Comment 1, 3, 7 we do not seam to agree on
> > - Comment 8 is not important
> We (you and I) don't form a consensus.
> Unless I'm mistaken, the process
> outlined above is still in place. If you feel strongly about these
> 9 issues, then you should submit them (he says reluctantly).
>
> GT> How did this process degenerate to such level of
> paperwork?...It does
> not have to be this way you know. I would very much like to know what
> everyone else things. Myself and Gary here seam to agree on
> comments 4,5 and
> 6...anyone disagree? .....and yes if you want me to submit
> the issues as
> required by this peculiar local process I will do so but I
> would rather know
> what the WG things first.
>
> Thanks
> George
>

------_=_NextPart_001_01C125AD.39291C50-- From owner-seamoby@diameter.org Wed Aug 15 14:11:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28223 for ; Wed, 15 Aug 2001 14:11:23 -0400 (EDT) Received: (qmail 8101 invoked by alias); 15 Aug 2001 17:59:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8095 invoked by uid 200); 15 Aug 2001 17:59:09 -0000 Received: (qmail 8090 invoked from network); 15 Aug 2001 17:59:07 -0000 Received: from femail4.sdc1.sfba.home.com (24.0.95.84) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 17:59:07 -0000 Received: from cr851003a ([24.157.232.166]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010815181041.KNQE12473.femail4.sdc1.sfba.home.com@cr851003a>; Wed, 15 Aug 2001 11:10:41 -0700 Message-ID: <019501c125b5$61e52500$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "George Tsirtsis" , Cc: "Alan O'Neill" , "Michaela Vanderveen" References: <8C92E23A3E87FB479988285F9E22BE4605474F@ftmail> Subject: Re: [seamoby] Comments on CT Reqs draft Date: Wed, 15 Aug 2001 14:09:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "George Tsirtsis" To: "'Kulwinder Atwal'" ; Cc: "Alan O'Neill" ; "Michaela Vanderveen" Sent: Wednesday, August 15, 2001 4:00 AM Subject: RE: [seamoby] Comments on CT Reqs draft > > > -----Original Message----- > From: Kulwinder Atwal [mailto:katwal2200@home.com] > Sent: Wednesday, August 15, 2001 12:43 AM > To: George Tsirtsis; 'Gary Kenward'; seamoby@cdma-2000.org > Cc: Alan O'Neill; Michaela Vanderveen > Subject: Re: [seamoby] Comments on CT Reqs draft > > > > ----- Original Message ----- > From: "George Tsirtsis" > To: "'Gary Kenward'" ; > Cc: "Alan O'Neill" ; "Michaela Vanderveen" > > Sent: Tuesday, August 14, 2001 6:47 PM > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, August 14, 2001 8:09 PM > > To: 'George Tsirtsis'; seamoby@cdma-2000.org > > Cc: Alan O'Neill; Michaela Vanderveen > > Subject: RE: [seamoby] Comments on CT Reqs draft > > > > > > > > > > Comment 1 > > > ----------- > > > "4.9 All context information to be transferred MUST be > > > available at the > > > AR performing the transfer, prior to the initiation of the context > > > transfer. > > > > > > The total context associated with the MN's traffic is composed of > > > various types of feature context. To effect a rapid transfer, the > > > context information has to be readily available when the AR begins > > > the transfer. " > > > > > > This does not make sense as stated. What initiates the > > > gathering of all the > > > relevant context to be transferred? Or you just mean that all relevant > > > context is in close proximity to the CT code (i.e.: same > > > box)? By saying the > > > context MUST be ready when CT is initiated we just defer the > > > potential for > > > delay, we do not eliminate it...i.e.: one may not initiate CT > > > until it has > > > gathered all context but the gathering process could take > > > very long time. > > > We suggest something like the following: > > > "CT should not be slowed down by a process or feature > > > inability to make > > > appropriate context available to CT. CT SHOULD be able to > > > transfer context > > > as it becomes available. > > Your suggestion is syntactically incorrect, and thus harder to understand. > > The intent is as you surmised: to require that the context be at the AR, > > and not elsewhere when the transfer is to be initiated. There are many > > finer points that could be made, but with markedly diminishing importance. > > > > GT> Gary it does not make sense. My point here is that the requirement > > relates to timing considerations which are covered by other requirements > in > > this spec...weather the context is in or out of the AR it is a mute point > > and a protocol should not be held accountable for not doing it this way. > > > > This requirement defines the scope of context transfer protocol. It states > that the context carried by this protocol will be transferred by this > protocol between Peer Access Routers _only_. Only the characteristics of > transferring context between Peer Access Routers will be considered in this > protocol. > > GT> That is fine. > > For example, we have ruled out the transfer of PDP context, and BTS context. > > 1. Also, the protocol will not introduce additional messaging to bring in > context from somewhere else. > > 2. The time required by some implementations to bring in the context from > somewhere else will not be included in the explicitly or implicitly in the > protocol design. > > This requirement does not exclude a _particular_ implementation from storing > the context anywhere it chooses. > > GT> Or an implementation could go and pick it up from anywhere it exists at > the time it is needed and as long as that does not affect the CT protocol > itself then it should not matter, yes? Correct. - Kulwinder. My impression is that the requirement > as stated does not allow for that option, hence the comment. > > It only excludes that implementation > decision from affecting the protocol design. > > At least, that is my recollection of the debate on the Design Team. > > > GT> Thanks > George > From owner-seamoby@diameter.org Wed Aug 15 14:50:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29083 for ; Wed, 15 Aug 2001 14:50:58 -0400 (EDT) Received: (qmail 8685 invoked by alias); 15 Aug 2001 18:38:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8679 invoked by uid 200); 15 Aug 2001 18:38:36 -0000 Received: (qmail 8671 invoked from network); 15 Aug 2001 18:38:33 -0000 Received: from femail16.sdc1.sfba.home.com (24.0.95.143) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Aug 2001 18:38:33 -0000 Received: from cr851003a ([24.157.232.166]) by femail16.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010815185012.LCBW28545.femail16.sdc1.sfba.home.com@cr851003a>; Wed, 15 Aug 2001 11:50:12 -0700 Message-ID: <01b701c125ba$e56daf00$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "Cedric Westphal" , "Pat Calhoun" Cc: References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> Subject: Re: [seamoby] Update on Issues from IETF meeting Date: Wed, 15 Aug 2001 14:48:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Cedric Westphal" To: "Pat Calhoun" Cc: Sent: Wednesday, August 15, 2001 11:21 AM Subject: Re: [seamoby] Update on Issues from IETF meeting > Pat, > > thanks for the minutes. It seems it was indeed pretty intense. > However... > > Pat Calhoun wrote: > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > would occur. This, as you state, is not a requirement, > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > is not a requirement, it is just stating the obvious. I agree that it is obvious, but by stating it as a requirement ensures that, candidate solutions that only address one of these possibilities are excluded. It maybe a "non-requirement", but it ensures that all proposed solutions are actually flexible enough to consider the basic laws of physics in their designs. I would call it an "inclusive" requirement, rather than a "non-requirement". > CT must happen prior to, > during or after handoff, not because you require it, but because basic laws of > physics. > > Stating whether or not CT could complete before or after handoff is to me a > requirement. I agree, this would be a better requirement. - Kulwinder. > > Cedric. > > > > and therefore adding > > something as simple as what proposed seems to do the same thing with the least > > amount of friction. > > > > > > > It looks to me like the baby was thrown away with the bath water. You mention some > > > 'intense discussion', could you elaborate to enlighten those who were not present, > > > > Here are the rough minutes for this particular discussion: > > > > > > Issues 4 & 7 > > ------------- > > > > 4 - Proactive v.s. Reactive. > > > > 7 - Remove pro and re from doc. > > > > Theo: Why remove? > > Two modes are too limited, may be more than two > > modes, putting in reqs will limit to two modes. > > > > Theo: two classes of sets of modes, other distincitions > > necessary. > > > > Charlie: Don't know yet, revisit issue later. Move > > on better understood reqs. Table it. > > > > John Longherty: Talk about protocol modes, examples > > rather than modes. Useful to discuss in terms of > > examples of how a protocol may work, but not > > normative. > > > > Allison: Design space to consider, potental to > > classify. Don't put in as requirement. > > > > Majiv: Misunderstanding. Timing req. originally > > there, to define timing req need to dig deeper, > > need to define in relation to handover, not > > supposed to be modes. Solution covers both, > > but solutions don't have to cover modes. > > Remove if expected to be a mode. > > > > Gary: Mode is the problem, not proactive and reactive. > > Mode is the issue, capability is more deescriptive. > > Protocol operate on two kinds of capabilities. > > Not bit in header, happens in different time relative > > to handoff. > > > > Hemant: Do we need to define temporal characteristics? > > Depends on when trigger was sent. > > > > Theo: Shift from mode to timing. Timing in which > > you act. CT tends to revolve around time > > restriction. Dismiss timing, then revisit. > > > > Rajeev: Mode -> capabilities won't solve. > > MN attaches to new router, is context there or not? > > Pro - there, Re - not there. Too much confusion, > > put in appendix. > > > > three options > > > > 1) Use word capabilities > > 2) Remove > > 3) Move to appendix. > > > > Need to consider revise or keep current text. > > > > Rajeev: Proposed text. If context there when MN > > attaches to new router, pro. If there after, re. > > > > Majeev: Timing requirements in req. doc? Will > > it delay handover? May want to define pro and > > re, if not, triggers may be needed. Confusing > > based on starting event and ending event. > > > > Rajeev: Presentation, is a distinction. > > > > Majeev: Does there need to be a timing > > requirement? > > > > Henrik: Cedric's text makes me least happy. > > Way it says it is difficult, don't know > > discussion says that you implement two > > modes. Other than that, OK. > > > > Gary: Timing requirement is in current doc, > > section 5, req for pro and re, current > > reqs are wrong, specifies a too tight > > timing req, needs to be fixed. > > No happy with delegating to appendix, important > > part of CT and for seamlessness. > > > > Pat: Advisory. > > > > Gary: No, it must be a requrimenet, proactive, > > there when packets arrive at new AR. > > Lose and be back in same debate. > > > > ????: QoS guy, how would a router react > > if first packet had a code point and > > the QoS was not there? Would drop. > > So there is a timing req. > > > > Pat: Some > > environments where you don't have > > handoff notification, in others, > > can. > > > > ???: Some networks have it. > > > > Rajeev: Always try to get context transfereed > > prior to handover. Not removing possibility > > of moving context. When you invoke CT. > > > > Henrik: Important to have capability to do flexibly, > > as early and late. Shouldn't be an appendix. > > > > Gopal: Can push or pull context, pro or re depends > > on timing. > > > > John Logherty: Local API issue. > > > > Gary: Makes a difference. Multiphasic, only time > > is just at time that handover is happening. Later, > > state isn't there for packet to be forwarded. > > Other phases, might want to transfer. Static, > > won't change. Value in concepts, landscape for > > people to work on solutions. > > > > Rajeev: Proactive mode, previous router initiates. > > Reactive, new router initiates. Both routers should > > be able to initiate. Proactive in either direction. > > Is context on new router? > > > > Pat: options > > > > 1) leave as is. > > 2) use word capabilities. > > 3) remove text from doc -5 > > 4) remove text to appendix -5 > > 5) state that CT before, during, or after > > handover. - many. > > > > 5) wins. > > > > > > Thanks, > > > > PatC > From owner-seamoby@diameter.org Wed Aug 15 20:13:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03422 for ; Wed, 15 Aug 2001 20:13:22 -0400 (EDT) Received: (qmail 10420 invoked by alias); 16 Aug 2001 00:01:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10414 invoked by uid 200); 16 Aug 2001 00:01:49 -0000 Received: (qmail 10409 invoked from network); 16 Aug 2001 00:01:46 -0000 Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 00:01:46 -0000 Received: from Gioconda (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id CAA17191 for ; Thu, 16 Aug 2001 02:14:42 +0200 From: "Henrik Levkowetz" To: Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 02:13:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B7AAA15.9BEF4D83@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric, Johns proposal and wording was the first that cut trough the fog at the meeting, and met with overwhelming agreement because it stated very simply what seems to have been many people's concern -- i.e. that a CT protocol _not_ be so limited that it could not handle any of the conceivable timing scenarios implied. As such, it may be obvious, but it is also VERY MUCH a requirement, and may sort out unsuitable protocol proposals which may not have the flexibility required. Do you actually have anything against it, apart from it being obvious? I for one am very happy to have this requirement plainly and simply stated. Regards, Henrik Cedric Westphal wrote: > > Pat Calhoun wrote: > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > Pat, > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > However... > > > > > > Pat Calhoun wrote: > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > would occur. This, as you state, is not a requirement, > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > during or after handoff, not because you require it, but because basic laws of > > > physics. > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > requirement. > > > > So how would you propose changing the text so it reads as an actualy requirement? > > Together with Gary, we did propose some text. I did not see much objection on the list > > about the wording, except some worries about the use of the word 'mode'. > Also, I like John's proposal in Issue 7, > which if I understand it well, is to look at the requirements from the context point > of view, and not from the protocol point of view. Basically, looking at the container > first > to design the crane, and not design a crane and see if the containers fit. > > Cheers, > > Cedric. > > > > > > > > > PatC From owner-seamoby@diameter.org Wed Aug 15 22:37:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06916 for ; Wed, 15 Aug 2001 22:37:19 -0400 (EDT) Received: (qmail 11182 invoked by alias); 16 Aug 2001 02:25:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11176 invoked by uid 200); 16 Aug 2001 02:25:38 -0000 Received: (qmail 11170 invoked from network); 16 Aug 2001 02:25:36 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 02:25:36 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA20997; Wed, 15 Aug 2001 19:36:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7G2ajU01159; Wed, 15 Aug 2001 19:36:45 -0700 X-mProtect: Wed, 15 Aug 2001 19:36:45 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdaudJzn; Wed, 15 Aug 2001 19:36:43 PDT Message-ID: <3B7B31BB.86CBC51@iprg.nokia.com> Date: Wed, 15 Aug 2001 19:36:43 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Westphal CC: Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> <20010815084105.A3622@charizard.diameter.org> <3B7AAA15.9BEF4D83@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric at al., I guess the purpose was not to disallow proactive or reactive CT. In fact, having CT to occur prior to, during and after handover allows for all the possible cases. In the form of a requirement, - when the MN arrives at the new AR, it must be possible for the context(s) to be present at the new AR - when the MN arrives at the new AR, it must be possible to perform CT when context(s) is(are) not present in order to obtain them In my opinion, this would be enough to proceed on this without getting into a rathole. Regards, -Rajeev Cedric Westphal wrote: > Pat Calhoun wrote: > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > Pat, > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > However... > > > > > > Pat Calhoun wrote: > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > would occur. This, as you state, is not a requirement, > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > during or after handoff, not because you require it, but because basic laws of > > > physics. > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > requirement. > > > > So how would you propose changing the text so it reads as an actualy requirement? > > Together with Gary, we did propose some text. I did not see much objection on the list > > about the wording, except some worries about the use of the word 'mode'. > Also, I like John's proposal in Issue 7, > which if I understand it well, is to look at the requirements from the context point > of view, and not from the protocol point of view. Basically, looking at the container > first > to design the crane, and not design a crane and see if the containers fit. > > Cheers, > > Cedric. > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 03:25:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25552 for ; Thu, 16 Aug 2001 03:25:36 -0400 (EDT) Received: (qmail 12421 invoked by alias); 16 Aug 2001 07:13:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12415 invoked by uid 200); 16 Aug 2001 07:13:44 -0000 Received: (qmail 12410 invoked from network); 16 Aug 2001 07:13:42 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 07:13:42 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA18923; Thu, 16 Aug 2001 00:24:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7G7OrQ22606; Thu, 16 Aug 2001 00:24:53 -0700 X-mProtect: Thu, 16 Aug 2001 00:24:53 -0700 Nokia Silicon Valley Messaging Protection Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdgyppXj; Thu, 16 Aug 2001 00:24:52 PDT Message-ID: <3B7B753A.6651E744@iprg.nokia.com> Date: Thu, 16 Aug 2001 00:24:42 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Henrik, Henrik Levkowetz wrote: > Cedric, > > Johns proposal and wording was the first that cut trough > the fog at the meeting, and met with overwhelming agreement because > it stated very simply what seems to have been many people's concern > -- i.e. that a CT protocol _not_ be so limited that it could not handle > any of the conceivable timing scenarios implied. > > As such, it may be obvious, but it is also VERY MUCH a > requirement, and may sort out unsuitable protocol proposals which may > not have the flexibility required. I disagree with this, but this flexibility is exactly the point I'm bringing up. The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff does satisfy the requirement, since it 'may occur prior to, during or after', so why not pick after? Talk about sorting out unsuitable protocols... Cheers, Cedric. > > > Do you actually have anything against it, apart from it being > obvious? I for one am very happy to have this requirement plainly and > simply stated. > > Regards, > Henrik > > Cedric Westphal wrote: > > > > Pat Calhoun wrote: > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > Pat, > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > However... > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > during or after handoff, not because you require it, but because basic laws of > > > > physics. > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > requirement. > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > about the wording, except some worries about the use of the word 'mode'. > > Also, I like John's proposal in Issue 7, > > which if I understand it well, is to look at the requirements from the context point > > of view, and not from the protocol point of view. Basically, looking at the container > > first > > to design the crane, and not design a crane and see if the containers fit. > > > > Cheers, > > > > Cedric. > > > > > > > > > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 03:35:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25619 for ; Thu, 16 Aug 2001 03:35:27 -0400 (EDT) Received: (qmail 12985 invoked by alias); 16 Aug 2001 07:23:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12979 invoked by uid 200); 16 Aug 2001 07:23:42 -0000 Received: (qmail 12973 invoked from network); 16 Aug 2001 07:23:39 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 07:23:39 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA20040; Thu, 16 Aug 2001 00:34:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7G7YoW00525; Thu, 16 Aug 2001 00:34:50 -0700 X-mProtect: Thu, 16 Aug 2001 00:34:50 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdy11w0G; Thu, 16 Aug 2001 00:34:47 PDT Message-ID: <3B7B778D.9FA2C53C@iprg.nokia.com> Date: Thu, 16 Aug 2001 00:34:37 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Koodli CC: Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> <20010815084105.A3622@charizard.diameter.org> <3B7AAA15.9BEF4D83@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Rajeev Koodli wrote: > Cedric at al., > > I guess the purpose was not to disallow proactive or reactive CT. In fact, having CT to > occur prior to, during and after handover allows for all the possible cases. In the form > of a requirement, > > - when the MN arrives at the new AR, it must be possible for the context(s) to be present > at the new AR > - when the MN arrives at the new AR, it must be possible to perform CT when context(s) > is(are) not present in order to obtain them Rajeev, this I totally agree with. I am concerned the proposed text does not reflect this though. But I hear where you guys at the meeting come from. Maybe an 'AND' instead of an 'OR': "CT may occur prior to, during AND after handoff" and let's move on. Take care, Cedric. > > > In my opinion, this would be enough to proceed on this without getting into a rathole. > > Regards, > > -Rajeev > > Cedric Westphal wrote: > > > Pat Calhoun wrote: > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > Pat, > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > However... > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > during or after handoff, not because you require it, but because basic laws of > > > > physics. > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > requirement. > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > about the wording, except some worries about the use of the word 'mode'. > > Also, I like John's proposal in Issue 7, > > which if I understand it well, is to look at the requirements from the context point > > of view, and not from the protocol point of view. Basically, looking at the container > > first > > to design the crane, and not design a crane and see if the containers fit. > > > > Cheers, > > > > Cedric. > > > > > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 06:13:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27247 for ; Thu, 16 Aug 2001 06:13:45 -0400 (EDT) Received: (qmail 14323 invoked by alias); 16 Aug 2001 10:01:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14317 invoked by uid 200); 16 Aug 2001 10:01:55 -0000 Received: (qmail 14312 invoked from network); 16 Aug 2001 10:01:52 -0000 Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 10:01:52 -0000 Received: from Gioconda (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id MAA25723; Thu, 16 Aug 2001 12:14:47 +0200 From: "Henrik Levkowetz" To: "Cedric Westphal" Cc: Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 12:13:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B7B753A.6651E744@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric, Stating that a protocol SHALL support context transfer which can occur before, during or after handover blatantly eliminates your example which does it ONLY 2 days after handoff. Henrik > > Henrik, > > Henrik Levkowetz wrote: > > > Cedric, > > > > Johns proposal and wording was the first that cut trough > > the fog at the meeting, and met with overwhelming agreement because > > it stated very simply what seems to have been many people's concern > > -- i.e. that a CT protocol _not_ be so limited that it could not handle > > any of the conceivable timing scenarios implied. > > > > As such, it may be obvious, but it is also VERY MUCH a > > requirement, and may sort out unsuitable protocol proposals which may > > not have the flexibility required. > > I disagree with this, but this flexibility is exactly the point I'm bringing up. > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff > does satisfy the requirement, since it 'may occur prior to, during or after', so why > not pick after? Talk about sorting out unsuitable protocols... > > Cheers, > > Cedric. > > > > > > > > > Do you actually have anything against it, apart from it being > > obvious? I for one am very happy to have this requirement plainly and > > simply stated. > > > > Regards, > > Henrik > > > > Cedric Westphal wrote: > > > > > > Pat Calhoun wrote: > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > > Pat, > > > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > > However... > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > > during or after handoff, not because you require it, but because basic laws of > > > > > physics. > > > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > > requirement. > > > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > > > about the wording, except some worries about the use of the word 'mode'. > > > Also, I like John's proposal in Issue 7, > > > which if I understand it well, is to look at the requirements from the context point > > > of view, and not from the protocol point of view. Basically, looking at the container > > > first > > > to design the crane, and not design a crane and see if the containers fit. > > > > > > Cheers, > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 06:37:38 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27487 for ; Thu, 16 Aug 2001 06:37:36 -0400 (EDT) Received: (qmail 14984 invoked by alias); 16 Aug 2001 10:25:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14978 invoked by uid 200); 16 Aug 2001 10:25:37 -0000 Received: (qmail 14973 invoked from network); 16 Aug 2001 10:25:31 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 10:25:31 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA06192; Thu, 16 Aug 2001 03:36:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GAahd07300; Thu, 16 Aug 2001 03:36:43 -0700 X-mProtect: Thu, 16 Aug 2001 03:36:43 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd7jZvzv; Thu, 16 Aug 2001 03:36:41 PDT Message-ID: <3B7BA235.C3C579A3@iprg.nokia.com> Date: Thu, 16 Aug 2001 03:36:37 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit "A CT protocol SHALL support context transfer which can occur before, during or after handover" this is not the same as 'CT MAY occur prior to, during, after', and that makes sense to me. Henrik Levkowetz wrote: > Cedric, > > Stating that a protocol SHALL support context transfer which > can occur before, during or after handover blatantly eliminates your > example which does it ONLY 2 days after handoff. > > Henrik > > > > > Henrik, > > > > Henrik Levkowetz wrote: > > > > > Cedric, > > > > > > Johns proposal and wording was the first that cut trough > > > the fog at the meeting, and met with overwhelming agreement because > > > it stated very simply what seems to have been many people's concern > > > -- i.e. that a CT protocol _not_ be so limited that it could not handle > > > any of the conceivable timing scenarios implied. > > > > > > As such, it may be obvious, but it is also VERY MUCH a > > > requirement, and may sort out unsuitable protocol proposals which may > > > not have the flexibility required. > > > > I disagree with this, but this flexibility is exactly the point I'm bringing up. > > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT > > > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff > > does satisfy the requirement, since it 'may occur prior to, during or after', so why > > not pick after? Talk about sorting out unsuitable protocols... > > > > Cheers, > > > > Cedric. > > > > > > > > > > > > > > > Do you actually have anything against it, apart from it being > > > obvious? I for one am very happy to have this requirement plainly and > > > simply stated. > > > > > > Regards, > > > Henrik > > > > > > Cedric Westphal wrote: > > > > > > > > Pat Calhoun wrote: > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > > > Pat, > > > > > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > > > However... > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > > > during or after handoff, not because you require it, but because basic laws of > > > > > > physics. > > > > > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > > > requirement. > > > > > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > > > > > about the wording, except some worries about the use of the word 'mode'. > > > > Also, I like John's proposal in Issue 7, > > > > which if I understand it well, is to look at the requirements from the context point > > > > of view, and not from the protocol point of view. Basically, looking at the container > > > > first > > > > to design the crane, and not design a crane and see if the containers fit. > > > > > > > > Cheers, > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 09:09:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04301 for ; Thu, 16 Aug 2001 09:09:34 -0400 (EDT) Received: (qmail 17071 invoked by alias); 16 Aug 2001 12:56:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17065 invoked by uid 200); 16 Aug 2001 12:56:04 -0000 Received: (qmail 17060 invoked from network); 16 Aug 2001 12:56:02 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 12:56:02 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GD6np11738 for ; Thu, 16 Aug 2001 09:06:50 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 16 Aug 2001 09:06:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 09:06:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F02@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Cedric Westphal Cc: Pat Calhoun , seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 09:06:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12654.54457130" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12654.54457130 Content-Type: text/plain; charset="iso-8859-1" Rajeev: "to proceed" - sure enough. but for the record, CT before handoff is not necessarly proactive, it's just early... Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, August 15, 2001 10:37 PM > To: Cedric Westphal > Cc: Pat Calhoun; seamoby@cdma-2000.org > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > > > Cedric at al., > > I guess the purpose was not to disallow proactive or reactive > CT. In fact, having CT to > occur prior to, during and after handover allows for all the > possible cases. In the form > of a requirement, > > - when the MN arrives at the new AR, it must be possible for > the context(s) to be present > at the new AR > - when the MN arrives at the new AR, it must be possible to > perform CT when context(s) > is(are) not present in order to obtain them > > In my opinion, this would be enough to proceed on this > without getting into a rathole. > > Regards, > > -Rajeev > > > Cedric Westphal wrote: > > > Pat Calhoun wrote: > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > Pat, > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > However... > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > Serioulsy, removing the terminology is not the same > as removing the concept. > > > > > > > > > > As far as I can tell, proactive vs. reactive was > essentially stating when CT > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > ...what I state is that saying 'CT may happen prior to, > during or after handoff' > > > > is not a requirement, it is just stating the obvious. > CT must happen prior to, > > > > during or after handoff, not because you require it, > but because basic laws of > > > > physics. > > > > > > And most people felt that the pro/re text also didn't > reflect any requirements. > > > > > > > > > > > Stating whether or not CT could complete before or > after handoff is to me a > > > > requirement. > > > > > > So how would you propose changing the text so it reads as > an actualy requirement? > > > > Together with Gary, we did propose some text. I did not see > much objection on the list > > > > about the wording, except some worries about the use of the > word 'mode'. > > Also, I like John's proposal in Issue 7, > > which if I understand it well, is to look at the > requirements from the context point > > of view, and not from the protocol point of view. > Basically, looking at the container > > first > > to design the crane, and not design a crane and see if the > containers fit. > > > > Cheers, > > > > Cedric. > > > > > > > > > > > PatC > > ------_=_NextPart_001_01C12654.54457130 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

Rajeev:

  "to proceed" - sure enough.

  but for the record, CT before handoff is not necessarly
proactive, it's just early...

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Wednesday, August 15, 2001 10:37 PM
> To: Cedric Westphal
> Cc: Pat Calhoun; seamoby@cdma-2000.org
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
>
>
> Cedric at al.,
>
> I guess the purpose was not to disallow proactive or reactive
> CT. In fact, having CT to
> occur prior to, during and after handover allows for all the
> possible cases. In the form
> of a requirement,
>
> - when the MN arrives at the new AR, it must be possible for
> the context(s) to be present
> at the new AR
> - when the MN arrives at the new AR, it must be possible to
> perform CT when context(s)
> is(are) not present in  order to obtain them
>
> In my opinion, this would be enough to proceed on this
> without getting into a rathole.
>
> Regards,
>
> -Rajeev
>
>
> Cedric Westphal wrote:
>
> > Pat Calhoun wrote:
> >
> > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote:
> > > > Pat,
> > > >
> > > > thanks for the minutes. It seems it was indeed pretty intense.
> > > > However...
> > > >
> > > > Pat Calhoun wrote:
> > > >
> > > > > > Serioulsy, removing the terminology is not the same
> as removing the concept.
> > > > >
> > > > > As far as I can tell, proactive vs. reactive was
> essentially stating when CT
> > > > > would occur. This, as you state, is not a requirement,
> > > >
> > > > ...what I state is that saying 'CT may happen prior to,
> during or after handoff'
> > > > is not a requirement, it is just stating the obvious.
> CT must happen prior to,
> > > > during or after handoff, not because you require it,
> but because basic laws of
> > > > physics.
> > >
> > > And most people felt that the pro/re text also didn't
> reflect any requirements.
> > >
> > > >
> > > > Stating whether or not CT could complete before or
> after handoff is to me a
> > > > requirement.
> > >
> > > So how would you propose changing the text so it reads as
> an actualy requirement?
> >
> > Together with Gary, we did propose some text. I did not see
> much objection on the list
> >
> > about the wording, except some worries about the use of the
> word 'mode'.
> > Also, I like John's proposal in Issue 7,
> > which if I understand it well, is to look at the
> requirements from the context point
> > of view, and not from the protocol point of view.
> Basically, looking at the container
> > first
> > to design the crane, and not design a crane and see if the
> containers fit.
> >
> > Cheers,
> >
> > Cedric.
> >
> > >
> > >
> > > PatC
>
>

------_=_NextPart_001_01C12654.54457130-- From owner-seamoby@diameter.org Thu Aug 16 09:33:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05687 for ; Thu, 16 Aug 2001 09:33:18 -0400 (EDT) Received: (qmail 17706 invoked by alias); 16 Aug 2001 13:20:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17700 invoked by uid 200); 16 Aug 2001 13:20:24 -0000 Received: (qmail 17695 invoked from network); 16 Aug 2001 13:20:22 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 13:20:22 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 14:31:30 +0100 Message-ID: <3B7BCB2F.9FF0297B@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 14:31:27 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: seamoby@cdma-2000.org CC: Cedric Westphal , Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting References: <3B7BA235.C3C579A3@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ced/All, First just to comment that having done some work for the design of a proactive mobility framework, I can only see that at the end of the day the terminology will boil down to whatever people's taste sees fit as a term compliant with the timing intrinsincs of context transfer. However, I would like to argue in favor of the terms active, proactive and reactive, not because I have writen a draft about proactive mobility but because I have substantial reasons to believe that the terms are generic enough to encompass the entire time continuum of _any_ event (not just context transfer) As I said in the seamoby meeting the meaning of active (during), reactive (after) and proactive (before) depends first on the reader and really has got a fractal nature with respect to the magnitude of application of the notions since they really do not apply just to a mode of operation as people _erroneously_ consider. Much like a fractal they apply to a set of modes, or to an ontology of set of modes, or to a set of ontologies of sets of modes, etc...ad infinitum Just to exhibit the futility of the discussion on the matter and the fact that at the end of the day it is more who influences whom (everybody company hats on) rather what the terminology really reflects I will only cite the meaning of the terms PROACTIVE and REACTIVE from what else, the one and only source of objectivity which if we do not respect we might as well throw dictionaries away, deny authority of linguists, and identify a tech terminology anarchy where only the strongest (hello hats) survives I am not going to comment on what the oxford dictionary says because I expect people to be able to identify the etymology of the terms as supplied by the experts of linguistics, in the light of objectivity: http://dictionary.oed.com/cgi/entry/00189006?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-rrbDl0-705 Let us now visit the etymology of the word REACTIVE http://dictionary.oed.com/cgi/entry/00198331?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 Last but not least the word Active http://dictionary.oed.com/cgi/entry/00002214 I stress the multiplicity of meaning but stick to notions of 1.a, 3.b, 4.a, 5. People managed to stick to the terms the label 'mode'.... WHY did this happen? ..because it serves them better for the purposes of dissmissing the terms or is it because they have a narrow view of the world, or is it maybe because they do not really consider the real meaning of the terms? I wonder... A CT protocol MUST support at least one of these if it is expected to work in this time dimension As such to me the above means that: 'a CT protocol MUST support a minimum of at least one time class of event servicing with respect to mobility, that is active,reactive or proactive event servicing for the purposes of mobility aware context transfer' What are the events? I don't care (and why should I) it may be a handoff, it may the connection, it may be foobar. The above mean to me that the terms above describe accurately a 'requirement' with respect to the time period that context transfer comes in effect with respect to an EVENT. The terms are elegant and comprehensive as long as people know what they mean. Oxford English Dictionary attests to that... In that light the above terms do not need replacement really since they do describe accurately what they are supposed to. As such I personally provide a reason that what Cedric suggested augmenting the set of requirements with, is valid. It just becomes a matter of taste whether people want to name it something else, like 'during, before, after' which is more informal. That is not to say that I oppose to the validity of 'during,before,after'. It is to say that we have been fighting over synonyms really at a time when we already identified the right words. I would personaly like to stick to active,reactive,proactive for the reasons presented above. If people feel that the 'during,before,after' works better in their head then fair enough, but we just embark in yet another game of renaming things.. Regs. Theo UCL/ Mobile Systems Cedric Westphal wrote: > "A CT protocol SHALL support context transfer which can occur > before, during or after handover" > this is not the same as 'CT MAY occur prior to, during, after', and > that makes sense to me. > > Henrik Levkowetz wrote: > > > Cedric, > > > > Stating that a protocol SHALL support context transfer which > > can occur before, during or after handover blatantly eliminates your > > example which does it ONLY 2 days after handoff. > > > > Henrik > > > > > > > > Henrik, > > > > > > Henrik Levkowetz wrote: > > > > > > > Cedric, > > > > > > > > Johns proposal and wording was the first that cut trough > > > > the fog at the meeting, and met with overwhelming agreement because > > > > it stated very simply what seems to have been many people's concern > > > > -- i.e. that a CT protocol _not_ be so limited that it could not handle > > > > any of the conceivable timing scenarios implied. > > > > > > > > As such, it may be obvious, but it is also VERY MUCH a > > > > requirement, and may sort out unsuitable protocol proposals which may > > > > not have the flexibility required. > > > > > > I disagree with this, but this flexibility is exactly the point I'm bringing up. > > > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT > > > > > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff > > > does satisfy the requirement, since it 'may occur prior to, during or after', so why > > > not pick after? Talk about sorting out unsuitable protocols... > > > > > > Cheers, > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, apart from it being > > > > obvious? I for one am very happy to have this requirement plainly and > > > > simply stated. > > > > > > > > Regards, > > > > Henrik > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > > > > Pat, > > > > > > > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > > > > However... > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > > > > during or after handoff, not because you require it, but because basic laws of > > > > > > > physics. > > > > > > > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > > > > requirement. > > > > > > > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > > > > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > > > > > > > about the wording, except some worries about the use of the word 'mode'. > > > > > Also, I like John's proposal in Issue 7, > > > > > which if I understand it well, is to look at the requirements from the context point > > > > > of view, and not from the protocol point of view. Basically, looking at the container > > > > > first > > > > > to design the crane, and not design a crane and see if the containers fit. > > > > > > > > > > Cheers, > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC From owner-seamoby@diameter.org Thu Aug 16 10:13:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08265 for ; Thu, 16 Aug 2001 10:13:42 -0400 (EDT) Received: (qmail 18714 invoked by alias); 16 Aug 2001 13:55:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18708 invoked by uid 200); 16 Aug 2001 13:55:47 -0000 Received: (qmail 18702 invoked from network); 16 Aug 2001 13:55:43 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 13:55:43 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 15:07:13 +0100 Message-ID: <3B7BD38F.73ABD756@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 15:07:11 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: [seamoby] ACTIVE,PROACTIVE,REACTIVE et al. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit For the sake of completeness I provide the terms' etymology from Oxford English Dictionary as they are : This is to help people that do not have access to the online service, appreciate the argument better! OED Term Definitions: +++++++++++++++++REACTIVE++++++++++++++++++++++++++++ A. adj. 1. Repercussive, echoing. Obs.1 1712 BLACKMORE Creation 357 Ye fish, assume a voice, with praises fill The hollow rock, and loud reactive hill. 2. Acting or operative in return. 1794 G. ADAMS Nat. & Exp. Philos. III. xxi. 103 Every body that acts, is at the same instant both active and re~active. 1851 H. SPENCER Soc. Stat. 318 We have to consider, not only what is done for the afflicted, but what is the reactive effect upon those who do it. 3. Path. a. Supervening on a previous opposite state; due to reaction. Also reactive formation = reaction formation s.v. REACTION 5; reactive inhibition, the inhibiting effect of the supervention of fatigue or boredom on the response to a stimulus. 1822-34 Good's Study Med. (ed. 4) IV. 434 The patient..was not rendered faint by the re-active glow that ensued upon his quitting the water. 1885-8 PYE-SMITH Fagge's Princ. Med. I. 51 Such patients..sometimes pass into a condition of reactive pyrexia. 1925 J. STRACHEY tr. Freud's Case of Hysteria in Coll. Papers III. 67 Repression is often achieved by means of an excessive reinforcement of the thought contrary to the one which is to be repressed. This process I call reactive reinforcement. Ibid. 68 The thought which asserts itself exaggeratedly in consciousness and (in the same way as a prejudice) cannot be removed I call a reactive thought. 1943 C. L. HULL Princ. Behavior xviii. 327 Uniform time intervals between reinforcements great enough to prevent the accumulation of appreciable amounts of reactive inhibition. 1968 Globe & Mail (Toronto) 3 Feb. 11/6 These young people can join `negative identity' groups and become..therapeutically involved in extreme reactive kinds of activity. 1974 CHAPLIN & KRAWIEC Systems & Theories of Psychol. vii. 263 In and of itself fatigue will generate a form of inhibition which Hull calls reactive inhibition, and the animal will cease to respond. 1975 Way Suppl. No. 25. 67 Dynamic psychology might interpret this as evidence for reactive formation, which is a technical term suggesting that we control an unacceptable impulse by exaggerating the opposite tendency. 1977 G. H. SAGE Introd. Motor Behav. (ed. 2) xvi. 359 The first of these is an inhibition (reactive inhibition) caused by a reluctance to repeat a response. b. Recuperative; responsive (to a stimulus); characterized by reaction to a stimulus. 1822-34 Good's Study Med. (ed. 4) I. 704 There is no longer any rallying or reactive power remaining. 1896 Allbutt's Syst. Med. I. 193 These granules are feebly reactive to light. Ibid. 293 Delicate children, with little reactive power. 1927 C. SPEARMAN Abilities of Man iv. 47 Stern's division of persons into the `spontaneous' and the `merely reactive'. 1952 M. K. WILSON tr. Lorenz's King Solomon's Ring xi. 171 A few birdsusually old, strongly reactive ones take off, emitting `Kiaw' cries and thereby provoking the whole flock to leave the ground with them. c. Psychol. Of mental illness: thought to be caused by reaction to environmental stress; exogenous; so reactive schizophrenic, a person with reactive schizophrenia (cf. process schizophrenia s.v. PROCESS n. 13a). 1924 A. A. BRILL Bleuler's Textbk. Psychiatry xii. 537 Reactive depressions, which become aggravated to a mental disease, are quite rare in the light of present views. 1955 MCCARTHY & CORRIN Med. Treatment of Mental Dis. xix. 326 Reactive depressions are the mild, brief depressions, the result of situations depressing in themselves, and not out of proportion to circumstances. 1958 H. WEINER in L. Bellak Schizophrenia iv. 157 Whether such reactive psychoses actually imply a different series of etiologic contributing factors, i.e., `non-organic', is highly speculative. 1962 Lancet 10 Jan. 105/1 Two were middle-aged men with anxiety states... The third was a middle-aged lady with a reactive depression. 1962 Psychol. Bull. LIX. 329/1 Reactive schizophrenia indicates a good prognosis..with notable stress precipitating the psychosis. Ibid. 332/1 If the Rorschach diagnosis is followed, then it appears that reactive schizophrenics are not psychotic. 1965 J. POLLITT Depression & its Treatment 95 The terms `endogenous' and `reactive'..differentiate types of depression on the basis of presence or absence of an external cause. 1966 I. B. WEINER Psychodiagnosis in Schizophrenia vi. 94 A group of process schizophrenics made no more frequent errors than the reactive schizophrenics. 1971 Brit. Med. Bull. XXVII. 77/2 One school of thought..allocates such cases to a special category of `reactive psychoses'. 1974 M. C. GERALD Pharmacol. xvi. 310 When the cause of depression can be identified,..we term this reactive or exogenous depression. 1976 L. J. WEST et al. Treatment of Schizophrenia vi. 278 The good premorbid/bad premorbid, and process/reactive dimensions do seem to identify significant characteristics. 4. Characterized by reaction (sense 4). 1868 GLADSTONE Juv. Mundi i. (1870) 24 The reactive tendency to preserve the text by recurrence to a standard. 1890 Harper's Mag. June 77/1 He constantly inclined to reactive measures. 5. Chem. a. Readily susceptible to chemical reaction. 1888 Nature 22 Mar. 503/1 The unsaturated hydrocarbons..are..more reactive than the paraffins. 1942 G. WENDT Chem. vii. 179 As in the other families of elements we shall meet, the lightest of the groupin this case fluorineis the most reactive. 1957 G. E. HUTCHINSON Treat Limnol. I. xi. 708 It is not clear, however, in what form this reactive iron is actually present in the lake water. 1972 R. A. JACKSON Mechanism iv. 78 A trapping or inhibiting agent may be insufficiently reactive towards a particular intermediate to divert it from its normal course of reaction, or the agent may react in such a way as to regenerate another reactive intermediate. b. Of a process: involving chemical reaction. 1950 Chem. Abstr. XLIV. 8190 (heading) Reactive diffusion in metals. 1960 Ibid. LIV. 23646 The reactive diffusion in a system Nb-B is accomplished by diffusion of B atoms through the reaction products toward the metal. 1971 New Scientist 8 Apr. 96/1 Reactive evaporation..is often used for depositing metal oxides. 1973 R. L. BURWELL in Basolo & Burwell Catalysis II. 72 Ethylene is adsorbed by reactive adsorption. Perhaps it first adsorbs as a -complex and then reacts to monoadsorbed ethane. 1978 FELDER & ROUSSEAU Elem. Princ. Chem. Processes x. 384 In this chapter we show..how calculated enthalpies of reaction are incorporated in energy balances on reactive processes. c. Of a dye or other colouring material: designed to react chemically with the substrate, usu. in order to become fixed. 1957 Jrnl. Soc. Dyers & Colourists LXXIII. 238/2 The search for more practical methods of using reactive dyes has continued, and this work has now culminated in the production of a new range of dyesthe Procion (ICI) dyeswhich are water-soluble but contain a reactive group capable of combining with cellulose under alkaline conditions. 1973 Materials & Technol. VI. iv. 310 The direct, basic, sulphur, vat, azoic and reactive dyes are all suitable for colouring the fibre [sc. rayon]. a1977 Harrison Mayer Ltd. Catal. 39/1 Reactive colours, a new range of leadless colours for underglaze, on-glaze or in-glaze decoration... On firing, these colours react with the glaze to give interesting and variegated effects. d. Of coke or coal: having a high reactivity (sense b). 1963 Economist 21 Dec. 1284/1 Reconciling the clean air policy with the British love of open fires means trying to produce enough smokeless fuel of the sort that can be burnt in the fireplaces of smokeless zones. But the Minister of Power now estimates that there will be a gap..between the demand for such `reactive' smokeless fuels and the supply. 1974 Encycl. Brit. Macropædia IV. 783/2 Coals of medium rank are used for low-temperature carbonization because they yield reactive cokes. 6. a. Electr. Possessing or pertaining to electrical reactance; spec. applied to the vector component of an alternating current (or voltage) which is 90° out of phase with respect to the associated voltage (or current), i.e. wattless; reactive power, the product of the voltage and the reactive current, or of the current and the reactive voltage; reactive volt-ampere, a unit of reactive power. 1892 J. A. FLEMING Alternate Current Transformer II. ii. 269 Reactive Coil or Dimmer.This is a device used in alternating current work to serve the same ends as rheostats in direct current plants. 1892 S. P. THOMPSON Dynamo-Electr. Machinery (ed. 4) xxii. 628 We have here two electromotive-forces, the impressed O A and the reactive A E..with their resultant the effective electromotive-force O E, with an angle E O A..between them. 1914 J. H. MORECROFT Continuous & Alternating Current Machinery vi. 205 The component of voltage 90° out of phase with the current we shall call the reactive component of the voltage or reactive voltage. 1916 Standardization Rules Amer. Inst. Electr. Engineers 15 Reactive volt-amperes, the product of the reactive component of the voltage by the total current, or of the reactive component of the current by the total voltage. 1920 Whittaker's Electr. Engineers's Pocket-Bk. (ed. 4) 222 The reactive current changes from leading to lagging as the field excitation is reduced. 1951 W. SLUCKIN Princ. Alternating Currents ix. 225 In an induction motor, neglecting heating losses, the active component provides the useful mechanical power delivered by the motor, while the reactive component is associated with the production of the alternating magnetic field necessary for the operation of the motor. 1956 C. S. SISKIND Electr. Circuits xi. 265 The vertical componentthe quadrature componentis EI sin . The latter, acting adversely to lessen the power factor, is expressed as the reactive volt-amperes, abbreviated R-va. 1961 Listener 9 Nov. 768/2 There is also the problem, with direct current lines, of providing what is called the reactive powerpower where the current is out of step with the voltagefor the operation of converter equipment. 1970 J. EARL Tuners & Amplifiers iv. 83 The source itself can be mostly resistive or mostly reactive. 1978 Gramophone May 1958/1 It is claimed to have an output of 100 watts RMS working into an 8-ohm inductive or reactive load. b. Mech. and Acoustics. Possessing or pertaining to mechanical or acoustic impedance. 1934 OLSON & MASSA Applied Acoustics ii. 32 (caption) Resistive and reactive air load per unit area on one side of a vibrating piston of radius R centimeters set in an infinite baffle. 1963 [see IMPEDANCE 2]. 1976 A. H. BENADE Fund. of Musical Acoustics xxi. 457/2 The other register hole on my special clarinet can be called a reactive register hole, i.e., an aperture in which the flow depends mainly on the inertia of the air moving through it. 7. Gram. (See quot.) rare. 1957 R. W. ZANDVOORT Handbk. Eng. Gram. V. ii. 224 To express the speaker's reaction to a previous statement by the person addressed which is repeated by the speaker (reactive questions)... You can't catch me.I can't, can't I? said Philip. B. n. Chem. [ad. F. réactif.] A reagent. rare. [1790 Monthly Rev. III. 546 Chemical tests, or, as the French call them, reactives.] 1791 HAMILTON Berthollet's Dyeing I. I. II. iv. 192 A chemist should be employed for preparing a proper reactive. 1887 BROWNING Parleyings, C. Avison ix, Reviewing learnedly the list complete Of chemical reactives. Hence reactively adv. So reactiveness (Webster 1847) = next. 1805 FOSTER Ess. I. ii. 30 The living world..is re-actively throwing on him various moral influences and infections. 1860 A. L. WINDSOR Ethica v. 285 A very irritable temper, that bore him reactively into close relationship with a few. ++++++++++++ PROACTIVE ++++++++++++++++++++++ Of a person, policy, etc.: that creates or controls a situation by taking the initiative or by anticipating events (as opp. to responding to them); also loosely, innovative, tending to make things happen. (Freq. in management or business contexts.) 1971 A. J. R. REISS Police & Public ii. 64 Citizens usually bring matters to police attention...The police department deals with such requests as a reactive organization...The police also acquire information by intervening in the lives of citizens on their own initiative. In this capacity, they serve as a proactive organization. 1977 D. M. SMITH Human Geogr. xi. 327 By comparing conditions before and after the change in the five reactive, control, and proactive [sc. police] beats, the effectiveness of this strategy could be judged. 1980 W. SAFIRE in N.Y. Times Mag. 2 Mar. 9/2 Webster says he has been forced to choose between `reactive' law enforcementresponding after a bank has been robbedand `pro-active' enforcement, in which his men are in on the planning stages of a crime. 1984 Financial Times 10 Feb. 26 A new kind of management able to take risks,..manage change, and be more proactive. 1985 Globe & Mail (Toronto) 10 Oct. B20/1 (Advt.), If you are the proactive and innovative individual we are looking for..we invite you to submit a resume in confidence. Hence proactively adv.; proaction, proactivity, proactive behaviour or practice. Also [as back-formation] proact v. intr., to take proactive measures; to act in advance, to anticipate. 1978 J. ALDERSON Communal Policing p. i, The education of a community and a police force in joint pro-activity was seen as the only way to reduce morbidity of crime levels. 1980 Times 3 Nov. 16/3 We anticipate, we plan, we pro-act rather than react to change. 1984 N.Y. Times 14 Oct. XI. 30/5 Determinate sentencing, as an alternative to parole, forces the system to wait for the smoking gun, rather than proactively intervene before another terrible tragedy. 1985 R. C. A. WHITE Admin. of Justice IV. xiv. 256 A distinction which separates the practice of law in law centres from that in private practice is that between reactivity and proactivity. 1986 Mag. Bank Admin. June 41/1 Aggressiveness, proaction or other performance criteria are paramount. 1986 Industry Week 23 June 52/1 This versatility is allowing us to proact rather than react to changing market conditions. ++++++++++++++++++++++++++++++ ACTIVE ++++++++++++++++++++++++++ gen. Characterized by action. Hence A. adj. 1. a. Opposed to contemplative or speculative: Given to outward action rather than inward contemplation or speculation; practical; esp. with `life.' (Also formerly absol. in pl. sc. virtues, faculties.) 1340 Ayenb. 199 Holy writ ous tek tuo maneres of liue..e verste is yhote workvol [active] vor et hi is ine zuynch of guode workes. 1340 HAMPOLE Prose Tr. 24 Vnto thes men itt longith som tyme to vsene werkis of mercy in actife liffe. 1362 LANGL. P. Pl. A VII. 236 Actyf lyf or contemplatyf · Crist wolde hit alse. c1400 Apol. for Loll. 23 Also ei tokun actifis & contemplatifis; at sterun to vertewe be er two maneris. 1401 Pol. Poems II. 63 There is maad mencion of two perfit lyves, that actif and contemplatif comounli ben callid, ffulli figurid by Marie and Martha hir sister. 1538 STARKEY England 4 But wether hyt [i.e. perfection] stond in the actyve lyfe.. or els in the contemplative..hyt ys not al sure. 1604 SHAKES. Oth. I. iii. 271 My speculative and active [1623 offic'd] instruments. 1609 TOURNEUR Fun. Poeme 355 All his industries (As well in actives as contemplatives). 1660 T. STANLEY Hist. Philos. (1701) 161/1 Philosophy concerns either action or contemplation (thence assuming two names, Contemplative and Active) the Active consisting in practice of moral Actions, the Contemplative, in penetration of abstruse Phisical causes, and the nature of the Divinity. 1828 D. STEWART Wks. VI. 122 As the operations in the minds of other men escape our notice we can judge of their activity only from the sensible effects it produces; thence we are led to apply the character of activity to those whose bodily activity is the most remarkable, and to distinguish mankind into two classes, the Active and the Speculative. b. Practical, as opposed to theoretical. Obs. 1609 DOULAND Orinth. Microl. 2 Active Musicke, which also they call Practick, is..the knowledge of singing well. 2. Opposed to passive: Originating or communicating action, exerting action upon others; acting of its own accord, spontaneous. In 17th c. often absol. in pl. sc. qualities, forces. c1400 Apol. for Loll. 14 God may not autorise at actyfe cursyng..But passyue cursyng..is just. 1413 LYDGATE Pylg. Sowle II. lx. (1859) 57 Quod the body..thou were in me actyf as fire is in the wood, and I in to the passyf as woode is in the fyre. 1477 NORTON Ordin. Alch. v. (Ashmole 1652) 54 Heate, and Cold, be qualities Active, Moisture, and Drines, be qualityes Passive. 1592 W. WEST Symbolæogr. I. 48G. The actiue person in Instrumentes is he which maketh the Instruments. 1677 HALE Prim. Orig. Man. IV. v. 332 If it should be in the power of an Angel by applying actives to passives to produce an Insect. 1736 BUTLER Analogy I. v. 117 Perception of danger is a natural Excitement of passive fear and active caution. 1846 MILL Logic III. iii. §9 (1868) 292 Objects which they first believed to be intelligent and active are really lifeless and passive. 1876 FREEMAN Norm. Conq. II. x. 492 The treasons of Eadwine were often passive rather than active. 3. Grammar. a. properly, An epithet of Voice in verbs used transitively; opposed to Passive (and, in some languages, to Reflexive or Middle). That form of the verb in which the action asserted by it is viewed as a characteristic or attribute of the thing whence it issues, as opposed to the Passive Voice in which the action is viewed as an attribute of the thing towards which it is directed; or, that form of the verb in which the logical subject of the action is made by the speaker the grammatical subject of his assertion, as shown by the verb's agreement with it in inflections, by position, or otherwise. This being (in Aryan Languages) the simple or original form, verbs used intransitively naturally have no other, and are said to have the Active Voice only. b. Less correctly, said of verbs themselves; in two senses. 1. Applied to verbs which assert that the subject acts upon or affects something else, as distinguished from Passive Verbs, or such as assert of the subject that it is acted on by something or suffers the action, and Neuter Verbs which assert an action or state that has neither character. 2. Applied to all verbs that assert action as distinct from mere existence or state; in this sense Active Verbs are divided into Active Transitive, in which the action passes over to or affects an object, as kill (corresponding to the Active of 1), and Active Intransitive, in which the action does not affect an object, as rise (forming part of the Neuter verbs of 1), Neuter in this nomenclature being restricted to verbs of existence or state, as be, sit. Both of these uses of the word are etymologically defensible, but both are inconvenient: the distinction between action and state is not always clear, and above all is one of things, not of assertions about them; that of action and passion is merely that of two ways of viewing and asserting the same action; while the passing over of an action to an object or the contrary is better expressed by Transitive and Intransitive, and is moreover not a division of verbs, but of the constructions of each verb separately, the great majority of verbs in Eng. having both constructions. 1530 PALSGR. 4 The thyrde parsonnes plurelles of verbes actyves in the frenche tonge..ende in ent. 1591 PERCIVALL Span. Dict. Cb, Of Uerbs personals there be three kinds, Actiue, Passiue and Neuter. 1765 W. WARD Ess. Gram. 59, A verb in the active voice very frequently denotes a state which implies no real action, as for instance to suffer; and so, a verb in the passive voice frequently denotes a state which implies no real suffering, as to be found. 1876 MASON Eng. Gram. 59 We may speak of one and the same action by means either of a verb in the active voice, or of a verb in the passive voice. 4. a. Opposed to quiescent or extinct: Existing in action, working, effective, having practical operation or results. active list (see LIST n.6); also transf.; active service, war service in the field, at sea, or in the air. 1640-4 CAPT. MERVIN in Rushworth Hist. Coll. III. (1692) I. 214 The Gray-headed Common Laws Funeral; and the Active Statutes death and Obsequies. 1790 BOSWELL Johnson xxiv. (Rtldg.) 215 Here was one of the many, many instances of his active benevolence. 1790 BURKE Fr. Rev. 39 The whole government would be under the constant inspection and active controul of the popular representative and of the magnates of the kingdom. 1829 [see SERVICE n.1 12]. 1830 LYELL Princ. Geol. I. 317 Kamtschatka, where there are seven active volcanos. 1838 Navy List 20 Sept. 118 Alphabetical List of Masters. Those in Italics are unfit for active Service. 1852 Ibid. 20 Dec. 327 The number of Captains on the Active List will be reduced to a number not permanently exceeding 350. 1857 LIVINGSTONE Travels vi. 113 It contains an active poison. 1876 FREEMAN Norm. Conq. II. vii. 102 Weary of tarrying where there was no chance of active service. 1878 HUXLEY Physiogr. 79 It is the oxygen which is the active agent. 1899 KIPLING Absent-Minded Beggar i, He is out on active service, wiping something off a slate. 1906 Harmsworth Encycl. VII. 576/2 No officer on the active list is allowed to leave the United Kingdom without special permission. 1907 Jrnl. Soc. Arts LV. 429/1 Of these only the Remington and the Hammond are to-day on the active list. b. spec. in Physics, = RADIOACTIVE a. 1900 RUTHERFORD in Phil. Mag. XLIX. 163 The top layer of paper over the thorium was found to be active on its upper side. 1905 [see active deposit]. 1938 R. W. LAWSON tr. Hevesy & Paneth's Man. Radioactivity (ed. 2) x. 120 Active isotopes that are lighter than the stable types disintegrate with emission of positrons. 5. Opposed to sluggish or inert: Abounding in action; energetic, lively, agile, nimble; diligent, busy, brisk. (Of persons and things.) 1597 SHAKES. 2 Hen. IV, IV. iii. 24, I were simply the most actiue fellow in Europe. 1609 Man in the Moone (1849) 31 It maketh her unfitte to performe any agill or active thing. 1666 PEPYS Diary (1879) III. 485 He being the activest man in the World. 1718 POPE Iliad xv. 683 So strong to fight, so active to pursue. 1786 COWPER Lett. 31 Jan. Wks. 1876 224 Infirmities..which make him less active than he was. 1857 BUCKLE Civil. iii. 142 Now, the richest Countries are those in which man is most active. 1863 FAWCETT Pol. Econ. III. vi. 371 An active demand for any other commodity is characterised by a rise in its price or value. 1866 ROGERS Agric. & Prices I. xxiii. 599 The most active seat of the trade. 1880 Manch. Guardian 16 Dec. 4/4 The market to-day has been more active than for a considerable time. 6. On the credit side of the balance-sheet, of the nature of an asset; as opposed to passive, i.e. of the nature of a liability. (Common in Fr., but hardly English.) 1875 POSTE Gaius III. 350 Selling the active and passive universality of the insolvent's estate..to a purchaser who became liable to the insolvent's creditors. 7. Used as the first element in such obv. Comb. as active-bodied, active-limbed, active-minded. 1870 BRYANT Homer I. v. 152 There the active-limbed, Fleet Iris stayed them. 1837 WHEWELL Induct. Sc. (1857) I. 121 The pleasure which..active-minded men feel in exercising the process of deduction. 1878 SEELEY Stein III. 547 The more active-minded among his contemporaries. 8. Comb. active carbon, charcoal = activated carbon, charcoal (see ACTIVATE v. b); active current Electr. (see quot. 1926); active deposit Physics (see quot. 1955); active layer Geomorphol., a surface layer of soil, overlying permafrost, that freezes in winter and thaws in summer; active mass Chem., the molecular concentration of a substance (see mass-action (b) s.v. MASS n.2). 1918 Jrnl. Industr. & Engin. Chem. X. 813/2 If our object is to make an active carbon, none of the mineral matter must be removed before heating. 1921 Jrnl. Soc. Chem. Industry XL. (Trans.) 231/1 All the secret process active carbons come upon the market in the form of a fine powder. 1938 Thorpe's Dict. Appl. Chem. II. 319/2 Active charcoal is widely used in industry for the recovery of valuable products which exist as attenuated vapours in unadsorbable gases. 1924 S. R. ROGET Dict. Electr. Terms 2 Active current. 1926 Gloss. Terms Electr. Engin. (B.S.I.) 30 Active current, that component of an alternating current (regarded as a vector quantity) which is in phase with the voltage. 1905 RUTHERFORD in Phil. Trans. R. Soc. 1904 A. CCIV. 172 In speaking generally of the active matter, which causes excited activity, without regard to its constituents, I have used the term `active deposit'. 1906 Radioactive Transformations iv. 95 All bodies surrounded by the radium emanation become coated with an invisible active deposit, possessing physical and chemical properties which sharply distinguish it from the emanation. 1955 Gloss. Terms Radiology (B.S.I.) 6 Active deposit, solid radioactive deposit formed by the decay of a radioactive emanation. 1943 S. W. MULLER Permafrost 5 Above the permafrost is a layer of ground that thaws in the summer and freezes again in the winter. This layer represents the seasonally frozen ground and is called the active layer. 1977 A. HALLAM Planet Earth 89 The churning of the active layer by freezing and thawing prevents the development of a stable soil structure. 1909 Cent. Dict. Suppl., Active mass. 1910 Encycl. Brit. VII. 27/1 These spatial concentrations are often called the `active masses' of the reacting components. 1932 PHILBRICK & HOLMYARD Text Bk. Theoret. & Inorg. Chem. II. iii. 110 This law was first enunciated in 1864 [in Forhandl. i Vidensk.-Selsk. i Christiania, p. 92] by Guldberg and Waage, who stated that the rate at which a substance reacted was proportional to its active mass. B. n. 1. A person devoted to the active life. (Cf. adj. 1 and CONTEMPLATIVE n. 1.) c1380 [see CONTEMPLATIVE B. n. 1]. a1425 Cloud of Unknowing (1944) 5/18 Into is day alle actyues pleynen hem of contemplatyues, as Martha did on Mary. 1671 PHILLIPS New World of Words, Actifs, an order of Fryars, that feed on Roots, and wear tawny habits. 1946 E. A. PEERS Fool of Love vii. 118 It is as an active that Ramon [Lull] appeals to the present age most widely. 1950 A. HUXLEY Themes & Variations 154 Were there not then, as always, a few ardent contemplatives and actives? 2. [Elliptical uses of the adj.] a. See ACTIVE a. 1, 2. b. Gram. The active voice; an active verb. Cf. PASSIVE n. 2. 1530 PALSGR. Introd., The actyves have but the pronowne or substantyve before the verbe. 1582 G. MARTIN Discoverie Manifold Corruptions i. 13 If passives must be turned into actives, and actives into passives, participles disagree in case from their substantives..: who would so presume in the text of holy Scripture, to haue al grammar..at his commaundement, but Beza & his lik? 1611 BRINSLEY Pos. Parts. (1669) 29 Cannot a Verb Neuter take r, to make it a Passive, as Actives do? c1620 A. HUME Orthogr. Brit. Tongue (1865) 32 Verbes of doing are actives or passives. The active verb adheres to the person of the agent; as, Christ hath conquered hel and death. 1669 MILTON Accedence 20 The Active Signifieth to do, and always endeth in o, as Doceo, I teach. 1818 E. V. BLOMFIELD tr. Matthiæ's Gr. Gram. II. 710 The effect of the active consists in determining the case which it governs. 1879 W. W. GOODWIN Elem. Greek Gram. (new ed.) 110 The uncontracted forms of the future active and middle of ..are found in Homer and Herodotus. 1933 O. JESPERSEN Essent. Eng. Gram. xii. 121 The subject of a passive verb is what in the active would be an object. But if in the active there are two objects, only one of them can be made the subject. 1973 N. S. SMITH tr. Ruwet's Introd. Generative Gram. vi. 114 This solution..still does not allow the formal indication of the relation between the passive (3) and the active (4). 1985 R. QUIRK et al. Comprehensive Gram. Eng. Lang. 163 In English, prepositional verbs..can often occur in the passive, but not so freely as in the active. Regs. Theo UCL/Mobile Systems From owner-seamoby@diameter.org Thu Aug 16 10:24:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08956 for ; Thu, 16 Aug 2001 10:24:34 -0400 (EDT) Received: (qmail 19188 invoked by alias); 16 Aug 2001 14:07:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19182 invoked by uid 200); 16 Aug 2001 14:07:34 -0000 Received: (qmail 19171 invoked by uid 500); 16 Aug 2001 14:07:27 -0000 Date: Thu, 16 Aug 2001 07:07:26 -0700 From: Pat Calhoun To: Cedric Westphal Cc: Rajeev Koodli , Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816070726.A18988@charizard.diameter.org> Mail-Followup-To: Cedric Westphal , Rajeev Koodli , Pat Calhoun , seamoby@cdma-2000.org References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> <20010815084105.A3622@charizard.diameter.org> <3B7AAA15.9BEF4D83@iprg.nokia.com> <3B7B778D.9FA2C53C@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7B778D.9FA2C53C@iprg.nokia.com>; from cedric@IPRG.nokia.com on Thu, Aug 16, 2001 at 12:34:37AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > this I totally agree with. I am concerned the proposed text does not reflect this though. > But I hear where you guys at the meeting come from. Maybe an 'AND' instead of an 'OR': > "CT may occur prior to, during AND after handoff" and let's move on. > Take care, This I can live with. PatC From owner-seamoby@diameter.org Thu Aug 16 10:38:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09818 for ; Thu, 16 Aug 2001 10:37:58 -0400 (EDT) Received: (qmail 19953 invoked by alias); 16 Aug 2001 14:24:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19947 invoked by uid 200); 16 Aug 2001 14:24:46 -0000 Received: (qmail 19939 invoked by uid 500); 16 Aug 2001 14:24:43 -0000 Date: Thu, 16 Aug 2001 07:24:43 -0700 From: Pat Calhoun To: Theo Pagtzis Cc: seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816072443.D18988@charizard.diameter.org> Mail-Followup-To: Theo Pagtzis , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz References: <3B7BA235.C3C579A3@iprg.nokia.com> <3B7BCB2F.9FF0297B@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7BCB2F.9FF0297B@cs.ucl.ac.uk>; from T.Pagtzis@cs.ucl.ac.uk on Thu, Aug 16, 2001 at 02:31:27PM +0100 Sender: owner-seamoby@diameter.org Precedence: bulk Theo, My problem wasn't the terms active,proactive,reactive, but the rather long text accompanying the terms, which caused nothing but confusion and would open up cans of worms. I find John's proposal to be short and to the point. If you think that something along the lines of: "Context Transfer MAY occur before (proactive), during (active) and after (reactive) a handoff." would be more acceptable since it keeps the terminology in place, I wouldn't be against it, and would welcome comments. PatC On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote: > Ced/All, > > First just to comment that having done some work for the design of a proactive mobility > framework, I can only see that > at the end of the day the terminology will boil down to whatever people's taste sees fit as a term > compliant with the timing intrinsincs of context transfer. > > However, I would like to argue in favor of the terms active, proactive and reactive, not because I > have writen a draft about proactive mobility but because I have substantial reasons to believe that > the terms are generic enough to encompass the entire time continuum of _any_ event (not just > context transfer) > > As I said in the seamoby meeting the meaning of active (during), reactive (after) and proactive > (before) depends first on the reader and really has got a fractal nature with respect to the > magnitude of > application of the notions since they really do not apply just to a mode of operation as people > _erroneously_ consider. Much like a fractal they apply to a set of modes, or to an ontology of set > of modes, or to a set of ontologies of sets of modes, etc...ad infinitum > > Just to exhibit the futility of the discussion on the matter and the fact that at the end of the > day it is more who influences whom (everybody company hats on) rather what the terminology really > reflects I will only cite the meaning of the terms PROACTIVE and REACTIVE from what else, the one > and only source of objectivity which if we do not respect we might as well throw dictionaries away, > deny authority of linguists, and identify a tech terminology anarchy where only the strongest > (hello hats) survives > > I am not going to comment on what the oxford dictionary says because I expect people to be able to > identify the etymology of the terms as supplied by the experts of linguistics, in the light of > objectivity: > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-rrbDl0-705 > > Let us now visit the etymology of the word REACTIVE > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 > > Last but not least the word Active > > http://dictionary.oed.com/cgi/entry/00002214 > > I stress the multiplicity of meaning but stick to notions of 1.a, 3.b, 4.a, 5. > > People managed to stick to the terms the label 'mode'.... WHY did this happen? ..because it serves > them better for the purposes of dissmissing the terms or is it because they have a narrow view of > the world, or is it maybe because they do not really consider the real meaning of the terms? I > wonder... > > A CT protocol MUST support at least one of these if it is expected to work in this time dimension > > As such to me the above means that: > > 'a CT protocol MUST support a minimum of at least one time class of event servicing with respect to > mobility, that is active,reactive or proactive event servicing for the purposes of mobility aware > context transfer' > > What are the events? I don't care (and why should I) it may be a handoff, it may the connection, it > may be foobar. > > The above mean to me that the terms above describe accurately a 'requirement' with respect to the > time period that context transfer comes in effect with respect to an EVENT. The terms are elegant > and comprehensive as long as people know what they mean. Oxford English Dictionary attests to > that... > > In that light the above terms do not need replacement really since they do describe accurately what > they are supposed to. As such I personally provide a reason that what Cedric suggested augmenting > the set of requirements with, is valid. It just becomes a matter of taste whether people want to > name it something else, like 'during, before, after' which is more informal. > > That is not to say that I oppose to the validity of 'during,before,after'. It is to say that we > have been fighting over synonyms really at a time when we already > identified the right words. > > I would personaly like to stick to active,reactive,proactive for the reasons presented above. If > people feel that the 'during,before,after' works better in their head then fair enough, but we just > embark in yet another game of renaming things.. > > Regs. > > Theo > > UCL/ Mobile Systems > > > > > Cedric Westphal wrote: > > > "A CT protocol SHALL support context transfer which can occur > > before, during or after handover" > > this is not the same as 'CT MAY occur prior to, during, after', and > > that makes sense to me. > > > > Henrik Levkowetz wrote: > > > > > Cedric, > > > > > > Stating that a protocol SHALL support context transfer which > > > can occur before, during or after handover blatantly eliminates your > > > example which does it ONLY 2 days after handoff. > > > > > > Henrik > > > > > > > > > > > Henrik, > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > Cedric, > > > > > > > > > > Johns proposal and wording was the first that cut trough > > > > > the fog at the meeting, and met with overwhelming agreement because > > > > > it stated very simply what seems to have been many people's concern > > > > > -- i.e. that a CT protocol _not_ be so limited that it could not handle > > > > > any of the conceivable timing scenarios implied. > > > > > > > > > > As such, it may be obvious, but it is also VERY MUCH a > > > > > requirement, and may sort out unsuitable protocol proposals which may > > > > > not have the flexibility required. > > > > > > > > I disagree with this, but this flexibility is exactly the point I'm bringing up. > > > > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT > > > > > > > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff > > > > does satisfy the requirement, since it 'may occur prior to, during or after', so why > > > > not pick after? Talk about sorting out unsuitable protocols... > > > > > > > > Cheers, > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, apart from it being > > > > > obvious? I for one am very happy to have this requirement plainly and > > > > > simply stated. > > > > > > > > > > Regards, > > > > > Henrik > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > > > > > Pat, > > > > > > > > > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > > > > > However... > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > > > > > during or after handoff, not because you require it, but because basic laws of > > > > > > > > physics. > > > > > > > > > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > > > > > requirement. > > > > > > > > > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > > > > > > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > > > > > > > > > about the wording, except some worries about the use of the word 'mode'. > > > > > > Also, I like John's proposal in Issue 7, > > > > > > which if I understand it well, is to look at the requirements from the context point > > > > > > of view, and not from the protocol point of view. Basically, looking at the container > > > > > > first > > > > > > to design the crane, and not design a crane and see if the containers fit. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC > From owner-seamoby@diameter.org Thu Aug 16 11:28:27 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12860 for ; Thu, 16 Aug 2001 11:28:05 -0400 (EDT) Received: (qmail 20673 invoked by alias); 16 Aug 2001 15:12:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20667 invoked by uid 200); 16 Aug 2001 15:12:01 -0000 Received: (qmail 20661 invoked from network); 16 Aug 2001 15:11:57 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 15:11:57 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 16:23:31 +0100 Message-ID: <3B7BE571.7CF71DC1@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 16:23:29 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting References: <3B7BA235.C3C579A3@iprg.nokia.com> <3B7BCB2F.9FF0297B@cs.ucl.ac.uk> <20010816072443.D18988@charizard.diameter.org> Content-Type: multipart/alternative; boundary="------------9CE8EC6C2A3AE08833C567E3" Sender: owner-seamoby@diameter.org Precedence: bulk --------------9CE8EC6C2A3AE08833C567E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol. However, I have one question: is it possible that it can happen proactively (before) AND reactively (after) at the same time? Aren't these time event a bit mutually exclusive or at best OR-inclusive? What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that... This includes also the possibility of including multi-phasic CT as Gary suggested, simply because OR may include PRO,RE or simply active individually or any combination of them together, which IMHO is also very important. What we do not want though is have a need for A _and_ B.. combinatorially this is restrictive.. Rgs. Theo UCL/ Mobile System Pat Calhoun wrote: > Theo, > > My problem wasn't the terms active,proactive,reactive, but the rather long text > accompanying the terms, which caused nothing but confusion and would open up > cans of worms. I find John's proposal to be short and to the point. > > If you think that something along the lines of: > > "Context Transfer MAY occur before (proactive), during (active) and after (reactive) > a handoff." > > would be more acceptable since it keeps the terminology in place, I wouldn't be > against it, and would welcome comments. > > PatC > On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote: > > Ced/All, > > > > First just to comment that having done some work for the design of a proactive mobility > > framework, I can only see that > > at the end of the day the terminology will boil down to whatever people's taste sees fit as a term > > compliant with the timing intrinsincs of context transfer. > > > > However, I would like to argue in favor of the terms active, proactive and reactive, not because I > > have writen a draft about proactive mobility but because I have substantial reasons to believe that > > the terms are generic enough to encompass the entire time continuum of _any_ event (not just > > context transfer) > > > > As I said in the seamoby meeting the meaning of active (during), reactive (after) and proactive > > (before) depends first on the reader and really has got a fractal nature with respect to the > > magnitude of > > application of the notions since they really do not apply just to a mode of operation as people > > _erroneously_ consider. Much like a fractal they apply to a set of modes, or to an ontology of set > > of modes, or to a set of ontologies of sets of modes, etc...ad infinitum > > > > Just to exhibit the futility of the discussion on the matter and the fact that at the end of the > > day it is more who influences whom (everybody company hats on) rather what the terminology really > > reflects I will only cite the meaning of the terms PROACTIVE and REACTIVE from what else, the one > > and only source of objectivity which if we do not respect we might as well throw dictionaries away, > > deny authority of linguists, and identify a tech terminology anarchy where only the strongest > > (hello hats) survives > > > > I am not going to comment on what the oxford dictionary says because I expect people to be able to > > identify the etymology of the terms as supplied by the experts of linguistics, in the light of > > objectivity: > > > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-rrbDl0-705 > > > > Let us now visit the etymology of the word REACTIVE > > > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha > > > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 > > > > Last but not least the word Active > > > > http://dictionary.oed.com/cgi/entry/00002214 > > > > I stress the multiplicity of meaning but stick to notions of 1.a, 3.b, 4.a, 5. > > > > People managed to stick to the terms the label 'mode'.... WHY did this happen? ..because it serves > > them better for the purposes of dissmissing the terms or is it because they have a narrow view of > > the world, or is it maybe because they do not really consider the real meaning of the terms? I > > wonder... > > > > A CT protocol MUST support at least one of these if it is expected to work in this time dimension > > > > As such to me the above means that: > > > > 'a CT protocol MUST support a minimum of at least one time class of event servicing with respect to > > mobility, that is active,reactive or proactive event servicing for the purposes of mobility aware > > context transfer' > > > > What are the events? I don't care (and why should I) it may be a handoff, it may the connection, it > > may be foobar. > > > > The above mean to me that the terms above describe accurately a 'requirement' with respect to the > > time period that context transfer comes in effect with respect to an EVENT. The terms are elegant > > and comprehensive as long as people know what they mean. Oxford English Dictionary attests to > > that... > > > > In that light the above terms do not need replacement really since they do describe accurately what > > they are supposed to. As such I personally provide a reason that what Cedric suggested augmenting > > the set of requirements with, is valid. It just becomes a matter of taste whether people want to > > name it something else, like 'during, before, after' which is more informal. > > > > That is not to say that I oppose to the validity of 'during,before,after'. It is to say that we > > have been fighting over synonyms really at a time when we already > > identified the right words. > > > > I would personaly like to stick to active,reactive,proactive for the reasons presented above. If > > people feel that the 'during,before,after' works better in their head then fair enough, but we just > > embark in yet another game of renaming things.. > > > > Regs. > > > > Theo > > > > UCL/ Mobile Systems > > > > > > > > > > Cedric Westphal wrote: > > > > > "A CT protocol SHALL support context transfer which can occur > > > before, during or after handover" > > > this is not the same as 'CT MAY occur prior to, during, after', and > > > that makes sense to me. > > > > > > Henrik Levkowetz wrote: > > > > > > > Cedric, > > > > > > > > Stating that a protocol SHALL support context transfer which > > > > can occur before, during or after handover blatantly eliminates your > > > > example which does it ONLY 2 days after handoff. > > > > > > > > Henrik > > > > > > > > > > > > > > Henrik, > > > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > > > Cedric, > > > > > > > > > > > > Johns proposal and wording was the first that cut trough > > > > > > the fog at the meeting, and met with overwhelming agreement because > > > > > > it stated very simply what seems to have been many people's concern > > > > > > -- i.e. that a CT protocol _not_ be so limited that it could not handle > > > > > > any of the conceivable timing scenarios implied. > > > > > > > > > > > > As such, it may be obvious, but it is also VERY MUCH a > > > > > > requirement, and may sort out unsuitable protocol proposals which may > > > > > > not have the flexibility required. > > > > > > > > > > I disagree with this, but this flexibility is exactly the point I'm bringing up. > > > > > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT > > > > > > > > > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff > > > > > does satisfy the requirement, since it 'may occur prior to, during or after', so why > > > > > not pick after? Talk about sorting out unsuitable protocols... > > > > > > > > > > Cheers, > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, apart from it being > > > > > > obvious? I for one am very happy to have this requirement plainly and > > > > > > simply stated. > > > > > > > > > > > > Regards, > > > > > > Henrik > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote: > > > > > > > > > Pat, > > > > > > > > > > > > > > > > > > thanks for the minutes. It seems it was indeed pretty intense. > > > > > > > > > However... > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept. > > > > > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT > > > > > > > > > > would occur. This, as you state, is not a requirement, > > > > > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff' > > > > > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to, > > > > > > > > > during or after handoff, not because you require it, but because basic laws of > > > > > > > > > physics. > > > > > > > > > > > > > > > > And most people felt that the pro/re text also didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete before or after handoff is to me a > > > > > > > > > requirement. > > > > > > > > > > > > > > > > So how would you propose changing the text so it reads as an actualy requirement? > > > > > > > > > > > > > > Together with Gary, we did propose some text. I did not see much objection on the list > > > > > > > > > > > > > > about the wording, except some worries about the use of the word 'mode'. > > > > > > > Also, I like John's proposal in Issue 7, > > > > > > > which if I understand it well, is to look at the requirements from the context point > > > > > > > of view, and not from the protocol point of view. Basically, looking at the container > > > > > > > first > > > > > > > to design the crane, and not design a crane and see if the containers fit. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC > > --------------9CE8EC6C2A3AE08833C567E3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol.

However, I have one question:

is it possible that it can happen proactively (before) AND reactively (after) at the same time?
Aren't these time event a bit mutually exclusive or at best OR-inclusive?

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that...

This includes also the possibility of including multi-phasic CT as Gary suggested, simply because OR may include PRO,RE or simply active individually or any
combination of them together, which IMHO is also very important.

What we do not want though is have a need for A  _and_  B.. combinatorially this is restrictive..
 

Rgs.

Theo

UCL/ Mobile System
Pat Calhoun wrote:

Theo,

My problem wasn't the terms active,proactive,reactive, but the rather long text
accompanying the terms, which caused nothing but confusion and would open up
cans of worms. I find John's proposal to be short and to the point.

If you think that something along the lines of:

"Context Transfer MAY occur before (proactive), during (active) and after (reactive)
a handoff."

would be more acceptable since it keeps the terminology in place, I wouldn't be
against it, and would welcome comments.

PatC
On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote:
> Ced/All,
>
>    First just to comment that having done some work for the design of a proactive mobility
> framework, I can only see that
> at the end of the day the terminology will boil down to whatever people's taste sees fit as a term
> compliant with the timing intrinsincs of context transfer.
>
> However, I would like to argue in favor of the terms active, proactive and reactive, not because I
> have writen a draft about proactive mobility but because I have substantial reasons to believe that
> the terms are generic enough to encompass the entire time continuum of _any_  event (not just
> context transfer)
>
> As I said in the seamoby meeting the meaning of active (during), reactive (after) and proactive
> (before) depends first on the reader and really has got a fractal nature with respect to the
> magnitude of
> application of the notions since they really do not apply just to a mode of operation as people
> _erroneously_  consider. Much like a fractal they apply to a set of modes, or to an ontology of set
> of modes, or to a set of ontologies of sets of modes, etc...ad infinitum
>
> Just to exhibit the futility of the discussion on the matter and the fact that at the end of the
> day it is more who influences whom (everybody company hats on) rather what the terminology really
> reflects I will only cite the meaning of the terms PROACTIVE and REACTIVE from what else, the one
> and only source of objectivity which if we do not respect we might as well throw dictionaries away,
> deny authority of linguists, and identify a tech terminology anarchy where only the strongest
> (hello hats) survives
>
> I am not going to comment on what the oxford dictionary says because I expect people to be able to
> identify the etymology of the terms as supplied by the experts of linguistics, in the light of
> objectivity:
>
> http://dictionary.oed.com/cgi/entry/00189006?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-rrbDl0-705
>
> Let us now visit the etymology of the word REACTIVE
>
> http://dictionary.oed.com/cgi/entry/00198331?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha
>
> I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4
>
> Last but not least the word Active
>
> http://dictionary.oed.com/cgi/entry/00002214
>
> I stress the multiplicity of meaning but stick to notions of  1.a, 3.b, 4.a, 5.
>
> People managed to stick to the terms the label 'mode'.... WHY  did this happen? ..because it serves
> them better for the purposes of dissmissing the terms or is it because they have a narrow view of
> the world, or is it maybe because they do not really consider the real meaning of the terms? I
> wonder...
>
> A CT protocol MUST support at least one of these if it is expected to work in this time dimension
>
> As such to me the above means that:
>
> 'a CT protocol MUST support a minimum of at least one time class of event servicing with respect to
> mobility, that is active,reactive or proactive event servicing for the purposes of mobility aware
> context transfer'
>
> What are the events? I don't care (and why should I) it may be a handoff, it may the connection, it
> may be foobar.
>
> The above mean to me that the terms above describe accurately a 'requirement' with respect to the
> time period that context transfer comes in effect with respect to an EVENT. The terms are elegant
> and comprehensive as long as people know what they mean. Oxford English Dictionary attests to
> that...
>
> In that light the above terms do not need replacement really since they do describe accurately what
> they are supposed to. As such I personally provide a reason that what Cedric suggested augmenting
> the set of requirements with, is valid. It just becomes a matter of taste whether people want to
> name it something else, like 'during, before, after' which is more informal.
>
> That is not to say that I oppose to the validity of 'during,before,after'. It is to say that we
> have been fighting over synonyms really at a time when we already
> identified the right words.
>
> I would personaly like to stick to active,reactive,proactive for the reasons presented above. If
> people feel that the 'during,before,after' works better in their head then fair enough, but we just
> embark in yet another game of renaming things..
>
> Regs.
>
> Theo
>
> UCL/ Mobile Systems
>
>
>
>
> Cedric Westphal wrote:
>
> > "A CT protocol SHALL support context transfer which can occur
> > before, during or after handover"
> > this is not the same as 'CT MAY occur prior to, during, after', and
> > that makes sense to me.
> >
> > Henrik Levkowetz wrote:
> >
> > > Cedric,
> > >
> > >         Stating that a protocol SHALL support context transfer which
> > > can occur before, during or after handover blatantly eliminates your
> > > example which does it ONLY 2 days after handoff.
> > >
> > >         Henrik
> > >
> > > >
> > > > Henrik,
> > > >
> > > > Henrik Levkowetz wrote:
> > > >
> > > > > Cedric,
> > > > >
> > > > >         Johns proposal and wording was the first that cut trough
> > > > > the fog at the meeting, and met with overwhelming agreement because
> > > > > it stated very simply what seems to have been many people's concern
> > > > > -- i.e. that a CT protocol _not_ be so limited that it could not handle
> > > > > any of the conceivable timing scenarios implied.
> > > > >
> > > > >         As such, it may be obvious, but it is also VERY MUCH a
> > > > > requirement, and may sort out unsuitable protocol proposals which may
> > > > > not have the flexibility required.
> > > >
> > > > I disagree with this, but this flexibility is exactly the point I'm bringing up.
> > > > The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT
> > > >
> > > > meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff
> > > > does satisfy the requirement, since it 'may occur prior to, during or after', so why
> > > > not pick after? Talk about sorting out unsuitable protocols...
> > > >
> > > > Cheers,
> > > >
> > > > Cedric.
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >         Do you actually have anything against it, apart from it being
> > > > > obvious? I for one am very happy to have this requirement plainly and
> > > > > simply stated.
> > > > >
> > > > >         Regards,
> > > > >                 Henrik
> > > > >
> > > > > Cedric Westphal wrote:
> > > > > >
> > > > > > Pat Calhoun wrote:
> > > > > >
> > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, Cedric Westphal wrote:
> > > > > > > > Pat,
> > > > > > > >
> > > > > > > > thanks for the minutes. It seems it was indeed pretty intense.
> > > > > > > > However...
> > > > > > > >
> > > > > > > > Pat Calhoun wrote:
> > > > > > > >
> > > > > > > > > > Serioulsy, removing the terminology is not the same as removing the concept.
> > > > > > > > >
> > > > > > > > > As far as I can tell, proactive vs. reactive was essentially stating when CT
> > > > > > > > > would occur. This, as you state, is not a requirement,
> > > > > > > >
> > > > > > > > ...what I state is that saying 'CT may happen prior to, during or after handoff'
> > > > > > > > is not a requirement, it is just stating the obvious. CT must happen prior to,
> > > > > > > > during or after handoff, not because you require it, but because basic laws of
> > > > > > > > physics.
> > > > > > >
> > > > > > > And most people felt that the pro/re text also didn't reflect any requirements.
> > > > > > >
> > > > > > > >
> > > > > > > > Stating whether or not CT could complete before or after handoff is to me a
> > > > > > > > requirement.
> > > > > > >
> > > > > > > So how would you propose changing the text so it reads as an actualy requirement?
> > > > > >
> > > > > > Together with Gary, we did propose some text. I did not see much objection on the list
> > > > > >
> > > > > > about the wording, except some worries about the use of the word 'mode'.
> > > > > > Also, I like John's proposal in Issue 7,
> > > > > > which if I understand it well, is to look at the requirements from the context point
> > > > > > of view, and not from the protocol point of view. Basically, looking at the container
> > > > > > first
> > > > > > to design the crane, and not design a crane and see if the containers fit.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Cedric.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > PatC
>

--------------9CE8EC6C2A3AE08833C567E3-- From owner-seamoby@diameter.org Thu Aug 16 11:44:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13707 for ; Thu, 16 Aug 2001 11:44:55 -0400 (EDT) Received: (qmail 21237 invoked by alias); 16 Aug 2001 15:33:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21231 invoked by uid 200); 16 Aug 2001 15:33:08 -0000 Received: (qmail 21222 invoked from network); 16 Aug 2001 15:33:06 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 15:33:06 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 11:44:15 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054766@ftmail> From: George Tsirtsis To: "'t.pagtzis@cs.ucl.ac.uk'" , Pat Calhoun Cc: seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 11:44:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1266A.4D89A620" Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1266A.4D89A620 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Theo Pagtzis [mailto:T.Pagtzis@cs.ucl.ac.uk] Sent: Thursday, August 16, 2001 4:23 PM To: Pat Calhoun Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol. However, I have one question: is it possible that it can happen proactively (before) AND reactively (after) at the same time? Aren't these time event a bit mutually exclusive or at best OR-inclusive? What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that... GT>Actually no... Some context may need to be transfered early and some late...e.g.: security keys (early) and header compression state (late) George ------_=_NextPart_001_01C1266A.4D89A620 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Theo Pagtzis [mailto:T.Pagtzis@cs.ucl.ac.uk]
Sent: Thursday, August 16, 2001 4:23 PM
To: Pat Calhoun
Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz
Subject: Re: [seamoby] Update on Issues from IETF meeting

With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol.

However, I have one question:

is it possible that it can happen proactively (before) AND reactively (after) at the same time?
Aren't these time event a bit mutually exclusive or at best OR-inclusive?

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that... 

GT>Actually no... Some context may need to be transfered early and some late...e.g.: security keys (early) and header compression state (late)

George

------_=_NextPart_001_01C1266A.4D89A620-- From owner-seamoby@diameter.org Thu Aug 16 12:00:13 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14335 for ; Thu, 16 Aug 2001 12:00:12 -0400 (EDT) Received: (qmail 21773 invoked by alias); 16 Aug 2001 15:48:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21767 invoked by uid 200); 16 Aug 2001 15:48:19 -0000 Received: (qmail 21762 invoked from network); 16 Aug 2001 15:48:17 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 15:48:17 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 16:59:47 +0100 Message-ID: <3B7BEDF1.BE0DEEF3@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 16:59:45 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: George Tsirtsis CC: Pat Calhoun , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting References: <8C92E23A3E87FB479988285F9E22BE46054766@ftmail> Content-Type: multipart/alternative; boundary="------------4635A34C14A6DE85441DDF01" Sender: owner-seamoby@diameter.org Precedence: bulk --------------4635A34C14A6DE85441DDF01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Hi George, > With all due respect I am in favour of the suggestion > below. It provides better notion of time and behaviour > simultaneously for a CT protocol. > > However, I have one question: > > is it possible that it can happen proactively (before) AND > reactively (after) at the same time? > Aren't these time event a bit mutually exclusive or at > best OR-inclusive? > > What I am pointing basically is the AND. Shouldn't that be > an OR? Boolean logic, reasons clearly for that... > > GT>Actually no... Some context may need to be transfered > early and some late...e.g.: security keys (early) and > header compression state (late) > > I disagree with the no, but I agree that it may be _some_ cases where the context is transfered, part of it early..(proactively) _and_ part of it (late). if A means 'late' B means 'early' A AND B means that both late and early have to happen _always_ (std boolean predicates) A OR B means that either late OR early OR both can happen I see A OR B as being much more open than A AND B In other words A OR B captures the case you have described and does suggest a change of the AND conjunct. to an OR inclusive disjunct.. Theo UCL/ Mobile Systems > George > --------------4635A34C14A6DE85441DDF01 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 


Hi George,
 
 

With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol.

However, I have one question:

is it possible that it can happen proactively (before) AND reactively (after) at the same time?
Aren't these time event a bit mutually exclusive or at best OR-inclusive?

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that...

GT>Actually no... Some context may need to be transfered early and some late...e.g.: security keys (early) and header compression state (late)
 


I disagree with the no, but I agree that it may be _some_ cases where the context is transfered, part of it early..(proactively) _and_ part of it (late).

if

A means 'late'
B means 'early'

A  AND B means that both late and early have to happen _always_       (std boolean predicates)
A  OR  B means that either late OR early OR both can happen

I see A  OR  B as being much more open than A AND B

In other words A  OR  B captures the case you have described and does suggest a change of the AND conjunct. to an OR inclusive disjunct..

Theo

UCL/ Mobile Systems

George
--------------4635A34C14A6DE85441DDF01-- From owner-seamoby@diameter.org Thu Aug 16 12:05:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14504 for ; Thu, 16 Aug 2001 12:05:01 -0400 (EDT) Received: (qmail 22141 invoked by alias); 16 Aug 2001 15:50:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22134 invoked by uid 200); 16 Aug 2001 15:50:48 -0000 Received: (qmail 22123 invoked from network); 16 Aug 2001 15:50:45 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 15:50:45 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 12:01:55 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054768@ftmail> From: George Tsirtsis To: "'t.pagtzis@cs.ucl.ac.uk'" Cc: Pat Calhoun , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 12:01:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1266C.C4D80760" Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1266C.C4D80760 Content-Type: text/plain; charset="iso-8859-1" whatever... -----Original Message----- From: Theo Pagtzis [mailto:T.Pagtzis@cs.ucl.ac.uk] Sent: Thursday, August 16, 2001 5:00 PM To: George Tsirtsis Cc: Pat Calhoun; seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting Hi George, With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol. However, I have one question: is it possible that it can happen proactively (before) AND reactively (after) at the same time? Aren't these time event a bit mutually exclusive or at best OR-inclusive? What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that... GT>Actually no... Some context may need to be transfered early and some late...e.g.: security keys (early) and header compression state (late) I disagree with the no, but I agree that it may be _some_ cases where the context is transfered, part of it early..(proactively) _and_ part of it (late). if A means 'late' B means 'early' A AND B means that both late and early have to happen _always_ (std boolean predicates) A OR B means that either late OR early OR both can happen I see A OR B as being much more open than A AND B In other words A OR B captures the case you have described and does suggest a change of the AND conjunct. to an OR inclusive disjunct.. Theo UCL/ Mobile Systems George ------_=_NextPart_001_01C1266C.C4D80760 Content-Type: text/html; charset="iso-8859-1"
whatever...
-----Original Message-----
From: Theo Pagtzis [mailto:T.Pagtzis@cs.ucl.ac.uk]
Sent: Thursday, August 16, 2001 5:00 PM
To: George Tsirtsis
Cc: Pat Calhoun; seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz
Subject: Re: [seamoby] Update on Issues from IETF meeting

 


Hi George,
 
 

With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol.

However, I have one question:

is it possible that it can happen proactively (before) AND reactively (after) at the same time?
Aren't these time event a bit mutually exclusive or at best OR-inclusive?

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that...

GT>Actually no... Some context may need to be transfered early and some late...e.g.: security keys (early) and header compression state (late)
 


I disagree with the no, but I agree that it may be _some_ cases where the context is transfered, part of it early..(proactively) _and_ part of it (late).

if

A means 'late'
B means 'early'

A  AND B means that both late and early have to happen _always_       (std boolean predicates)
A  OR  B means that either late OR early OR both can happen

I see A  OR  B as being much more open than A AND B

In other words A  OR  B captures the case you have described and does suggest a change of the AND conjunct. to an OR inclusive disjunct..

Theo

UCL/ Mobile Systems

George
------_=_NextPart_001_01C1266C.C4D80760-- From owner-seamoby@diameter.org Thu Aug 16 13:23:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16491 for ; Thu, 16 Aug 2001 13:22:57 -0400 (EDT) Received: (qmail 23552 invoked by alias); 16 Aug 2001 17:04:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23546 invoked by uid 200); 16 Aug 2001 17:04:29 -0000 Received: (qmail 23541 invoked from network); 16 Aug 2001 17:04:26 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 17:04:26 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GHFGp17755 for ; Thu, 16 Aug 2001 13:15:16 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 16 Aug 2001 13:15:11 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 13:15:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F04@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , Theo Pagtzis Cc: seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 13:15:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12677.019C2AA0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12677.019C2AA0 Content-Type: text/plain; charset="iso-8859-1" But what is "handoff"? > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, August 16, 2001 10:25 AM > To: Theo Pagtzis > Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > Theo, > > My problem wasn't the terms active,proactive,reactive, but > the rather long text > accompanying the terms, which caused nothing but confusion > and would open up > cans of worms. I find John's proposal to be short and to the point. > > If you think that something along the lines of: > > "Context Transfer MAY occur before (proactive), during > (active) and after (reactive) > a handoff." > > would be more acceptable since it keeps the terminology in > place, I wouldn't be > against it, and would welcome comments. > > PatC > On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote: > > Ced/All, > > > > First just to comment that having done some work for the > design of a proactive mobility > > framework, I can only see that > > at the end of the day the terminology will boil down to > whatever people's taste sees fit as a term > > compliant with the timing intrinsincs of context transfer. > > > > However, I would like to argue in favor of the terms > active, proactive and reactive, not because I > > have writen a draft about proactive mobility but because I > have substantial reasons to believe that > > the terms are generic enough to encompass the entire time > continuum of _any_ event (not just > > context transfer) > > > > As I said in the seamoby meeting the meaning of active > (during), reactive (after) and proactive > > (before) depends first on the reader and really has got a > fractal nature with respect to the > > magnitude of > > application of the notions since they really do not apply > just to a mode of operation as people > > _erroneously_ consider. Much like a fractal they apply to > a set of modes, or to an ontology of set > > of modes, or to a set of ontologies of sets of modes, > etc...ad infinitum > > > > Just to exhibit the futility of the discussion on the > matter and the fact that at the end of the > > day it is more who influences whom (everybody company hats > on) rather what the terminology really > > reflects I will only cite the meaning of the terms > PROACTIVE and REACTIVE from what else, the one > > and only source of objectivity which if we do not respect > we might as well throw dictionaries away, > > deny authority of linguists, and identify a tech > terminology anarchy where only the strongest > > (hello hats) survives > > > > I am not going to comment on what the oxford dictionary > says because I expect people to be able to > > identify the etymology of the terms as supplied by the > experts of linguistics, in the light of > > objectivity: > > > > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_ id=Iz5i-> rrbDl0-705 > > > > Let us now visit the etymology of the word REACTIVE > > > > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha > > > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 > > > > Last but not least the word Active > > > > http://dictionary.oed.com/cgi/entry/00002214 > > > > I stress the multiplicity of meaning but stick to notions > of 1.a, 3.b, 4.a, 5. > > > > People managed to stick to the terms the label 'mode'.... > WHY did this happen? ..because it serves > > them better for the purposes of dissmissing the terms or is > it because they have a narrow view of > > the world, or is it maybe because they do not really > consider the real meaning of the terms? I > > wonder... > > > > A CT protocol MUST support at least one of these if it is > expected to work in this time dimension > > > > As such to me the above means that: > > > > 'a CT protocol MUST support a minimum of at least one time > class of event servicing with respect to > > mobility, that is active,reactive or proactive event > servicing for the purposes of mobility aware > > context transfer' > > > > What are the events? I don't care (and why should I) it may > be a handoff, it may the connection, it > > may be foobar. > > > > The above mean to me that the terms above describe > accurately a 'requirement' with respect to the > > time period that context transfer comes in effect with > respect to an EVENT. The terms are elegant > > and comprehensive as long as people know what they mean. > Oxford English Dictionary attests to > > that... > > > > In that light the above terms do not need replacement > really since they do describe accurately what > > they are supposed to. As such I personally provide a reason > that what Cedric suggested augmenting > > the set of requirements with, is valid. It just becomes a > matter of taste whether people want to > > name it something else, like 'during, before, after' which > is more informal. > > > > That is not to say that I oppose to the validity of > 'during,before,after'. It is to say that we > > have been fighting over synonyms really at a time when we already > > identified the right words. > > > > I would personaly like to stick to > active,reactive,proactive for the reasons presented above. If > > people feel that the 'during,before,after' works better in > their head then fair enough, but we just > > embark in yet another game of renaming things.. > > > > Regs. > > > > Theo > > > > UCL/ Mobile Systems > > > > > > > > > > Cedric Westphal wrote: > > > > > "A CT protocol SHALL support context transfer which can occur > > > before, during or after handover" > > > this is not the same as 'CT MAY occur prior to, during, > after', and > > > that makes sense to me. > > > > > > Henrik Levkowetz wrote: > > > > > > > Cedric, > > > > > > > > Stating that a protocol SHALL support context > transfer which > > > > can occur before, during or after handover blatantly > eliminates your > > > > example which does it ONLY 2 days after handoff. > > > > > > > > Henrik > > > > > > > > > > > > > > Henrik, > > > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > > > Cedric, > > > > > > > > > > > > Johns proposal and wording was the first > that cut trough > > > > > > the fog at the meeting, and met with overwhelming > agreement because > > > > > > it stated very simply what seems to have been many > people's concern > > > > > > -- i.e. that a CT protocol _not_ be so limited that > it could not handle > > > > > > any of the conceivable timing scenarios implied. > > > > > > > > > > > > As such, it may be obvious, but it is also > VERY MUCH a > > > > > > requirement, and may sort out unsuitable protocol > proposals which may > > > > > > not have the flexibility required. > > > > > > > > > > I disagree with this, but this flexibility is exactly > the point I'm bringing up. > > > > > The proposed requirement is so much a requirement > that I'd like to see ONE ctp that does NOT > > > > > > > > > > meet it. I am sorry, but a ctp that ONLY sends > context 2 days after a handoff > > > > > does satisfy the requirement, since it 'may occur > prior to, during or after', so why > > > > > not pick after? Talk about sorting out unsuitable protocols... > > > > > > > > > > Cheers, > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, > apart from it being > > > > > > obvious? I for one am very happy to have this > requirement plainly and > > > > > > simply stated. > > > > > > > > > > > > Regards, > > > > > > Henrik > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, > Cedric Westphal wrote: > > > > > > > > > Pat, > > > > > > > > > > > > > > > > > > thanks for the minutes. It seems it was > indeed pretty intense. > > > > > > > > > However... > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is > not the same as removing the concept. > > > > > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. > reactive was essentially stating when CT > > > > > > > > > > would occur. This, as you state, is not a > requirement, > > > > > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen > prior to, during or after handoff' > > > > > > > > > is not a requirement, it is just stating the > obvious. CT must happen prior to, > > > > > > > > > during or after handoff, not because you > require it, but because basic laws of > > > > > > > > > physics. > > > > > > > > > > > > > > > > And most people felt that the pro/re text also > didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete > before or after handoff is to me a > > > > > > > > > requirement. > > > > > > > > > > > > > > > > So how would you propose changing the text so > it reads as an actualy requirement? > > > > > > > > > > > > > > Together with Gary, we did propose some text. I > did not see much objection on the list > > > > > > > > > > > > > > about the wording, except some worries about the > use of the word 'mode'. > > > > > > > Also, I like John's proposal in Issue 7, > > > > > > > which if I understand it well, is to look at the > requirements from the context point > > > > > > > of view, and not from the protocol point of view. > Basically, looking at the container > > > > > > > first > > > > > > > to design the crane, and not design a crane and > see if the containers fit. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC > > > ------_=_NextPart_001_01C12677.019C2AA0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

But what is "handoff"?

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Thursday, August 16, 2001 10:25 AM
> To: Theo Pagtzis
> Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
> Theo,
>
> My problem wasn't the terms active,proactive,reactive, but
> the rather long text
> accompanying the terms, which caused nothing but confusion
> and would open up
> cans of worms. I find John's proposal to be short and to the point.
>
> If you think that something along the lines of:
>
> "Context Transfer MAY occur before (proactive), during
> (active) and after (reactive)
> a handoff."
>
> would be more acceptable since it keeps the terminology in
> place, I wouldn't be
> against it, and would welcome comments.
>
> PatC
> On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote:
> > Ced/All,
> >
> >    First just to comment that having done some work for the
> design of a proactive mobility
> > framework, I can only see that
> > at the end of the day the terminology will boil down to
> whatever people's taste sees fit as a term
> > compliant with the timing intrinsincs of context transfer.
> >
> > However, I would like to argue in favor of the terms
> active, proactive and reactive, not because I
> > have writen a draft about proactive mobility but because I
> have substantial reasons to believe that
> > the terms are generic enough to encompass the entire time
> continuum of _any_  event (not just
> > context transfer)
> >
> > As I said in the seamoby meeting the meaning of active
> (during), reactive (after) and proactive
> > (before) depends first on the reader and really has got a
> fractal nature with respect to the
> > magnitude of
> > application of the notions since they really do not apply
> just to a mode of operation as people
> > _erroneously_  consider. Much like a fractal they apply to
> a set of modes, or to an ontology of set
> > of modes, or to a set of ontologies of sets of modes,
> etc...ad infinitum
> >
> > Just to exhibit the futility of the discussion on the
> matter and the fact that at the end of the
> > day it is more who influences whom (everybody company hats
> on) rather what the terminology really
> > reflects I will only cite the meaning of the terms
> PROACTIVE and REACTIVE from what else, the one
> > and only source of objectivity which if we do not respect
> we might as well throw dictionaries away,
> > deny authority of linguists, and identify a tech
> terminology anarchy where only the strongest
> > (hello hats) survives
> >
> > I am not going to comment on what the oxford dictionary
> says because I expect people to be able to
> > identify the etymology of the terms as supplied by the
> experts of linguistics, in the light of
> > objectivity:
> >
> >
> http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q
ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-> rrbDl0-705
> >
> > Let us now visit the etymology of the word REACTIVE
> >
> >
> http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q
ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha
> >
> > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4
> >
> > Last but not least the word Active
> >
> > http://dictionary.oed.com/cgi/entry/00002214
> >
> > I stress the multiplicity of meaning but stick to notions
> of  1.a, 3.b, 4.a, 5.
> >
> > People managed to stick to the terms the label 'mode'....
> WHY  did this happen? ..because it serves
> > them better for the purposes of dissmissing the terms or is
> it because they have a narrow view of
> > the world, or is it maybe because they do not really
> consider the real meaning of the terms? I
> > wonder...
> >
> > A CT protocol MUST support at least one of these if it is
> expected to work in this time dimension
> >
> > As such to me the above means that:
> >
> > 'a CT protocol MUST support a minimum of at least one time
> class of event servicing with respect to
> > mobility, that is active,reactive or proactive event
> servicing for the purposes of mobility aware
> > context transfer'
> >
> > What are the events? I don't care (and why should I) it may
> be a handoff, it may the connection, it
> > may be foobar.
> >
> > The above mean to me that the terms above describe
> accurately a 'requirement' with respect to the
> > time period that context transfer comes in effect with
> respect to an EVENT. The terms are elegant
> > and comprehensive as long as people know what they mean.
> Oxford English Dictionary attests to
> > that...
> >
> > In that light the above terms do not need replacement
> really since they do describe accurately what
> > they are supposed to. As such I personally provide a reason
> that what Cedric suggested augmenting
> > the set of requirements with, is valid. It just becomes a
> matter of taste whether people want to
> > name it something else, like 'during, before, after' which
> is more informal.
> >
> > That is not to say that I oppose to the validity of
> 'during,before,after'. It is to say that we
> > have been fighting over synonyms really at a time when we already
> > identified the right words.
> >
> > I would personaly like to stick to
> active,reactive,proactive for the reasons presented above. If
> > people feel that the 'during,before,after' works better in
> their head then fair enough, but we just
> > embark in yet another game of renaming things..
> >
> > Regs.
> >
> > Theo
> >
> > UCL/ Mobile Systems
> >
> >
> >
> >
> > Cedric Westphal wrote:
> >
> > > "A CT protocol SHALL support context transfer which can occur
> > > before, during or after handover"
> > > this is not the same as 'CT MAY occur prior to, during,
> after', and
> > > that makes sense to me.
> > >
> > > Henrik Levkowetz wrote:
> > >
> > > > Cedric,
> > > >
> > > >         Stating that a protocol SHALL support context
> transfer which
> > > > can occur before, during or after handover blatantly
> eliminates your
> > > > example which does it ONLY 2 days after handoff.
> > > >
> > > >         Henrik
> > > >
> > > > >
> > > > > Henrik,
> > > > >
> > > > > Henrik Levkowetz wrote:
> > > > >
> > > > > > Cedric,
> > > > > >
> > > > > >         Johns proposal and wording was the first
> that cut trough
> > > > > > the fog at the meeting, and met with overwhelming
> agreement because
> > > > > > it stated very simply what seems to have been many
> people's concern
> > > > > > -- i.e. that a CT protocol _not_ be so limited that
> it could not handle
> > > > > > any of the conceivable timing scenarios implied.
> > > > > >
> > > > > >         As such, it may be obvious, but it is also
> VERY MUCH a
> > > > > > requirement, and may sort out unsuitable protocol
> proposals which may
> > > > > > not have the flexibility required.
> > > > >
> > > > > I disagree with this, but this flexibility is exactly
> the point I'm bringing up.
> > > > > The proposed requirement is so much a requirement
> that I'd like to see ONE ctp that does NOT
> > > > >
> > > > > meet it. I am sorry, but a ctp that ONLY sends
> context 2 days after a handoff
> > > > > does satisfy the requirement, since it 'may occur
> prior to, during or after', so why
> > > > > not pick after? Talk about sorting out unsuitable protocols...
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Cedric.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >         Do you actually have anything against it,
> apart from it being
> > > > > > obvious? I for one am very happy to have this
> requirement plainly and
> > > > > > simply stated.
> > > > > >
> > > > > >         Regards,
> > > > > >                 Henrik
> > > > > >
> > > > > > Cedric Westphal wrote:
> > > > > > >
> > > > > > > Pat Calhoun wrote:
> > > > > > >
> > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700,
> Cedric Westphal wrote:
> > > > > > > > > Pat,
> > > > > > > > >
> > > > > > > > > thanks for the minutes. It seems it was
> indeed pretty intense.
> > > > > > > > > However...
> > > > > > > > >
> > > > > > > > > Pat Calhoun wrote:
> > > > > > > > >
> > > > > > > > > > > Serioulsy, removing the terminology is
> not the same as removing the concept.
> > > > > > > > > >
> > > > > > > > > > As far as I can tell, proactive vs.
> reactive was essentially stating when CT
> > > > > > > > > > would occur. This, as you state, is not a
> requirement,
> > > > > > > > >
> > > > > > > > > ...what I state is that saying 'CT may happen
> prior to, during or after handoff'
> > > > > > > > > is not a requirement, it is just stating the
> obvious. CT must happen prior to,
> > > > > > > > > during or after handoff, not because you
> require it, but because basic laws of
> > > > > > > > > physics.
> > > > > > > >
> > > > > > > > And most people felt that the pro/re text also
> didn't reflect any requirements.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Stating whether or not CT could complete
> before or after handoff is to me a
> > > > > > > > > requirement.
> > > > > > > >
> > > > > > > > So how would you propose changing the text so
> it reads as an actualy requirement?
> > > > > > >
> > > > > > > Together with Gary, we did propose some text. I
> did not see much objection on the list
> > > > > > >
> > > > > > > about the wording, except some worries about the
> use of the word 'mode'.
> > > > > > > Also, I like John's proposal in Issue 7,
> > > > > > > which if I understand it well, is to look at the
> requirements from the context point
> > > > > > > of view, and not from the protocol point of view.
> Basically, looking at the container
> > > > > > > first
> > > > > > > to design the crane, and not design a crane and
> see if the containers fit.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Cedric.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > PatC
> >
>

------_=_NextPart_001_01C12677.019C2AA0-- From owner-seamoby@diameter.org Thu Aug 16 13:35:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16873 for ; Thu, 16 Aug 2001 13:35:01 -0400 (EDT) Received: (qmail 23878 invoked by alias); 16 Aug 2001 17:13:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23872 invoked by uid 200); 16 Aug 2001 17:13:32 -0000 Received: (qmail 23865 invoked from network); 16 Aug 2001 17:13:29 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 17:13:29 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7GHP8326770 for ; Thu, 16 Aug 2001 20:25:08 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 16 Aug 2001 20:24:02 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVVD78>; Thu, 16 Aug 2001 20:24:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094196@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 20:23:59 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12678.3C268D18" Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12678.3C268D18 Content-Type: text/plain; charset="iso-8859-1" Hi all, I think that CT could happen under the following conditions: 1) Before handoff 2) During handoff 3) After handoff Futher more, I see it as feasible that: 1) All context (for a particular CTP instance) could be sent in a single packet (subject to MTU) 2) Context (for a particular CTP instance) could be sent seperately I think that it depends on the situation, implementation and requirements for the particular context being transfered. I request that the CT requirements allow for this. thanks, John ------_=_NextPart_001_01C12678.3C268D18 Content-Type: text/html; charset="iso-8859-1"
Hi all,
 
I think that CT could happen under the following conditions:
    1) Before handoff
    2) During handoff
    3) After handoff
 
Futher more, I see it as feasible that:
    1) All context (for a particular CTP instance) could be sent in a single packet (subject to MTU)
    2) Context (for a particular CTP instance) could be sent seperately
 
I think that it depends on the situation, implementation and requirements for the particular context being transfered.
 
I request that the CT requirements allow for this.
 
thanks,
John
------_=_NextPart_001_01C12678.3C268D18-- From owner-seamoby@diameter.org Thu Aug 16 13:40:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17083 for ; Thu, 16 Aug 2001 13:40:06 -0400 (EDT) Received: (qmail 24065 invoked by alias); 16 Aug 2001 17:18:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24059 invoked by uid 200); 16 Aug 2001 17:18:53 -0000 Received: (qmail 24051 invoked by uid 500); 16 Aug 2001 17:18:51 -0000 Date: Thu, 16 Aug 2001 10:18:51 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , Theo Pagtzis , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816101851.A23961@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , Theo Pagtzis , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz References: <9FBD322B7824D511B36900508BF93C9C9F5F04@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5F04@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, Aug 16, 2001 at 01:15:11PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk Since the MIP WG doesn't have a problem with this term, I don't see why we need to open that can of worms. Do we want to move on, or spend more cycles arguing terminology and push our milestones out further? PatC On Thu, Aug 16, 2001 at 01:15:11PM -0400, Gary Kenward wrote: > But what is "handoff"? > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, August 16, 2001 10:25 AM > > To: Theo Pagtzis > > Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz > > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > > > > Theo, > > > > My problem wasn't the terms active,proactive,reactive, but > > the rather long text > > accompanying the terms, which caused nothing but confusion > > and would open up > > cans of worms. I find John's proposal to be short and to the point. > > > > If you think that something along the lines of: > > > > "Context Transfer MAY occur before (proactive), during > > (active) and after (reactive) > > a handoff." > > > > would be more acceptable since it keeps the terminology in > > place, I wouldn't be > > against it, and would welcome comments. > > > > PatC > > On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote: > > > Ced/All, > > > > > > First just to comment that having done some work for the > > design of a proactive mobility > > > framework, I can only see that > > > at the end of the day the terminology will boil down to > > whatever people's taste sees fit as a term > > > compliant with the timing intrinsincs of context transfer. > > > > > > However, I would like to argue in favor of the terms > > active, proactive and reactive, not because I > > > have writen a draft about proactive mobility but because I > > have substantial reasons to believe that > > > the terms are generic enough to encompass the entire time > > continuum of _any_ event (not just > > > context transfer) > > > > > > As I said in the seamoby meeting the meaning of active > > (during), reactive (after) and proactive > > > (before) depends first on the reader and really has got a > > fractal nature with respect to the > > > magnitude of > > > application of the notions since they really do not apply > > just to a mode of operation as people > > > _erroneously_ consider. Much like a fractal they apply to > > a set of modes, or to an ontology of set > > > of modes, or to a set of ontologies of sets of modes, > > etc...ad infinitum > > > > > > Just to exhibit the futility of the discussion on the > > matter and the fact that at the end of the > > > day it is more who influences whom (everybody company hats > > on) rather what the terminology really > > > reflects I will only cite the meaning of the terms > > PROACTIVE and REACTIVE from what else, the one > > > and only source of objectivity which if we do not respect > > we might as well throw dictionaries away, > > > deny authority of linguists, and identify a tech > > terminology anarchy where only the strongest > > > (hello hats) survives > > > > > > I am not going to comment on what the oxford dictionary > > says because I expect people to be able to > > > identify the etymology of the terms as supplied by the > > experts of linguistics, in the light of > > > objectivity: > > > > > > > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q > ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_ > id=Iz5i-> rrbDl0-705 > > > > > > Let us now visit the etymology of the word REACTIVE > > > > > > > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q > ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha > > > > > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 > > > > > > Last but not least the word Active > > > > > > http://dictionary.oed.com/cgi/entry/00002214 > > > > > > I stress the multiplicity of meaning but stick to notions > > of 1.a, 3.b, 4.a, 5. > > > > > > People managed to stick to the terms the label 'mode'.... > > WHY did this happen? ..because it serves > > > them better for the purposes of dissmissing the terms or is > > it because they have a narrow view of > > > the world, or is it maybe because they do not really > > consider the real meaning of the terms? I > > > wonder... > > > > > > A CT protocol MUST support at least one of these if it is > > expected to work in this time dimension > > > > > > As such to me the above means that: > > > > > > 'a CT protocol MUST support a minimum of at least one time > > class of event servicing with respect to > > > mobility, that is active,reactive or proactive event > > servicing for the purposes of mobility aware > > > context transfer' > > > > > > What are the events? I don't care (and why should I) it may > > be a handoff, it may the connection, it > > > may be foobar. > > > > > > The above mean to me that the terms above describe > > accurately a 'requirement' with respect to the > > > time period that context transfer comes in effect with > > respect to an EVENT. The terms are elegant > > > and comprehensive as long as people know what they mean. > > Oxford English Dictionary attests to > > > that... > > > > > > In that light the above terms do not need replacement > > really since they do describe accurately what > > > they are supposed to. As such I personally provide a reason > > that what Cedric suggested augmenting > > > the set of requirements with, is valid. It just becomes a > > matter of taste whether people want to > > > name it something else, like 'during, before, after' which > > is more informal. > > > > > > That is not to say that I oppose to the validity of > > 'during,before,after'. It is to say that we > > > have been fighting over synonyms really at a time when we already > > > identified the right words. > > > > > > I would personaly like to stick to > > active,reactive,proactive for the reasons presented above. If > > > people feel that the 'during,before,after' works better in > > their head then fair enough, but we just > > > embark in yet another game of renaming things.. > > > > > > Regs. > > > > > > Theo > > > > > > UCL/ Mobile Systems > > > > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > "A CT protocol SHALL support context transfer which can occur > > > > before, during or after handover" > > > > this is not the same as 'CT MAY occur prior to, during, > > after', and > > > > that makes sense to me. > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > Cedric, > > > > > > > > > > Stating that a protocol SHALL support context > > transfer which > > > > > can occur before, during or after handover blatantly > > eliminates your > > > > > example which does it ONLY 2 days after handoff. > > > > > > > > > > Henrik > > > > > > > > > > > > > > > > > Henrik, > > > > > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > > > > > Cedric, > > > > > > > > > > > > > > Johns proposal and wording was the first > > that cut trough > > > > > > > the fog at the meeting, and met with overwhelming > > agreement because > > > > > > > it stated very simply what seems to have been many > > people's concern > > > > > > > -- i.e. that a CT protocol _not_ be so limited that > > it could not handle > > > > > > > any of the conceivable timing scenarios implied. > > > > > > > > > > > > > > As such, it may be obvious, but it is also > > VERY MUCH a > > > > > > > requirement, and may sort out unsuitable protocol > > proposals which may > > > > > > > not have the flexibility required. > > > > > > > > > > > > I disagree with this, but this flexibility is exactly > > the point I'm bringing up. > > > > > > The proposed requirement is so much a requirement > > that I'd like to see ONE ctp that does NOT > > > > > > > > > > > > meet it. I am sorry, but a ctp that ONLY sends > > context 2 days after a handoff > > > > > > does satisfy the requirement, since it 'may occur > > prior to, during or after', so why > > > > > > not pick after? Talk about sorting out unsuitable protocols... > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, > > apart from it being > > > > > > > obvious? I for one am very happy to have this > > requirement plainly and > > > > > > > simply stated. > > > > > > > > > > > > > > Regards, > > > > > > > Henrik > > > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, > > Cedric Westphal wrote: > > > > > > > > > > Pat, > > > > > > > > > > > > > > > > > > > > thanks for the minutes. It seems it was > > indeed pretty intense. > > > > > > > > > > However... > > > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is > > not the same as removing the concept. > > > > > > > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. > > reactive was essentially stating when CT > > > > > > > > > > > would occur. This, as you state, is not a > > requirement, > > > > > > > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen > > prior to, during or after handoff' > > > > > > > > > > is not a requirement, it is just stating the > > obvious. CT must happen prior to, > > > > > > > > > > during or after handoff, not because you > > require it, but because basic laws of > > > > > > > > > > physics. > > > > > > > > > > > > > > > > > > And most people felt that the pro/re text also > > didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete > > before or after handoff is to me a > > > > > > > > > > requirement. > > > > > > > > > > > > > > > > > > So how would you propose changing the text so > > it reads as an actualy requirement? > > > > > > > > > > > > > > > > Together with Gary, we did propose some text. I > > did not see much objection on the list > > > > > > > > > > > > > > > > about the wording, except some worries about the > > use of the word 'mode'. > > > > > > > > Also, I like John's proposal in Issue 7, > > > > > > > > which if I understand it well, is to look at the > > requirements from the context point > > > > > > > > of view, and not from the protocol point of view. > > Basically, looking at the container > > > > > > > > first > > > > > > > > to design the crane, and not design a crane and > > see if the containers fit. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC > > > > > From owner-seamoby@diameter.org Thu Aug 16 13:45:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17300 for ; Thu, 16 Aug 2001 13:45:09 -0400 (EDT) Received: (qmail 24203 invoked by alias); 16 Aug 2001 17:22:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24197 invoked by uid 200); 16 Aug 2001 17:22:48 -0000 Received: (qmail 24189 invoked by uid 500); 16 Aug 2001 17:22:46 -0000 Date: Thu, 16 Aug 2001 10:22:46 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816102246.B23961@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com References: <0C1353ABB1DEB74DB067ADFF749C4EEF094196@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF094196@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Thu, Aug 16, 2001 at 08:23:59PM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk Well, we are trying to get consensus on your first point, but the other issue that seems to have consensus is to allow for CT to occur in multiple phases. PatC On Thu, Aug 16, 2001 at 08:23:59PM +0300, john.loughney@nokia.com wrote: > Hi all, > > I think that CT could happen under the following conditions: > 1) Before handoff > 2) During handoff > 3) After handoff > > Futher more, I see it as feasible that: > 1) All context (for a particular CTP instance) could be sent in a single > packet (subject to MTU) > 2) Context (for a particular CTP instance) could be sent seperately > > I think that it depends on the situation, implementation and requirements > for the particular context being transfered. > > I request that the CT requirements allow for this. > > thanks, > John From owner-seamoby@diameter.org Thu Aug 16 13:47:27 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17379 for ; Thu, 16 Aug 2001 13:47:26 -0400 (EDT) Received: (qmail 25034 invoked by alias); 16 Aug 2001 17:30:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25027 invoked by uid 200); 16 Aug 2001 17:30:19 -0000 Received: (qmail 25016 invoked from network); 16 Aug 2001 17:30:15 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 17:30:15 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08446; Thu, 16 Aug 2001 11:41:37 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA17387; Thu, 16 Aug 2001 10:41:40 -0700 (PDT) Message-Id: <200108161741.KAA17387@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 10:41:32 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Update on Issues from IETF meeting To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, john.loughney@nokia.com Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j0j8/R57kLS1u7F+5z50NA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Folks, At the risk of sounding hysterical, can we PLEASE come to some concensus on this and move on? We seem to be stuck in an infinite loop trying to number the angels that dance on the point of a pin. I thought we had concensus at the meeting. Requirements are meant to be general guidelines for development of the protocol, and to exclude obviously inappropriate features. If people can't agree on a narrow scope, then let's define the requirement as broadly as possible and let the protocol designers decide what's appropriate for the particular feature they want to transfer. It sounds to me like that's going to be the case anyway Sorry. jak >Delivered-To: seamoby-list@charizard.diameter.org >From: john.loughney@nokia.com >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com >Subject: RE: [seamoby] Update on Issues from IETF meeting >Date: Thu, 16 Aug 2001 20:23:59 +0300 > >Hi all, > >I think that CT could happen under the following conditions: > 1) Before handoff > 2) During handoff > 3) After handoff > >Futher more, I see it as feasible that: > 1) All context (for a particular CTP instance) could be sent in a single >packet (subject to MTU) > 2) Context (for a particular CTP instance) could be sent seperately > >I think that it depends on the situation, implementation and requirements >for the particular context being transfered. > >I request that the CT requirements allow for this. > >thanks, >John From owner-seamoby@diameter.org Thu Aug 16 14:13:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18198 for ; Thu, 16 Aug 2001 14:12:58 -0400 (EDT) Received: (qmail 26404 invoked by alias); 16 Aug 2001 17:55:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26398 invoked by uid 200); 16 Aug 2001 17:55:08 -0000 Received: (qmail 26391 invoked by uid 500); 16 Aug 2001 17:55:06 -0000 Date: Thu, 16 Aug 2001 10:55:06 -0700 From: Pat Calhoun To: Theo Pagtzis Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] ACTIVE,PROACTIVE,REACTIVE et al. Message-ID: <20010816105506.C26352@charizard.diameter.org> Mail-Followup-To: Theo Pagtzis , seamoby@cdma-2000.org References: <3B7BD38F.73ABD756@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3B7BD38F.73ABD756@cs.ucl.ac.uk>; from T.Pagtzis@cs.ucl.ac.uk on Thu, Aug 16, 2001 at 03:07:11PM +0100 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit That's all fine and good, but I think that people want to read documents and not require a dictionary to grasp the actual meaning of the language used. :) PatC On Thu, Aug 16, 2001 at 03:07:11PM +0100, Theo Pagtzis wrote: > For the sake of completeness I provide the terms' etymology from > Oxford English Dictionary as they are : > > This is to help people that do not have access to the online service, > appreciate the argument better! > > OED Term Definitions: > > +++++++++++++++++REACTIVE++++++++++++++++++++++++++++ > > A. adj. > > 1. Repercussive, echoing. Obs.1 > > 1712 BLACKMORE Creation 357 Ye fish, assume a voice, with praises > fill The hollow rock, and loud reactive hill. > > > 2. Acting or operative in return. > > 1794 G. ADAMS Nat. & Exp. Philos. III. xxi. 103 Every body that > acts, is at the same instant both active and re~active. > 1851 H. SPENCER Soc. Stat. 318 We have to consider, not only what is > done for the afflicted, but what is the reactive effect > upon those who do it. > > > 3. Path. a. Supervening on a previous opposite state; due to > reaction. Also reactive formation = > reaction formation s.v. REACTION 5; reactive inhibition, the > inhibiting effect of the supervention of fatigue > or boredom on the response to a stimulus. > > 1822-34 Good's Study Med. (ed. 4) IV. 434 The patient..was not > rendered faint by the re-active glow that ensued upon > his quitting the water. 1885-8 PYE-SMITH Fagge's Princ. Med. I. 51 > Such patients..sometimes pass into a condition of > reactive pyrexia. 1925 J. STRACHEY tr. Freud's Case of Hysteria in > Coll. Papers III. 67 Repression is often achieved by > means of an excessive reinforcement of the thought contrary to the one > which is to be repressed. This process I call > reactive reinforcement. Ibid. 68 The thought which asserts itself > exaggeratedly in consciousness and (in the same way as > a prejudice) cannot be removed I call a reactive thought. 1943 C. L. > HULL Princ. Behavior xviii. 327 Uniform time intervals > between reinforcements great enough to prevent the accumulation of > appreciable amounts of reactive inhibition. 1968 Globe > & Mail (Toronto) 3 Feb. 11/6 These young people can join `negative > identity' groups and become..therapeutically involved > in extreme reactive kinds of activity. 1974 CHAPLIN & KRAWIEC Systems > & Theories of Psychol. vii. 263 In and of itself > fatigue will generate a form of inhibition which Hull calls reactive > inhibition, and the animal will cease to respond. 1975 Way > Suppl. No. 25. 67 Dynamic psychology might interpret this as evidence > for reactive formation, which is a technical term > suggesting that we control an unacceptable impulse by exaggerating the > opposite tendency. 1977 G. H. SAGE Introd. Motor > Behav. (ed. 2) xvi. 359 The first of these is an inhibition (reactive > inhibition) caused by a reluctance to repeat a response. > > > b. Recuperative; responsive (to a stimulus); characterized by > reaction to a stimulus. > > 1822-34 Good's Study Med. (ed. 4) I. 704 There is no longer any > rallying or reactive power remaining. 1896 Allbutt's Syst. > Med. I. 193 These granules are feebly reactive to light. Ibid. 293 > Delicate children, with little reactive power. 1927 C. > SPEARMAN Abilities of Man iv. 47 Stern's division of persons into the > `spontaneous' and the `merely reactive'. 1952 M. > K. WILSON tr. Lorenz's King Solomon's Ring xi. 171 A few birdsusually > old, strongly reactive ones take off, emitting > `Kiaw' cries and thereby provoking the whole flock to leave the ground > with them. > > > c. Psychol. Of mental illness: thought to be caused by reaction to > environmental stress; exogenous; so > reactive schizophrenic, a person with reactive schizophrenia (cf. > process schizophrenia s.v. PROCESS n. > 13a). > > 1924 A. A. BRILL Bleuler's Textbk. Psychiatry xii. 537 Reactive > depressions, which become aggravated to a mental > disease, are quite rare in the light of present views. 1955 MCCARTHY & > CORRIN Med. Treatment of Mental Dis. xix. 326 > Reactive depressions are the mild, brief depressions, the result of > situations depressing in themselves, and not out of > proportion to circumstances. 1958 H. WEINER in L. Bellak Schizophrenia > iv. 157 Whether such reactive psychoses actually > imply a different series of etiologic contributing factors, i.e., > `non-organic', is highly speculative. 1962 Lancet 10 Jan. 105/1 > Two were middle-aged men with anxiety states... The third was a > middle-aged lady with a reactive depression. 1962 > Psychol. Bull. LIX. 329/1 Reactive schizophrenia indicates a good > prognosis..with notable stress precipitating the > psychosis. Ibid. 332/1 If the Rorschach diagnosis is followed, then it > appears that reactive schizophrenics are not > psychotic. 1965 J. POLLITT Depression & its Treatment 95 The terms > `endogenous' and `reactive'..differentiate types of > depression on the basis of presence or absence of an external cause. > 1966 I. B. WEINER Psychodiagnosis in Schizophrenia > vi. 94 A group of process schizophrenics made no more frequent errors > than the reactive schizophrenics. 1971 Brit. Med. > Bull. XXVII. 77/2 One school of thought..allocates such cases to a > special category of `reactive psychoses'. 1974 M. C. > GERALD Pharmacol. xvi. 310 When the cause of depression can be > identified,..we term this reactive or exogenous > depression. 1976 L. J. WEST et al. Treatment of Schizophrenia vi. 278 > The good premorbid/bad premorbid, and > process/reactive dimensions do seem to identify significant > characteristics. > > > 4. Characterized by reaction (sense 4). > > 1868 GLADSTONE Juv. Mundi i. (1870) 24 The reactive tendency to > preserve the text by recurrence to a standard. 1890 > Harper's Mag. June 77/1 He constantly inclined to reactive measures. > > > 5. Chem. a. Readily susceptible to chemical reaction. > > 1888 Nature 22 Mar. 503/1 The unsaturated hydrocarbons..are..more > reactive than the paraffins. 1942 G. WENDT Chem. > vii. 179 As in the other families of elements we shall meet, the > lightest of the groupin this case fluorineis the most > reactive. 1957 G. E. HUTCHINSON Treat Limnol. I. xi. 708 It is not > clear, however, in what form this reactive iron is actually > present in the lake water. 1972 R. A. JACKSON Mechanism iv. 78 A > trapping or inhibiting agent may be insufficiently > reactive towards a particular intermediate to divert it from its > normal course of reaction, or the agent may react in such a > way as to regenerate another reactive intermediate. > > > b. Of a process: involving chemical reaction. > > 1950 Chem. Abstr. XLIV. 8190 (heading) Reactive diffusion in metals. > 1960 Ibid. LIV. 23646 The reactive diffusion in a > system Nb-B is accomplished by diffusion of B atoms through the > reaction products toward the metal. 1971 New Scientist > 8 Apr. 96/1 Reactive evaporation..is often used for depositing metal > oxides. 1973 R. L. BURWELL in Basolo & Burwell > Catalysis II. 72 Ethylene is adsorbed by reactive adsorption. Perhaps > it first adsorbs as a -complex and then reacts to > monoadsorbed ethane. 1978 FELDER & ROUSSEAU Elem. Princ. Chem. > Processes x. 384 In this chapter we show..how > calculated enthalpies of reaction are incorporated in energy balances > on reactive processes. > > > c. Of a dye or other colouring material: designed to react > chemically with the substrate, usu. in order to > become fixed. > > 1957 Jrnl. Soc. Dyers & Colourists LXXIII. 238/2 The search for more > practical methods of using reactive dyes has > continued, and this work has now culminated in the production of a new > range of dyesthe Procion (ICI) dyeswhich are > water-soluble but contain a reactive group capable of combining with > cellulose under alkaline conditions. 1973 Materials & > Technol. VI. iv. 310 The direct, basic, sulphur, vat, azoic and > reactive dyes are all suitable for colouring the fibre [sc. rayon]. > a1977 Harrison Mayer Ltd. Catal. 39/1 Reactive colours, a new range of > leadless colours for underglaze, on-glaze or > in-glaze decoration... On firing, these colours react with the glaze > to give interesting and variegated effects. > > > d. Of coke or coal: having a high reactivity (sense b). > > 1963 Economist 21 Dec. 1284/1 Reconciling the clean air policy with > the British love of open fires means trying to produce > enough smokeless fuel of the sort that can be burnt in the fireplaces > of smokeless zones. But the Minister of Power now > estimates that there will be a gap..between the demand for such > `reactive' smokeless fuels and the supply. 1974 Encycl. > Brit. Macropædia IV. 783/2 Coals of medium rank are used for > low-temperature carbonization because they yield reactive > cokes. > > > 6. a. Electr. Possessing or pertaining to electrical reactance; > spec. applied to the vector component of an > alternating current (or voltage) which is 90° out of phase with > respect to the associated voltage (or current), > i.e. wattless; reactive power, the product of the voltage and the > reactive current, or of the current and the > reactive voltage; reactive volt-ampere, a unit of reactive power. > > 1892 J. A. FLEMING Alternate Current Transformer II. ii. 269 > Reactive Coil or Dimmer.This is a device used in > alternating current work to serve the same ends as rheostats in direct > current plants. 1892 S. P. THOMPSON > Dynamo-Electr. Machinery (ed. 4) xxii. 628 We have here two > electromotive-forces, the impressed O A and the reactive > A E..with their resultant the effective electromotive-force O E, with > an angle E O A..between them. 1914 J. H. > MORECROFT Continuous & Alternating Current Machinery vi. 205 The > component of voltage 90° out of phase with the > current we shall call the reactive component of the voltage or > reactive voltage. 1916 Standardization Rules Amer. Inst. > Electr. Engineers 15 Reactive volt-amperes, the product of the > reactive component of the voltage by the total current, or of > the reactive component of the current by the total voltage. 1920 > Whittaker's Electr. Engineers's Pocket-Bk. (ed. 4) 222 > The reactive current changes from leading to lagging as the field > excitation is reduced. 1951 W. SLUCKIN Princ. Alternating > Currents ix. 225 In an induction motor, neglecting heating losses, the > active component provides the useful mechanical > power delivered by the motor, while the reactive component is > associated with the production of the alternating magnetic > field necessary for the operation of the motor. 1956 C. S. SISKIND > Electr. Circuits xi. 265 The vertical componentthe > quadrature componentis EI sin . The latter, acting adversely to lessen > the power factor, is expressed as the reactive > volt-amperes, abbreviated R-va. 1961 Listener 9 Nov. 768/2 There is > also the problem, with direct current lines, of > providing what is called the reactive powerpower where the current is > out of step with the voltagefor the operation of > converter equipment. 1970 J. EARL Tuners & Amplifiers iv. 83 The > source itself can be mostly resistive or mostly reactive. > 1978 Gramophone May 1958/1 It is claimed to have an output of 100 > watts RMS working into an 8-ohm inductive or > reactive load. > > > b. Mech. and Acoustics. Possessing or pertaining to mechanical or > acoustic impedance. > > 1934 OLSON & MASSA Applied Acoustics ii. 32 (caption) Resistive and > reactive air load per unit area on one side of a > vibrating piston of radius R centimeters set in an infinite baffle. > 1963 [see IMPEDANCE 2]. 1976 A. H. BENADE Fund. of > Musical Acoustics xxi. 457/2 The other register hole on my special > clarinet can be called a reactive register hole, i.e., an > aperture in which the flow depends mainly on the inertia of the air > moving through it. > > > 7. Gram. (See quot.) rare. > > 1957 R. W. ZANDVOORT Handbk. Eng. Gram. V. ii. 224 To express the > speaker's reaction to a previous statement by the > person addressed which is repeated by the speaker (reactive > questions)... You can't catch me.I can't, can't I? said > Philip. > > > B. n. Chem. [ad. F. réactif.] A reagent. rare. > > [1790 Monthly Rev. III. 546 Chemical tests, or, as the French call > them, reactives.] 1791 HAMILTON Berthollet's Dyeing > I. I. II. iv. 192 A chemist should be employed for preparing a proper > reactive. 1887 BROWNING Parleyings, C. Avison ix, > Reviewing learnedly the list complete Of chemical reactives. > > > Hence reactively adv. So reactiveness (Webster 1847) = next. > > 1805 FOSTER Ess. I. ii. 30 The living world..is re-actively throwing > on him various moral influences and infections. 1860 A. > L. WINDSOR Ethica v. 285 A very irritable temper, that bore him > reactively into close relationship with a few. > > > > ++++++++++++ PROACTIVE ++++++++++++++++++++++ > > Of a person, policy, etc.: that creates or controls a situation by > taking the initiative or by anticipating events > (as opp. to responding to them); also loosely, innovative, tending to > make things happen. (Freq. in > management or business contexts.) > > 1971 A. J. R. REISS Police & Public ii. 64 Citizens usually bring > matters to police attention...The police department deals > with such requests as a reactive organization...The police also > acquire information by intervening in the lives of citizens on > their own initiative. In this capacity, they serve as a proactive > organization. 1977 D. M. SMITH Human Geogr. xi. 327 By > comparing conditions before and after the change in the five reactive, > control, and proactive [sc. police] beats, the > effectiveness of this strategy could be judged. 1980 W. SAFIRE in N.Y. > Times Mag. 2 Mar. 9/2 Webster says he has been > forced to choose between `reactive' law enforcementresponding after a > bank has been robbedand `pro-active' > enforcement, in which his men are in on the planning stages of a > crime. 1984 Financial Times 10 Feb. 26 A new kind of > management able to take risks,..manage change, and be more proactive. > 1985 Globe & Mail (Toronto) 10 Oct. B20/1 > (Advt.), If you are the proactive and innovative individual we are > looking for..we invite you to submit a resume in > confidence. > > > Hence proactively adv.; proaction, proactivity, proactive > behaviour or practice. Also [as > back-formation] proact v. intr., to take proactive measures; to act in > advance, to anticipate. > > 1978 J. ALDERSON Communal Policing p. i, The education of a > community and a police force in joint pro-activity was seen > as the only way to reduce morbidity of crime levels. 1980 Times 3 Nov. > 16/3 We anticipate, we plan, we pro-act rather than > react to change. 1984 N.Y. Times 14 Oct. XI. 30/5 Determinate > sentencing, as an alternative to parole, forces the system to > wait for the smoking gun, rather than proactively intervene before > another terrible tragedy. 1985 R. C. A. WHITE Admin. of > Justice IV. xiv. 256 A distinction which separates the practice of law > in law centres from that in private practice is that > between reactivity and proactivity. 1986 Mag. Bank Admin. June 41/1 > Aggressiveness, proaction or other performance > criteria are paramount. 1986 Industry Week 23 June 52/1 This > versatility is allowing us to proact rather than react to > changing market conditions. > > ++++++++++++++++++++++++++++++ ACTIVE ++++++++++++++++++++++++++ > > gen. Characterized by action. Hence > > A. adj. > > 1. a. Opposed to contemplative or speculative: Given to outward > action rather than inward contemplation > or speculation; practical; esp. with `life.' (Also formerly absol. in > pl. sc. virtues, faculties.) > > 1340 Ayenb. 199 Holy writ ous tek tuo maneres of liue..e verste is > yhote workvol [active] vor et hi is ine zuynch of > guode workes. 1340 HAMPOLE Prose Tr. 24 Vnto thes men itt longith som > tyme to vsene werkis of mercy in actife liffe. > 1362 LANGL. P. Pl. A VII. 236 Actyf lyf or contemplatyf · Crist wolde > hit alse. c1400 Apol. for Loll. 23 Also ei tokun actifis > & contemplatifis; at sterun to vertewe be er two maneris. 1401 Pol. > Poems II. 63 There is maad mencion of two perfit > lyves, that actif and contemplatif comounli ben callid, ffulli figurid > by Marie and Martha hir sister. 1538 STARKEY England 4 > But wether hyt [i.e. perfection] stond in the actyve lyfe.. or els in > the contemplative..hyt ys not al sure. 1604 SHAKES. Oth. > I. iii. 271 My speculative and active [1623 offic'd] instruments. 1609 > TOURNEUR Fun. Poeme 355 All his industries (As > well in actives as contemplatives). 1660 T. STANLEY Hist. Philos. > (1701) 161/1 Philosophy concerns either action or > contemplation (thence assuming two names, Contemplative and Active) > the Active consisting in practice of moral Actions, > the Contemplative, in penetration of abstruse Phisical causes, and the > nature of the Divinity. 1828 D. STEWART Wks. VI. > 122 As the operations in the minds of other men escape our notice we > can judge of their activity only from the sensible > effects it produces; thence we are led to apply the character of > activity to those whose bodily activity is the most > remarkable, and to distinguish mankind into two classes, the Active > and the Speculative. > > > b. Practical, as opposed to theoretical. Obs. > > 1609 DOULAND Orinth. Microl. 2 Active Musicke, which also they call > Practick, is..the knowledge of singing well. > > > 2. Opposed to passive: Originating or communicating action, > exerting action upon others; acting of its own > accord, spontaneous. In 17th c. often absol. in pl. sc. qualities, > forces. > > c1400 Apol. for Loll. 14 God may not autorise at actyfe cursyng..But > passyue cursyng..is just. 1413 LYDGATE Pylg. > Sowle II. lx. (1859) 57 Quod the body..thou were in me actyf as fire > is in the wood, and I in to the passyf as woode is in the > fyre. 1477 NORTON Ordin. Alch. v. (Ashmole 1652) 54 Heate, and Cold, > be qualities Active, Moisture, and Drines, be > qualityes Passive. 1592 W. WEST Symbolæogr. I. 48G. The actiue person > in Instrumentes is he which maketh the > Instruments. 1677 HALE Prim. Orig. Man. IV. v. 332 If it should be in > the power of an Angel by applying actives to passives > to produce an Insect. 1736 BUTLER Analogy I. v. 117 Perception of > danger is a natural Excitement of passive fear and active > caution. 1846 MILL Logic III. iii. §9 (1868) 292 Objects which they > first believed to be intelligent and active are really > lifeless and passive. 1876 FREEMAN Norm. Conq. II. x. 492 The treasons > of Eadwine were often passive rather than > active. > > > 3. Grammar. a. properly, An epithet of Voice in verbs used > transitively; opposed to Passive (and, in some > languages, to Reflexive or Middle). That form of the verb in which the > action asserted by it is viewed as a > characteristic or attribute of the thing whence it issues, as opposed > to the Passive Voice in which the action > is viewed as an attribute of the thing towards which it is directed; > or, that form of the verb in which the > logical subject of the action is made by the speaker the grammatical > subject of his assertion, as shown by the > verb's agreement with it in inflections, by position, or otherwise. > This being (in Aryan Languages) the simple > or original form, verbs used intransitively naturally have no other, > and are said to have the Active Voice only. > > b. Less correctly, said of verbs themselves; in two senses. 1. > Applied to verbs which assert that the > subject acts upon or affects something else, as distinguished from > Passive Verbs, or such as assert of the > subject that it is acted on by something or suffers the action, and > Neuter Verbs which assert an action or > state that has neither character. 2. Applied to all verbs that assert > action as distinct from mere existence or > state; in this sense Active Verbs are divided into Active Transitive, > in which the action passes over to or > affects an object, as kill (corresponding to the Active of 1), and > Active Intransitive, in which the action does > not affect an object, as rise (forming part of the Neuter verbs of 1), > Neuter in this nomenclature being > restricted to verbs of existence or state, as be, sit. > Both of these uses of the word are etymologically defensible, but > both are inconvenient: the distinction between action > and state is not always clear, and above all is one of things, not of > assertions about them; that of action and passion is > merely that of two ways of viewing and asserting the same action; > while the passing over of an action to an object or the > contrary is better expressed by Transitive and Intransitive, and is > moreover not a division of verbs, but of the > constructions of each verb separately, the great majority of verbs in > Eng. having both constructions. > > 1530 PALSGR. 4 The thyrde parsonnes plurelles of verbes actyves in > the frenche tonge..ende in ent. 1591 PERCIVALL > Span. Dict. Cb, Of Uerbs personals there be three kinds, Actiue, > Passiue and Neuter. 1765 W. WARD Ess. Gram. 59, A > verb in the active voice very frequently denotes a state which implies > no real action, as for instance to suffer; and so, a verb > in the passive voice frequently denotes a state which implies no real > suffering, as to be found. 1876 MASON Eng. Gram. 59 > We may speak of one and the same action by means either of a verb in > the active voice, or of a verb in the passive voice. > > > 4. a. Opposed to quiescent or extinct: Existing in action, > working, effective, having practical operation or > results. active list (see LIST n.6); also transf.; active service, war > service in the field, at sea, or in the air. > > 1640-4 CAPT. MERVIN in Rushworth Hist. Coll. III. (1692) I. 214 The > Gray-headed Common Laws Funeral; and the > Active Statutes death and Obsequies. 1790 BOSWELL Johnson xxiv. > (Rtldg.) 215 Here was one of the many, many > instances of his active benevolence. 1790 BURKE Fr. Rev. 39 The whole > government would be under the constant > inspection and active controul of the popular representative and of > the magnates of the kingdom. 1829 [see SERVICE n.1 12]. > 1830 LYELL Princ. Geol. I. 317 Kamtschatka, where there are seven > active volcanos. 1838 Navy List 20 Sept. 118 > Alphabetical List of Masters. Those in Italics are unfit for active > Service. 1852 Ibid. 20 Dec. 327 The number of Captains on > the Active List will be reduced to a number not permanently exceeding > 350. 1857 LIVINGSTONE Travels vi. 113 It contains > an active poison. 1876 FREEMAN Norm. Conq. II. vii. 102 Weary of > tarrying where there was no chance of active service. > 1878 HUXLEY Physiogr. 79 It is the oxygen which is the active agent. > 1899 KIPLING Absent-Minded Beggar i, He is out on > active service, wiping something off a slate. 1906 Harmsworth Encycl. > VII. 576/2 No officer on the active list is allowed to > leave the United Kingdom without special permission. 1907 Jrnl. Soc. > Arts LV. 429/1 Of these only the Remington and the > Hammond are to-day on the active list. > > > b. spec. in Physics, = RADIOACTIVE a. > > 1900 RUTHERFORD in Phil. Mag. XLIX. 163 The top layer of paper over > the thorium was found to be active on its upper > side. 1905 [see active deposit]. 1938 R. W. LAWSON tr. Hevesy & > Paneth's Man. Radioactivity (ed. 2) x. 120 Active > isotopes that are lighter than the stable types disintegrate with > emission of positrons. > > > 5. Opposed to sluggish or inert: Abounding in action; energetic, > lively, agile, nimble; diligent, busy, brisk. > (Of persons and things.) > > 1597 SHAKES. 2 Hen. IV, IV. iii. 24, I were simply the most actiue > fellow in Europe. 1609 Man in the Moone (1849) 31 It > maketh her unfitte to performe any agill or active thing. 1666 PEPYS > Diary (1879) III. 485 He being the activest man in the > World. 1718 POPE Iliad xv. 683 So strong to fight, so active to > pursue. 1786 COWPER Lett. 31 Jan. Wks. 1876 224 > Infirmities..which make him less active than he was. 1857 BUCKLE > Civil. iii. 142 Now, the richest Countries are those in > which man is most active. 1863 FAWCETT Pol. Econ. III. vi. 371 An > active demand for any other commodity is characterised > by a rise in its price or value. 1866 ROGERS Agric. & Prices I. xxiii. > 599 The most active seat of the trade. 1880 Manch. > Guardian 16 Dec. 4/4 The market to-day has been more active than for a > considerable time. > > > 6. On the credit side of the balance-sheet, of the nature of an > asset; as opposed to passive, i.e. of the > nature of a liability. (Common in Fr., but hardly English.) > > 1875 POSTE Gaius III. 350 Selling the active and passive > universality of the insolvent's estate..to a purchaser who became > liable to the insolvent's creditors. > > > 7. Used as the first element in such obv. Comb. as active-bodied, > active-limbed, active-minded. > > 1870 BRYANT Homer I. v. 152 There the active-limbed, Fleet Iris > stayed them. 1837 WHEWELL Induct. Sc. (1857) I. 121 > The pleasure which..active-minded men feel in exercising the process > of deduction. 1878 SEELEY Stein III. 547 The more > active-minded among his contemporaries. > > > 8. Comb. active carbon, charcoal = activated carbon, charcoal (see > ACTIVATE v. b); active current > Electr. (see quot. 1926); active deposit Physics (see quot. 1955); > active layer Geomorphol., a surface > layer of soil, overlying permafrost, that freezes in winter and thaws > in summer; active mass Chem., the > molecular concentration of a substance (see mass-action (b) s.v. MASS > n.2). > > 1918 Jrnl. Industr. & Engin. Chem. X. 813/2 If our object is to > make an active carbon, none of the mineral matter must be > removed before heating. 1921 Jrnl. Soc. Chem. Industry XL. (Trans.) > 231/1 All the secret process active carbons come upon > the market in the form of a fine powder. 1938 Thorpe's Dict. Appl. > Chem. II. 319/2 Active charcoal is widely used in industry > for the recovery of valuable products which exist as attenuated > vapours in unadsorbable gases. > > 1924 S. R. ROGET Dict. Electr. Terms 2 Active current. 1926 Gloss. > Terms Electr. Engin. (B.S.I.) 30 Active current, that > component of an alternating current (regarded as a vector quantity) > which is in phase with the voltage. > > 1905 RUTHERFORD in Phil. Trans. R. Soc. 1904 A. CCIV. 172 In speaking > generally of the active matter, which causes > excited activity, without regard to its constituents, I have used the > term `active deposit'. 1906 Radioactive > Transformations iv. 95 All bodies surrounded by the radium emanation > become coated with an invisible active deposit, > possessing physical and chemical properties which sharply distinguish > it from the emanation. 1955 Gloss. Terms Radiology > (B.S.I.) 6 Active deposit, solid radioactive deposit formed by the > decay of a radioactive emanation. > > 1943 S. W. MULLER Permafrost 5 Above the permafrost is a layer of > ground that thaws in the summer and freezes again in > the winter. This layer represents the seasonally frozen ground and is > called the active layer. 1977 A. HALLAM Planet > Earth 89 The churning of the active layer by freezing and thawing > prevents the development of a stable soil structure. > > 1909 Cent. Dict. Suppl., Active mass. 1910 Encycl. Brit. VII. 27/1 > These spatial concentrations are often called the `active > masses' of the reacting components. 1932 PHILBRICK & HOLMYARD Text Bk. > Theoret. & Inorg. Chem. II. iii. 110 This law > was first enunciated in 1864 [in Forhandl. i Vidensk.-Selsk. i > Christiania, p. 92] by Guldberg and Waage, who stated that > the rate at which a substance reacted was proportional to its active > mass. > > > > > B. n. > > 1. A person devoted to the active life. (Cf. adj. 1 and > CONTEMPLATIVE n. 1.) > > c1380 [see CONTEMPLATIVE B. n. 1]. a1425 Cloud of Unknowing (1944) > 5/18 Into is day alle actyues pleynen hem of > contemplatyues, as Martha did on Mary. 1671 PHILLIPS New World of > Words, Actifs, an order of Fryars, that feed on > Roots, and wear tawny habits. 1946 E. A. PEERS Fool of Love vii. 118 > It is as an active that Ramon [Lull] appeals to the > present age most widely. 1950 A. HUXLEY Themes & Variations 154 Were > there not then, as always, a few ardent > contemplatives and actives? > > > 2. [Elliptical uses of the adj.] a. See ACTIVE a. 1, 2. > > b. Gram. The active voice; an active verb. Cf. PASSIVE n. 2. > > 1530 PALSGR. Introd., The actyves have but the pronowne or > substantyve before the verbe. 1582 G. MARTIN Discoverie > Manifold Corruptions i. 13 If passives must be turned into actives, > and actives into passives, participles disagree in case > from their substantives..: who would so presume in the text of holy > Scripture, to haue al grammar..at his commaundement, > but Beza & his lik? 1611 BRINSLEY Pos. Parts. (1669) 29 Cannot a Verb > Neuter take r, to make it a Passive, as Actives > do? c1620 A. HUME Orthogr. Brit. Tongue (1865) 32 Verbes of doing are > actives or passives. The active verb adheres to > the person of the agent; as, Christ hath conquered hel and death. 1669 > MILTON Accedence 20 The Active Signifieth to do, > and always endeth in o, as Doceo, I teach. 1818 E. V. BLOMFIELD tr. > Matthiæ's Gr. Gram. II. 710 The effect of the active > consists in determining the case which it governs. 1879 W. W. GOODWIN > Elem. Greek Gram. (new ed.) 110 The > uncontracted forms of the future active and middle of ..are found in > Homer and Herodotus. 1933 O. JESPERSEN > Essent. Eng. Gram. xii. 121 The subject of a passive verb is what in > the active would be an object. But if in the active there > are two objects, only one of them can be made the subject. 1973 N. S. > SMITH tr. Ruwet's Introd. Generative Gram. vi. 114 > This solution..still does not allow the formal indication of the > relation between the passive (3) and the active (4). 1985 R. > QUIRK et al. Comprehensive Gram. Eng. Lang. 163 In English, > prepositional verbs..can often occur in the passive, but not > so freely as in the active. > > > Regs. > > Theo > > UCL/Mobile Systems > From owner-seamoby@diameter.org Thu Aug 16 14:31:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18660 for ; Thu, 16 Aug 2001 14:31:52 -0400 (EDT) Received: (qmail 27540 invoked by alias); 16 Aug 2001 18:20:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27534 invoked by uid 200); 16 Aug 2001 18:20:23 -0000 Received: (qmail 27529 invoked from network); 16 Aug 2001 18:20:21 -0000 Received: from mailb.telia.com (root@194.22.194.6) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 18:20:21 -0000 Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242]) by mailb.telia.com (8.9.3/8.9.3) with SMTP id UAA09613 for ; Thu, 16 Aug 2001 20:31:59 +0200 (CEST) From: "Henrik Levkowetz" To: Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 20:31:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108161741.KAA17387@heliopolis.eng.sun.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > Folks, > > At the risk of sounding hysterical, can we PLEASE come to some concensus > on this and move on? We seem to be stuck in an infinite loop trying > to number the angels that dance on the point of a pin. I thought > we had concensus at the meeting. Yes. So did I. Let's get on with it! Regards, Henrik > > Requirements are meant to be general guidelines for development > of the protocol, and to exclude obviously inappropriate features. > If people can't agree on a narrow scope, then let's define the > requirement as broadly as possible and let the protocol designers > decide what's appropriate for the particular feature they want > to transfer. It sounds to me like that's going to be the case > anyway > > Sorry. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: john.loughney@nokia.com > >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, > henrik@ipunplugged.com > >Subject: RE: [seamoby] Update on Issues from IETF meeting > >Date: Thu, 16 Aug 2001 20:23:59 +0300 > > > >Hi all, > > > >I think that CT could happen under the following conditions: > > 1) Before handoff > > 2) During handoff > > 3) After handoff > > > >Futher more, I see it as feasible that: > > 1) All context (for a particular CTP instance) could be sent in a single > >packet (subject to MTU) > > 2) Context (for a particular CTP instance) could be sent seperately > > > >I think that it depends on the situation, implementation and requirements > >for the particular context being transfered. > > > >I request that the CT requirements allow for this. > > > >thanks, > >John > > From owner-seamoby@diameter.org Thu Aug 16 15:15:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20367 for ; Thu, 16 Aug 2001 15:15:13 -0400 (EDT) Received: (qmail 28201 invoked by alias); 16 Aug 2001 19:03:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28195 invoked by uid 200); 16 Aug 2001 19:03:53 -0000 Received: (qmail 28190 invoked from network); 16 Aug 2001 19:03:51 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 19:03:51 -0000 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id EAA10043 for ; Fri, 17 Aug 2001 04:15:33 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id EAA18913; Fri, 17 Aug 2001 04:15:33 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id EAA19607; Fri, 17 Aug 2001 04:15:32 +0900 (JST) Received: from localhost ([172.30.24.47]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0GI600K24DEFHH@tsbpo1.po.toshiba.co.jp> for seamoby@cdma-2000.org; Fri, 17 Aug 2001 04:13:32 +0900 (JST) Date: Thu, 16 Aug 2001 15:15:25 -0400 (LDT) From: NAKAJIMA Nobuyasu Subject: [seamoby] What message should Paging Agent send out? In-reply-to: <87ofpq43wm.wl@catfish.research.telcordia.com> To: seamoby@cdma-2000.org Message-id: <20010816.151525.60851380.nobuyasu.nakajima@toshiba.co.jp> MIME-version: 1.0 X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <87ofpq43wm.wl@catfish.research.telcordia.com> Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Though the definition of Paging Agent in RFC3154 (paging requirement) is ambiguous when we consider what message the Paging Agent sends out, I think that DMHA's Paging Agent should send IP paging message out to alert the dormant host. This means that some entity which converts the IP paging message to L2 paging message is necessary (if L2 paging is utilized). I think that taking the converting function out of DMHA's Paging Agent is a good idea, because at the same time, we can take out the implementation issue that how Paging Agent deals with L2 paging. Comments? Nobuyasu ----- Nobuyasu Nakajima Toshiba America Research, Inc. From owner-seamoby@diameter.org Thu Aug 16 15:21:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20476 for ; Thu, 16 Aug 2001 15:21:15 -0400 (EDT) Received: (qmail 28717 invoked by alias); 16 Aug 2001 19:09:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28711 invoked by uid 200); 16 Aug 2001 19:08:59 -0000 Received: (qmail 28706 invoked from network); 16 Aug 2001 19:08:57 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 19:08:57 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 20:20:33 +0100 Message-ID: <3B7C1CFF.43BA07A@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 20:20:31 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: G.Tsirtsis@flarion.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting References: <0C1353ABB1DEB74DB067ADFF749C4EEF094196@esebe004.NOE.Nokia.com> Content-Type: multipart/alternative; boundary="------------1039302959578646FF86000E" Sender: owner-seamoby@diameter.org Precedence: bulk --------------1039302959578646FF86000E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello John, although the before (proactive), during (active), after (reactive) is indeed correct, I would object to the specific of the event, that is the 'handoff' This seriously restricts the solution space since you do not necessarily want to restrict yourself for context transfer around handoffs only. It may well be something else, something which is not a handoff. This is exactly why Gary actually wonder (rhetorically :) what is a handoff IMHO. In that sense, I would be strongly in favour of identifying in the requirement that: CT may be effected after (reactively), before (proactively), during (actively) and _event_ not a specific instantiation of an event such as a 'handoff'. I do not think any requirements must make any assumptions whether the CT state for some state class should be restricted to a size of number of packets. However the requirement must allow for time phases that part or all of the CT may take place, or at the very least it must not preclude such possibility. Regs Theo UCL/ Mobile Systems john.loughney@nokia.com wrote: > Hi all,I think that CT could happen under the following > conditions: 1) Before handoff 2) During handoff 3) After > handoffFuther more, I see it as feasible that: 1) All context > (for a particular CTP instance) could be sent in a single packet > (subject to MTU) 2) Context (for a particular CTP instance) could > be sent seperatelyI think that it depends on the situation, > implementation and requirements for the particular context being > transfered.I request that the CT requirements allow for > this.thanks,John --------------1039302959578646FF86000E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello John,

   although the before (proactive), during (active), after (reactive) is indeed correct, I would object to the specific of the event, that is the 'handoff'

This seriously restricts the solution space since you do not necessarily want to restrict yourself for context transfer around handoffs only. It may well be something else, something which is not a handoff. This is exactly why Gary actually wonder (rhetorically :) what is a handoff IMHO. In that sense, I would be
strongly in favour of identifying in the requirement that:

CT may be effected after (reactively), before (proactively), during (actively) and _event_  not a specific instantiation of an event such as a 'handoff'.

I do not think any requirements must make any assumptions whether the CT state for some state class should be restricted to a size of number of packets. However the requirement must allow for time phases that part or all of the CT may take place, or at the very least it must not preclude such possibility.
 

Regs

Theo

UCL/ Mobile Systems
 
 

john.loughney@nokia.com wrote:

 Hi all,I think that CT could happen under the following conditions:    1) Before handoff    2) During handoff    3) After handoffFuther more, I see it as feasible that:    1) All context (for a particular CTP instance) could be sent in a single packet (subject to MTU)    2) Context (for a particular CTP instance) could be sent seperatelyI think that it depends on the situation, implementation and requirements for the particular context being transfered.I request that the CT requirements allow for this.thanks,John
--------------1039302959578646FF86000E-- From owner-seamoby@diameter.org Thu Aug 16 16:06:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21708 for ; Thu, 16 Aug 2001 16:06:20 -0400 (EDT) Received: (qmail 29971 invoked by alias); 16 Aug 2001 19:55:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29965 invoked by uid 200); 16 Aug 2001 19:55:02 -0000 Received: (qmail 29960 invoked from network); 16 Aug 2001 19:55:00 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 19:55:00 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 21:06:39 +0100 Message-ID: <3B7C27CB.7B43B9A7@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 21:06:35 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] ACTIVE,PROACTIVE,REACTIVE et al. References: <3B7BD38F.73ABD756@cs.ucl.ac.uk> <20010816105506.C26352@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, :)) well, so far (last two months) I have heard people using the terms without a dictionary. The thing is that we had to use some authority (a dictionary) to prove a point. If people have been using the terms without knowing (or pretending that they know) what it is then I stand amazed...but I think this has not been quite the case so far.. Theo UCL/ Mobile Systems Pat Calhoun wrote: > That's all fine and good, but I think that people want to read documents > and not require a dictionary to grasp the actual meaning of the language > used. > > :) > > PatC From owner-seamoby@diameter.org Thu Aug 16 16:08:49 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21767 for ; Thu, 16 Aug 2001 16:08:48 -0400 (EDT) Received: (qmail 30393 invoked by alias); 16 Aug 2001 19:56:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30385 invoked by uid 200); 16 Aug 2001 19:56:47 -0000 Received: (qmail 30368 invoked from network); 16 Aug 2001 19:56:43 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 19:56:43 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 21:08:10 +0100 Message-ID: <3B7C2828.6F267073@cs.ucl.ac.uk> Date: Thu, 16 Aug 2001 21:08:08 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: James Kempf CC: G.Tsirtsis@flarion.com, john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting References: <200108161741.KAA17387@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi James, I couldn't agree more with it. But if it is requirements that we care about we need to be careful now or regret it later.. Consensus is of course the ultimate objective.. Theo UCL/ Mobile Systems James Kempf wrote: > Folks, > > At the risk of sounding hysterical, can we PLEASE come to some concensus > on this and move on? We seem to be stuck in an infinite loop trying > to number the angels that dance on the point of a pin. I thought > we had concensus at the meeting. > > Requirements are meant to be general guidelines for development > of the protocol, and to exclude obviously inappropriate features. > If people can't agree on a narrow scope, then let's define the > requirement as broadly as possible and let the protocol designers > decide what's appropriate for the particular feature they want > to transfer. It sounds to me like that's going to be the case > anyway > > Sorry. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: john.loughney@nokia.com > >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, > henrik@ipunplugged.com > >Subject: RE: [seamoby] Update on Issues from IETF meeting > >Date: Thu, 16 Aug 2001 20:23:59 +0300 > > > >Hi all, > > > >I think that CT could happen under the following conditions: > > 1) Before handoff > > 2) During handoff > > 3) After handoff > > > >Futher more, I see it as feasible that: > > 1) All context (for a particular CTP instance) could be sent in a single > >packet (subject to MTU) > > 2) Context (for a particular CTP instance) could be sent seperately > > > >I think that it depends on the situation, implementation and requirements > >for the particular context being transfered. > > > >I request that the CT requirements allow for this. > > > >thanks, > >John From owner-seamoby@diameter.org Thu Aug 16 17:05:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22821 for ; Thu, 16 Aug 2001 17:04:58 -0400 (EDT) Received: (qmail 31249 invoked by alias); 16 Aug 2001 20:45:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31243 invoked by uid 200); 16 Aug 2001 20:45:12 -0000 Received: (qmail 31235 invoked from network); 16 Aug 2001 20:45:09 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 20:45:09 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GKu0p14719 for ; Thu, 16 Aug 2001 16:56:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 16 Aug 2001 16:56:04 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 16:56:07 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F05@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: Theo Pagtzis , seamoby@cdma-2000.org, Cedric Westphal , Henrik Levkowetz Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 16:56:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12695.E0353310" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12695.E0353310 Content-Type: text/plain; charset="iso-8859-1" That was my point Pat. Thanks. > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, August 16, 2001 1:19 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; Theo Pagtzis; seamoby@cdma-2000.org; > Cedric Westphal; > Henrik Levkowetz > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > Since the MIP WG doesn't have a problem with this term, I don't see > why we need to open that can of worms. > > Do we want to move on, or spend more cycles arguing > terminology and push > our milestones out further? > > PatC > On Thu, Aug 16, 2001 at 01:15:11PM -0400, Gary Kenward wrote: > > But what is "handoff"? > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, August 16, 2001 10:25 AM > > > To: Theo Pagtzis > > > Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz > > > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > > > > > > > Theo, > > > > > > My problem wasn't the terms active,proactive,reactive, but > > > the rather long text > > > accompanying the terms, which caused nothing but confusion > > > and would open up > > > cans of worms. I find John's proposal to be short and to > the point. > > > > > > If you think that something along the lines of: > > > > > > "Context Transfer MAY occur before (proactive), during > > > (active) and after (reactive) > > > a handoff." > > > > > > would be more acceptable since it keeps the terminology in > > > place, I wouldn't be > > > against it, and would welcome comments. > > > > > > PatC > > > On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote: > > > > Ced/All, > > > > > > > > First just to comment that having done some work for the > > > design of a proactive mobility > > > > framework, I can only see that > > > > at the end of the day the terminology will boil down to > > > whatever people's taste sees fit as a term > > > > compliant with the timing intrinsincs of context transfer. > > > > > > > > However, I would like to argue in favor of the terms > > > active, proactive and reactive, not because I > > > > have writen a draft about proactive mobility but because I > > > have substantial reasons to believe that > > > > the terms are generic enough to encompass the entire time > > > continuum of _any_ event (not just > > > > context transfer) > > > > > > > > As I said in the seamoby meeting the meaning of active > > > (during), reactive (after) and proactive > > > > (before) depends first on the reader and really has got a > > > fractal nature with respect to the > > > > magnitude of > > > > application of the notions since they really do not apply > > > just to a mode of operation as people > > > > _erroneously_ consider. Much like a fractal they apply to > > > a set of modes, or to an ontology of set > > > > of modes, or to a set of ontologies of sets of modes, > > > etc...ad infinitum > > > > > > > > Just to exhibit the futility of the discussion on the > > > matter and the fact that at the end of the > > > > day it is more who influences whom (everybody company hats > > > on) rather what the terminology really > > > > reflects I will only cite the meaning of the terms > > > PROACTIVE and REACTIVE from what else, the one > > > > and only source of objectivity which if we do not respect > > > we might as well throw dictionaries away, > > > > deny authority of linguists, and identify a tech > > > terminology anarchy where only the strongest > > > > (hello hats) survives > > > > > > > > I am not going to comment on what the oxford dictionary > > > says because I expect people to be able to > > > > identify the etymology of the terms as supplied by the > > > experts of linguistics, in the light of > > > > objectivity: > > > > > > > > > > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q > > > ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type > =alpha&search_ > > id=Iz5i-> rrbDl0-705 > > > > > > > > Let us now visit the etymology of the word REACTIVE > > > > > > > > > > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q > > > ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&so > rt_type=alpha > > > > > > > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4 > > > > > > > > Last but not least the word Active > > > > > > > > http://dictionary.oed.com/cgi/entry/00002214 > > > > > > > > I stress the multiplicity of meaning but stick to notions > > > of 1.a, 3.b, 4.a, 5. > > > > > > > > People managed to stick to the terms the label 'mode'.... > > > WHY did this happen? ..because it serves > > > > them better for the purposes of dissmissing the terms or is > > > it because they have a narrow view of > > > > the world, or is it maybe because they do not really > > > consider the real meaning of the terms? I > > > > wonder... > > > > > > > > A CT protocol MUST support at least one of these if it is > > > expected to work in this time dimension > > > > > > > > As such to me the above means that: > > > > > > > > 'a CT protocol MUST support a minimum of at least one time > > > class of event servicing with respect to > > > > mobility, that is active,reactive or proactive event > > > servicing for the purposes of mobility aware > > > > context transfer' > > > > > > > > What are the events? I don't care (and why should I) it may > > > be a handoff, it may the connection, it > > > > may be foobar. > > > > > > > > The above mean to me that the terms above describe > > > accurately a 'requirement' with respect to the > > > > time period that context transfer comes in effect with > > > respect to an EVENT. The terms are elegant > > > > and comprehensive as long as people know what they mean. > > > Oxford English Dictionary attests to > > > > that... > > > > > > > > In that light the above terms do not need replacement > > > really since they do describe accurately what > > > > they are supposed to. As such I personally provide a reason > > > that what Cedric suggested augmenting > > > > the set of requirements with, is valid. It just becomes a > > > matter of taste whether people want to > > > > name it something else, like 'during, before, after' which > > > is more informal. > > > > > > > > That is not to say that I oppose to the validity of > > > 'during,before,after'. It is to say that we > > > > have been fighting over synonyms really at a time when > we already > > > > identified the right words. > > > > > > > > I would personaly like to stick to > > > active,reactive,proactive for the reasons presented above. If > > > > people feel that the 'during,before,after' works better in > > > their head then fair enough, but we just > > > > embark in yet another game of renaming things.. > > > > > > > > Regs. > > > > > > > > Theo > > > > > > > > UCL/ Mobile Systems > > > > > > > > > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > "A CT protocol SHALL support context transfer which can occur > > > > > before, during or after handover" > > > > > this is not the same as 'CT MAY occur prior to, during, > > > after', and > > > > > that makes sense to me. > > > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > > > Cedric, > > > > > > > > > > > > Stating that a protocol SHALL support context > > > transfer which > > > > > > can occur before, during or after handover blatantly > > > eliminates your > > > > > > example which does it ONLY 2 days after handoff. > > > > > > > > > > > > Henrik > > > > > > > > > > > > > > > > > > > > Henrik, > > > > > > > > > > > > > > Henrik Levkowetz wrote: > > > > > > > > > > > > > > > Cedric, > > > > > > > > > > > > > > > > Johns proposal and wording was the first > > > that cut trough > > > > > > > > the fog at the meeting, and met with overwhelming > > > agreement because > > > > > > > > it stated very simply what seems to have been many > > > people's concern > > > > > > > > -- i.e. that a CT protocol _not_ be so limited that > > > it could not handle > > > > > > > > any of the conceivable timing scenarios implied. > > > > > > > > > > > > > > > > As such, it may be obvious, but it is also > > > VERY MUCH a > > > > > > > > requirement, and may sort out unsuitable protocol > > > proposals which may > > > > > > > > not have the flexibility required. > > > > > > > > > > > > > > I disagree with this, but this flexibility is exactly > > > the point I'm bringing up. > > > > > > > The proposed requirement is so much a requirement > > > that I'd like to see ONE ctp that does NOT > > > > > > > > > > > > > > meet it. I am sorry, but a ctp that ONLY sends > > > context 2 days after a handoff > > > > > > > does satisfy the requirement, since it 'may occur > > > prior to, during or after', so why > > > > > > > not pick after? Talk about sorting out unsuitable > protocols... > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you actually have anything against it, > > > apart from it being > > > > > > > > obvious? I for one am very happy to have this > > > requirement plainly and > > > > > > > > simply stated. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Henrik > > > > > > > > > > > > > > > > Cedric Westphal wrote: > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700, > > > Cedric Westphal wrote: > > > > > > > > > > > Pat, > > > > > > > > > > > > > > > > > > > > > > thanks for the minutes. It seems it was > > > indeed pretty intense. > > > > > > > > > > > However... > > > > > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > > > > > > > > > > Serioulsy, removing the terminology is > > > not the same as removing the concept. > > > > > > > > > > > > > > > > > > > > > > > > As far as I can tell, proactive vs. > > > reactive was essentially stating when CT > > > > > > > > > > > > would occur. This, as you state, is not a > > > requirement, > > > > > > > > > > > > > > > > > > > > > > ...what I state is that saying 'CT may happen > > > prior to, during or after handoff' > > > > > > > > > > > is not a requirement, it is just stating the > > > obvious. CT must happen prior to, > > > > > > > > > > > during or after handoff, not because you > > > require it, but because basic laws of > > > > > > > > > > > physics. > > > > > > > > > > > > > > > > > > > > And most people felt that the pro/re text also > > > didn't reflect any requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stating whether or not CT could complete > > > before or after handoff is to me a > > > > > > > > > > > requirement. > > > > > > > > > > > > > > > > > > > > So how would you propose changing the text so > > > it reads as an actualy requirement? > > > > > > > > > > > > > > > > > > Together with Gary, we did propose some text. I > > > did not see much objection on the list > > > > > > > > > > > > > > > > > > about the wording, except some worries about the > > > use of the word 'mode'. > > > > > > > > > Also, I like John's proposal in Issue 7, > > > > > > > > > which if I understand it well, is to look at the > > > requirements from the context point > > > > > > > > > of view, and not from the protocol point of view. > > > Basically, looking at the container > > > > > > > > > first > > > > > > > > > to design the crane, and not design a crane and > > > see if the containers fit. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Cedric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PatC > > > > > > > > ------_=_NextPart_001_01C12695.E0353310 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Update on Issues from IETF meeting

That was my point Pat.

Thanks.

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Thursday, August 16, 2001 1:19 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; Theo Pagtzis; seamoby@cdma-2000.org;
> Cedric Westphal;
> Henrik Levkowetz
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
> Since the MIP WG doesn't have a problem with this term, I don't see
> why we need to open that can of worms.
>
> Do we want to move on, or spend more cycles arguing
> terminology and push
> our milestones out further?
>
> PatC
> On Thu, Aug 16, 2001 at 01:15:11PM -0400, Gary Kenward wrote:
> > But what is "handoff"?
> >
> > > -----Original Message-----
> > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > Sent: Thursday, August 16, 2001 10:25 AM
> > > To: Theo Pagtzis
> > > Cc: seamoby@cdma-2000.org; Cedric Westphal; Henrik Levkowetz
> > > Subject: Re: [seamoby] Update on Issues from IETF meeting
> > >
> > >
> > > Theo,
> > >
> > > My problem wasn't the terms active,proactive,reactive, but
> > > the rather long text
> > > accompanying the terms, which caused nothing but confusion
> > > and would open up
> > > cans of worms. I find John's proposal to be short and to
> the point.
> > >
> > > If you think that something along the lines of:
> > >
> > > "Context Transfer MAY occur before (proactive), during
> > > (active) and after (reactive)
> > > a handoff."
> > >
> > > would be more acceptable since it keeps the terminology in
> > > place, I wouldn't be
> > > against it, and would welcome comments.
> > >
> > > PatC
> > > On Thu, Aug 16, 2001 at 02:31:27PM +0100, Theo Pagtzis wrote:
> > > > Ced/All,
> > > >
> > > >    First just to comment that having done some work for the
> > > design of a proactive mobility
> > > > framework, I can only see that
> > > > at the end of the day the terminology will boil down to
> > > whatever people's taste sees fit as a term
> > > > compliant with the timing intrinsincs of context transfer.
> > > >
> > > > However, I would like to argue in favor of the terms
> > > active, proactive and reactive, not because I
> > > > have writen a draft about proactive mobility but because I
> > > have substantial reasons to believe that
> > > > the terms are generic enough to encompass the entire time
> > > continuum of _any_  event (not just
> > > > context transfer)
> > > >
> > > > As I said in the seamoby meeting the meaning of active
> > > (during), reactive (after) and proactive
> > > > (before) depends first on the reader and really has got a
> > > fractal nature with respect to the
> > > > magnitude of
> > > > application of the notions since they really do not apply
> > > just to a mode of operation as people
> > > > _erroneously_  consider. Much like a fractal they apply to
> > > a set of modes, or to an ontology of set
> > > > of modes, or to a set of ontologies of sets of modes,
> > > etc...ad infinitum
> > > >
> > > > Just to exhibit the futility of the discussion on the
> > > matter and the fact that at the end of the
> > > > day it is more who influences whom (everybody company hats
> > > on) rather what the terminology really
> > > > reflects I will only cite the meaning of the terms
> > > PROACTIVE and REACTIVE from what else, the one
> > > > and only source of objectivity which if we do not respect
> > > we might as well throw dictionaries away,
> > > > deny authority of linguists, and identify a tech
> > > terminology anarchy where only the strongest
> > > > (hello hats) survives
> > > >
> > > > I am not going to comment on what the oxford dictionary
> > > says because I expect people to be able to
> > > > identify the etymology of the terms as supplied by the
> > > experts of linguistics, in the light of
> > > > objectivity:
> > > >
> > > >
> > > http://dictionary.oed.com/cgi/entry/00189006?query_type=word&q
> >
> ueryword=proactive&edition=2e&first=1&max_to_show=10&sort_type
> =alpha&search_
> > id=Iz5i-> rrbDl0-705
> > > >
> > > > Let us now visit the etymology of the word REACTIVE
> > > >
> > > >
> > > http://dictionary.oed.com/cgi/entry/00198331?query_type=word&q
> >
> ueryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&so
> rt_type=alpha
> > > >
> > > > I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4
> > > >
> > > > Last but not least the word Active
> > > >
> > > > http://dictionary.oed.com/cgi/entry/00002214
> > > >
> > > > I stress the multiplicity of meaning but stick to notions
> > > of  1.a, 3.b, 4.a, 5.
> > > >
> > > > People managed to stick to the terms the label 'mode'....
> > > WHY  did this happen? ..because it serves
> > > > them better for the purposes of dissmissing the terms or is
> > > it because they have a narrow view of
> > > > the world, or is it maybe because they do not really
> > > consider the real meaning of the terms? I
> > > > wonder...
> > > >
> > > > A CT protocol MUST support at least one of these if it is
> > > expected to work in this time dimension
> > > >
> > > > As such to me the above means that:
> > > >
> > > > 'a CT protocol MUST support a minimum of at least one time
> > > class of event servicing with respect to
> > > > mobility, that is active,reactive or proactive event
> > > servicing for the purposes of mobility aware
> > > > context transfer'
> > > >
> > > > What are the events? I don't care (and why should I) it may
> > > be a handoff, it may the connection, it
> > > > may be foobar.
> > > >
> > > > The above mean to me that the terms above describe
> > > accurately a 'requirement' with respect to the
> > > > time period that context transfer comes in effect with
> > > respect to an EVENT. The terms are elegant
> > > > and comprehensive as long as people know what they mean.
> > > Oxford English Dictionary attests to
> > > > that...
> > > >
> > > > In that light the above terms do not need replacement
> > > really since they do describe accurately what
> > > > they are supposed to. As such I personally provide a reason
> > > that what Cedric suggested augmenting
> > > > the set of requirements with, is valid. It just becomes a
> > > matter of taste whether people want to
> > > > name it something else, like 'during, before, after' which
> > > is more informal.
> > > >
> > > > That is not to say that I oppose to the validity of
> > > 'during,before,after'. It is to say that we
> > > > have been fighting over synonyms really at a time when
> we already
> > > > identified the right words.
> > > >
> > > > I would personaly like to stick to
> > > active,reactive,proactive for the reasons presented above. If
> > > > people feel that the 'during,before,after' works better in
> > > their head then fair enough, but we just
> > > > embark in yet another game of renaming things..
> > > >
> > > > Regs.
> > > >
> > > > Theo
> > > >
> > > > UCL/ Mobile Systems
> > > >
> > > >
> > > >
> > > >
> > > > Cedric Westphal wrote:
> > > >
> > > > > "A CT protocol SHALL support context transfer which can occur
> > > > > before, during or after handover"
> > > > > this is not the same as 'CT MAY occur prior to, during,
> > > after', and
> > > > > that makes sense to me.
> > > > >
> > > > > Henrik Levkowetz wrote:
> > > > >
> > > > > > Cedric,
> > > > > >
> > > > > >         Stating that a protocol SHALL support context
> > > transfer which
> > > > > > can occur before, during or after handover blatantly
> > > eliminates your
> > > > > > example which does it ONLY 2 days after handoff.
> > > > > >
> > > > > >         Henrik
> > > > > >
> > > > > > >
> > > > > > > Henrik,
> > > > > > >
> > > > > > > Henrik Levkowetz wrote:
> > > > > > >
> > > > > > > > Cedric,
> > > > > > > >
> > > > > > > >         Johns proposal and wording was the first
> > > that cut trough
> > > > > > > > the fog at the meeting, and met with overwhelming
> > > agreement because
> > > > > > > > it stated very simply what seems to have been many
> > > people's concern
> > > > > > > > -- i.e. that a CT protocol _not_ be so limited that
> > > it could not handle
> > > > > > > > any of the conceivable timing scenarios implied.
> > > > > > > >
> > > > > > > >         As such, it may be obvious, but it is also
> > > VERY MUCH a
> > > > > > > > requirement, and may sort out unsuitable protocol
> > > proposals which may
> > > > > > > > not have the flexibility required.
> > > > > > >
> > > > > > > I disagree with this, but this flexibility is exactly
> > > the point I'm bringing up.
> > > > > > > The proposed requirement is so much a requirement
> > > that I'd like to see ONE ctp that does NOT
> > > > > > >
> > > > > > > meet it. I am sorry, but a ctp that ONLY sends
> > > context 2 days after a handoff
> > > > > > > does satisfy the requirement, since it 'may occur
> > > prior to, during or after', so why
> > > > > > > not pick after? Talk about sorting out unsuitable
> protocols...
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Cedric.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >         Do you actually have anything against it,
> > > apart from it being
> > > > > > > > obvious? I for one am very happy to have this
> > > requirement plainly and
> > > > > > > > simply stated.
> > > > > > > >
> > > > > > > >         Regards,
> > > > > > > >                 Henrik
> > > > > > > >
> > > > > > > > Cedric Westphal wrote:
> > > > > > > > >
> > > > > > > > > Pat Calhoun wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Aug 15, 2001 at 08:21:52AM -0700,
> > > Cedric Westphal wrote:
> > > > > > > > > > > Pat,
> > > > > > > > > > >
> > > > > > > > > > > thanks for the minutes. It seems it was
> > > indeed pretty intense.
> > > > > > > > > > > However...
> > > > > > > > > > >
> > > > > > > > > > > Pat Calhoun wrote:
> > > > > > > > > > >
> > > > > > > > > > > > > Serioulsy, removing the terminology is
> > > not the same as removing the concept.
> > > > > > > > > > > >
> > > > > > > > > > > > As far as I can tell, proactive vs.
> > > reactive was essentially stating when CT
> > > > > > > > > > > > would occur. This, as you state, is not a
> > > requirement,
> > > > > > > > > > >
> > > > > > > > > > > ...what I state is that saying 'CT may happen
> > > prior to, during or after handoff'
> > > > > > > > > > > is not a requirement, it is just stating the
> > > obvious. CT must happen prior to,
> > > > > > > > > > > during or after handoff, not because you
> > > require it, but because basic laws of
> > > > > > > > > > > physics.
> > > > > > > > > >
> > > > > > > > > > And most people felt that the pro/re text also
> > > didn't reflect any requirements.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Stating whether or not CT could complete
> > > before or after handoff is to me a
> > > > > > > > > > > requirement.
> > > > > > > > > >
> > > > > > > > > > So how would you propose changing the text so
> > > it reads as an actualy requirement?
> > > > > > > > >
> > > > > > > > > Together with Gary, we did propose some text. I
> > > did not see much objection on the list
> > > > > > > > >
> > > > > > > > > about the wording, except some worries about the
> > > use of the word 'mode'.
> > > > > > > > > Also, I like John's proposal in Issue 7,
> > > > > > > > > which if I understand it well, is to look at the
> > > requirements from the context point
> > > > > > > > > of view, and not from the protocol point of view.
> > > Basically, looking at the container
> > > > > > > > > first
> > > > > > > > > to design the crane, and not design a crane and
> > > see if the containers fit.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > > Cedric.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > PatC
> > > >
> > >
>

------_=_NextPart_001_01C12695.E0353310-- From owner-seamoby@diameter.org Thu Aug 16 17:18:31 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23098 for ; Thu, 16 Aug 2001 17:18:31 -0400 (EDT) Received: (qmail 31681 invoked by alias); 16 Aug 2001 21:01:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31678 invoked by uid 200); 16 Aug 2001 21:01:07 -0000 Received: (qmail 31669 invoked from network); 16 Aug 2001 21:01:01 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 21:01:01 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA08141; Thu, 16 Aug 2001 14:12:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GLC2Q25860; Thu, 16 Aug 2001 14:12:02 -0700 X-mProtect: Thu, 16 Aug 2001 14:12:02 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdFh5SHT; Thu, 16 Aug 2001 14:11:59 PDT Message-ID: <3B7C3720.C5DAB35E@iprg.nokia.com> Date: Thu, 16 Aug 2001 14:12:00 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Cedric Westphal , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <20010813161840.A9564@charizard.diameter.org> <3B7A84F3.639E69CA@iprg.nokia.com> <20010815071401.A1591@charizard.diameter.org> <3B7A9390.5ECD9B0C@iprg.nokia.com> <20010815084105.A3622@charizard.diameter.org> <3B7AAA15.9BEF4D83@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > this I totally agree with. I am concerned the proposed text does not reflect this though. > > But I hear where you guys at the meeting come from. Maybe an 'AND' instead of an 'OR': > > "CT may occur prior to, during AND after handoff" and let's move on. > > Take care, > > This I can live with. Fine with me as well. Regards, -Rajeev > > > PatC From owner-seamoby@diameter.org Thu Aug 16 17:20:55 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23145 for ; Thu, 16 Aug 2001 17:20:54 -0400 (EDT) Received: (qmail 31713 invoked by alias); 16 Aug 2001 21:01:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31706 invoked by uid 200); 16 Aug 2001 21:01:23 -0000 Received: (qmail 31694 invoked from network); 16 Aug 2001 21:01:18 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 21:01:18 -0000 Received: from jewels (scottcorson.lab.flarion.com [216.122.123.220]) by RRMAIL01.RADIOROUTER_NT with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q30YM8SY; Thu, 16 Aug 2001 17:12:16 -0400 Message-Id: <3.0.6.32.20010816171710.0096d7a0@127.0.0.1> X-Sender: mscorson/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 16 Aug 2001 17:17:10 -0400 To: James Kempf , t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, john.loughney@nokia.com From: "M. Scott Corson" Subject: RE: [seamoby] Update on Issues from IETF meeting Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com In-Reply-To: <200108161741.KAA17387@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk I guess I cannot agree that requirements are meant to be general guidelines as James suggests. They are meant to be more than that...certainly MUST requirements. Perhaps, as a way out of this rathole, we could simply change the draft title from General Requirements for a Context Transfer Framework to General *Guidelines* for a Context Transfer Framework As a requirements doc, the draft has problems. As a guidelines doc, it's OK. I know the group was in requirements mode, but it seems to have produced a guidelines draft. We could just acknowledge that and propose some protocols. -Scott At 10:41 AM 8/16/01 -0700, James Kempf wrote: >Folks, > >Requirements are meant to be general guidelines for development >of the protocol, and to exclude obviously inappropriate features. >If people can't agree on a narrow scope, then let's define the >requirement as broadly as possible and let the protocol designers >decide what's appropriate for the particular feature they want >to transfer. It sounds to me like that's going to be the case >anyway > >Sorry. > > jak > >>Delivered-To: seamoby-list@charizard.diameter.org >>From: john.loughney@nokia.com >>To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com >>Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, >henrik@ipunplugged.com >>Subject: RE: [seamoby] Update on Issues from IETF meeting >>Date: Thu, 16 Aug 2001 20:23:59 +0300 >> >>Hi all, >> >>I think that CT could happen under the following conditions: >> 1) Before handoff >> 2) During handoff >> 3) After handoff >> >>Futher more, I see it as feasible that: >> 1) All context (for a particular CTP instance) could be sent in a single >>packet (subject to MTU) >> 2) Context (for a particular CTP instance) could be sent seperately >> >>I think that it depends on the situation, implementation and requirements >>for the particular context being transfered. >> >>I request that the CT requirements allow for this. >> >>thanks, >>John > > From owner-seamoby@diameter.org Thu Aug 16 17:23:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23193 for ; Thu, 16 Aug 2001 17:23:28 -0400 (EDT) Received: (qmail 341 invoked by alias); 16 Aug 2001 21:11:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 334 invoked by uid 200); 16 Aug 2001 21:11:34 -0000 Received: (qmail 316 invoked from network); 16 Aug 2001 21:11:30 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 21:11:30 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA09182; Thu, 16 Aug 2001 14:22:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GLMdT13637; Thu, 16 Aug 2001 14:22:39 -0700 X-mProtect: Thu, 16 Aug 2001 14:22:39 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdqn26O2; Thu, 16 Aug 2001 14:22:37 PDT Message-ID: <3B7C399D.43FA6839@iprg.nokia.com> Date: Thu, 16 Aug 2001 14:22:37 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > James Kempf wrote: > > Folks, > > > > At the risk of sounding hysterical, can we PLEASE come to some concensus > > on this and move on? We seem to be stuck in an infinite loop trying > > to number the angels that dance on the point of a pin. I thought > > we had concensus at the meeting. > > Yes. So did I. Let's get on with it! > > Regards, > Henrik > I was there. There it was (consensus). Here I am re-iterating it again (don't exactly know why!). Let's move on! Regards, -Rajeev > > > > > Requirements are meant to be general guidelines for development > > of the protocol, and to exclude obviously inappropriate features. > > If people can't agree on a narrow scope, then let's define the > > requirement as broadly as possible and let the protocol designers > > decide what's appropriate for the particular feature they want > > to transfer. It sounds to me like that's going to be the case > > anyway > > > > Sorry. > > > > jak > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > >From: john.loughney@nokia.com > > >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > > >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, > > henrik@ipunplugged.com > > >Subject: RE: [seamoby] Update on Issues from IETF meeting > > >Date: Thu, 16 Aug 2001 20:23:59 +0300 > > > > > >Hi all, > > > > > >I think that CT could happen under the following conditions: > > > 1) Before handoff > > > 2) During handoff > > > 3) After handoff > > > > > >Futher more, I see it as feasible that: > > > 1) All context (for a particular CTP instance) could be sent in a single > > >packet (subject to MTU) > > > 2) Context (for a particular CTP instance) could be sent seperately > > > > > >I think that it depends on the situation, implementation and requirements > > >for the particular context being transfered. > > > > > >I request that the CT requirements allow for this. > > > > > >thanks, > > >John > > > > From owner-seamoby@diameter.org Thu Aug 16 17:46:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25459 for ; Thu, 16 Aug 2001 17:45:58 -0400 (EDT) Received: (qmail 1021 invoked by alias); 16 Aug 2001 21:32:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1016 invoked by uid 200); 16 Aug 2001 21:32:38 -0000 Received: (qmail 1011 invoked from network); 16 Aug 2001 21:32:31 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 21:32:31 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GLhMp17549 for ; Thu, 16 Aug 2001 17:43:22 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 16 Aug 2001 17:43:23 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 17:43:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5F06@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Henrik Levkowetz Cc: seamoby@cdma-2000.org Subject: [seamoby] RE: [seam by] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 17:43:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1269C.7CA05300" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1269C.7CA05300 Content-Type: text/plain; charset="iso-8859-1" Consensus can not be determined at a wg meeting. We have to go through this on the email list. And so, yes, let's get on with it. Before/after or proactive/reactive - pick a pair and let's move on. I prefer the latter: I know what they mean, I know what they don't mean, and most important, I know how they can be used. BUT, I will not oppose the former, because I don't believe we will every resolve the discussion until we see real protocol proposals. And, I totally expect a future debate over the meanings of "before" and "after", but so be it. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Thursday, August 16, 2001 5:23 PM > To: Henrik Levkowetz > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] Update on Issues from IETF meeting > > > Henrik Levkowetz wrote: > > > James Kempf wrote: > > > Folks, > > > > > > At the risk of sounding hysterical, can we PLEASE come to > some concensus > > > on this and move on? We seem to be stuck in an infinite > loop trying > > > to number the angels that dance on the point of a pin. I thought > > > we had concensus at the meeting. > > > > Yes. So did I. Let's get on with it! > > > > Regards, > > Henrik > > > > I was there. There it was (consensus). Here I am re-iterating > it again (don't > exactly know why!). > Let's move on! > > Regards, > > -Rajeev > > > > > > > > > > > Requirements are meant to be general guidelines for development > > > of the protocol, and to exclude obviously inappropriate features. > > > If people can't agree on a narrow scope, then let's define the > > > requirement as broadly as possible and let the protocol designers > > > decide what's appropriate for the particular feature they want > > > to transfer. It sounds to me like that's going to be the case > > > anyway > > > > > > Sorry. > > > > > > jak > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > >From: john.loughney@nokia.com > > > >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > > > >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, > cedric@iprg.nokia.com, > > > henrik@ipunplugged.com > > > >Subject: RE: [seamoby] Update on Issues from IETF meeting > > > >Date: Thu, 16 Aug 2001 20:23:59 +0300 > > > > > > > >Hi all, > > > > > > > >I think that CT could happen under the following conditions: > > > > 1) Before handoff > > > > 2) During handoff > > > > 3) After handoff > > > > > > > >Futher more, I see it as feasible that: > > > > 1) All context (for a particular CTP instance) could > be sent in a single > > > >packet (subject to MTU) > > > > 2) Context (for a particular CTP instance) could be > sent seperately > > > > > > > >I think that it depends on the situation, implementation > and requirements > > > >for the particular context being transfered. > > > > > > > >I request that the CT requirements allow for this. > > > > > > > >thanks, > > > >John > > > > > > > > ------_=_NextPart_001_01C1269C.7CA05300 Content-Type: text/html; charset="iso-8859-1" RE: [seam by] Update on Issues from IETF meeting

Consensus can not be determined at a wg meeting. We have to
go through this on the email list.

And so, yes, let's get on with it.

Before/after or proactive/reactive - pick a pair and let's move
on. I prefer the latter: I know what they mean, I know what they don't
mean, and most important, I know how they can be used.

BUT, I will not oppose the former, because I don't believe we
will every resolve the discussion until we see real protocol proposals.
And, I totally expect a future debate over the meanings of "before" and
"after", but so be it.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Thursday, August 16, 2001 5:23 PM
> To: Henrik Levkowetz
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] Update on Issues from IETF meeting
>
>
> Henrik Levkowetz wrote:
>
> > James Kempf wrote:
> > > Folks,
> > >
> > > At the risk of sounding hysterical, can we PLEASE come to
> some concensus
> > > on this and move on? We seem to be stuck in an infinite
> loop trying
> > > to number the angels that dance on the point of a pin. I thought
> > > we had concensus at the meeting.
> >
> >         Yes. So did I. Let's get on with it!
> >
> >         Regards,
> >                 Henrik
> >
>
> I was there. There it was (consensus). Here I am re-iterating
> it again (don't
> exactly know why!).
> Let's move on!
>
> Regards,
>
> -Rajeev
>
>
>
> >
> > >
> > > Requirements are meant to be general guidelines for development
> > > of the protocol, and to exclude obviously inappropriate features.
> > > If people can't agree on a narrow scope, then let's define the
> > > requirement as broadly as possible and let the protocol designers
> > > decide what's appropriate for the particular feature they want
> > > to transfer. It sounds to me like that's going to be the case
> > > anyway
> > >
> > > Sorry.
> > >
> > >               jak
> > >
> > > >Delivered-To: seamoby-list@charizard.diameter.org
> > > >From: john.loughney@nokia.com
> > > >To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com
> > > >Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org,
> cedric@iprg.nokia.com,
> > > henrik@ipunplugged.com
> > > >Subject: RE: [seamoby] Update on Issues from IETF meeting
> > > >Date: Thu, 16 Aug 2001 20:23:59 +0300
> > > >
> > > >Hi all,
> > > >
> > > >I think that CT could happen under the following conditions:
> > > >    1) Before handoff
> > > >    2) During handoff
> > > >    3) After handoff
> > > >
> > > >Futher more, I see it as feasible that:
> > > >    1) All context (for a particular CTP instance) could
> be sent in a single
> > > >packet (subject to MTU)
> > > >    2) Context (for a particular CTP instance) could be
> sent seperately
> > > >
> > > >I think that it depends on the situation, implementation
> and requirements
> > > >for the particular context being transfered.
> > > >
> > > >I request that the CT requirements allow for this.
> > > >
> > > >thanks,
> > > >John
> > >
> > >
>
>

------_=_NextPart_001_01C1269C.7CA05300-- From owner-seamoby@diameter.org Thu Aug 16 17:53:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25816 for ; Thu, 16 Aug 2001 17:53:24 -0400 (EDT) Received: (qmail 1546 invoked by alias); 16 Aug 2001 21:41:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1540 invoked by uid 200); 16 Aug 2001 21:41:54 -0000 Received: (qmail 1530 invoked from network); 16 Aug 2001 21:41:52 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 21:41:52 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12184; Thu, 16 Aug 2001 14:53:33 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA27892; Thu, 16 Aug 2001 14:53:32 -0700 (PDT) Message-Id: <200108162153.OAA27892@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 14:53:24 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Update on Issues from IETF meeting To: James.Kempf@sun.com, t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, john.loughney@nokia.com, mscorson@ix.netcom.com Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Bh3KiCv1k4nh0IN+nCL5BA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Scott, > >I guess I cannot agree that requirements are meant to be general guidelines >as James suggests. They are meant to be more than that...certainly MUST >requirements. > What I heard in email this morning from, I believe, Gary is that the exact timing of transfer will depend on the feature context being transferred. Consequently, I do not think it is possible to get a more precise set of requirements for the general timing problem than what JohnL proposed at IETF 51 and what, I thought, the WG had agreed to as concensus. Any further attempt to be precise would necessarily compromise the generality of the requirement and involve investigating specific feature context requirements. >Perhaps, as a way out of this rathole, we could simply change the draft >title from > >General Requirements for a Context Transfer Framework >to >General *Guidelines* for a Context Transfer Framework > >As a requirements doc, the draft has problems. >As a guidelines doc, it's OK. > >I know the group was in requirements mode, but it seems to have produced a >guidelines draft. We could just acknowledge that and propose some protocols. Fine, I have no problems with that. IMHO, much of the problem the group is having in achieving precision on requirements may be due to the fact that everybody has a different set of feature contexts they are thinking of, and so they come at the problem of specifying requirements for the general problem from that perspective. Agreeing to one particular set of precise requirements would in some cases involve choosing the requirements for one or a group of feature contexts and preclude those of another feature context having different and, in come cases, opposing requirements, hence, the debate continues to circle. I've not been deeply involved in the discussion, only observing, but this is sort of what I've been seeing. jak From owner-seamoby@diameter.org Thu Aug 16 18:15:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26494 for ; Thu, 16 Aug 2001 18:15:38 -0400 (EDT) Received: (qmail 2108 invoked by alias); 16 Aug 2001 22:03:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2102 invoked by uid 200); 16 Aug 2001 22:03:53 -0000 Received: (qmail 2096 invoked from network); 16 Aug 2001 22:03:51 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 22:03:51 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA12960; Thu, 16 Aug 2001 15:14:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GMEqx29675; Thu, 16 Aug 2001 15:14:52 -0700 X-mProtect: Thu, 16 Aug 2001 15:14:52 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd6gKNzh; Thu, 16 Aug 2001 15:14:51 PDT Message-ID: <3B7C45DB.8DB42CFF@iprg.nokia.com> Date: Thu, 16 Aug 2001 15:14:51 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting References: <200108162153.OAA27892@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit James and Scott, I do not agree that we should convert the Requirements draft to a Guidelines draft. May be I am missing something, but, I think a Guidelines draft _could_ follow once we have a solution, which itself follows the Requirements. Can we move on with the consensus that was reached in London and not open the can on Requirements vs Guidelines ? Thanks, -Rajeev James Kempf wrote: > Scott, > > > > >I guess I cannot agree that requirements are meant to be general guidelines > >as James suggests. They are meant to be more than that...certainly MUST > >requirements. > > > > What I heard in email this morning from, I believe, Gary is that > the exact timing of transfer will depend on the feature context > being transferred. Consequently, I do not think it is possible > to get a more precise set of requirements for the general timing problem > than what JohnL proposed at IETF 51 and what, I thought, the > WG had agreed to as concensus. > > Any further attempt to be precise would necessarily compromise > the generality of the requirement and involve investigating > specific feature context requirements. > > >Perhaps, as a way out of this rathole, we could simply change the draft > >title from > > > >General Requirements for a Context Transfer Framework > >to > >General *Guidelines* for a Context Transfer Framework > > > >As a requirements doc, the draft has problems. > >As a guidelines doc, it's OK. > > > >I know the group was in requirements mode, but it seems to have produced a > >guidelines draft. We could just acknowledge that and propose some protocols. > > Fine, I have no problems with that. IMHO, much of the problem the group > is having in achieving precision on requirements may be due to the > fact that everybody has a different set of feature contexts they > are thinking of, and so they come at the problem of specifying > requirements for the general problem from that perspective. Agreeing > to one particular set of precise requirements would in some > cases involve choosing the requirements for one or a group of > feature contexts and preclude those of another feature context having > different and, in come cases, opposing requirements, hence, the > debate continues to circle. I've not been deeply involved in the discussion, > only observing, but this is sort of what I've been seeing. > > jak From owner-seamoby@diameter.org Thu Aug 16 18:47:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26985 for ; Thu, 16 Aug 2001 18:47:23 -0400 (EDT) Received: (qmail 2710 invoked by alias); 16 Aug 2001 22:35:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2704 invoked by uid 200); 16 Aug 2001 22:35:53 -0000 Received: (qmail 2699 invoked from network); 16 Aug 2001 22:35:50 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 22:35:50 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02290; Thu, 16 Aug 2001 15:47:32 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA29852; Thu, 16 Aug 2001 15:47:32 -0700 (PDT) Message-Id: <200108162247.PAA29852@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 15:47:24 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] What message should Paging Agent send out? To: seamoby@cdma-2000.org, nobuyasu.nakajima@toshiba.co.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LKoi79lCGwBmykeyBTMZcw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk >Though the definition of Paging Agent in RFC3154 (paging requirement) >is ambiguous when we consider what message the Paging Agent sends >out, I think that DMHA's Paging Agent should send IP paging message >out to alert the dormant host. > >This means that some entity which converts the IP paging message to L2 >paging message is necessary (if L2 paging is utilized). I think that >taking the converting function out of DMHA's Paging Agent is a good >idea, because at the same time, we can take out the implementation >issue that how Paging Agent deals with L2 paging. > >Comments? I don't see any problem with having the Paging Agent do L2 paging if it can. If the particular L2 doesn't support paging, then the paging goes by IP. That is clear from the definition. The Paging Agent is meant to be the definitive functional entity that issues the paging message to the dormant mode mobile host. Whether or not it issues an IP paging message or L2 paging message depends on the specific L2 to which the Paging Agent is connected. It's like a Mobile IP Foreign Agent in this respect. Is there a specific example or problem that you feel isn't covered by this functional architecture? jak From owner-seamoby@diameter.org Thu Aug 16 18:50:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27023 for ; Thu, 16 Aug 2001 18:50:56 -0400 (EDT) Received: (qmail 3217 invoked by alias); 16 Aug 2001 22:39:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3211 invoked by uid 200); 16 Aug 2001 22:39:03 -0000 Received: (qmail 3203 invoked from network); 16 Aug 2001 22:39:01 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 22:39:01 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 18:50:13 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605476A@ftmail> From: George Tsirtsis To: "'Rajeev Koodli'" , James Kempf Cc: t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Thu, 16 Aug 2001 18:50:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I believe that Scott was pointing out the inability of this group to produce "actual" requirements. During earlier e-mails I identified at least 3 of the so called requirements that are not really requirements and yet they are MUSTs in this requirements document. I have yet to receive an e-mail to say the contrary... If the group does not care then lets move on...with the so called "requirements document" which actually does not contain real requirements... George P.S.: I hope this group also appreciates that the criticism is not necessarily towards the people involved but towards this relatively new IETF process that IMO is fundamentally flawed. i.e.: the requirement to produce "requirements" documents before protocols. I hope the ADs are listening in! -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Thursday, August 16, 2001 11:15 PM To: James Kempf Cc: t.pagtzis@cs.ucl.ac.uk; G.Tsirtsis@flarion.com; john.loughney@nokia.com; mscorson@ix.netcom.com; pcalhoun@diameter.org; seamoby@cdma-2000.org; cedric@iprg.nokia.com; henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting James and Scott, I do not agree that we should convert the Requirements draft to a Guidelines draft. May be I am missing something, but, I think a Guidelines draft _could_ follow once we have a solution, which itself follows the Requirements. Can we move on with the consensus that was reached in London and not open the can on Requirements vs Guidelines ? Thanks, -Rajeev James Kempf wrote: > Scott, > > > > >I guess I cannot agree that requirements are meant to be general guidelines > >as James suggests. They are meant to be more than that...certainly MUST > >requirements. > > > > What I heard in email this morning from, I believe, Gary is that > the exact timing of transfer will depend on the feature context > being transferred. Consequently, I do not think it is possible > to get a more precise set of requirements for the general timing problem > than what JohnL proposed at IETF 51 and what, I thought, the > WG had agreed to as concensus. > > Any further attempt to be precise would necessarily compromise > the generality of the requirement and involve investigating > specific feature context requirements. > > >Perhaps, as a way out of this rathole, we could simply change the draft > >title from > > > >General Requirements for a Context Transfer Framework > >to > >General *Guidelines* for a Context Transfer Framework > > > >As a requirements doc, the draft has problems. > >As a guidelines doc, it's OK. > > > >I know the group was in requirements mode, but it seems to have produced a > >guidelines draft. We could just acknowledge that and propose some protocols. > > Fine, I have no problems with that. IMHO, much of the problem the group > is having in achieving precision on requirements may be due to the > fact that everybody has a different set of feature contexts they > are thinking of, and so they come at the problem of specifying > requirements for the general problem from that perspective. Agreeing > to one particular set of precise requirements would in some > cases involve choosing the requirements for one or a group of > feature contexts and preclude those of another feature context having > different and, in come cases, opposing requirements, hence, the > debate continues to circle. I've not been deeply involved in the discussion, > only observing, but this is sort of what I've been seeing. > > jak From owner-seamoby@diameter.org Thu Aug 16 19:16:27 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27351 for ; Thu, 16 Aug 2001 19:16:25 -0400 (EDT) Received: (qmail 3797 invoked by alias); 16 Aug 2001 23:04:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3790 invoked by uid 200); 16 Aug 2001 23:04:33 -0000 Received: (qmail 3784 invoked from network); 16 Aug 2001 23:04:31 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Aug 2001 23:04:31 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10304; Thu, 16 Aug 2001 17:16:00 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA01114; Thu, 16 Aug 2001 16:15:57 -0700 (PDT) Message-Id: <200108162315.QAA01114@heliopolis.eng.sun.com> Date: Thu, 16 Aug 2001 16:15:49 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Update on Issues from IETF meeting To: rajeev@IPRG.nokia.com, James.Kempf@sun.com, G.Tsirtsis@flarion.com Cc: t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j32XVsbmAXt5bq56thcQoA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk George, >P.S.: I hope this group also appreciates that the criticism is not >necessarily towards the people involved but towards this relatively new IETF >process that IMO is fundamentally flawed. i.e.: the requirement to produce >"requirements" documents before protocols. I hope the ADs are listening in! > Actually, I disagree with this assessment. I do not think that it is possible to design a protocol without first agreeing what it should do, which is what requirements are. Many of the disputes I've seen or been involved in during the protocol design phase stem from fundamental disagreement about requirements, though the participants in the group end up arguing about header fields and data format rather than what is really the point at issue. We have had very good success with defining requirements for paging, for example, because the problem domain was fairly constrained, if initially poorly understood. Now that we have the requirements done, we are proceeding smoothly into protocol design. Similarly, although the requirements phase was long and contentious, I believe the AAA working group has also had good success with this process. That said, requirements generation is not always necessary if the problem is well enough understood that everbody agrees on what the protocol should do up front. I think MIP fast handoff is in this category. I believe the problem in context transfer stems partly from the unfamiliarity of the participants with what exactly requirements generation is about, which, as you point out, is a new process at IETF with which many (including myself) are not completely familiar or comfortable. The other problem, as I pointed out in my response to Scott's email, is that the details of the requirements for a context transfer protocol in many cases depend intimately on the exact feature context being transferred, and so any attempt to come up with general requirements is likely to result in fuzzy or broad guidelines rather than specific, detailed points, which, as you and Scott pointed out, is a problem with the current draft. This is likely to lead to differences of opinion as people approach the problem from particular perspectives of feature contexts that they want to transfer. I think it may not be possible to come up with any more specific set of requirements than the current guideline-level, without locking in the requirements for particular feature contexts. I think that when the feature context protocols are defined, the requirements better be alot more specific because the problem needs to be better defined to constrain things like synchronization with handover, etc. which are hard to define in a general way. Anyway, that's my 0.02 euro, and we probably ought to take this thread to ietf@ietf.org. I think we need to accept the document with edits as defined in the London meeting and move on. Whether it is called guidelines or requirements is irrelevent, because it is not going to get any more specific until we start looking at particular feature contexts that need to be transferred, IMHO. jak From owner-seamoby@diameter.org Thu Aug 16 19:32:50 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27570 for ; Thu, 16 Aug 2001 19:32:50 -0400 (EDT) Received: (qmail 4404 invoked by alias); 16 Aug 2001 23:21:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4398 invoked by uid 200); 16 Aug 2001 23:21:23 -0000 Received: (qmail 4391 invoked by uid 500); 16 Aug 2001 23:21:20 -0000 Date: Thu, 16 Aug 2001 16:21:20 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Henrik Levkowetz , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816162120.C4357@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Henrik Levkowetz , seamoby@cdma-2000.org References: <3B7C399D.43FA6839@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7C399D.43FA6839@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Thu, Aug 16, 2001 at 02:22:37PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > I was there. There it was (consensus). Here I am re-iterating it again (don't > exactly know why!). Here's why. We cannot use consensus based on meetings. I can only do it on the list. Those are the IETF rules. If all I hear are negative comments, then I have to assume that we don't have consensus, and need to try to get rough consensus. Now that folks are coming out of the woodwork, it will be easier for me to know how is for/against the proposal. PatC From owner-seamoby@diameter.org Thu Aug 16 19:35:08 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27598 for ; Thu, 16 Aug 2001 19:35:07 -0400 (EDT) Received: (qmail 4563 invoked by alias); 16 Aug 2001 23:21:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4552 invoked by uid 200); 16 Aug 2001 23:21:53 -0000 Received: (qmail 4531 invoked by uid 500); 16 Aug 2001 23:21:46 -0000 Date: Thu, 16 Aug 2001 16:21:46 -0700 From: Pat Calhoun To: Theo Pagtzis Cc: James Kempf , G.Tsirtsis@flarion.com, john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816162146.D4357@charizard.diameter.org> Mail-Followup-To: Theo Pagtzis , James Kempf , G.Tsirtsis@flarion.com, john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com References: <200108161741.KAA17387@heliopolis.eng.sun.com> <3B7C2828.6F267073@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7C2828.6F267073@cs.ucl.ac.uk>; from T.Pagtzis@cs.ucl.ac.uk on Thu, Aug 16, 2001 at 09:08:08PM +0100 Sender: owner-seamoby@diameter.org Precedence: bulk > I couldn't agree more with it. But if it is requirements that we care about > we need to be careful now or regret it later.. > > Consensus is of course the ultimate objective.. Rough consensus is the objective. PatC From owner-seamoby@diameter.org Thu Aug 16 19:39:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27736 for ; Thu, 16 Aug 2001 19:39:56 -0400 (EDT) Received: (qmail 5440 invoked by alias); 16 Aug 2001 23:28:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5434 invoked by uid 200); 16 Aug 2001 23:28:32 -0000 Received: (qmail 5418 invoked by uid 500); 16 Aug 2001 23:28:28 -0000 Date: Thu, 16 Aug 2001 16:28:28 -0700 From: Pat Calhoun To: James Kempf Cc: rajeev@IPRG.nokia.com, G.Tsirtsis@flarion.com, t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting Message-ID: <20010816162828.E4357@charizard.diameter.org> Mail-Followup-To: James Kempf , rajeev@IPRG.nokia.com, G.Tsirtsis@flarion.com, t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com References: <200108162315.QAA01114@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108162315.QAA01114@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Thu, Aug 16, 2001 at 04:15:49PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > Anyway, that's my 0.02 euro, and we probably ought to take this thread to > ietf@ietf.org. Yes, please do and take it off this list. We have milestones, and if you want them changed, talk to the ADs. If you think the system is flawed, take up on the IETF list. Meanwhile, let's get this thing out so we can work on protocols. > I think we need to accept the document with edits as > defined in the London meeting and move on. Whether it is called > guidelines or requirements is irrelevent, because it is not going > to get any more specific until we start looking at particular feature > contexts that need to be transferred, IMHO. It is very relevant to the ADs. PatC From owner-seamoby@diameter.org Thu Aug 16 21:03:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28448 for ; Thu, 16 Aug 2001 21:03:18 -0400 (EDT) Received: (qmail 6417 invoked by alias); 17 Aug 2001 00:51:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6411 invoked by uid 200); 17 Aug 2001 00:51:16 -0000 Received: (qmail 6405 invoked from network); 17 Aug 2001 00:51:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 00:51:14 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA24628; Thu, 16 Aug 2001 18:02:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7H12Sm30988; Thu, 16 Aug 2001 18:02:28 -0700 X-mProtect: Thu, 16 Aug 2001 18:02:28 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdMLcX1Y; Thu, 16 Aug 2001 18:02:26 PDT Message-ID: <3B7C6D23.30872183@iprg.nokia.com> Date: Thu, 16 Aug 2001 18:02:27 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Henrik Levkowetz , seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <3B7C399D.43FA6839@iprg.nokia.com> <20010816162120.C4357@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit OK Pat. I wasn't questioning the rules. Just voicing my exasperation on the issue. -Rajeev Pat Calhoun wrote: > > I was there. There it was (consensus). Here I am re-iterating it again (don't > > exactly know why!). > > Here's why. We cannot use consensus based on meetings. I can only do it on > the list. Those are the IETF rules. If all I hear are negative comments, > then I have to assume that we don't have consensus, and need to try to get > rough consensus. > > Now that folks are coming out of the woodwork, it will be easier for me > to know how is for/against the proposal. > > PatC From owner-seamoby@diameter.org Fri Aug 17 01:52:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10496 for ; Fri, 17 Aug 2001 01:52:20 -0400 (EDT) Received: (qmail 8001 invoked by alias); 17 Aug 2001 05:40:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7995 invoked by uid 200); 17 Aug 2001 05:40:19 -0000 Received: (qmail 7987 invoked from network); 17 Aug 2001 05:40:17 -0000 Received: from femail6.sdc1.sfba.home.com (24.0.95.86) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 05:40:17 -0000 Received: from cr851003a ([24.157.232.166]) by femail6.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010817055201.EPRJ15121.femail6.sdc1.sfba.home.com@cr851003a>; Thu, 16 Aug 2001 22:52:01 -0700 Message-ID: <001a01c126e1$594e8620$a6e89d18@slnt1.on.wave.home.com> From: "Kulwinder Atwal" To: "James Kempf" , , Cc: , , , , , , References: <200108162315.QAA01114@heliopolis.eng.sun.com> Subject: Re: [seamoby] Update on Issues from IETF meeting Date: Fri, 17 Aug 2001 01:56:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with James' assessment. I would also add that there has been fierce debate amoung Design Team members that has resulted in less than crisp requirements. This vagueness is not only to allow designers flexibility, but also implementors. The nature of context transfer in an IP network involves many different types of context, link-layers, network topologies, and time scales. It is difficult to be exact without ruling out someone's notion of how IP-based CTP should work. Rather than aim for a document that is 100%, instead this document is probably around 80% with the other 20% left to the Design Phase. The complexity of the task has caused many, many ratholes. There are issues in the remaining 20% that could be opened up by what seem like harmless editorial changes, but the vagueness provides flexibility, and helps us move to Last Call. The current Change Request process I believe is necessary as it helps avoid ratholes by monitoring the progress of issues and focusing debate: http://www.diameter.org/seamoby-ct-issues.html Unless new Issues are introduced by the Change Request process, I believe we should accept the changes from London and move on to the next phase. I support John's change to "before,during, and after" due to the flexibility and forward movement it provides for the requirments document. - Kulwinder. ----- Original Message ----- From: "James Kempf" To: ; ; Cc: ; ; ; ; ; ; Sent: Thursday, August 16, 2001 7:15 PM Subject: RE: [seamoby] Update on Issues from IETF meeting > > I believe the problem in context transfer stems partly from the unfamiliarity > of the participants with what exactly requirements generation is about, > which, as you point out, is a new process at IETF with which many (including > myself) are not completely familiar or comfortable. The other problem, > as I pointed out in my response to Scott's email, is that the details of the > requirements for a context transfer protocol in many cases depend intimately on > the exact feature context being transferred, and so any attempt to > come up with general requirements is likely to result in fuzzy or > broad guidelines rather than specific, detailed points, which, as you > and Scott pointed out, is a problem with the current draft. This is likely to > lead to differences of opinion as people approach the problem from particular > perspectives of feature contexts that they want to transfer. I think it may not > be possible to come up with any more specific set of requirements than the > current guideline-level, without locking in the requirements for particular > feature contexts. I think that when the feature context protocols are defined, > the requirements better be alot more specific because the problem needs to be > better defined to constrain things like synchronization with handover, etc. > which are hard to define in a general way. > > Anyway, that's my 0.02 euro, and we probably ought to take this thread to > ietf@ietf.org. I think we need to accept the document with edits as > defined in the London meeting and move on. Whether it is called > guidelines or requirements is irrelevent, because it is not going > to get any more specific until we start looking at particular feature > contexts that need to be transferred, IMHO. > > > jak > From owner-seamoby@diameter.org Fri Aug 17 03:49:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21317 for ; Fri, 17 Aug 2001 03:49:50 -0400 (EDT) Received: (qmail 8945 invoked by alias); 17 Aug 2001 07:38:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8939 invoked by uid 200); 17 Aug 2001 07:38:17 -0000 Received: (qmail 8930 invoked from network); 17 Aug 2001 07:38:15 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 07:38:15 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 03:49:24 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605476B@ftmail> From: George Tsirtsis To: "'James Kempf'" , rajeev@IPRG.nokia.com Cc: t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Fri, 17 Aug 2001 03:49:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: James Kempf [mailto:James.Kempf@sun.com] Sent: Friday, August 17, 2001 12:16 AM To: rajeev@IPRG.nokia.com; James.Kempf@sun.com; G.Tsirtsis@flarion.com Cc: t.pagtzis@cs.ucl.ac.uk; john.loughney@nokia.com; mscorson@ix.netcom.com; pcalhoun@diameter.org; seamoby@cdma-2000.org; cedric@IPRG.nokia.com; henrik@ipunplugged.com Subject: RE: [seamoby] Update on Issues from IETF meeting George, >P.S.: I hope this group also appreciates that the criticism is not >necessarily towards the people involved but towards this relatively new IETF >process that IMO is fundamentally flawed. i.e.: the requirement to produce >"requirements" documents before protocols. I hope the ADs are listening in! > Actually, I disagree with this assessment. I do not think that it is possible to design a protocol without first agreeing what it should do, which is what requirements are. GT> Is that so? I thought the Internet was built this way. Some time ago IETF believed in "running code". Anyway, as you said this discussion is not for this list...I will not push this any further, just move on. George From owner-seamoby@diameter.org Fri Aug 17 05:28:01 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22281 for ; Fri, 17 Aug 2001 05:28:00 -0400 (EDT) Received: (qmail 9826 invoked by alias); 17 Aug 2001 09:16:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9820 invoked by uid 200); 17 Aug 2001 09:16:05 -0000 Received: (qmail 9815 invoked from network); 17 Aug 2001 09:15:59 -0000 Received: from bells.cs.ucl.ac.uk (128.16.5.31) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 09:15:59 -0000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Aug 2001 10:27:09 +0100 Message-ID: <3B7CE36B.5E2A81AC@cs.ucl.ac.uk> Date: Fri, 17 Aug 2001 10:27:07 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: "M. Scott Corson" CC: James Kempf , G.Tsirtsis@flarion.com, john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting References: <3.0.6.32.20010816171710.0096d7a0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Scott, Rather than commenting what the document should be named as, we would appreciate if you could point out the specifics that you feel -as a member of the constituency- that are leaning towards what you term as 'guidelines' as opposed to what the rest of the Seamoby constituency calls 'requirements'. This would help us all understand what are your inferences from reading the document that the group is bringing together. To dismiss a whole effort as being guidelines rather than requirements is rather deconstructing since we cannot see what are the points from the document you are not in agreement with and most important _why_ ! Would you like to elaborate on specific points you do not agree with in this document? If not I fear that it will not be fruitful at all to pursue this angle any further. Regs Theo UCL/ Mobile Systems "M. Scott Corson" wrote: > I guess I cannot agree that requirements are meant to be general guidelines > as James suggests. They are meant to be more than that...certainly MUST > requirements. > > Perhaps, as a way out of this rathole, we could simply change the draft > title from > > General Requirements for a Context Transfer Framework > to > General *Guidelines* for a Context Transfer Framework > > As a requirements doc, the draft has problems. > As a guidelines doc, it's OK. > > I know the group was in requirements mode, but it seems to have produced a > guidelines draft. We could just acknowledge that and propose some protocols. > > -Scott > > At 10:41 AM 8/16/01 -0700, James Kempf wrote: > >Folks, > > > >Requirements are meant to be general guidelines for development > >of the protocol, and to exclude obviously inappropriate features. > >If people can't agree on a narrow scope, then let's define the > >requirement as broadly as possible and let the protocol designers > >decide what's appropriate for the particular feature they want > >to transfer. It sounds to me like that's going to be the case > >anyway > > > >Sorry. > > > > jak > > > >>Delivered-To: seamoby-list@charizard.diameter.org > >>From: john.loughney@nokia.com > >>To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > >>Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, > >henrik@ipunplugged.com > >>Subject: RE: [seamoby] Update on Issues from IETF meeting > >>Date: Thu, 16 Aug 2001 20:23:59 +0300 > >> > >>Hi all, > >> > >>I think that CT could happen under the following conditions: > >> 1) Before handoff > >> 2) During handoff > >> 3) After handoff > >> > >>Futher more, I see it as feasible that: > >> 1) All context (for a particular CTP instance) could be sent in a single > >>packet (subject to MTU) > >> 2) Context (for a particular CTP instance) could be sent seperately > >> > >>I think that it depends on the situation, implementation and requirements > >>for the particular context being transfered. > >> > >>I request that the CT requirements allow for this. > >> > >>thanks, > >>John > > > > From owner-seamoby@diameter.org Fri Aug 17 12:00:00 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06388 for ; Fri, 17 Aug 2001 11:59:59 -0400 (EDT) Received: (qmail 12038 invoked by alias); 17 Aug 2001 15:48:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12032 invoked by uid 200); 17 Aug 2001 15:48:08 -0000 Received: (qmail 12027 invoked from network); 17 Aug 2001 15:48:06 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 15:48:06 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 11:59:18 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054776@ftmail> From: George Tsirtsis To: "'t.pagtzis@cs.ucl.ac.uk'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Fri, 17 Aug 2001 11:59:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Scott was part of the review team that created the 8 "comments" that I sent a few days ago to this list. -----Original Message----- From: Theo Pagtzis [mailto:T.Pagtzis@cs.ucl.ac.uk] Sent: Friday, August 17, 2001 10:27 AM To: M. Scott Corson Cc: James Kempf; G.Tsirtsis@flarion.com; john.loughney@nokia.com; pcalhoun@diameter.org; seamoby@cdma-2000.org; cedric@iprg.nokia.com; henrik@ipunplugged.com Subject: Re: [seamoby] Update on Issues from IETF meeting Hello Scott, Rather than commenting what the document should be named as, we would appreciate if you could point out the specifics that you feel -as a member of the constituency- that are leaning towards what you term as 'guidelines' as opposed to what the rest of the Seamoby constituency calls 'requirements'. This would help us all understand what are your inferences from reading the document that the group is bringing together. To dismiss a whole effort as being guidelines rather than requirements is rather deconstructing since we cannot see what are the points from the document you are not in agreement with and most important _why_ ! Would you like to elaborate on specific points you do not agree with in this document? If not I fear that it will not be fruitful at all to pursue this angle any further. Regs Theo UCL/ Mobile Systems "M. Scott Corson" wrote: > I guess I cannot agree that requirements are meant to be general guidelines > as James suggests. They are meant to be more than that...certainly MUST > requirements. > > Perhaps, as a way out of this rathole, we could simply change the draft > title from > > General Requirements for a Context Transfer Framework > to > General *Guidelines* for a Context Transfer Framework > > As a requirements doc, the draft has problems. > As a guidelines doc, it's OK. > > I know the group was in requirements mode, but it seems to have produced a > guidelines draft. We could just acknowledge that and propose some protocols. > > -Scott > > At 10:41 AM 8/16/01 -0700, James Kempf wrote: > >Folks, > > > >Requirements are meant to be general guidelines for development > >of the protocol, and to exclude obviously inappropriate features. > >If people can't agree on a narrow scope, then let's define the > >requirement as broadly as possible and let the protocol designers > >decide what's appropriate for the particular feature they want > >to transfer. It sounds to me like that's going to be the case > >anyway > > > >Sorry. > > > > jak > > > >>Delivered-To: seamoby-list@charizard.diameter.org > >>From: john.loughney@nokia.com > >>To: t.pagtzis@cs.ucl.ac.uk, G.Tsirtsis@flarion.com > >>Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@iprg.nokia.com, > >henrik@ipunplugged.com > >>Subject: RE: [seamoby] Update on Issues from IETF meeting > >>Date: Thu, 16 Aug 2001 20:23:59 +0300 > >> > >>Hi all, > >> > >>I think that CT could happen under the following conditions: > >> 1) Before handoff > >> 2) During handoff > >> 3) After handoff > >> > >>Futher more, I see it as feasible that: > >> 1) All context (for a particular CTP instance) could be sent in a single > >>packet (subject to MTU) > >> 2) Context (for a particular CTP instance) could be sent seperately > >> > >>I think that it depends on the situation, implementation and requirements > >>for the particular context being transfered. > >> > >>I request that the CT requirements allow for this. > >> > >>thanks, > >>John > > > > From owner-seamoby@diameter.org Fri Aug 17 12:03:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06544 for ; Fri, 17 Aug 2001 12:03:50 -0400 (EDT) Received: (qmail 12542 invoked by alias); 17 Aug 2001 15:52:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12536 invoked by uid 200); 17 Aug 2001 15:52:10 -0000 Received: (qmail 12531 invoked from network); 17 Aug 2001 15:52:08 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 15:52:08 -0000 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id BAA25759; Sat, 18 Aug 2001 01:03:53 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id BAA00651; Sat, 18 Aug 2001 01:03:53 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id BAA06071; Sat, 18 Aug 2001 01:03:53 +0900 (JST) Received: from localhost ([172.30.24.47]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0GI7005I7Z6Y8T@tsbpo1.po.toshiba.co.jp>; Sat, 18 Aug 2001 01:01:51 +0900 (JST) Date: Fri, 17 Aug 2001 12:03:51 -0400 (LDT) From: NAKAJIMA Nobuyasu Subject: Re: [seamoby] What message should Paging Agent send out? In-reply-to: <200108162247.PAA29852@heliopolis.eng.sun.com> To: James.Kempf@Sun.COM Cc: seamoby@cdma-2000.org Message-id: <20010817.120351.01367238.nobuyasu.nakajima@toshiba.co.jp> MIME-version: 1.0 X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <200108162247.PAA29852@heliopolis.eng.sun.com> Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Thank you for your comments! > >Though the definition of Paging Agent in RFC3154 (paging requirement) > >is ambiguous when we consider what message the Paging Agent sends > >out, I think that DMHA's Paging Agent should send IP paging message > >out to alert the dormant host. > > > >This means that some entity which converts the IP paging message to L2 > >paging message is necessary (if L2 paging is utilized). I think that > >taking the converting function out of DMHA's Paging Agent is a good > >idea, because at the same time, we can take out the implementation > >issue that how Paging Agent deals with L2 paging. > > > >Comments? > > I don't see any problem with having the Paging Agent do L2 paging > if it can. If the particular L2 doesn't support paging, then > the paging goes by IP. That is clear from the definition. The > Paging Agent is meant to be the definitive functional entity that issues > the paging message to the dormant mode mobile host. Whether or > not it issues an IP paging message or L2 paging message depends > on the specific L2 to which the Paging Agent is connected. It's > like a Mobile IP Foreign Agent in this respect. > > Is there a specific example or problem that you feel isn't covered > by this functional architecture? I start thinking this in a different way, but... I think that the question is; do we need clear distinction between L3 paging area and L2 paging area? For example, suppose that a L3 paging area consists of several L2 paging areas which are based on different L2 technology. Then current Paging Agent has to know about different types of L2 technology and different types of L2 paging method. This might make the functionality of the Paging Agent difficult to understand. Of course the current Paging Agent is a "functional" entity, but I think that things become easy to understand if we define the Paging Agent as a sender of L3 paging messages instead of various L2 paging messages dependent on the L2 system. If the people who consider the seamoby paging think that this is a trivial issue and not worth considering any more, then leave the definition of Paging Agent as it is. I may be wrong... Thanks Nobuyasu ---- Nobuyasu Nakajima Toshiba America Research, Inc. From owner-seamoby@diameter.org Fri Aug 17 14:11:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10710 for ; Fri, 17 Aug 2001 14:11:58 -0400 (EDT) Received: (qmail 13244 invoked by alias); 17 Aug 2001 18:00:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13238 invoked by uid 200); 17 Aug 2001 18:00:29 -0000 Received: (qmail 13233 invoked from network); 17 Aug 2001 18:00:27 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 18:00:27 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20002; Fri, 17 Aug 2001 12:12:09 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA03778; Fri, 17 Aug 2001 11:11:32 -0700 (PDT) Message-Id: <200108171811.LAA03778@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 11:11:25 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] What message should Paging Agent send out? To: James.Kempf@sun.com, nobuyasu.nakajima@toshiba.co.jp Cc: seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZGSVXMF8XYq2S/C5k6NX7A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk > >I start thinking this in a different way, but... > >I think that the question is; do we need clear distinction between >L3 paging area and L2 paging area? > >For example, suppose that a L3 paging area consists of several L2 >paging areas which are based on different L2 technology. Then current >Paging Agent has to know about different types of L2 technology and >different types of L2 paging method. This might make the functionality >of the Paging Agent difficult to understand. > Correct. It must map the L3 paging area into the L2 paging areas. >Of course the current Paging Agent is a "functional" entity, but I >think that things become easy to understand if we define the Paging >Agent as a sender of L3 paging messages instead of various L2 paging >messages dependent on the L2 system. > If we do that, we need to define a separate entity that converts the L3 paging message into an L2 paging message. One possibility would be to have one paging agent that dealt with L3 paging and others that deal with L2 paging. >If the people who consider the seamoby paging think that this is a >trivial issue and not worth considering any more, then leave the >definition of Paging Agent as it is. I may be wrong... > We can certainly go back and modify the architecture if there seems to be a concensus to do so, but it means we will have to cycle the draft back through WG and IETF last call, which is a somewhat time consuming process. I think we ought to avoid that until we have some implementation experience indicating that the current architecture is deficient, since other issues may arise. Let's keep track of this issue and see what comes out of the protocol design/prototyping phase. jak From owner-seamoby@diameter.org Fri Aug 17 16:20:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14569 for ; Fri, 17 Aug 2001 16:20:08 -0400 (EDT) Received: (qmail 14004 invoked by alias); 17 Aug 2001 20:08:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13998 invoked by uid 200); 17 Aug 2001 20:08:48 -0000 Received: (qmail 13993 invoked from network); 17 Aug 2001 20:08:46 -0000 Received: from thumper.research.telcordia.com (128.96.41.1) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 20:08:46 -0000 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f7HKK0Z03180 for ; Fri, 17 Aug 2001 16:20:00 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@tari-dhcp5.research.telcordia.com [207.3.232.119]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA25337 for ; Fri, 17 Aug 2001 16:22:18 -0400 (EDT) Date: Fri, 17 Aug 2001 16:15:09 -0400 Message-ID: <87n14ye94i.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: seamoby@cdma-2000.org Subject: [seamoby] LH-DMHA updated User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-seamoby@diameter.org Precedence: bulk I've submitted an updated version of LH-DMHA (draft-ohba-seamoby-last-hop-dmha-01), which includes significant changes in order to comply with RFC 3154 as much as possible. The updated document also includes a section in appendix for RFC 3154 conformance checking. It will appear in the internet-draft directory early in the next week. Regards, Yoshihiro Ohba From owner-seamoby@diameter.org Fri Aug 17 16:36:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14850 for ; Fri, 17 Aug 2001 16:36:29 -0400 (EDT) Received: (qmail 14529 invoked by alias); 17 Aug 2001 20:25:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14526 invoked by uid 200); 17 Aug 2001 20:25:00 -0000 Received: (qmail 14521 invoked from network); 17 Aug 2001 20:24:58 -0000 Received: from netmail.alcatel.com (128.251.168.50) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 20:24:58 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA00750; Fri, 17 Aug 2001 15:36:45 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f7HKaie01739; Fri, 17 Aug 2001 15:36:44 -0500 (CDT) Message-ID: <3B7D8105.87726F37@usa.alcatel.com> Date: Fri, 17 Aug 2001 15:39:33 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: seamoby@cdma-2000.org Subject: Re: [seamoby] LH-DMHA updated References: <87n14ye94i.wl@catfish.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohba-san, are you submitting this as your final solution, as per Pat's schedule agreed upon in London, or is it some intermediate version of it? Yoshihiro Ohba wrote: > I've submitted an updated version of LH-DMHA > (draft-ohba-seamoby-last-hop-dmha-01), which includes significant > changes in order to comply with RFC 3154 as much as possible. The > updated document also includes a section in appendix for RFC 3154 > conformance checking. It will appear in the internet-draft directory > early in the next week. > > Regards, > Yoshihiro Ohba -- Behcet From owner-seamoby@diameter.org Fri Aug 17 17:06:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15268 for ; Fri, 17 Aug 2001 17:06:16 -0400 (EDT) Received: (qmail 15076 invoked by alias); 17 Aug 2001 20:54:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15070 invoked by uid 200); 17 Aug 2001 20:54:56 -0000 Received: (qmail 15065 invoked from network); 17 Aug 2001 20:54:54 -0000 Received: from thumper.research.telcordia.com (128.96.41.1) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Aug 2001 20:54:54 -0000 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f7HL68Z06933; Fri, 17 Aug 2001 17:06:08 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@tari-dhcp5.research.telcordia.com [207.3.232.119]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA25431; Fri, 17 Aug 2001 17:08:25 -0400 (EDT) Date: Fri, 17 Aug 2001 17:01:16 -0400 Message-ID: <87lmkie6zn.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: Behcet Sarikaya Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] LH-DMHA updated In-Reply-To: <3B7D8105.87726F37@usa.alcatel.com> References: <87n14ye94i.wl@catfish.research.telcordia.com> <3B7D8105.87726F37@usa.alcatel.com> User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-seamoby@diameter.org Precedence: bulk Behcet, At Fri, 17 Aug 2001 15:39:33 -0500, Behcet Sarikaya wrote: > > Ohba-san, are you submitting this as your final solution, as per Pat's > schedule agreed upon in London, or is it some intermediate version of it? > That is an intermediate version. I would continue to update it until September 14. Yoshihiro Ohba From owner-seamoby@diameter.org Sat Aug 18 00:04:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21142 for ; Sat, 18 Aug 2001 00:04:13 -0400 (EDT) Received: (qmail 16753 invoked by alias); 18 Aug 2001 03:52:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16747 invoked by uid 200); 18 Aug 2001 03:52:28 -0000 Received: (qmail 16742 invoked from network); 18 Aug 2001 03:52:25 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Aug 2001 03:52:26 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08223; Fri, 17 Aug 2001 08:16:45 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA25767; Fri, 17 Aug 2001 08:15:52 -0700 (PDT) Message-Id: <200108171515.IAA25767@heliopolis.eng.sun.com> Date: Fri, 17 Aug 2001 08:15:44 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] Update on Issues from IETF meeting To: James.Kempf@Sun.COM, pcalhoun@diameter.org Cc: rajeev@IPRG.nokia.com, G.Tsirtsis@flarion.com, t.pagtzis@cs.ucl.ac.uk, john.loughney@nokia.com, mscorson@ix.netcom.com, pcalhoun@diameter.org, seamoby@cdma-2000.org, cedric@IPRG.nokia.com, henrik@ipunplugged.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: exLOXwfTouS5BhFBMA/7SA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk > >Meanwhile, let's get this thing out so we can work on protocols. > Precisely! >> I think we need to accept the document with edits as >> defined in the London meeting and move on. Whether it is called >> guidelines or requirements is irrelevent, because it is not going >> to get any more specific until we start looking at particular feature >> contexts that need to be transferred, IMHO. > >It is very relevant to the ADs. > Well then, let's just put whatever name they want on it. :-) The point is that the content reflects the concensus of the WG on *general* (stress here) requirments for context transfer. The preciseness of the general requirements can only be determined to the extent that there is no conflict between the requriements for transfer of specific feature contexts. Where there is a conflict, the general requirements must, of necessity, reflect a compromise, and so will be less specific. It's impossible to make the requirement more specific without excluding one or the other case in conflict. My impression, particularly with regard to the timing issue, is that this is exactly what is happening. Some specific feature contexts (like QoS) could be transferred earlier, some (like header compression) must be transferred later. Trying to be more specific than JohnL.'s wording proposed in London and later on the list is going to exclude one or the other. Hence, the burden of making the timing requirement more specific ("no more than xxx milliseconds latency prior to L3 handover..", etc) should fall on the individual feature context requrirements document, not on the general requirements document. Am I missing something? jak From owner-seamoby@diameter.org Sat Aug 18 03:16:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09205 for ; Sat, 18 Aug 2001 03:16:34 -0400 (EDT) Received: (qmail 17545 invoked by alias); 18 Aug 2001 07:04:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17539 invoked by uid 200); 18 Aug 2001 07:04:56 -0000 Received: (qmail 17534 invoked from network); 18 Aug 2001 07:04:53 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Aug 2001 07:04:53 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7I7H6300549 for ; Sat, 18 Aug 2001 10:17:06 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 18 Aug 2001 10:16:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVW1BR>; Sat, 18 Aug 2001 10:16:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF24298E@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Sat, 18 Aug 2001 10:16:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Pat, > Well, we are trying to get consensus on your first point, but > the other issue that seems to have consensus is to allow for > CT to occur in multiple phases. I know ... I was just trying to restate my points in a different format, so people wouldn't be arguing about 'and' / 'or' and so on ... John From owner-seamoby@diameter.org Sat Aug 18 18:18:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15949 for ; Sat, 18 Aug 2001 18:18:40 -0400 (EDT) Received: (qmail 19094 invoked by alias); 18 Aug 2001 22:05:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19088 invoked by uid 200); 18 Aug 2001 22:05:35 -0000 Received: (qmail 19083 invoked from network); 18 Aug 2001 22:05:33 -0000 Received: from dfw-smtpout3.email.verio.net (129.250.36.43) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Aug 2001 22:05:33 -0000 Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp id 15YEP7-0004Er-00; Sat, 18 Aug 2001 22:17:17 +0000 Received: from [63.184.75.187] (helo=localhost) by dfw-mmp4.email.verio.net with esmtp id 15YEP1-0002p8-00; Sat, 18 Aug 2001 22:17:11 +0000 X-Sender: robertlong@veriomail.com From: Bob Long To: "Mortgage Rate Info" Date: Sat, 18 Aug 2001 15:23:19 -0700 Subject: [seamoby] Need a Home Loan? We Can Help!! Reply-To: robertlong@veriomail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__32671061_55399.99" Message-Id: Sender: owner-seamoby@diameter.org Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__32671061_55399.99 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__32671061_55399.99 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9 IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249 Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+ TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8 UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90 O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+ PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48 U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+ PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+ PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42 Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+ PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250 PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48 Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+ PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+ YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50 byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4 MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48 Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48 L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+ PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0 PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP TlQ+PC9QPjwvQk9EWT48L0hUTUw+ ------=_NextPart_000_001__32671061_55399.99-- From owner-seamoby@diameter.org Mon Aug 20 12:25:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25749 for ; Mon, 20 Aug 2001 12:25:52 -0400 (EDT) Received: (qmail 30068 invoked by alias); 20 Aug 2001 16:13:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30062 invoked by uid 200); 20 Aug 2001 16:13:14 -0000 Received: (qmail 30057 invoked from network); 20 Aug 2001 16:13:12 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Aug 2001 16:13:12 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA20836 for ; Mon, 20 Aug 2001 09:16:25 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA20758 for ; Mon, 20 Aug 2001 09:16:12 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 20 Aug 2001 11:24:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9F73@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Cedric Westphal Cc: seamoby@cdma-2000.org Subject: RE: [seamoby]Rant: Update on Issues from IETF meeting Date: Mon, 20 Aug 2001 11:24:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Pat, thank for the minutes, although, the spelling of my name migrated from Madjid (Majid is ok too) towards Majeev (I guess I should blame myself for agreeing with Rajeev too much :). Ok, and now the rant: For whatever it is worth, I am for removing the terminology like reactive and proactive or whatever other word. I can not fathom that words like during and after causes allergic reactions (no offense). As Gary mentioned, we did discuss these terms for several months on Ct list, we discussed them on Seamoby list for a month, we became quite to have a 90 minute discussion in London and we convinced each other (those of us who were there), now we want list consensus, why are we singing the same tones again? A simple consensus (yes or no) should be fine. We agreed to leave very important requirements such as timing and reliablity for later. So why are we fighting about some terminology, that may or may not affect many peoples implementations? Are we escaping the reality??? I bet revisiting the requirements after 6 months of protocol (or even framework) work would be much more useful. I would rather discuss the CT profile issue (the thread that was killed). My single squashed Nickel, Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, August 15, 2001 9:14 AM To: Cedric Westphal Cc: Pat Calhoun; seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting > Serioulsy, removing the terminology is not the same as removing the concept. As far as I can tell, proactive vs. reactive was essentially stating when CT would occur. This, as you state, is not a requirement, and therefore adding something as simple as what proposed seems to do the same thing with the least amount of friction. > It looks to me like the baby was thrown away with the bath water. You mention some > 'intense discussion', could you elaborate to enlighten those who were not present, Here are the rough minutes for this particular discussion: Issues 4 & 7 ------------- 4 - Proactive v.s. Reactive. 7 - Remove pro and re from doc. Theo: Why remove? Two modes are too limited, may be more than two modes, putting in reqs will limit to two modes. Theo: two classes of sets of modes, other distincitions necessary. Charlie: Don't know yet, revisit issue later. Move on better understood reqs. Table it. John Longherty: Talk about protocol modes, examples rather than modes. Useful to discuss in terms of examples of how a protocol may work, but not normative. Allison: Design space to consider, potental to classify. Don't put in as requirement. Majiv: Misunderstanding. Timing req. originally there, to define timing req need to dig deeper, need to define in relation to handover, not supposed to be modes. Solution covers both, but solutions don't have to cover modes. Remove if expected to be a mode. Gary: Mode is the problem, not proactive and reactive. Mode is the issue, capability is more deescriptive. Protocol operate on two kinds of capabilities. Not bit in header, happens in different time relative to handoff. Hemant: Do we need to define temporal characteristics? Depends on when trigger was sent. Theo: Shift from mode to timing. Timing in which you act. CT tends to revolve around time restriction. Dismiss timing, then revisit. Rajeev: Mode -> capabilities won't solve. MN attaches to new router, is context there or not? Pro - there, Re - not there. Too much confusion, put in appendix. three options 1) Use word capabilities 2) Remove 3) Move to appendix. Need to consider revise or keep current text. Rajeev: Proposed text. If context there when MN attaches to new router, pro. If there after, re. Majeev: Timing requirements in req. doc? Will it delay handover? May want to define pro and re, if not, triggers may be needed. Confusing based on starting event and ending event. Rajeev: Presentation, is a distinction. Majeev: Does there need to be a timing requirement? Henrik: Cedric's text makes me least happy. Way it says it is difficult, don't know discussion says that you implement two modes. Other than that, OK. Gary: Timing requirement is in current doc, section 5, req for pro and re, current reqs are wrong, specifies a too tight timing req, needs to be fixed. No happy with delegating to appendix, important part of CT and for seamlessness. Pat: Advisory. Gary: No, it must be a requrimenet, proactive, there when packets arrive at new AR. Lose and be back in same debate. ????: QoS guy, how would a router react if first packet had a code point and the QoS was not there? Would drop. So there is a timing req. Pat: Some environments where you don't have handoff notification, in others, can. ???: Some networks have it. Rajeev: Always try to get context transfereed prior to handover. Not removing possibility of moving context. When you invoke CT. Henrik: Important to have capability to do flexibly, as early and late. Shouldn't be an appendix. Gopal: Can push or pull context, pro or re depends on timing. John Logherty: Local API issue. Gary: Makes a difference. Multiphasic, only time is just at time that handover is happening. Later, state isn't there for packet to be forwarded. Other phases, might want to transfer. Static, won't change. Value in concepts, landscape for people to work on solutions. Rajeev: Proactive mode, previous router initiates. Reactive, new router initiates. Both routers should be able to initiate. Proactive in either direction. Is context on new router? Pat: options 1) leave as is. 2) use word capabilities. 3) remove text from doc -5 4) remove text to appendix -5 5) state that CT before, during, or after handover. - many. 5) wins. Thanks, PatC From owner-seamoby@diameter.org Mon Aug 20 12:31:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25897 for ; Mon, 20 Aug 2001 12:31:50 -0400 (EDT) Received: (qmail 30590 invoked by alias); 20 Aug 2001 16:20:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30584 invoked by uid 200); 20 Aug 2001 16:20:16 -0000 Received: (qmail 30579 invoked from network); 20 Aug 2001 16:20:14 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Aug 2001 16:20:14 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA26880 for ; Mon, 20 Aug 2001 09:32:11 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA15926 for ; Mon, 20 Aug 2001 09:32:10 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 20 Aug 2001 11:32:10 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9F74@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Update on Issues from IETF meeting Date: Mon, 20 Aug 2001 11:32:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Rajeev, I did a 1 hour attempt reading your hc draft coming to London. I did not finish it unfortunately :( I am trying to learn about HC, so I am pretty illiterate on HC. What HC method was that draft based on? Rohc or something else? Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Tuesday, August 14, 2001 8:17 PM To: Kulwinder Atwal Cc: Hamid Syed; 'Pat Calhoun'; seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting Kulwinder Atwal wrote: > > > > > > Rajeev: as far as I am aware, a TCP compression profile has not been > > > defined yet. > > No, but I hear it is being worked on. I saw some presentations at > Minniapolis. > > > > UDP compression Profile . . . For CT we could have: TCP context > > > profileUDP context profile . . . > > > Rajeev: In general, it could be profiles for HC/QoS/... > > I don't see how one could have single profile for HC when each HC Profile > has a different context. > For example, RTP has a sequence number, while UDP does not. > Rajeev: I didn't imply that a single profile would suffice for HC (or QoS). You certainly need more than one. Would you be willing to review draft-koodli-seamoby-hc-relocate-01.txt ? :-) You will find discussion on this as well as a CT profile for IP/UDP/RTP HC. Regards, -Rajeev From owner-seamoby@diameter.org Mon Aug 20 15:11:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00524 for ; Mon, 20 Aug 2001 15:11:18 -0400 (EDT) Received: (qmail 31456 invoked by alias); 20 Aug 2001 18:59:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31450 invoked by uid 200); 20 Aug 2001 18:59:45 -0000 Received: (qmail 31445 invoked from network); 20 Aug 2001 18:59:42 -0000 Received: from netmail.alcatel.com (128.251.168.50) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Aug 2001 18:59:42 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA14186; Mon, 20 Aug 2001 14:11:38 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f7KJBce26111; Mon, 20 Aug 2001 14:11:38 -0500 (CDT) Message-ID: <3B8151E0.30534D75@usa.alcatel.com> Date: Mon, 20 Aug 2001 14:07:28 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba , seamoby@cdma-2000.org Subject: Re: [seamoby] RFC 3154 References: <87n14ye94i.wl@catfish.research.telcordia.com> <3B7D8105.87726F37@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have two questions on the reqs RFC 3154 (I happen to be a coauthor!): 1. The RFC dictates that: An attacker can wide cast fake paging messages pretending to be sent by a paging agent. The impacts will be similar to the ones described in Sections 4.1 and 4.3.1. However, depending on how the IP paging protocol is designed, additional harm may be caused. where is 4.1? and 4.3.1? It seems that 4.1 should be 3.1, should 4.3.1 be 3.3? 2.When messages are wide casted, is this usually because the location of the receiver is unknown, or is it because the message is being sent to multiple recipients? Kind regards, -- Behcet From owner-seamoby@diameter.org Mon Aug 20 16:29:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03001 for ; Mon, 20 Aug 2001 16:29:34 -0400 (EDT) Received: (qmail 425 invoked by alias); 20 Aug 2001 20:18:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 419 invoked by uid 200); 20 Aug 2001 20:18:06 -0000 Received: (qmail 414 invoked from network); 20 Aug 2001 20:18:05 -0000 Received: from inet-tsb.toshiba.co.jp (202.33.96.40) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Aug 2001 20:18:05 -0000 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id FAA09558; Tue, 21 Aug 2001 05:30:00 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id FAA01918; Tue, 21 Aug 2001 05:29:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id FAA08067; Tue, 21 Aug 2001 05:29:59 +0900 (JST) Received: from localhost ([172.30.24.62]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0GID00HPBVIELH@tsbpo1.po.toshiba.co.jp>; Tue, 21 Aug 2001 05:27:55 +0900 (JST) Date: Mon, 20 Aug 2001 16:31:13 -0400 (LDT) From: NAKAJIMA Nobuyasu Subject: Re: [seamoby] What message should Paging Agent send out? In-reply-to: <200108171811.LAA03778@heliopolis.eng.sun.com> To: James.Kempf@sun.com Cc: seamoby@cdma-2000.org Message-id: <20010820.163113.01366182.nobuyasu.nakajima@toshiba.co.jp> MIME-version: 1.0 X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <200108171811.LAA03778@heliopolis.eng.sun.com> Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > If we do that, we need to define a separate entity that converts > the L3 paging message into an L2 paging message. Yes. I am thinking about this. > We can certainly go back and modify the architecture if there > seems to be a concensus to do so, but it means we will have > to cycle the draft back through WG and IETF last call, which > is a somewhat time consuming process. I think we ought to > avoid that until we have some implementation experience > indicating that the current architecture is deficient, since > other issues may arise. Let's keep track of this issue > and see what comes out of the protocol design/prototyping > phase. Agreed. Nobuyasu ----- Nobuyasu Nakajima Toshiba America Research, Inc. From owner-seamoby@diameter.org Mon Aug 20 20:01:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07830 for ; Mon, 20 Aug 2001 20:01:02 -0400 (EDT) Received: (qmail 2045 invoked by alias); 20 Aug 2001 23:49:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2039 invoked by uid 200); 20 Aug 2001 23:49:34 -0000 Received: (qmail 2031 invoked by uid 500); 20 Aug 2001 23:49:32 -0000 Date: Mon, 20 Aug 2001 16:49:32 -0700 From: Pat Calhoun To: Behcet Sarikaya Cc: Yoshihiro Ohba , seamoby@cdma-2000.org Subject: Re: [seamoby] RFC 3154 Message-ID: <20010820164932.D1924@charizard.diameter.org> Mail-Followup-To: Behcet Sarikaya , Yoshihiro Ohba , seamoby@cdma-2000.org References: <87n14ye94i.wl@catfish.research.telcordia.com> <3B7D8105.87726F37@usa.alcatel.com> <3B8151E0.30534D75@usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8151E0.30534D75@usa.alcatel.com>; from behcet.sarikaya@usa.alcatel.com on Mon, Aug 20, 2001 at 02:07:28PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk Behcet, Since these are editorial errors, I don't see the need to respin the work, and consume scarce resources. Let's just keep track of this, and should we ever need to update 3154, we can address it then. Thanks, PatC On Mon, Aug 20, 2001 at 02:07:28PM -0400, Behcet Sarikaya wrote: > Hello, > I have two questions on the reqs RFC 3154 (I happen to be a coauthor!): > 1. The RFC dictates that: > An attacker can wide cast fake paging messages pretending to be sent > by a paging agent. The impacts will be similar to the ones described > in Sections 4.1 and 4.3.1. However, depending on how the IP paging > protocol is designed, additional harm may be caused. > where is 4.1? and 4.3.1? > It seems that 4.1 should be 3.1, should 4.3.1 be 3.3? > 2.When messages are wide casted, is this usually because the location of the > receiver is unknown, or is it because the message is being sent to multiple > recipients? > > Kind regards, > -- > Behcet > From owner-seamoby@diameter.org Tue Aug 21 07:12:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04571 for ; Tue, 21 Aug 2001 07:12:17 -0400 (EDT) Received: (qmail 4899 invoked by alias); 21 Aug 2001 11:00:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4893 invoked by uid 200); 21 Aug 2001 11:00:50 -0000 Received: (qmail 4888 invoked from network); 21 Aug 2001 11:00:48 -0000 Received: from unknown (HELO rafi) (213.8.76.34) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Aug 2001 11:00:48 -0000 Received: from mail pickup service by rafi with Microsoft SMTPSVC; Tue, 21 Aug 2001 14:12:36 +0200 From: To: Subject: [seamoby] Instant Messaging platform at your Web site is now a few clicks away Date: Tue, 21 Aug 2001 14:12:36 +0200 Message-ID: <128501c12a3a$90aed050$0200a8c0@rafi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcEqOpCudDBamk3pQUW3hVU5qe8ZRQ== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Aug 2001 12:12:36.0803 (UTC) FILETIME=[90BF9930:01C12A3A] Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04571 Instant Messaging platform at your Web site is now a few clicks away ---------------------------------------------------------------------- Install a FREE Instant Messaging server at your Web site. Use it as is or customize to meet your specific branding. Cross platform servers line support 25 and up to 1000 concurrent users All servers offered can be secured with RSA 512Bit (and higher) encryption!! Download free 10 concurrent users server at: http://www.seebex.com/download/get_server.asp It is easier, faster and affordable than ever!! For further information please check seebex Web site at: http://www.seebex.com or contact our Marketing & Sales department at sales@seebex.com First 50 Web sites to download and embed the free 10 concurrent users server are entitled to a free 100 concurrent users server and will be listed on Seebex Web site. From owner-seamoby@diameter.org Wed Aug 22 11:47:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14228 for ; Wed, 22 Aug 2001 11:46:55 -0400 (EDT) Received: (qmail 15879 invoked by alias); 22 Aug 2001 15:30:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15873 invoked by uid 200); 22 Aug 2001 15:30:44 -0000 Received: (qmail 15868 invoked by uid 500); 22 Aug 2001 15:30:42 -0000 Date: Wed, 22 Aug 2001 08:30:42 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Preliminary Meeting minutes - please review Message-ID: <20010822083042.B15493@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, Below is the first draft of the minutes from the London meeting. I'd like to thank Jim Kempf for taking the minutes. I'd also like folks to read the minutes carefully. There were lots of intense discussions, which made minute taking very difficult. I've had to make small changes to enhance readability, and want to make sure that I haven't messed up. Comments appreciated, PatC ---- Seamoby Meeting - Monday August 6th Agenda Bashing and document/milestone review L2 Triggers - James Kempf The goal is to collect requirements from various WGs for L2 triggers to optimize handoff. Requirements can then be used to design an API or protocol if desired Also available to L2 designers Draft discusses requirements from the following Fmipv6 and low latency MIPv4 Seamoby context transfer Issue: Why are there two sets of requirements, one for MIP and one for seamoby Because there are two application areas Should they be merged into a single one? What about other areas, such as CAR, paging, QOS? MIP handover and seamoby CT were immediate generator of requirements for L2 triggers, so we included them. Should we also include requirements from these other areas? If so, can we get volunteers familiar with the subjects to write the requirements? Comment: CAR is relevant to the both MIP and CT, but why QOS? This makes sense because QOS indications are immediate, so they could be used as an L2 trigger. However, someone else stated that an L2 trigger is normally viewed as an interrupt, but as a list of capabilities of the link layer. Next Steps: Add additional requirements, edit text following the outcome of this IETF meeting. Where should the work happen? MIP? Seamoby, or perhaps a joint WG? Or should a new WG be created under the Sub-IP area? Draft ready for IETF last call at IETF 53. Comment: This is handoff related, so maybe it belongs in Mobile IP. Comment: One of the first requirements in CT was to define the triggers, but this work is not ready yet for publishing in this draft, given this draft's intended deadlines. Comment: Worried about separating the requirements for Mobile IP and CT in the triggers, since this seems the wrong approach. Comment: Encourage to do the trigger work, but keep it simple. Issues in CAR - Govind Krishnamurthi Seamless IP mobility protocols assume that the identity of the target AR (TAR) for MN's handover is known to the current AR. TAR needs to be selected based on MN's requirements, AR capabilities and local policies Problem Statement: To determine a set of CARs (i.e. the ARs that physically adjacent (PAARs) to the current AR and have the capabilities to support the MN's requirements) This information serves as input to the TAR selection process at the time of handoff. Comment: What does physically adjacent mean? It means not necessarily topologically adjacent. Issues for discussion Pros and cons of anticipated vs. dynamic CAR discovery vs hybrid CAR discovery Radio traffic East of PAAR identification Control over TAR selection Simultaneous connections to two ARs from MN Power conservation issues Others Comment: Should seamoby develop protocols separately for the anticipated and the dynamic case, and leave it to the network operator to choose one over the other? Will these have hooks to build a Hybrid CAR discovery protocol Capabilities Exchange: What are the relevant capabilities? Should seamoby be involved in defining capabilities at all? If not, which WG will do this? Comment: How is this different from Mobile IP? Why can't router advertisements be used? Because it is more than just advertising itself, but also its capabilities. Comment: cdma2000 already has its own handoff discovery methods at L2. But we cannot expect them to use this protocol. It may be useful in heterogeneous environments. Comment: Should the mobile be allowed to discovery the candidates? It really depends upon the type of environment. It does, however, requirement that mobiles be simultaneously attached to several wireless networks. How does this protocol use to handle ping-pong effects? Comment: Handoff candidate will requirement some security relationships, and therefore could be unscalable, and therefore this work shouldn't happen. Having a GSM/802.11 roaming agreement is a hard thing to setup. Comment: If we expect to do fast handoff at L3, this work will be needed. Comment: Some items used in the discovery process are known, or handled, by different nodes in the network. Some by the mobile and others by the network elements. Comment: The mobile must be allowed to request this information. Hum: Is CAR useful work? Yes Hum: Should mobiles be involved? Yes Moving Forward on Paging - Pat Calhoun Pat Calhoun discussed the proposed timelines for the paging work, which is listed below from an earlier e-mail to the mailing list: Here is a proposal on how to proceed: 1. Folks submit protocols by no later than September 14th. 2. Each protocol submission must also include an accompanying I-D that compares the protocol against the requirements. For each requirement, the author must state whether the protocol complies to the requirements, and if so, how. Note that we aren't looking for a dissertation, but also not looking for empty claims. 3. Myself (or an appointed editor) will compile the list into a single Internet Draft, which will be used to ease comparison. This draft will be available on September 28th. 4. The document will be submitted to the WG, and a Last Call will be made to make sure that the WG agrees with the comparison. WG Last Call ends Oct 12th. 5. If there is a clear winner, then we begin protocol design based on leading protocol. Otherwise, discussions within the WG will commence to determine which protocol is best for our purposes. In either case, the WG will not rubber stamp the protocol. Input from the WG will be taken to ensure that the spec can withstand a WG Last Call. Our milestones show that we have a potential interim meeting in September. We can use this meeting to discuss the paging proposals, should we need a face-to-face. However, if such a meeting occurs, it would most likely fall within the mid-October timeframe. Some Considerations for Context Transfer - Gary Kenward The basic issue is that we don't know in which direction a mobile may be going. There are special cases where this is not true. CT can happen at anytime. If this does happen, then you may need to CT to many ARs. This is a one-to-many CT requirement, and this should be in the requirements Internet-Draft. CT shouldn't be tied to a CAR. Comment: Is the user of ANR intended? As opposed to AR and AG, which are commonly used terms? Hierarchy complicates things. Comment: Because of Hierarchy, is CT done at the edges, or in the core network? Seamoby Meeting - Wednesday August 8th [note: the first hour of the meeting was used by the MORE BOF] Discussion on Pending CT Requirements Issues - Pat Calhoun There are four remaining issues that need to be resolved: Issue 2 Issue 4 Issue 7 Issue 5 Issue 2 4.2 Not much favor on list - CT must define common IP level (layer 3) triggers to initiate CT, support mobile to initiate CT. Already there. 4.3 New requirement. CT must separate signaling to initiate CT from actual transfer. Should the requirement be dropped? 4.3 is proposed text. Not currently in requirements. Comment: We must have this feature and the mobile must initiate. Comment: This requirement isn't needed. It doesn't disallow any feature. Comment: 4.3 is not for mobile initiated. 4.2 is what triggers cause a context transfer, but we won't define what they are. Comment: If there are L2 triggers, do I have to defined L3 triggers? Triggers without signaling may be OK, but 4.3 is not necessary. 4.2 is a must. Comment: We need both. CT is useful if no L2 triggers exist. Hum: How many folks want to keep this text with some wordsmithing? Consensus is yes. Issue 4 & 7 These two issues are bundled since they both address proactive and reactive text. Issue 4 proposes new text, while 7 is a request to remove it from the doc. Comment: Why remove it? Two modes are too limited. There may be more than two modes, and having this in the reqs may limit future extensions. Comment: Don't know yet, perhaps revisit this issue later and move on to better understood requirements? Comment: This talks about protocol modes, but they are examples rather than modes. They are useful to discuss in terms of examples of how a protocol may work, but not normative. Comment: Perhaps this should be reconsidered during the design phase. Don't put it in as a requirement. Comment: This is a misunderstanding. The original timing requirements were there. To define the timing requirements we need to dig deeper and need to define its relation to handover. This was not supposed to be modes. A solution may cover both, but don't have to cover modes. It should be removed if it is expected to be a mode. Comment: Mode is the problem, not proactive or reactive. The use of the term capability is more descriptive, and should be used instead of mode. There is no bit in the header, this just describes how CT happens at different time relative to a handoff. Comment: Do we need to define temporal characteristics? This depends upon when a trigger was sent. Comment: Need to shift from mode to timing. Timing in which you act. CT tends to resolve around time restrictions. Dismiss timing, then revisit. Comment: Mode->Capabilities will not solve the problem. MN attaches to a new router, is context there or not? Pro - it's there. Re - It isn't there. Too much confusion. Put the text in an appendix. Comment: Proposed text. If context there when MN attaches to a new router, pro. If there after, re. Comment: Are timing requirements in the spec? Will it delay handover? May want to define pro and re. Otherwise, triggers may be needed. Confusion is based on starting and ending events. Comment: Presentation, is a distinction. Comment: Does there need to be a timing requirement? Comment: Cedric's text makes me the least happy. The way it is phrased it is difficult to understand. I don't know whether the discussion states that you implement two modes. Other than that, OK. Comment: Timing requirements is in the current doc in section 5. The current requirements for pro ad re are wrong. They specify too tight timing, and need to be fixed. Not happy with delegating to an appendix. It is an important part of CT and for seamlessness. Comment: It must be a requirement. Proactive is there when a packet arrives at a new AR. If we remove it, we'll be back in the same debate later. Comment: How would a router react if the first packet had a code point, and the QoS context wasn't there? Would it drop it? So there are timing requirements. Comment: Some environments exist where you don't have handoff notifications, so you have to live with what you have. Comment: But some networks have it. Comment: Always try to get context transferred prior to handover. Don't remove the possibility of moving context. Comment: It is important to have the capability for flexibility, as early and late. This shouldn't be an appendix. Comment: We can push or pull context. Pro or re depends on timing. Comment: This is purely a local API issue. Comment: This makes a difference. Multi-phasic means send state when handover is happening. Later, state isn't there for packet to be forwarded. Some other state may be transferred in other phases. The value is the concept, landscape for people to work on solutions. Comment: Proactive mode, previous router initiates. Reactive the new router initiates. Comment: Both routers should be able to initiate. You may be proactive in either direction. Hum: Here are the current options: 1) leave as is. 2) use word capabilities. 3) remove text from doc -5 4) remove text to appendix -5 5) state that CT before, during, or after handover. - many. Consensus shows folks want option 5. Issue 5 Multiphasic requirement. Transfer context in phases allowing time critical state first, and not critical later. This is a MAY. Comment: Irrelevant as to actual payloads, time critical is not the issue. Hum: How wants to adopt this text? Consensus shows yes. Some CT Issues - Charlie Perkins CT-Handover interworking IP handover - process which enables an MN to acquire network layer connectivity when it changes access routers, allowing it to send an receive IP packets. IP handover is a routing issue. CT - Process that facilitates continuing offering of IP features, typically during terminal mobility. CT addresses performance of transport protocols assuming IP connectivity is available. Is handover complete without CT? NO - MIP work not complete w.o. Seamoby. YES - Two concepts, preferred time relationship between two. Need to preserve connection on link. Also time relationship, before, during, or after handover, highlights distinction between handover and CT. Features have own characteristics, how to reinitialize if not transferred, etc. Transport Considerations Should it run over SCTP? Why? Some advantages in particular cases. Time critical - can't get after retransmission, then discard. Can't use TCP/SCTP with this? Comment: SCTP does have a mode to run this way. No fragmented packets is bad. Or do we use a well defined transport or define own transport? Comment: Does RFC allow? Separate draft allows. Comment: Nobody can state reliability, timing, and security requirements except in relation to individual features. Comment: Can't answer in general, depends on feature, need to do prototype and figure out. Comment: Some precedent, punting on reliable vs. unreliable, have both profiles. Different kinds of situations, stateless operation may do it. Here is Charlie's proposal 1) Start looking at particular features, standard features, how to transfer, build from there. Profile types. 2) Some standard features as sub-options of handover signaling messages. 3) Facilitate CT for different CT, Comment: Interoperable contexts. Worry about negotiating two access routers or end points, what does this mean? CT Framework. sending header compression, new AR can say no. If it can handle but interoperability problems, then bad. Set out data structures and fields. Negotiation. One target, or do negotiation. Might not need CAR discovery. Comment: Many ways to use profiles. Target AR selection. See if target supports profile. Also, do transfer, see if AR supports. Well defined profile. Comment: Both sides understand context. Run transfer. Should not include negotiations. CT profile type is a good idea. Different technologies, how would they understand? Comment: CT can be done independently of CAR selection. Comment: Negotiation is too slow. What would new AR do if failed? Can't relay useful info back. Comment: Decouple CAR selection from CT. Could do it proactively. Comment: What happens if CT fails? Security, reliability, link failure, no AR. Requirements should mention this case. Comment: Failure, then either renegotiate or? Comment: Too premature, depends on feature. Comment: Consider context negotiation failure. Third option, don't hand off. Target AR is same as source AR. Comment: Renegotiation should not be part. Should fail. Comment: Negotiation should be separate. Features should tell failover. Can tell mobile everything failed, OK. Comment: An optimization, just takes longer time if fails. Comment: Specific context could signal success or failure if needed. No ACK or NACK needed, then no indication. If so, then can. Comment: Request/reply sequence, should be possible to ACK/NACK. Comment: Implies tie CT to handover signaling. Separate signaling, how to indicate? Comment: Handover, CT not done, may have to renegotiate. Comment: CT only for handover or other things. If only handover, think about CT and profile types, mobility framework. Comment: IRTF micromobility scheme, still should allow CT. Comment: Mobility may be part of different messaging. Comment: Notification. Assumption to notify mobile, assumptions are a can of worms. Complexity could be avoided by taking a more piece by piece approach. AR section phase, different protocols transfer differently. Some way to get from a -> b. Comment: Devil in details. Comment: Time to handover. MORE BOF. Session mobility. Could benefit from CT. Reqs. for context movement for things that are not L3. Comment: Use CT for non time critical. Comment: Originator may need to know if context transferred. Comment: Assumed that CT is between ARs. MN is agent of CT, not necessarily the AR. Comment: 4.6 ARs as peers. Comment: CT between any two points. Too complex. More immediate problem. Solve AR/AR issue. Handover can be done w.o. CT. but what about if service is special. Dropping VoIP to best effort not an option. Comment: App wants a particular of service, separable protocols. Comment: Partial handover. Inter-technology. Might want to drop certain flows but not others. Can't get full blown. Conf call, hit lower rate, drop some service. Comment: App cares about mandatory context, don't run and don't pay. Comment: Policy, negotiation is complex. Comment: MN carries own context. Can't prevent a router from determining whether a device is appropriate. Proper protocol design should help. Is context delivery mechanism authenticated? Comment: Discussion during problem statement. Context not the same as on old router. Make CT during link handover. Can be expensive and error prone. Not just auth. CT are not mirror images. Comment: MN carry context, pay as you go. The router will affect. May have to rely on transmission over the air of context. Comment: Another req. is mutual auth. Don't allow for MN to be agent of CT, could download from MN, then push to new AR. Otherwise ARs may need mutual auth. Item 4.6. Comment: Mobile retrieve context and handoff to new, mobile moves to new AR, requests CT, mobile sends back up again. Comment: Route on old AR to new AR, push to new AR through old AR. Handoff after. Don't assume any access technology, or even IP address discovery. Comment: Need to have context features push to new AR via old. MN may do, also cases where. Comment: CT between ARs is more important than via MN, but needs to be resolved later. Could be agents, etc. Different kinds of context. Different kinds of transfer. Comment: Too detailed, req doc should not be a checklist. AR peers is logical notion, independent of path. Many scenarios. Separate puzzle, independent reqs. Comment: CT doesn't require that it is stored at AR when transferred, brought to current AR at time of transfer. No advantage to push to MN. Comment: Not always bandwidth to push from MN to router. Looking at simplest case, AR to AR, sec assc., etc. Could establish associate. BU in MIP, problem. Req doc should not prohibit. Comment: Examples of apps, ideas w.r.t architecture, might be a good idea to collect ideas. Focus discussion, too diffuse. Comment: Framework doc does describe. Comment: Close off requirements, look at existing doc, any limiting what they need, they address, get finished. Comment: Agree. Request, like to see context for a feature. Address issue of what is appropriate to send between two. Add a doc to WG, requirements for particular feature transfer. WG can bash back and forth. Action Items - Pat Calhoun Minutes to list. Gary updates req doc, last call, issues during last call. Next Steps - Pat Calhoun CT Reqs - done by Salt Lake City. CT protocol submission begins end of September AD: Req. in some WGs with a lot of practice, forces into interoperability, req to bring out issues, no implied req. during solution phase, could be useful even if incomplete. Requirements doc by end of Sept. DMHA wants to do conf calls after protocol comparisons, instead of a face to face meeting. From owner-seamoby@diameter.org Sat Aug 25 06:00:12 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09335 for ; Sat, 25 Aug 2001 06:00:11 -0400 (EDT) Received: (qmail 11923 invoked by alias); 25 Aug 2001 09:48:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11917 invoked by uid 200); 25 Aug 2001 09:48:00 -0000 Received: (qmail 11905 invoked from network); 25 Aug 2001 09:47:57 -0000 Received: from smtp010.mail.yahoo.com (216.136.173.30) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Aug 2001 09:47:57 -0000 Received: from 24-168-138-53.nj.rr.com (HELO solid) (24.168.138.53) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Aug 2001 10:00:09 -0000 X-Apparently-From: Message-ID: <00dd01c12d4d$90012390$6401a8c0@solid> From: "Eunsoo Shim" To: , Cc: , , "Rich Gitlin" References: Subject: Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Date: Sat, 25 Aug 2001 06:06:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, It's an interesting draft. Actually we submitted an I-D for fast handoff in MIPv4 last November with the idea of using the neighboring FA information. Unfortunately the I-D does not exist in the archive any more but it is available at http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobileip-neighbor-00.tx t. The neighbor FA in our draft is the PAAR described in your draft. The section 2 (Neighbor FA Information) describes a mechanism that each FA (AR in MIPv6) discovers its neighboring FAs (PAARs). It is a simple mechanism where each MN reports to the new FA (AR) of its old FA(AR) and then the new FA learns about the old FA as one of its neighbor FAs. Also the new FA informs the old FA of itself. Thus two FAs get to know each other. After a certain transition period, a FA gets to know its all neighbor FAs. It is a dynamic and distributed algorithm. We believe our neighbor FA discovery mechanism can be a solution for the problem of identifying the candidate ARs. Thanks. Eunsoo ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 13, 2001 10:48 AM Subject: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery I'm resending the draft to the mailing list as I did not see it appear in the archives. Sorry if you receive multiple copies. BRs, Govind. Abstract: Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability information from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's packet session may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for seamless handoffs is identifying the candidate access routers for the mobile node's handoff. When a collection of candidates has been identified, an algorithm is run to determine the target access router, and this router becomes the target of handoff at Layer 3. This document presents a problem statement describing issues involved in designing a candidate access router discovery protocol. The document does not discuss the algorithm by which the actual target router is identified, nor how the handoff to the target is achieved. Comments are welcome. Best Regards, Govind. <> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-seamoby@diameter.org Sat Aug 25 06:44:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09507 for ; Sat, 25 Aug 2001 06:44:37 -0400 (EDT) Received: (qmail 12514 invoked by alias); 25 Aug 2001 10:32:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12508 invoked by uid 200); 25 Aug 2001 10:32:33 -0000 Received: (qmail 12497 invoked from network); 25 Aug 2001 10:32:31 -0000 Received: from unknown (HELO MailBreak.Com) (216.207.225.170) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Aug 2001 10:32:31 -0000 Received: from solid [24.168.138.53] by mailbreak.com [216.207.225.173] with SMTP (MDaemon.PRO.v4.0.4.R); Sat, 25 Aug 2001 06:44:13 -0400 Message-ID: <024901c12d53$c3e89660$6401a8c0@solid> From: "Eunsoo Shim" To: Cc: , References: Subject: Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery Date: Sat, 25 Aug 2001 06:50:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-MDRemoteIP: 24.168.138.53 X-Return-Path: eunsoo@mailbreak.com Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, It's an interesting draft. Actually we submitted an I-D for fast handoff in MIPv4 last November with the idea of using the neighboring FA information. Unfortunately the I-D does not exist in the archive any more but it is available at http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobileip-neighbor-00.tx t. The neighbor FA in our draft is the PAAR described in your draft. The section 2 (Neighbor FA Information) describes a mechanism that each FA (AR in MIPv6) discovers its neighboring FAs (PAARs). It is a simple mechanism where each MN reports to the new FA (AR) of its old FA(AR) and then the new FA learns about the old FA as one of its neighbor FAs. Also the new FA informs the old FA of itself. Thus two FAs get to know each other. After a certain transition period, a FA gets to know its all neighbor FAs. It is a dynamic and distributed algorithm. We believe our neighbor FA discovery mechanism can be a solution for the problem of identifying the candidate ARs. Thanks. Eunsoo ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 13, 2001 10:48 AM Subject: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery I'm resending the draft to the mailing list as I did not see it appear in the archives. Sorry if you receive multiple copies. BRs, Govind. Abstract: Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability information from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's packet session may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for seamless handoffs is identifying the candidate access routers for the mobile node's handoff. When a collection of candidates has been identified, an algorithm is run to determine the target access router, and this router becomes the target of handoff at Layer 3. This document presents a problem statement describing issues involved in designing a candidate access router discovery protocol. The document does not discuss the algorithm by which the actual target router is identified, nor how the handoff to the target is achieved. Comments are welcome. Best Regards, Govind. QÍQ <> From owner-seamoby@diameter.org Tue Aug 28 15:13:03 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19058 for ; Tue, 28 Aug 2001 15:13:02 -0400 (EDT) Received: (qmail 29590 invoked by alias); 28 Aug 2001 19:00:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29584 invoked by uid 200); 28 Aug 2001 19:00:41 -0000 Received: (qmail 29579 invoked from network); 28 Aug 2001 19:00:39 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Aug 2001 19:00:39 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA18931; Tue, 28 Aug 2001 12:12:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7SJCVx29594; Tue, 28 Aug 2001 12:12:31 -0700 X-mProtect: Tue, 28 Aug 2001 12:12:31 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdcxfbLr; Tue, 28 Aug 2001 12:12:30 PDT Message-ID: <3B8BED1D.BF749806@iprg.nokia.com> Date: Tue, 28 Aug 2001 12:12:30 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Update on Issues from IETF meeting References: <35DBB8B7AC89D4118E98009027B1009B017A9F74@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Madjid, I have been away from e-mail for over a week! The HC method assumed in our draft is based on ROHC. We have used the rohc-rtp draft (now RFC 3095). Regards, -Rajeev Nakhjiri Madjid-MNAKHJI1 wrote: > Rajeev, > > I did a 1 hour attempt reading your hc draft coming to London. > I did not finish it unfortunately :( > I am trying to learn about HC, so I am pretty illiterate on HC. > What HC method was that draft based on? Rohc or something else? > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Tuesday, August 14, 2001 8:17 PM > To: Kulwinder Atwal > Cc: Hamid Syed; 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Update on Issues from IETF meeting > > Kulwinder Atwal wrote: > > > > > > > > > Rajeev: as far as I am aware, a TCP compression profile has not been > > > > defined yet. > > > > No, but I hear it is being worked on. I saw some presentations at > > Minniapolis. > > > > > > UDP compression Profile . . . For CT we could have: TCP context > > > > profileUDP context profile . . . > > > > Rajeev: In general, it could be profiles for HC/QoS/... > > > > I don't see how one could have single profile for HC when each HC Profile > > has a different context. > > For example, RTP has a sequence number, while UDP does not. > > > > Rajeev: I didn't imply that a single profile would suffice for HC (or QoS). > You certainly need more than one. Would you be willing to review > draft-koodli-seamoby-hc-relocate-01.txt ? :-) > You will find discussion on this as well as a CT profile for IP/UDP/RTP HC. > > Regards, > > -Rajeev From owner-seamoby@diameter.org Wed Aug 29 01:12:50 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00485 for ; Wed, 29 Aug 2001 01:12:21 -0400 (EDT) Received: (qmail 31074 invoked by alias); 29 Aug 2001 04:52:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31068 invoked by uid 200); 29 Aug 2001 04:52:38 -0000 Received: (qmail 31063 invoked from network); 29 Aug 2001 04:52:35 -0000 Received: from unknown (HELO market0) (208.158.105.111) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Aug 2001 04:52:35 -0000 Received: from mail pickup service by market0 with Microsoft SMTPSVC; Tue, 28 Aug 2001 22:01:37 -0700 From: To: Subject: [seamoby] ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping Date: Tue, 28 Aug 2001 22:01:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_D1258_01C1300D.01A5B670" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 29 Aug 2001 05:01:37.0044 (UTC) FILETIME=[AE6F8540:01C13047] Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_D1258_01C1300D.01A5B670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com, please click --> Un-Subscribe My E-mai l International Order Welcome FREE SHIPPING NOT APPLY Cell Phone Accessories Blow out Sale...!! Save Up to 80%...!! ***** FREE SHIPPING (in US only) ***** Why pay more in Retail Store..??? 1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for All Cell Phone (5 pack) Antenna Booster for All Cell Phone (1pack) large image Retail Price: $19.95 Blow Out Price: $5.95 (save 75%) More Details... Buy it NOW !! Free Shipping Antenna Booster for All Cell Phone (5 pack) large image Retail Price: $99.75 Blow Out Price: $19.95 (save 80%) More Details... Buy it NOW !! Free Shipping 2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable NOKIA 51xx/6xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping 3. NOKIA 82xx/33xx Black Car Charger 11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib Battery NOKIA 82xx/33xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery large image Retail Price: $65.99 Blow Out Price: $24.95 (save 62%) More Details... Buy it NOW !! Free Shipping 4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA 51xx/6xx Data Cable NOKIA 51xx/61xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping NOKIA 51xx/6xx Data Cable large image Retail Price: $69.99 Blow Out Price: $14.95 (save 79%) More Details... Buy it NOW !! Free Shipping 5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia 8260/8290 Li-ion 1200mAh Vibrating Battery NOKIA 82xx/33xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $24.95 (save 46%) More Details... Buy it NOW !! Free Shipping 6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery large image Retail Price: $79.99 Blow Out Price: $34.95 (save 56%) More Details... Buy it NOW !! Free Shipping Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery large image Retail Price: $70.99 Blow Out Price: $29.95 (save 58%) More Details... Buy it NOW !! Free Shipping 7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia 3310/3390 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $14.95 (save 67%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping 8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping ------=_NextPart_000_D1258_01C1300D.01A5B670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
Cell=20 Phone Accessories
Blow out Sale...!!
Save Up to 80%...!!
***** FREE=20 SHIPPING (in=20 US only) *****
Why pay more in = Retail Store..???

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 Antenna Booster for All Cell Phone = (1pack) 9.=20 Antenna Booster for All Cell Phone (5 = pack)
=20 Retail=20 Price: $19.95
Blow Out Price: $5.95 = (save 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
=20 Retail=20 Price: $99.75
Blow Out Price: $19.95 (save = 80%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
2.=20 NOKIA=20 51xx/6xx Black Car Charger 10.=20 Nokia 3310/3390 Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
3.=20 NOKIA=20 82xx/33xx Black Car Charger
 11.=20 Nokia 8260/8290 Li-ion 1200mAh 12=20 Lights Flashing=20 & Vib Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $65.99
Blow Out Price: $24.95 (save = 62%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
4.=20 NOKIA=20 51xx/61xx Hands Free with on/off = Switch 12.=20 NOKIA=20 51xx/6xx Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $69.99
Blow Out Price: $14.95 (save = 79%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
5.=20 NOKIA=20 82xx/33xx Hands Free with on/off = Switch 13.=20 Nokia 8260/8290 Li-ion 1200mAh Vibrating = Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $45.99
Blow Out Price: $24.95 (save = 46%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
6.=20 NOKIA=20 51xx/6xx Li-ion 3200mAh Vibrating = Battery 14.Nokia=20 51xx/6xx Super Slim Black Li-ion 1200mAh Vib = Battery
=20 Retail=20 Price: $79.99
Blow Out Price: $34.95 (save = 56%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $70.99
Blow Out Price: $29.95 (save = 58%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
7.=20 NOKIA=20 51xx/6xx Black NIMH-700mAh Vibrating = Battery 15.=20 Nokia 3310/3390 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $45.99
Blow Out Price: $14.95 (save = 67%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
8.=20 Nokia 8260/8290 Data Cable 16.=20 Nokia 8260/8290 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping		 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
------=_NextPart_000_D1258_01C1300D.01A5B670-- From owner-seamoby@diameter.org Fri Aug 31 09:12:50 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03885 for ; Fri, 31 Aug 2001 09:12:50 -0400 (EDT) Received: (qmail 18443 invoked by alias); 31 Aug 2001 13:00:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18437 invoked by uid 200); 31 Aug 2001 13:00:18 -0000 Received: (qmail 18432 invoked from network); 31 Aug 2001 13:00:16 -0000 Received: from ebene.inrialpes.fr (194.199.18.70) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Aug 2001 13:00:16 -0000 Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f7VD9FE05532 for ; Fri, 31 Aug 2001 15:09:16 +0200 (MEST) Message-ID: <3B8FFE6B.8B723F17@inrialpes.fr> Date: Fri, 31 Aug 2001 23:15:23 +0200 From: Pars MUTAF X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: seamoby@cdma-2000.org Subject: [seamoby] Paging area auto-configuration References: <20010822083042.B15493@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello all; We have submitted an I-D called "DPAC: Dynamic Paging Area Configuration" for DMHA (aka IP paging). Interested people can find it at the following address until it appears in IETF directories: http://www.inrialpes.fr/planete/people/mutaf/draft-mutaf-dpac-00.txt Millions of comments? No problem :-) Thank you in advance. Regards, pars PS: Below is the abstract: Abstract This document defines dynamic paging area configuration extensions to IP paging. The motivation is three fold: First, paging areas are auto-configured, hence human effort is minimized. Second, paging area shapes adapt to host mobility characteristics, hence more efficient. Third, paging area sizes are variable, allowing future optimization. Dynamic paging area configuration can be regarded as the major advantage of having L3 paging areas.