RE: [Seamoby] Minutes of Meeting at IETF 52
"Gary Kenward" <gkenward@nortelnetworks.com> Fri, 04 January 2002 15:25 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 KAA05339 for <seamoby-archive@odin.ietf.org>; Fri, 4 Jan 2002 10:25:18 -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 KAA24472; Fri, 4 Jan 2002 10:13:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24443 for <seamoby@optimus.ietf.org>; Fri, 4 Jan 2002 10:12:58 -0500 (EST)
Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04896 for <seamoby@ietf.org>; Fri, 4 Jan 2002 10:12:55 -0500 (EST)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04FCQA14938; Fri, 4 Jan 2002 10:12:26 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04FCOj20486; Fri, 4 Jan 2002 10:12:24 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <CFTPSHRX>; Fri, 4 Jan 2002 10:10:47 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4738@zcard031.ca.nortel.com>
From: Gary Kenward <gkenward@nortelnetworks.com>
To: 'George Tsirtsis' <G.Tsirtsis@flarion.com>, 'James Kempf' <kempf@docomolabs-usa.com>, seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52
Date: Fri, 04 Jan 2002 10:10:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19532.00681890"
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
George: Clearly there is much confusion over this particular requirement, and I promptly admit that it is odd. I am concerned that old issues will continue to be re-hashed if we start throwing out decisions that were made, in this case, almost a year ago. Someone, early last year, suggested that ct should check to ensure that the context it was sending was valid context. I cannot reproduce the whole conversation, but yes, the suggestion was to check semantics as well as syntax of the context. I personally could not see how this validation function could be provided without an enormous amount of complexity. Most of the participants in this conversation agreed, and to avoid any further discussion (the debate actually went on for a while), it was stated as a requirement that the ct solution would not attempt to perform validation of the context. This still leaves open the possibility that a router manufacturer could attempt validation (and probably should, to some degree, as part of the building of the feature context). Given that the IETF defines protocols, and validation does not seem to require a protocol capability, you are right in that this requirement does not really belong. However, past experience has repeatedly shown that this working group will repeatedly re-visit old issues if they are not clearly capture. Perhaps you, or someone else could think of better wording and propose it. Gary "To introduce something altogether new would mean to begin all over, to become ignorant again, and to run the old, old risk of failing to learn." (Isaac Asimov) > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: January 3, 2002 15:43 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Minutes of Meeting at IETF 52 > > > James, > > From the minutes.... > > "Section 4.13 expanded greatly. > Q: Is WILL NOT part of the standard terms? > A: No, is SHOULD be a MUST NOT. > Q: So if the CT solution verifies the CT info prior to > transfer it is NOT > acceptable? > A: We'll take that up on the mailing list." > > To remind you 4.13 is "4.13 The context transfer solution > WILL NOT verify > the context information prior to transfer." > > The old "SHOULD" was clearly not acceptable. The new "MUST > NOT" suggestion > was an obvious and a bit funny :-) mistake...As I pointed out > long time ago > this requirement should just be removed...it just makes no > sense....if only > it was the only one... ooops! I did not say that :-0 > > George > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 03, 2002 7:24 PM > To: seamoby@ietf.org > Subject: [Seamoby] Minutes of Meeting at IETF 52 > > > Attached. There is a one week comment period, ending on January 10. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >
- [Seamoby] Removing CT Requirements James Kempf
- [Seamoby] Minutes of Meeting at IETF 52 James Kempf
- Re: [Seamoby] Minutes of Meeting at IETF 52 Hemant Chaskar
- Re: [Seamoby] Minutes of Meeting at IETF 52 Behcet Sarikaya
- RE: [Seamoby] Minutes of Meeting at IETF 52 George Tsirtsis
- Re: [Seamoby] Minutes of Meeting at IETF 52 James Kempf
- Re: [Seamoby] Minutes of Meeting at IETF 52 James Kempf
- Re: [Seamoby] Minutes of Meeting at IETF 52 Behcet Sarikaya
- Re: [Seamoby] Minutes of Meeting at IETF 52 James Kempf
- Re: [Seamoby] Minutes of Meeting at IETF 52 Behcet Sarikaya
- Re: [Seamoby] Minutes of Meeting at IETF 52 James Kempf
- RE: [Seamoby] Minutes of Meeting at IETF 52 George Tsirtsis
- RE: [Seamoby] Minutes of Meeting at IETF 52 Gary Kenward
- RE: [Seamoby] Minutes of Meeting at IETF 52 George Tsirtsis
- RE: [Seamoby] Minutes of Meeting at IETF 52 Gary Kenward
- RE: [Seamoby] Minutes of Meeting at IETF 52 Gary Kenward