Subject: RE: [seamoby] FW: Mobile Host -> Mobile Terminal name change prop osal

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 8 Feb 2001 14:26:10 -0500

> -----Original Message-----
> From: Mat Horan [mailto:[email-masked]]
> Sent: Thursday, February 08, 2001 12:07 PM
> To: [email-masked]
> Subject: [seamoby] FW: Mobile Host -> Mobile Terminal name change
> proposal
> 
> 
> 
> 
> As long as we're considering definition name changes I'd like 
> to propose
> changing the term Mobile Host to Mobile Terminal.  The 
> functionality of this
> device remains the same as does the name and functionality of 
> the Mobile
> Node.
> The reason for this is that many implementations may use a 
> device other than
> a "PC" to connect to an Access Point or Mobile Node.  This device may
> connect to a "PC" or may be embedded.

Could a Mobile Terminal not be a mobile node, or mobile host?
Just becuase it is embedded does not reduce its functionality.

Please clarify.

- Kulwinder.

> Regards,
> Mat
> Mat Horan
> COM DEV Wireless Group
> 805.544.1089 x2244 (v), 805.544.2055 (f)
> http://www.comdev.cc
> 
> 
> -----Original Message-----
> From:	Seamless Mobility Working Group
> [mailto:[email-masked]]  On 
> Behalf Of Nakhjiri
> Madjid-MNAKHJI1
> Sent:	Wednesday, February 07, 2001 9:12 AM
> To:	[email-masked]
> 
> 
> Henrik, others
> Based on my email exchange with Rajeev, I like to suggest the 
> following
> changes.
> Also, please let me know what you think about the name 
> changes (at the very
> end of this email), I feel this is something that needs to be 
> addressed and
> decided at the conference call.
> Regards,
> Madjid
> 
> 
> 3.1.4- I suggest that we add the following to the end of the 
> definition of
> context 3.1.4
> "It should be noted that, not context, but subcontext is the 
> smallest unit
> of information storage and transfer, in other word, storage 
> and transfer of
> information for one single microflow at a time (instead of 
> all microflows
> for the mobile at once) should be allowed."
> 3.1.2 - I like to add a sentence to the  second paragraph of 
> section 3.1.2
> as follows
> Eventual protocol state modifications, needed for proper operation
> or maximizing utility of the protocol at the new network, are
> outside the scope of the context definition. The same applies to
> cases where the protocols at original network are not supported at
> the new network; matching equivalent protocols at different sides of
> a seam is outside the scope. [New: However, for cases where the
> functionality each protocol can be provided based on several mechnisms
> (example: MPLS and diffserv for QoS, or RTP/UDP/IP and TCP/IP 
> for header
> compression), states for all supported mechanisms needs to be 
> stored and
> transfered]. The network element, which stores the
> state for each protocol will not be determined here (left to
> protocol/ system implementers). However, the issue of buffering the
> state during (or until after) the handover might be addressed here.
> 
> -------------------------------------
> Rajeev suggest using the word feature instead of protocol, 
> what do people
> think? I agree.
> He is also suggesting to change the name subcontext to 
> context, to make
> context the smallest unit of transfer, instead of subcontext, do I
> understand this correctly? If yes, I do not agree. what do 
> people think?
> 
>