Subject: RE: [seamoby] Update on Issues from IETF meeting

From: James Kempf <[email-masked]>
Date: Thu, 16 Aug 2001 16:15:49 -0700 (PDT)

George,

>P.S.: I hope this group also appreciates that the criticism is not
>necessarily towards the people involved but towards this relatively new IETF
>process that IMO is fundamentally flawed. i.e.: the requirement to produce
>"requirements" documents before protocols. I hope the ADs are listening in!
>

Actually, I disagree with this assessment. I do not think that it is
possible to design a protocol without first agreeing what it should
do, which is what requirements are. Many of the disputes I've seen or been 
involved in during the protocol design phase stem from fundamental disagreement 
about requirements, though the participants in the group end up arguing
about header fields and data format rather than what is really the point
at issue. We have had very good success with defining requirements
for paging, for example, because the problem domain was fairly constrained,
if initially poorly understood. Now that we have the requirements done,
we are proceeding smoothly into protocol design. Similarly, although the
requirements phase was long and contentious, I believe the AAA working
group has also had good success with this process. That said, requirements
generation is not always necessary if the problem is well enough
understood that everbody agrees on what the protocol should do up front.
I think MIP fast handoff is in this category.

I believe the problem in context transfer stems partly from the unfamiliarity
of the participants with what exactly requirements generation is about,
which, as you point out, is a new process at IETF with which many (including
myself) are not completely familiar or comfortable. The other problem,
as I pointed out in my response to Scott's email, is that the details of the 
requirements for a context transfer protocol in many cases depend intimately on
the exact feature context being transferred, and so any attempt to
come up with general requirements is likely to result in fuzzy or
broad guidelines rather than specific, detailed points, which, as you 
and Scott pointed out, is a problem with the current draft. This is likely to 
lead to differences of opinion as people approach the problem from particular 
perspectives of feature contexts that they want to transfer. I think it may not 
be possible to come up with any more specific set of requirements than the 
current guideline-level, without locking in the requirements for particular 
feature contexts. I think that when the feature context protocols are defined, 
the requirements better be alot more specific because the problem needs to be 
better defined to constrain things like synchronization with handover, etc.
which are hard to define in a general way.

Anyway, that's my 0.02 euro, and we probably ought to take this thread to
[email-masked]. I think we need to accept the document with edits as
defined in the London meeting and move on. Whether it is called
guidelines or requirements is irrelevent, because it is not going
to get any more specific until we start looking at particular feature
contexts that need to be transferred, IMHO.

		jak

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 16 Aug 2001 16:28:28 -0700

> [email-masked].

Yes, please do and take it off this list. We have milestones, and if you want
them changed, talk to the ADs. If you think the system is flawed, take up on
the IETF list.

Meanwhile, let's get this thing out so we can work on protocols.

> I think we need to accept the document with edits as

It is very relevant to the ADs.

PatC

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Fri, 17 Aug 2001 01:56:23 -0400

I agree with James' assessment.

I would also add that there has been fierce debate amoung Design Team
members that has resulted in less than crisp requirements.  This vagueness
is not only to allow designers flexibility, but also implementors.

The nature of context transfer in an IP network involves many different
types of context, link-layers, network topologies, and time scales.  It is
difficult to be exact without ruling out someone's notion of how IP-based
CTP should work.

Rather than aim for a document that is 100%, instead this document is
probably around 80% with the other 20% left to the Design Phase.

The complexity of the task has caused many, many ratholes.  There are issues
in the remaining 20% that could be opened up by what seem like harmless
editorial changes, but the vagueness provides flexibility, and helps us move
to Last Call.

The current Change Request process I believe is necessary as it helps avoid
ratholes by monitoring the progress of issues and focusing debate:

http://www.diameter.org/seamoby-ct-issues.html

Unless new Issues are introduced by the Change Request process, I believe we
should accept the changes from London and move on to the next phase.

I support John's change to "before,during, and after" due to the flexibility
and forward movement it provides for the requirments document.

- Kulwinder.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 16, 2001 7:15 PM
Subject: RE: [seamoby] Update on Issues from IETF meeting