RE: [Seamoby] Minutes of Meeting at IETF 52

[George Tsirtsis <[e-mail]>]

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:[e-mail]
<mailto:[e-mail]> ]
Sent: Friday, January 04, 2002 3:11 PM
To: 'George Tsirtsis'; 'James Kempf'; [e-mail]
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:[e-mail]
<mailto:[e-mail]> ] 
> Sent: January 3, 2002 15:43 
> To: 'James Kempf'; [e-mail] 
> 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:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 03, 2002 7:24 PM 
> To: [e-mail] 
> Subject: [Seamoby] Minutes of Meeting at IETF 52 
> 
> 
> Attached. There is a one week comment period, ending on January 10. 
> 
>             jak 
> 
> _______________________________________________ 
> Seamoby mailing list 
> [e-mail] 
> https://www1.ietf.org/mailman/listinfo/seamoby
<https://www1.ietf.org/mailman/listinfo/seamoby>  
>