Subject: RE: [seamoby] Some proposed changes to the requirements draft.

From: "Shahrier, Sharif M." <[email-masked]>
Date: Mon, 12 Nov 2001 14:14:59 -0500

Hello James,

4.18 "The context transfer protocol MUST support both centralized and
distributed location of context information."

This requirement should be there so that there can be a "local" context
database (LCD)  within each AR. The LCD keeps a log of the context
parameters of every session that is currently active for the MN. 

In addition, there should be a "central"  context database (CCD). The CCD
keeps a log of all parameters that the MN is likely ever to need, whether or
not they are currently used.

Thus, LCD is a local cache memory and the CCD is a secondary storage memory.
New data in the LCD may replace that in the CCD using a write-through cache
coherency policy, whenever it needs to be updated.  When a new session
becomes active, the appropriate parameters may be read from the CCD to
replace the "unused" entries in the LCD.

The LCD is local to its AR, but the CCD is centralized and may be shared by
all the ARs.

This 2-level cache-main memory hierarchy will help reduce the size of the
LCD, and the CCD will help the context transfer itself, since it is
accessable by all the ARs.

jak> I don't understand this. What is this supposed to mean?

5.6.1 "The context transfer protocol MUST include methods for
interworking
with any IETF IP handover solutions".

5.6.2 "The context transfer solution MAY include methods for
interworking
with non-IETF handover solutions".
contexts or sub-divisions thereof".

jak> These two requirements assume that there will be only one context
transfer protocol for all application areas. I tend to believe that
there will be a set of protocols, some of which are tied directly to the
handover protocol, for better integration of those areas where timing
requirements are tightly tied to handover.

Note, Iuse the word "interworking" and not "independance". I feel that it is
better come up with a single context transfer solution that meets all the
"worst-case" handover scanarios, because otherwise we may end up
standardizing many  different context transfer protocols; each to meet a
specific handover specification, possibly leading to interworking problems,
amongst other things. 

As far as the scope of the problem SEAMOBY assigned to us, I believe, should
be to come up with a single context transfer protocol.

Did you have any comments to my other requirements?

-Sharif

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Mon, 12 Nov 2001 15:49:33 -0500

Gary,
> 
>     Any application area that utilizes the context transfer protocol 
> MUST define a standard representation 
>     for conveying context information. 
The wording may need to be fixed, but the requirement is not as you 
are both interpreting it. The "standard representation" 
referred to is the representation of the data chunks, or objects, 
in the context transfer protocol that are used to contain the context. 
The actual context is encapsulated within these data chunks, and the 
representation of that context is opaque to context transfer. What is 

I was not involved with the earlier drafting of this requirement. Could you
please explain why it's necessary
To define representation of data chunks for encapsulating the context?
I would prefer to just send the context information as part of the DATA
SEGMENT in a regular IP datagram, without any form
Of encapsulation .
-Sharif.

---

From: [email-masked]
Date: Tue, 13 Nov 2001 09:22:14 +0200

Hi James,

> Comments included, marked with jak>.
> 
> Section 5.1.2 "The context transfer protocol MUST define a stanard
> representation for coveying context information that will be 
> interpreted
> uniformly and perspicuously by different implementations"
> 
> I would like this to be deleted, because it has nothing to do with the
> actual "transfer" of the context.
> 
> jak> Agreed. This requirement is in the domain of the individual
> applications that use the protocol. Perhaps
> it should say:
> 
>     MUST define a standard representation for conveying context 
>     information.

I agree, but SHOULD might be more applicable than MUST, as I 
see this as more of a recommendation as opposed to an 
absolute requirement.

Then a general comment on Sharif's proposals:

> interworking with any IETF IP handover solutions".
> 
> interworking with non-IETF handover solutions".

Unless we have a reason why these are requirements,
I don't think we can support adding these into the document.

br,
John

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 13 Nov 2001 10:33:17 -0500

Hello John,

> 4.17 "The context transfer protocol MUST minimize the number of 
> signaling messages at the sending and receiving Access Routers".

I don't see the need for this.  I don't think this should be
a requirement.

Minimizing signaling messages have several benefits (a) reduces load on the
networks, (b) improves the effective utilization by ensuring that the
traffic is not dominated by signaling messages, (c) improves reliability,
(d) improves scalability.

> 4.18 "The context transfer protocol MUST support both centralized 
> and distributed location of context information."

I don't think that there is any concensus for this kind of 
requirement to be added.

Would you prefer it if it were re-worded as follows:

4.18 "The context transfer protocol SHOULD support centralized and
distributed storage of context information, if the network provides for it".

[Some current context directories e.g. PDP context has a centralized
directory structure within a system, other networks have a distributed
storage structure. Now, consider inter-system handoff from one network that
has a "centralized" directory to another network which supports a
"distributed" directory. If we want to use the same context transfer
protocol in this situation, it should work for both centralized and
distributed directory architectures. Do you not agree?]

> 5.1.6 "The context transfer protocol MUST provide mechanisms for 
* sharing contexts or sub-divisions thereof".

In some cases a feature context may be shared by two or more mobiles. Now,
it is possible to duplicate this feature context into individual context
areas for each mobile. No problem, If there are only a few feature context
being shared.

But what if there are large numbers of feature contexts being shared? Large
numbers of duplications would lead to a lot of excess directory space being
used up. This is not efficient.

