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
>