RE: [Seamoby] Minutes of Meeting at IETF 52

["Gary Kenward"<[e-mail]>]

George:

-----Original Message-----
From: George Tsirtsis [mailto:[e-mail]]
Sent: January 4, 2002 10:49
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; [e-mail]
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 
[gwk] The issue is on the table because you brought it up. Is it whimsy, or
are you having fun ;^}?
 
Non-validation was put into the requirements simply because, like sooooo
many issues discussed and thought to be resolved, data validation kept being
re-introduced. Making non-validation a requirement based upon the 
general agreement of those involved in the discussions did stop that
discussion, until now. 
 
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.
[gwk] Deja vu all over again. There are reasons behind everyone on of the
requirements. In some cases the discussion was long, laborious, and
inconclusive, and so esseentially, not worth repeating. 
 
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.
[gwk] Actually, this is one of the more important requirements. In reality,
the decision made was that "CT WILL NOT be a distributed protocol for
information gathering NOR  will CT be responsible for fetching the context
from a central server". Both ideas where proposed. 
 
4.13 The context transfer solution WILL NOT verify the context information
prior to transfer.
[gwk] Again, some wanted to have CT validate the context prior to
transmission. The group decided that this was not part of the scope of the
CT solution. So how would you capture it? 
4.15 The context transfer solution MAY include methods for interworking with
non-IETF mobility solutions. 
[gwk] Again, a number of us do not believe that CT should be a MIP
extension. If the only interest is in
defining a CT extension to MIP, then CT should be in the MIP wg, not
SeaMoby. 
5.5.2 A context update MUST preserve the integrity, and thus the meaning, of
the context at each receiving AR."
[gwk] As Madjid has pointed out: this is the summary of many hours of debate
about error control and the
use of "light weight" protocols. 
 
I don't understand your pre-occupation with these requirements. I have no
idea how one captures the discussion and effort that went into  the debates
around these issues except by including them in the requirements. Perhaps
there should have been a general discussion section (check out the brunner
NSIS requirements draft for an example). However, if you are a student of
requirements analysis and specification, you would know that
general discussions sections are not verifiable and thus are not
requirements. All of the above requirements
are verifiable.
 
At worst, these requirements can be perceived as innocuous. I have not heard
any argument that they are false, or limiting. There are plenty of examples
of RFCs that waste words, so I don't think that terseness
is a real issue.

 
I sound like a broken record I know...sorry.
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
 
IMHO, CT will never happen because everyone seems pre-occupied with defining
the solution within the
requirements document. As I understand the IESGs view of the role of
requirements, nothing is being cast in
stone. The requirements form a set of agreed upon guidelines that should
hopefully help everyone focus on
a finite problem set. If a requirement turns out to be very wrong, then the
wg can and should revise it.
If a requirement turns out to be useless, then everyone can, should and will
ignore it.
 
Gary
 
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>  
>