Thus "sharing" feature context would require only one copy of it, and would
save a lot of space - hence the requirement.

I hope you agree.

I don't agree that the last 3 should be added.

Can you provide us a good reason why this should be the case. 

The current requirement draft clearly states in 4.14 and 4.15 that the CT
protocol MUST/SHOULD interwork with IETF/non IETF mobility solutions. Given
that the IETF has a number of mobility protocols, I think this is a
necessary requirement.

The IETF also has several handover solutions in the works, and thus to be
perfectly consistent with the aforementioned mobility requirements, we need
to  add these requirements as well for handover.

And there are also plenty on non IETF handover proposals, interworking
between UMTS and 802.11; UMTS and HYPERLAN1/2; between large scale 802.11
LANs and more. These are currently quite active areas, and any context
transfer solution that we standardize in the IP-layer, SHOULD be able to
interwork with these systems as well.

-Sharif.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 10:48:46 -0500

James:

  I can include both sentences: the first is fine for re-wording of the
existing requirement. However, the second is actually a new, separate
requirement, and should
be included as such. There are lots of reasons for trying to keep
requirements separated,
the best one being that each can be debated separately on it's own merits.

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: November 12, 2001 20:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.; seamoby
> Cc: Shahrier, Sharif M.
> Subject: Re: [seamoby] Some proposed changes to the 
> requirements draft.
> 
> 
> Gary,
> 
> > needed is a standard representation for these containers.
> >
> > The words do say "a standard representation for *conveying*"; the
> > key words are "for conveying". They do not say "a standard
> representation
> > for the context" which is how you are both interpreting the
> requirement.
> >
> > Again, we can clarify the wording, but the requirement still makes
> sense.
> > As for James proposal, this would be a new requirement.
> >
> 
> I misunderstood the requirement. I think you need to reword 
> it to avoid
> the possibility of misunderstanding. How about:
> 
>     The context transfer protocol MUST define a standardized container
>     format for encapsulating and conveying context information.
> Interpretation
>     of the context information within the container is the 
> domain of the
> application
>     for which context is being transfered. Applications 
> SHOULD define an
> interoperable
>     format for context information if they want to use the context
> transfer protocol.
> 
> Or, you can simply include the first sentence if you feel 
> that the rest
> is too controversial
> or would expand the requirement beyond what is currently agreed.
> 
>             jak
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 11:03:23 -0500

John:

> From: [email-masked] [mailto:[email-masked]]
> Sent: November 13, 2001 04:58
> To: [email-masked]; [email-masked]
> Subject: RE: [seamoby] Some proposed changes to the 
> requirements draft.
> 
> 
> Hi Sharif,
> 
> My comments, inline:
> 
> > Next, I would like to following additional requirements in the CT 
> > requirements draft.
> 
> > 4.16 "The context transfer protocol MUST be scalable. It MUST be 
> > scalable to millions of hosts".
> 
> This is 'motherhood & apple pie' text (i.e. - noone would really
> disagree). I don't know how this adds anything to the text.  
> Additionally, I would suggest SHOULD rather than MUST is
> what you mean.
> 

I wasn't going to comment, but your observation needs some clarification.
While scaleability is important, there are definitely different domains of
"scaleability". ARP for example, scales within a subnetwork, and not to the 
global internet. Myself, I do not know what "scaleable to millions of hosts"
really means. If the concern is in regards to the ability for the context
transfer solution to support a real wireless mobile network and one of the
constraining factors is the number of ct's that can be handled per time
period,
then both the number of terminals *and* the number of handoffs per time
period
are at issue (is trivial to say that any ct solution can handle an infinite
number
of terminals if the handoff rate is zero). The number of ARs are also
important,
for, again, ct is only required if there are more then one ARs.

 It is not clear to me how we would define the scaleability of ct in any
real
terms. We know that it must be applicable to within an administrative
domain,
and thus, the top limit would be the IP address space, but that is a
greatest
upper bound and not very useful. Usually, in these situations, people resort
to rate of complexity measures to define scaleability.

 Finally, scaleability is desireable, as long as the requirement is for
scaleability
at an acceptable cost. 

 Other then this, I do not know how one would word a requirement around
scaleability
other then the motherhood of "ct must be scaleable at an acceptable cost".

gary
 
*snip*

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 11:06:42 -0500

Sharif:
 
  This requirement is for the ARs to authenticate each other so that a ct
exchange can
be trusted. It has nothing to do with the MN and handoff per se.
 
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 
I have some issues with the following requirement in the CT draft.
 
4.9 The entities transferring context MUST have completed a mutual
authentication process prior to
      initiating the transfer.
 
I don't support this requirement.
 
It appears to me this may not fit the case for "break-before-make" handover
.  For instance, the mobile may break connection with the old
AP, and re-establish connection with the new AP. 
 
Assuming that the context is transferred prior to re-establishing the new
connection.
 
The mobile will need to re-authenticate after it makes a new connection at
its new AP.
 
I have seen several practical cases that supports this scanario, thus I feel
it is necessary for authentication after the transfer of context 
in "break-before-make".
 
-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 13 Nov 2001 11:28:57 -0500

