Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Action item For 01/05 Meeting



Thanks for the feedback Vivek

Find my responses below.

BR
Alan.

-----Original Message-----
From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
Sent: Wednesday, January 05, 2005 7:16 AM
To: Carlton, Alan G; stds-802-21@listserv.ieee.org
Subject: RE: Action item For 01/05 Meeting
Importance: High



Some comments on these slides:

1] Slide 2:
Instead of having 6 rows (xx to/from yy)  maybe we should have only 4
rows: 802.3, 802.x, 3GPP and 3GPP2.
The core elements are probably better addressed on individual technology
basis rather than through handover scenario basis.

AC: My intent here was to provide maximum flexibility to a proposal and
also allow good visibility as to what the intended scope of a proposal is.
With the matrix as is, it is possible for partial proposal to address 802.x
to 3GPP only. This would be indicated by the population of Row 5. If said
proposal scope covered a Reference Model, Event Service and Information Service
for this scenario then this would be indicated by the inclusion of text or
not in the correspondng cells. We can talk about this at Tuesdays conference
call.

Also columns under "Other Elements" should either be removed or left at
discretion of individual proposal, since those might differ across
proposals.

AC: I think it would be nice if we could agree some commom elements
here. The items I have included are just suggestions we can modify
change them. The intention in my mind of the "other" column was for the
discretionary element that you have noted.


2] Slide 3 and 5 can probably be combined.

AC: Yes you are probably right, I'll make some mods.

On slide 3 if we need 4
separate columns we may need to explain them somewhat as well, in case
people have questions.

AC: Totally agree - This may be something that is missing from our TRD.
We need to have a common agreement on this terminology

Also just claiming support for different
scenarios is probably not enough. Proposals probably need to back that
up by identifying "amendments" to these technologies to achieve this
support and that should probably be captured as well.

AC: Something to this effect could be included in the ultimate
evaluation guidelines document.

3] Also on slide 5 I am not sure we need these many scenarios. This
should probably be governed by architectural and other differences
between different scenarios within a proposal, to make them meaningful.

AC: The Note at the bottom provides for some flexibity. Of course if
a call flow pertaining to a particular proposal is redundant because the
basic mechanisms have already being explained elsewhere in another
call flow for example then a statement to that effect should be good
enough.


Best Regards,
-Vivek

|-----Original Message-----
|From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] On
|Behalf Of Carlton, Alan G
|Sent: Tuesday, January 04, 2005 4:44 PM
|To: stds-802-21@listserv.ieee.org
|Subject: Action item For 01/05 Meeting
|
|Assuming tomorrows meeting is going ahead. Here is an update to the
slides
|as requested at the last conference call.
|
|Best Regards
|Alan.
|
| <<80221 Tuesday 0105 CC Input.ppt>>
|
|