[Seamoby] RE: Removing CT Requirements

George Tsirtsis <G.Tsirtsis@flarion.com> Mon, 07 January 2002 11:04 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12911 for <seamoby-archive@odin.ietf.org>; Mon, 7 Jan 2002 06:04:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01010; Mon, 7 Jan 2002 05:41:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00979 for <seamoby@optimus.ietf.org>; Mon, 7 Jan 2002 05:41:24 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12716 for <seamoby@ietf.org>; Mon, 7 Jan 2002 05:41:21 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <CJDRHSFH>; Mon, 7 Jan 2002 05:40:53 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB8E8@ftmail>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: 'Gary Kenward' <gkenward@nortelnetworks.com>, 'James Kempf' <kempf@docomolabs-usa.com>, George Tsirtsis <G.Tsirtsis@flarion.com>
Cc: seamoby@ietf.org
Date: Mon, 07 Jan 2002 05:40:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19767.C66F1980"
Subject: [Seamoby] RE: Removing CT Requirements
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

yes I could say this is ambiguous and unnecessary since I can clearly claim
that error rates provided by almost all links today are good enough....
 
George

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, January 04, 2002 6:04 PM
To: 'James Kempf'; George Tsirtsis
Cc: seamoby@ietf.org
Subject: RE: Removing CT Requirements



I would like to know from George if he believes 
5.5.2 is irrelevant, or simply ambiguously worded. 
I believe (and I suspect that George may concur) 
that error protection for the context is 
required (consider the possible impact of attempting 
to install or use erroneous context at an AR), and 
that it is important to clearly identify that requirement 
(particularly given that there are no transport 
requirements in the id). 

Gary 

> -----Original Message----- 
> From: James Kempf [ mailto:kempf@docomolabs-usa.com
<mailto:kempf@docomolabs-usa.com> ] 
> Sent: January 4, 2002 12:31 
> To: Kenward, Gary [WDLN2:AN10:EXCH]; George Tsirtsis 
> Cc: seamoby@ietf.org 
> Subject: Removing CT Requirements 
> 
> 
> It seems to me like George is making a specific request as part of the 
> WG last call that the following 
> requirements be removed from the document: 
> 
> 4.12 The context information to be transferred MUST be 
> available at the 
> AR performing the transfer, prior to the initiation of a 
> given phase of 
> the context transfer. 
> 4.13 The context transfer solution WILL NOT verify the context 
> information prior to transfer. 
> 4.15 The context transfer solution MAY include methods for 
> interworking 
> with non-IETF mobility solutions. 
> 5.5.2 A context update MUST preserve the integrity, and thus the 
> meaning, of the context at each receiving AR." 
> 
> 
> based on their being impossible to interpret meaningfully in an 
> implementation and deployment context or to their being obvious. 
> 
> Rather than spend another week exchanging email on this 
> topic, I'd like 
> to ask the WG at this time if there 
> is anyone else who feels that one or several of these requirements 
> should be removed before we send this document to the IESG? 
> 
>                 jak 
> 
>