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

From: "Gary Kenward" <[email-masked]>
Date: Fri, 4 Jan 2002 11:18:24 -0500

George:

   Yes we agree, but I do not hear a recommendation for action that would
solve the problem of eliminating trivial requirements, while preventing
wheel spinning. I'm trying to avoid repeating how long we've been at these
requirements, and how many times we have re-visited the same issues (the
mobility issue was covered the first time way back when).

   I also agree with your observations about the requirements you have
singled
out, except for 5.5.2. As you probably recall, 5.5.2 is compromise wording
for
the very critical need to ensure that the context is transferred without
introducing errors (significant errors? more then 1 error in 10000000 bits?
*sigh* *shrug*). And so, I'm not sure why you see it as being
semi-irrelevant.
Maybe you see 5.5.2 as being ambiguous? Sure it is, but are you suggesting 
we go back 10 months, and spend another 5 weeks debating subjective terms
for error control?

  Finally, I do want you to understand that I am not in opposition to your
point of view, I am simply trying to explain the circumstances. I suggest
that you post a specific request to the working group to remove the
"semi-irrelevant" requirements, and dis-ambiguate the remaining
requirements.
You have my support.

Gary

BTW: is "broken record" a relevant phrase any more? would the more apropos
term be a "wacked CD"? my daughter loves to listen to music play on
purposely
"broken records" ("played" by DJ's of all things, on very expensive machines
designed specifically to permit "scratching" and "skipping"), so does this
make a "broken record" a good thing? *smile*

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]]
Sent: January 4, 2002 10:49
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52

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]]
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: 
  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:[email-masked]] 
> Sent: January 3, 2002 15:43 
> To: 'James Kempf'; [email-masked] 
> 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] 
> Subject: [Seamoby] Minutes of Meeting at IETF 52 
> 
> 
> Attached. There is a one week comment period, ending on January 10. 
> 
>             jak 
> 
> _______________________________________________ 
> Seamoby mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/seamoby 
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Jan 2002 09:31:19 -0800

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