Subject: Re: [Seamoby] Minutes of Meeting at IETF 52

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 03 Jan 2002 20:05:44

Hi James:

In the "Slide discussion on issue involving MN detection of
network topologies:" discussion thread, there was the following point made 
at the end of the day:

- MN providing information to AR in order to aid CAR discovery is not to be 
precluded, if such a protocol does not compromise security and reliablity of 
information.

Hemant

>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>
>Subject: [Seamoby] Minutes of Meeting at IETF 52
>Date: Thu, 3 Jan 2002 11:23:31 -0800
>
>Attached. There is a one week comment period, ending on January 10.
>
>             jak
><< MinutesIETF-52seamoby.txt >>

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Jan 2002 06:07:16 -0500

James,

I do not care about the minutes. I pointed to what IMO needs to be changed
in the draft based on the discussion in the meeting.

George

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, January 03, 2002 8:46 PM
To: George Tsirtsis; [email-masked]
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52

George,

So are you proposing that the minutes be amended to
include a statement of what Section 4.13 refers to?

            jak
----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 03, 2002 12:42 PM
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:[email-masked]]
> Sent: Thursday, January 03, 2002 7:24 PM
> To: [email-masked]

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 4 Jan 2002 10:10:53 -0500

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) 

> From: George Tsirtsis [mailto:[email-masked]]
> Sent: January 3, 2002 15:43
> To: 'James Kempf'; [email-masked]
> Q: So if the CT solution verifies the CT info prior to 
> transfer it is NOT
> acceptable?
> To remind you 4.13 is "4.13 The context transfer solution 
> WILL NOT verify
> 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

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Jan 2002 10:49:05 -0500

Gary,
 
We agree in essence but disagree on action...as it has been for some time on
this issue. I will thus try once again and see how it goes.
 
Data validation was at some point suggested....and unfortunately accepted as
a requirement. After some thought and multiple complaints people realized
that this can not be a requirement....yet the idea of *removing* the
requirement was for some, to me still weird, reason dismissed as utterly
impossible! The authors in an attempt to correct the situation reworded this
and made non-validation a requirement which brought a smile to my face :)
and the issue again on the table 
 
I do not understand the reluctance of this group to *remove* requirements.
Removing a requirement DOES NOT....I repeat DOES NOT mean that the thing
removed is now illegal or must not be supported...it  just means that a
proposal does not HAVE to cover it to be a valid proposal.
 
This has resulted in a document littered with semi-irrelevant and ambiguous
requirements such as:
"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."

I sound like a broken record I know...sorry.
 
George

-----Original Message-----
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Friday, January 04, 2002 3:11 PM
To: 'George Tsirtsis'; 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52

George: 

Gary 

> From: George Tsirtsis [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Attached. There is a one week comment period, ending on January 10. 
<https://www1.ietf.org/mailman/listinfo/seamoby>