Subject: [Mip6] Comments on draft-chen-mip6-gprs-02.txt

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 2 Nov 2004 11:54:18 -0800 (PST)

I understand from the authors that this document is targeting for individual
RFC submission. I only have some editorial comments. 

minor nits:
In my copy, I was getting blank pages off and on. Please check if it still 
happens in the latest version.

General comment: Since this document describes issues with GPRS services
and IMS services, it might be better to organize the issues under each of
those services; for example:

3.1 GPRS Services
   3.1.1 Mobile Terminal defined packet filtering
   3.1.2 Network Service Defined packet filtering
   
3.2  IMS Services
    :
    :
    
 In section 3.1 "The TFT only applies...with it" is not very clear, please
 re-word the senstence.

 4.1.1.2  "As a result, two possible decisions can be made by the GGSN... to B"
 
 Is this indicating possible solutions or today GGSN is capable of handling the
 Route optimization this way?

 section 4.2.1.2
 
 "If tunnelled packets ....PDP Context to B" - may be this part of text is
 redundant since we are describing the issues.
 
 section 5. 
 At the end of the page, it made reference to [14] which is non-existent.
 
 As discussed before on the private list that "home agent tunneling" is due
 to the issue of GGSN's handling of IP-in-IP tunnel - it is not a MIP6 specific
 issue - it should be mentioned in  the document to clarify that.

 -Samita

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "CHEN, Xiaobao" <[email-masked]>
Date: Wed, 3 Nov 2004 11:14:53 -0000

Samita,
 
Many thanks for the  comments. My response is in line.

Regards,
 
Xiaobao

	-----Original Message----- 
	From: [email-masked] on behalf of Samita Chakrabarti 
	Sent: Tue 02/11/2004 19:54 
	To: [email-masked] 
	Cc: [email-masked] 
	Subject: [Mip6] Comments on draft-chen-mip6-gprs-02.txt

	I understand from the authors that this document is targeting for
individual
	RFC submission. I only have some editorial comments.
	
	minor nits:
	In my copy, I was getting blank pages off and on. Please check if it
still
	happens in the latest version.

	[xc] Yes, will check it again and make sure it won't happen in the
next revised version.

	General comment: Since this document describes issues with GPRS
services
	and IMS services, it might be better to organize the issues under
each of
	those services; for example:
	
	3.1 GPRS Services
	  
	3.2  IMS Services
	    :
	    :

	[xc] Good point. This is certainly one of the ways for organising the
structure for the problems descriptions  that we considered before. After
comparing this with the current structure of the descriptions, i.e. the GPRS
node being either the correspondent  node or the mobile node,  we found it
perhaps easier and clearer  for some readers who may not be very familiar
with the 3GPP networks to understand the descriptions by describing  the
problems in a style close to the way that Mobile IP works.

	But I will discuss this again with other co-authors to see what is
the best way for describing the problems clearly.

	 In section 3.1 "The TFT only applies...with it" is not very clear,
please
	 re-word the senstence.

	[xc] Yes, will provide clarifications in the next revised version. 
	
	 4.1.1.2  "As a result, two possible decisions can be made by the
GGSN... to B"
	
	 Is this indicating possible solutions or today GGSN is capable of
handling the
	 Route optimization this way?

	[xc] In current 3GPP standard specifications, the GGSN  allows one
PDP without TFT at  maximum. And it is also possible that all PDP contexts
have TFT's.  The sentense you mentiond  in the draft indicates that the GGSN,
when having a PDP without the TFT, may choose to use this PDP to deliver  the
IP datagrams that fail to match any TFT's.  But the problem with this is that
the IP datagrams will not receive the correct QoS. And this won't work for
the cases when all PDP's have TFT'.

	This sentense does not intend to indicate any solution but further
describe problems still exist even  if one TFT-free PDP  is  possible.
	
	 section 4.2.1.2
	
	 "If tunnelled packets ....PDP Context to B" - may be this part of
text is
	 redundant since we are describing the issues.

	[xc] We will consider to delete the sentence. 

	 section 5.
	 At the end of the page, it made reference to [14] which is
non-existent.

	[xc] Yes, it will be corrected.

	 As discussed before on the private list that "home agent tunneling"
is due
	 to the issue of GGSN's handling of IP-in-IP tunnel - it is not a
MIP6 specific
	 issue - it should be mentioned in  the document to clarify that.

	[xc] Agreed.

	 -Samita

********************************************************************
Important.
Confidentiality: This communication is intended for the above-named
person and may be confidential and/or legally privileged.
Any opinions expressed in this communication are not necessarily 
those of the company. If it has come to you in error you must 
take no action based on it, nor must you copy or show it to anyone; 
please delete/destroy and inform the sender immediately.

Monitoring/Viruses.
Orange may monitor all incoming and outgoing emails in line with 
current legislation.  Although we have taken steps to ensure that 
this email and attachments are free from any virus, we advise that 
in keeping with good computing practice the recipient should ensure 
they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered 
in England No 2178917, with its address at St James Court, 
Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ.
********************************************************************