Gary,
> Additionally, I would suggest SHOULD rather than MUST is 
Myself, I do not know what "scaleable to millions of hosts" 
really means. If the concern is in regards to the ability for the context 
transfer solution to support a real wireless mobile network and one of the 
constraining factors is the number of ct's that can be handled per time
period, 
then both the number of terminals *and* the number of handoffs per time
period 
are at issue (is trivial to say that any ct solution can handle an infinite
number 
of terminals if the handoff rate is zero
I agree with this. Number of ct's handled per time period and the number of
handoffs per time
Period are both good cases to support the scalability requirement. The other
point is the quantity of context information
Being transferred for each mobile over a given time. This bandwidth must be
scalable.
 It is not clear to me how we would define the scaleability of ct in any
real 
terms. We know that it must be applicable to within an administrative
domain, 
and thus, the top limit would be the IP address space, but that is a
greatest 
upper bound and not very useful. Usually, in these situations, people resort

to rate of complexity measures to define scaleability. 
I agree that the scalability of the CT must be applicabile within an
administrative domain; scalability must also
Be applicable across different operator networks as well.
I don't see how the IPv4 address space affects the scalability of CT. Could
you please explain?
 Finally, scaleability is desireable, as long as the requirement is for
scaleability 
at an acceptable cost. 
 Other then this, I do not know how one would word a requirement around
scaleability 
other then the motherhood of "ct must be scaleable at an acceptable cost". 
I agree. Perhaps something like:
4.16 The context transfer protocol MUST be scalable at an acceptable cost.
        The context transfer protocol MUST be ale to handle a large number
of  of context transfers per second, and MUST
        Be able to support a large number of handoffs per second. The
quantity of context information being transferred for each 
        Mobile per second MUST be scalable, i.e. the bandwidth of the
context transfer MUST be scalable.
        The context transfers MAY be within the same administrative domain,
or they MAY be across different 
         administrative domains.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 13 Nov 2001 11:43:57 -0500

Gary,
 
                Understood. However, the requirements contains nothing (?)
about the mobile authenticating with its context, after the context 
Has been transferred. 
 
I think a requirement should be there for this, otherwise, without
authentication, the MN can "get at" any context, or context feature that its
not authorized access to.
 
How about:
 
                There MUST be mutual authentication between the MN and its
context, after the context transfer has occurred.
 
-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 13 Nov 2001 16:17:21 -0500

Majid,
 
            Consider the case where the context transfer occurs before
handover. So, the context will arrive at the newAR before
            The mobile node does. What if something goes wrong - the context
is not correctly received by the newAR.
            When the MN arrives at the newAR, it needs to know this fact.
So, the MN should authenticate the received context, just
            To make sure that its context was successfully received by the
newAR.
 
-Sharif. 
 
Maybe you mean that the MN should authenticate the received context data,
but
then why does the MN should do this. The context is going to the new AR,
anyway.
If authentication of data is needed, new AR does it on behalf of MN.
 
Why are we dragging MN into the authentication process.
 
these issues are attacking the basic framework of CT, IMHO
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 16:21:53 -0500

Sharif:
 
  You have totally lost me here. The intent for CT is to transfer context
between functionally
equivalent peers. Specifically, ARs. The purpose of this context is to
support forwarding service
at an AR. The MN does not have access to this context. 
 
  If the network has security requirements for MN access (e.g.
authentication, authorization, encryption), 
then this implies there is a security context at the old AR that must be
relocated to the  new AR in order
for the MN to send bearer traffic through the AN. Again, the MN does not
have, or need to have, access
to this context. By definition, the MN would not know what to do with the
context, as it represents forwarding
service features.
 
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 11:44
To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 13 Nov 2001 16:29:52 -0500

Gary,
 
            I  agree that  MN "getting at" a context was not a good
description. However, please refer to my earlier posting to Majid's
comments.
            The reason for authentication with the MN is so that if the
context arrive at the newAR before the MN does, the MN needs to know that
            It did indeed arrive there correctly, and there was no problems
during the transfer, i.e. the context did not end up at a different AR from
that of the MN.
 
-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 4:22 PM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

 
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 11:44
To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 16:39:21 -0500

Sharif:
 
  I have responded in a previous message, but to add a comment in response
to the direction you
are describing: one vision of CT is that it actually does transfer context
to ARs before the MN 
arrives (e.g. it is proactive), and because of the physics of RF coverage
and mobility, this means
that the context should be transfered to a number of candidate ARs. Yes,
there are lots of issues
with this approach, but the intent is improve bearer service handover.
 
Cheers,
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 16:30
To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Gary,

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 4:22 PM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

 
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 11:44
To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 16:59:57 -0500

Sharif:
 
Not my call, but I would hope so. We have to address the issues in stages or
we will
never progress.
 
Most important, however, is that you cannot speculate on problems with CT
until we
understand the CT protocol and process. IMHO, the purpose of requirements
draft is not
to try and anticipate all the possible problems that might emerge from a
given solution.
And we already have requirements for maintaining security during CT.
 
Finally, this is not DoD work: the requirements are not intended to be the
utlimate,
cast-in-titanium, truth about CT for all time. It should be reasonably
complete, but
we must expect that we will discover more about the problem domain when we
start
working on solutions. No one, as far as I have ever heard or experienced,
has ever
succeed in doing a complete waterfall design for a system of any significant
complexity
(I think the requirements document for the pet rock was never changed after
approval).
 
Just my delusional opinion.
Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 16:41
To: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.; 'Nakhjiri
Madjid-MNAKHJI1'

Gary,

If CT failures, whether due to stale context or something else, creates
security problems, then
these need to be addressed. But, we should wait until we understand the
requirements for security
context transfer, before we state requirements for solutions to speculated
problems.
 
            Are these types of problems outside the scope of the current CT
requirements draft?
 
-Sharif.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 13 Nov 2001 17:51:23 -0500

Color is not an appropriate way to indicate quoting of other's text
in an IETF WG. Recall that despite many efforts to change it, the 
rule for IETF work is plain text. I prefer to include European 
characters in this definition, but that is where the grey-area is.

Please behave!

At 04:17 PM 11/13/2001, Shahrier, Sharif M. wrote:

>Majid,
>
>            Consider the case where the context transfer occurs before handover. So, the context will arrive at the newAR before...
>-Sharif. 
>
>Maybe you mean that the MN should authenticate the received context data, but
>
>then why does the MN should do this. The context is going to the new AR, anyway.
>
>               Understood. However, the requirements contains nothing (?) about the mobile authenticating with its context, after the context 
>
>Has been transferred. 
>
> 
>
>I think a requirement should be there for this, otherwise, without authentication, the MN can get at any context, or context feature that its not authorized access to.
>
>How about:
>
>                There MUST be mutual authentication between the MN and its context, after the context transfer has occurred.
>
>-Sharif.
>
>  This requirement is for the ARs to authenticate each other so that a ct exchange can
>
>n several practical cases that supports this scanario, thus I feel it is necessary for authentication after the transfer of context 
>
>in break-before-make .
>
> 
>
>-Sharif.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Nov 2001 18:17:24 -0600

<snip > 

Madjid>> I think, what I all along thought was we define a generic
format for the data and the packets regardless of the type of feature.
See our TEXT draft or Rajeev/ Charlie's draft as examples.

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Nov 2001 18:20:28 -0600

I agree, you need to specify for the receiving AR and the protocol unit
inside of it
how to parse context data for various features and how to ask to
retransmissions or
updates if necessary. 
 
If we start by saying we don't even want to define a packet format for CT,
then why
are we working on the CT protocol standard, let every technology/ system/
feature
do its own thing??
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, November 12, 2001 3:58 PM
To: 'Shahrier, Sharif M.'; 'James Kempf'; seamoby
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Sharif:
 
The thought was that the payload would be comprised of one or more of these
"chunks", each one representing a different feature context. The container
format would have to at least to provide a type field (where the type would
indicate the feature the context belonged to, but would be simply be used by
the
receiving AR to dispatch the container content to the appropriate entity),
and, a length field. There may be more to the container format, but nothing 
comes to mind.
 
Of course, the actually container representation is still to be determined.
The requirement states only that a representation must be defined.
 
There are plenty of analogies in other IETF protocols for this mechanism for
conveying pieces of similar but different data in one IP payload.
 
Gary
 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 12, 2001 15:50
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; Shahrier, Sharif M.;
seamoby
Cc: Shahrier, Sharif M.

Gary,

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Nov 2001 18:29:59 -0600

Agree with John,

4.16 and 4.17 don't add any value, seems like we are turning
the clock back to April 2001????

Agree with John on 4.18 and the last 3.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:58 AM
To: [email-masked]; [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Hi Sharif,

> sharing contexts or sub-divisions thereof".

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Nov 2001 18:41:41 -0600

Sherif,
 
First I think the chairs closed this thread. Authentication has to happen
between ARs, since
CT happens between ARs. If the MN was supposed to be involved in context
reestablishment,
we wouldn't be here in the first place.
Second, there are a lot of things that can go wrong with CT, and failed
authentication is one
of them. Reliability for CT and the backup mechanisms for CT are still open
issues, but for sure
a failed authentication at MN is not one of these issues and here is why:
 
after the two ARs have authenticated themselves to each other (maybe once
for all or maybe
before a CT, I don't inject my opinion here), then they engage in CT. The CT
data can be
authenticated if necessary. The receiving AR, will check the authentication
of context data.
 
Architecture-wise, this is the only way to do it,  based on the fact that
only ARs do CT.
And MN is not in this picture.
 
Hope this clears things out.
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Majid,

-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: [email-masked]
Date: Wed, 14 Nov 2001 08:41:42 +0200

Hi Madjid,

> The centralized approach to context transfer was dismissed
> very early on. Is this still an issues?

I don't think so.  However, if someone wants to invent
a way to do context transfer via a centralized server,
they can ... I don't think that any changes are needed
to the draft.

> Something like 5.6.1 is included, don't remember if it says
> "any" IETF protocols or not.
> 
> For 5.6.2 I am not quite sure if some non-IETF protocols even
> have the same definition for context as we do (PDP context is one
> example), any idea??

I imagine something could be invented ...

John

---

From: [email-masked]
Date: Wed, 14 Nov 2001 08:43:19 +0200

Hi,

> can we not use the word "encapsulating" context information, it
> could be inpreted as tunneling, or maybe I am paranoid :)

Agreed, so the text could be:

 The context transfer protocol MUST define a standardized container
 format for conveying context information. Interpretation
 of the context information within the container is the domain of the
 application for which context is being transfered. Applications 
 SHOULD define an interoperable format for context information if they 
 want to use the context transfer protocol.

John

---

From: [email-masked]
Date: Wed, 14 Nov 2001 09:37:25 +0200

Hi Henrik,
 
 >  Please, can we drop this ?
 
Out of the darkness, a voice of reason appears.  I support this, let's not
add this requirement.
 
John

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 09:32:03 -0500

Majid,

	The PDP context is used in the UMTS systems. A "global" PDP context
resides in the GGSN, and a "local" PDP context resides at each SGSN. The
context parameters at each SGSN is a subset of all those stored at the GGSN.
The MN's, of course, are attached to the SGSNs and send their datagrams to
the GGSN via the GTP (Generic Tunnel Protocol). 

Thus, the GGSN maintains a "central" context directory, while the SGSNs each
maintain a "local" context directory. 

The UMTS system is slated to use the IPv6 protocol, and hopefully, a lot of
the protocols that we develop in the IETF will find its way into this
architecture.

Aside from the UMTS, there are other wireless systems that will use context
transfer protocols with a combination of local/centralized directory
structure.

With this viewpoint, I strongly believe that the context transfer protocol
should support a combination of local and central context memory.

-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 09:35:36 -0500

If this is the case then that is fine. The requirements draft did not
explicitly spell this out.

-Sharif.

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Wed, 14 Nov 2001 09:35:38 -0500

Madjid,
 
I have some questions for clarifications.  First and before going into the
details, I would like to understand the focus of the work.  Is it only
concentrated on the context transfer?  or It involves the hooks that are
necessary to ensure that right contexts are at the right ARs serving the
right MNs?
 
I would agree with you that the authentication will take place between the
ARs before any CT takes place, may be as in wireless environment there is a
trust relationship between certain ARs where there is no need for
authorization.
 
However, if the MN is not involved in the CT.  How does the target AR ensure
that it is using the right context to serve the right MN? 
 
Regards,
 
Kamel
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tue, November 13, 2001 7:42 PM
To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Sherif,

 
 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Majid,

-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 09:43:59 -0500

Hello,
 
No, it is not a given that there's a requirement that the protocol MUST be
scalable to millions
of hosts. It SHOULD be scalable to the number of hosts that a MN may
reasonably have as
candidate access routers for a handover. 
 
In the paging requirements draft, section 4.2. explicitly spells out that:
 
            The IP paging protocol MUST be scalable to millions of Hosts.
 
This was agreed to earlier within this same WG. 
 
Since this was acceptable for both functional requirement and for
conformance testing, I can see no reason why it (or some version of it)
cannot be valid as well for the context transfer protocol requirements
draft.
 
-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 09:52:24 -0500

Majid,
 
            To add to points Kamel had made, I would also like to add
another point. 
 
            Given that there is a trust relationship between AR's in a
specific domain, where there is no need for authorization. If the MN then
were to "roam" to a different administrative domain, where there may be no
trust relationship between the AR's in the previous domain and the new
domain, how does the target AR in the new domain ensure that it is using the
right context to serve the right MN?
 
-Sharif.
 
-----Original Message-----
From: Shaheen, Kamel M. 
Sent: Wednesday, November 14, 2001 9:36 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Madjid,

 
 
Regards,
 
Kamel
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tue, November 13, 2001 7:42 PM
To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Sherif,

 
 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Majid,

-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 10:49:57 -0500

I realize that for you, the situation is very different. You have a real
system with real issues
to resolve. It is only one of many networks however, and perhaps a better
way to get the wg up
to speed on the specific requirements of UMTS (and other networks) is to
schedule some presentations
at the next IETF on existing context transfer problems/solutions. What say
you Pat and James?
 
Gary,
 
            I would support the presentation of existing context transfer
problems/solutions at the next IETF meeting. If Pat and James agree to this
suggestion, I would try and see if I can get something together on the PDP
context in the UMTS.
 
-Sharif.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 10:09:25 -0600

Hi Kamel, 

Please see my responses in line.

Regards,
Madjid

-----Original Message-----
From: Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 8:36 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Madjid,

Madjid>> Well If I may speak on the design team's behalf, others are welcome
to pitch in:
Yes, I think the consensus was that we only focus on transfer of context
not storage, dump, collection.... for the protocol standardization process.
However, for an implementation, you can't avoid the issues you mentioned.
We need to get into the specifics of each feature and see where the unit
that is processing that feature (say diffserv..) is located. 
Since this question is very feature specific, we decided to limit the scope
and say that we assume context resides at old (transmitting) AR prior to
transmission
and it will be received by one single unit (new AR) and it is "re-routed"
from there
to the feature processing unit.
If you assume otherwise, definition of a protocol without going into
specifics of 
each feature become very hard.

Madjid>> Authentication between ARs might happen once for all based on a
mutual trust (say an 
established SA). This would help timing and scalability of all future CTs
between those two
ARs regardless of which MN is involved. Don't know what you mean by
authorization here, but
authentication of the MN specific data can be a separate issues and might
require
more protection (maybe even encryption). So other measures are needed.
Please look at
our TEXT draft, 
http://www.ietf.org/internet-drafts/draft-nakhjiri-seamoby-text-ct-00.txt
for a bit more details on security issues (not quite mature yet).

However, if the MN is not involved in the CT.  

Madjid>> Depends what you call MN's involvement, is it sending the actual
context data
(this was ruled out), or is it just involved in trigger mechanism (we used
this one
in our draft). 

How does the target AR ensure that it is using the right context to serve
the right MN? 

Madjid>> This was why a standard formulation for context data and messaging
is needed.
An MN identifier and a microflow identifier and a feature identifier all
needed to make
sure the target AR understands what it needs to do with the data, please
take a look at
our draft for an example.

Regards,

Kamel
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tue, November 13, 2001 7:42 PM
To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Sherif,

-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Majid,

-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 10:22:12 -0600

Sherif,
 
I think you are actually contradicting him, he says you need both.
To answer your question, not having a "trust relationship" ( I don't like this term: I call
it security association) is not a CT specific problem, it is a general mobility/ security problem.
You want secure communication, you need security association. NO SA, no security.
You want security AND seamless mobility, you need to establish SAs in advance
or just don't move.

If you have an actual problem for which you think requirements are blocking
 a solution for (assuming that it is within the scope), I suggest you write an ID and
state that problem, so we all understand your position. 
 
Otherwise,  We have discussed ALL of your issues in length, please look at the archives.
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 8:52 AM
To: Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Majid,
 
            To add to points Kamel had made, I would also like to add another point. 
 
            Given that there is a trust relationship between AR's in a specific domain, where there is no need for authorization. If the MN then were to "roam" to a different administrative domain, where there may be no trust relationship between the AR's in the previous domain and the new domain, how does the target AR in the new domain ensure that it is using the right context to serve the right MN?
 
-Sharif.
 
-----Original Message-----
From: Shaheen, Kamel M. 
Sent: Wednesday, November 14, 2001 9:36 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Madjid,
 
I have some questions for clarifications.  First and before going into the details, I would like to understand the focus of the work.  Is it only concentrated on the context transfer?  or It involves the hooks that are necessary to ensure that right contexts are at the right ARs serving the right MNs?
 
I would agree with you that the authentication will take place between the ARs before any CT takes place, may be as in wireless environment there is a trust relationship between certain ARs where there is no need for authorization.
 
However, if the MN is not involved in the CT.  How does the target AR ensure that it is using the right context to serve the right MN? 
 
Regards,
 
Kamel
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tue, November 13, 2001 7:42 PM
To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Sherif,
 
First I think the chairs closed this thread. Authentication has to happen between ARs, since
CT happens between ARs. If the MN was supposed to be involved in context reestablishment,
we wouldn't be here in the first place.
Second, there are a lot of things that can go wrong with CT, and failed authentication is one
of them. Reliability for CT and the backup mechanisms for CT are still open issues, but for sure
a failed authentication at MN is not one of these issues and here is why:
 
after the two ARs have authenticated themselves to each other (maybe once for all or maybe
before a CT, I don't inject my opinion here), then they engage in CT. The CT data can be
authenticated if necessary. The receiving AR, will check the authentication of context data.
 
Architecture-wise, this is the only way to do it,  based on the fact that only ARs do CT.
And MN is not in this picture.
 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Majid,
 
            Consider the case where the context transfer occurs before handover. So, the context will arrive at the newAR before
            The mobile node does. What if something goes wrong - the context is not correctly received by the newAR.
            When the MN arrives at the newAR, it needs to know this fact. So, the MN should authenticate the received context, just
            To make sure that its context was successfully received by the newAR.
 
-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

I think a requirement should be there for this, otherwise, without authentication, the MN can "get at" any context, or context feature that its not authorized access to.
 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

4.9 The entities transferring context MUST have completed a mutual authentication process prior to
      initiating the transfer.

It appears to me this may not fit the case for "break-before-make" handover .  For instance, the mobile may break connection with the old
AP, and re-establish connection with the new AP. 
 
Assuming that the context is transferred prior to re-establishing the new connection.
 
The mobile will need to re-authenticate after it makes a new connection at its new AP.
 
I have seen several practical cases that supports this scanario, thus I feel it is necessary for authentication after the transfer of context 
in "break-before-make".
 
-Sharif.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 10:25:40 -0600

Speaking of solution proposal, anybody has had a chance to look at our draft, I think
we tried to open up some issues there.

Regards,
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 9:40 AM
To: 'Shahrier, Sharif M.'; Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Sharif:

   One thing that I am pretty sure Seamoby is not going to get into, is exploring the world of
internetwork authentication. CT needs it, yes, but will Seamoby be defining the solution?
As far as I know, it's not in our charter. Just as defining new security protocols for CT was
place out of scope very early on in the discussions.

  You have valid points, many were discussed last spring. It doesn't hurt to revisit issues, for
we are constantly expanding our understanding of this problem domain (or, at least I hope so).
However, in my delusional view, we all need some real solution proposals to chew on in order to
really progress.

  I realize that for you, the situation is very different. You have a real system with real issues
to resolve. It is only one of many networks however, and perhaps a better way to get the wg up
to speed on the specific requirements of UMTS (and other networks) is to schedule some presentations
at the next IETF on existing context transfer problems/solutions. What say you Pat and James?

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 14, 2001 09:52
To: Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; Kenward, Gary [WDLN2:AN10:EXCH]
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Majid,

 
-Sharif.
 
-----Original Message-----
From: Shaheen, Kamel M. 
Sent: Wednesday, November 14, 2001 9:36 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Madjid,

 
 
Regards,
 
Kamel
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tue, November 13, 2001 7:42 PM
To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Sherif,

 
 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 3:17 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Majid,

-Sharif. 

 
 
Madjid
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:44 AM
To: 'Gary Kenward'; Shahrier, Sharif M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
Gary,

 
How about:

-Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:07 AM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.
 
Sharif:

Gary
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 09:51
To: Shahrier, Sharif M.
Cc: [email-masked]'
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

 

 

-Sharif.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 12:29:40 -0600

Yes, without even seeing the entire text, I definitely
prefer enclosing over encapsulating :)

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 11:12 AM
To: Nakhjiri Madjid-MNAKHJI1; Gary Kenward; Shahrier, Sharif M.; seamoby
Cc: Shahrier, Sharif M.
Subject: Re: [seamoby] Some proposed changes to the requirements draft.

Well, how about "enclosing" then? I just think we need to clarify the
requirement text some, as I think it is unclear
as currently written.

        jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Gary Kenward"
<[email-masked]>; "Shahrier, Sharif M."
<[email-masked]>; "seamoby" <[email-masked]>
Cc: "Shahrier, Sharif M." <[email-masked]>
Sent: Tuesday, November 13, 2001 4:22 PM
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

> Sent: Monday, November 12, 2001 7:17 PM
> To: Gary Kenward; Shahrier, Sharif M.; seamoby
> Cc: Shahrier, Sharif M.
> Subject: Re: [seamoby] Some proposed changes to the requirements
draft.
> I misunderstood the requirement. I think you need to reword it to
avoid
>     for which context is being transfered. Applications SHOULD define
an
> Or, you can simply include the first sentence if you feel that the
rest

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 12:33:31 -0600

Thanks, 

I agree. Our requirements can't look like UMTS requirements.

The UMTS/ GPRS need for context transfer is definitely
 a topic of interest, BUT in a separate ID. I will look forward to reading
it.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 11:32 AM
To: Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel M.; 'Nakhjiri
Madjid-MNAKHJI1'

Gary/Sharif,

I certainly agree that we should not be tayloring our requirements for
existing UMTS/GPRS networks. The requirements should define the
properties of a desirable solution for the Internet.

Regarding the specific requirement, about authentication, as Majhid
indicated, the thread is closed. CT happens between ARs or other
entities involved in routing in the wired network. The MN isn't
involved. If you look at the problem statement (the latest draft of
which is on my disk ready to go), that's how it is defined. So the
authentication involved is between ARs.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Shahrier, Sharif M.'" <[email-masked]>;
"Shaheen, Kamel M." <[email-masked]>; "'Nakhjiri
Madjid-MNAKHJI1'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2001 7:40 AM
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

> Sharif:
>
>    One thing that I am pretty sure Seamoby is not going to get into,
is
> exploring the world of
> internetwork authentication. CT needs it, yes, but will Seamoby be
defining
> the solution?
> As far as I know, it's not in our charter. Just as defining new
security
> protocols for CT was
>   You have valid points, many were discussed last spring. It doesn't
hurt to
> revisit issues, for
> we are constantly expanding our understanding of this problem domain
(or, at
> least I hope so).
> However, in my delusional view, we all need some real solution
proposals to
> chew on in order to

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 14:25:02 -0500

James,

James,

I don't disagree that protocols developed within the IETF should be focused
on the Internet, as that is the main charter of the IETF. 
However, I do think that in the wider interests of global harmonization with
other networks, the IETF's protocols should interwork with them. 

[In fact, I have noted that many companies are currently using Mobile IP to
interconnect many different types of networks.]

Thus, it was good to note that the CT requirements draft contained:

4.15 "The context transfer solution MAY include methods for interworking
with non-IETF mobility solution".

In the same notion, I had proposed that:

"The context transfer solution MAY include methods for interworking with
non-IETF handover solutions."

I hope that people will agree.

Thanks.

-Sharif.

 -----Original Message-----
From: 	James Kempf [mailto:[email-masked]] 
Sent:	Wednesday, November 14, 2001 1:58 PM
To:	Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; Gary Kenward;
Shahrier, Sharif M.

Kamel,

This issue came up last spring. The IETF is specifically concerned with
standards for the Internet, it is the Standards Development Organization
(SDO) for the Internet. Working groups can consider the experience of
other standards development organizations when developing Internet
standards, that is simple common sense and good engineering practice. We
can also consider the needs of othe standards bodies for Internet
standards, just as we consider the needs of companies and individuals.
But any requirements or protocols we develop should be focused on the
Internet, not on standards developed by other standards bodies.

Hope that's clear.

            jak

----- Original Message -----
From: "Shaheen, Kamel M." <[email-masked]>
To: "'Nakhjiri Madjid-MNAKHJI1'" <[email-masked]>; "'James
Kempf'" <[email-masked]>; "Gary Kenward"
<[email-masked]>; "Shahrier, Sharif M."
<[email-masked]>; "Shaheen, Kamel M."
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2001 10:45 AM
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

> I would respectfully disagree.  I think it would be beneficial to this
work
> to understand and to take previous work into consideration (not
necessarily
> to duplicate) if we would like wider acceptance and more generalized
> solution.  Specially given the current drive toward global more
harmonized
> kind of interworking.
> Sent: Wed, November 14, 2001 1:34 PM
> To: 'James Kempf'; Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel
> M.; Nakhjiri Madjid-MNAKHJI1
draft.
> >   I realize that for you, the situation is very different. You have
a
> > to speed on the specific requirements of UMTS (and other networks)
is
> to
> > at the next IETF on existing context transfer problems/solutions.
What
> say
> > I have some questions for clarifications.  First and before going
into
> > I would agree with you that the authentication will take place
between
> the
> > ARs before any CT takes place, may be as in wireless environment
there
> is a
> > However, if the MN is not involved in the CT.  How does the target
AR
> ensure
> > of them. Reliability for CT and the backup mechanisms for CT are
still
> open
> > before a CT, I don't inject my opinion here), then they engage in
CT.
> The CT
> >             To make sure that its context was successfully received
by
> >                 Understood. However, the requirements contains
nothing
> (?)
> >                 There MUST be mutual authentication between the MN
and
> its
> >   This requirement is for the ARs to authenticate each other so that
a
> ct
> > Assuming that the context is transferred prior to re-establishing
the
> new
> > I have seen several practical cases that supports this scanario,
thus
> I feel

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 14 Nov 2001 15:01:41 -0500

Hi Shahrier,

In the formative months of SeaMoby we were bandying about the
notion of heterogeneous handovers, i.e.  how would one perform
an IP friendly handover from IS-95 to Bluetooth or 802.11b for
example.  This was written out of the SeaMoby charter by the
IESG.  I think it is still  a noble goal.  However, I am not
sure how practical it is anymore.  In retrospect that was 
probably a bit too idealistic proposition.

Also, I have come around to recognize the importance of an
abstract CT mechanism that improves mobile IP handovers that
remains as radio agnostic as possible.  Not sure if this make
YOU feel any better though.... :-)

Best regards,

Phil

> I hope that people will agree.

****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 14:11:48 -0600

I guess I owe you a correction, instead of 

"Our requirements can't look like UMTS requirements"

I should say, "we cannot comply with UMTS requirements only and
forget everything else" what about
CDMA2000 or 802.11a/b or hyperlan?

I second James comments on this. I invite you to write a draft
on UMTS requirements and inform us about them, so we can make
better generic protocols. I personally am very interested to 
make CT, UMTS friendly, A draft would be a good start :)

