[Seamoby] Difficulty of Achieving Precision on Certain Requiremnts
"James Kempf" <kempf@docomolabs-usa.com> Sat, 20 July 2002 01:07 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 VAA21199 for <seamoby-archive@odin.ietf.org>; Fri, 19 Jul 2002 21:07:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13104; Fri, 19 Jul 2002 21:05:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13073 for <seamoby@ns.ietf.org>; Fri, 19 Jul 2002 21:05:50 -0400 (EDT)
Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21166 for <seamoby@ietf.org>; Fri, 19 Jul 2002 21:04:51 -0400 (EDT)
Message-ID: <00db01c22f89$4a972680$0f6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Gary Kenward <gkenward@nortelnetworks.com>, Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>, seamoby@ietf.org
References: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com>
Date: Fri, 19 Jul 2002 18:03:39 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Difficulty of Achieving Precision on Certain Requiremnts
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
Content-Transfer-Encoding: 7bit
Gary, > So you are proposing now that there are also feature specific > CT protocols? If this is true, and we follow your argument, > the we need to revisit all the attributes stated for CT: reliability, > timeliness, etc., etc. to determine what capabilities should be > common, and what capabilities should be feature specific. > Do you really think this is necessary? I just looked through the requirements and they all looked pretty general to me. If you think there are some specific requirements that would need updating, please post suggested modifications to the list. Best would be a separate thread per requirement, so that people can follow. > As far as updates go, I think it is a common capability. > Others don't agree, and they have examples which are convincing, such as header compression transfer (this one came up in coversations with the IESG this week). I was not involved in the initial discusssions on CT so I do not have the history on it. But I also don't have a lot invested in a particular outcome. I would like the WG to achieve concensus on a set of requirements that are specific enough to pass IESG muster, so that we can procced on to actually designing the protocol. My observation, over the last couple weeks of mailing list traffic and talking to some people involved, is that the requirements are not sufficiently crisp in places where people have very different ideas about what types of feature contexts they want to transfer. These include: 1) Update allowed v.s. prohibited. 2) Tight synchronization with external events v.s. no synchronization. 3) What transport to use. Trying to specify requirements in these areas for a general context transfer protocol when people have legitimate but very different notions of what they want to use the protocol for that would result in very different feature specific requirements can't succeed. In a separate thread, I will propose a new section that specifies requirements on specifications for individual feature contexts. Note that this proposal will not contain requirements on the feature contexts themselves, but only on their specifications. These will address the issues above. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
- [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- RE: [Seamoby] Proposal on Sync/NoSync Requirement john.loughney
- Re: [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- RE: [Seamoby] Proposal on Sync/NoSync Requirement john.loughney
- Re: [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary Kenward
- Re: [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary Kenward
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- Re: [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- Re: [Seamoby] Proposal on Sync/NoSync Requirement James Kempf
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary Kenward
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary Kenward
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary Kenward
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Proposal on Sync/NoSync Requirement Nakhjiri Madjid-MNAKHJI1
- [Seamoby] Difficulty of Achieving Precision on Ce… James Kempf