Madjid

-----Original Message-----
From: Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 12:45 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; Gary Kenward; Shahrier,
Sharif M.; Shaheen, Kamel M.
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

I would respectfully disagree.  I think it would be beneficial to this work
to understand and to take previous work into consideration (not necessarily
to duplicate) if we would like wider acceptance and more generalized
solution.  Specially given the current drive toward global more harmonized
kind of interworking.

Regards,

Kamel 

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Wed, November 14, 2001 1:34 PM
To: 'James Kempf'; Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel

Thanks, 

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 11:32 AM
To: Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel M.; 'Nakhjiri
Madjid-MNAKHJI1'

Gary/Sharif,

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Shahrier, Sharif M.'" <[email-masked]>;

is
defining
security
hurt to
(or, at
proposals to

---

From: "Shaheen, Kamel M." <[email-masked]>
Date: Wed, 14 Nov 2001 15:17:09 -0500

Hi Phil,

In 3GPP, there is a WI for interworking between UMTS and HIPERLAN/802.11 and
the work has already started with several proposals on the table. This
effort (WI) has been pushed mainly by the service provider.  I am assuming
that a similar push is in the work for IS-95/3GPP2 (I am not sure though!).

The current practice in UMTS (3GPP)is to refer to IETF RFCs and I am sure
the practice will continue if such RFC (potential RFC) exists for context
transfer.

Regards,

Kamel 

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Wed, November 14, 2001 3:02 PM
To: 'Shahrier, Sharif M.'; 'James Kempf'; Shaheen, Kamel M.; 'Nakhjiri
Madjid-MNAKHJI1'; Gary Kenward
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Hi Shahrier,

Best regards,

Phil

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 17:00:17 -0600

Kamel,

Could you send me the WI description or the document. I am interested
in knowing what is out there in 3GPP.

Well, there are 2 problems here:

1-CT does not have a solution RFC.
2-I feel that the differences between definitions of
context in 3GPP and IETF needs to be hashed out, so 
we make sure we talk about the same thing, when we say
"context" (I will talk about it in my email to Sherif).

Madjid

-----Original Message-----
From: Shaheen, Kamel M. [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 2:17 PM
To: 'Phillip Neumiller'; Shahrier, Sharif M.; 'James Kempf'; Shaheen,
Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; Gary Kenward
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Hi Phil,

Regards,

Kamel 

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Wed, November 14, 2001 3:02 PM
To: 'Shahrier, Sharif M.'; 'James Kempf'; Shaheen, Kamel M.; 'Nakhjiri

Hi Shahrier,

Best regards,

Phil

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 15 Nov 2001 09:21:02 -0500

Hello Majid, everyone:

	I don't think the requirements document prevents any solutions from
maintaining a centralized centext storage, as well as a local context
storage at the ARs, is there?

Also, there is nothing to prevent context transfer via a "triangular" route,
i.e. from the oldAR's local context --> to central context database -->
newAR's local context, is there, as per the current requirements document?

-Sharif.

Ok, It is clear that storage issue is out of scope. So I am 
not going to debate on central versus localized context, that
would be a specific issue for UMTS to solve if part of "context"
is at SGSN and part of it in GGSN (which are both edge routers essentially,
pointing at different edges of GPRS network, i.e. radio versus internet).

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 15 Nov 2001 10:26:31 -0500

-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 14, 2001 09:52
To: Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; Kenward, Gary
[WDLN2:AN10:EXCH]

*snip*

[gwk] It's called the 5-tuple. source address identifies the MN, other
fields identify
the microflow.

If you are concerned about spoofing, etc., that's handled by securing the
transfer process. 
 
Regards,
 
Kamel
-----Original Message--
*snip* *snip* *snip*