[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt



Francis,

> -----Original Message-----
> From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Sunday, March 09, 2003 6:51 AM
> To: Margaret Wasserman
> Cc: v6ops@ops.ietf.org
> Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt 
> 
> 
> A short & late review of draft-ietf-v6ops-3gpp-cases-02.txt:
> I have no concern, only a comment and some editorial remarks.
> 
> The comment:
>  IMHO the PDP PPP context finishing at the ISP NAS will be the
>  more common GPRS scenario because regulatory bodies won't accept
>  the mobile operator and the ISP will be the same entity, i.e.,
>  customers should get the choice. This scenario is explicitely
>  put out of the scope of the document in 4.1.

I do not completely agree with your statement - especially, as having a different ISP than the mobile operator doesn't have anything to do with PDP Type PPP. It can be achieved with PDP Type IP as well. Anyways, I wonder if this has to be discussed here.

Back a question: We deliberately put the case where there is PPP connection directly from the mobile to the ISP as an out of scope case as we would tendo to believe that it is part of a more general case (i.e. the ISP cases). Are you happy with this decision, or are you objecting to that? (You seemed to be happy about it as we discussed it the last time.)

> 
> Typos & co:
> 
>  3.1 GPRS architecture basics 
> 
>    It also serves as the default router for the UE. 
> 
> => It can also serve as the default router for the UE. 
> 
>  3.2
> 
>      - I-CSCF (Interrogating-CSCF) is the contact point within an 
>         operatorĘs network for all connections destined to a 
> subscriber 
>         of that network operator, or a roaming subscriber currently 
>         located within that network operatorĘs service area. 
> 
> => ' characters were replaced by Ę (AE is latin 15).

Shoot! I thought I got all of those out, but it seems that the MS Word -> text conversion does put some strange characters in the text file. Thanx.

> 
>  4.1 Figure 3
> 
>    +-------------+ 
>     |             | 
>     |     UE      |                                    +------+ 
> 
> =>
> 
>     +-------------+ 
>     |             | 
>     |     UE      |                                    +------+ 
> 

Cheers.

>  4.2 Figure 9
> 
>     +------+     +------+     +-----+        +-----+ 
>     |      |     |      |     |     |        |     | 
>     |  UE  |-...-|      |-----| IMS |--------|     | 
>     |      |     | GGSN |     |     |+------+| IMS | 
>     | IPv6 |     |      |     |     || IPv4 ||     | 
>     +------+     +------+     +-----++------++-----+ 
>                        Figure 9: Two IMS islands connected over IPv4 
> 
> =>
> 
>     +------+     +------+     +-----+          +-----+ 
>     |      |     |      |     |     |          |     | 
>     |  UE  |-...-|      |-----| IMS |----------|     | 
>     |      |     | GGSN |     |     | +------+ | IMS | 
>     | IPv6 |     |      |     |     | | IPv4 | |     | 
>     +------+     +------+     +-----+ +------+ +-----+ 
>                        Figure 9: Two IMS islands connected over IPv4 

Francis, I only found that you changed the picture where there is the IPv4 "cloud" (=block). Was this for estetical reasons, or do the lines get wrapped in your screen?

> 
>  Acknowledgements 
> 
>    The authors would like to thank Basavaraj Patil, Tuomo 
> Sipil", Fred 
>                                                                ^
>    not an ASCII character
> 

Cheers.

> Informative references 
> 
>     Partnership Project (3GPP) Standards", September 2002, RFC3314.   
> 
> =>
> 
>     Partnership Project (3GPP) Standards", RFC3314, September 2002.   

Yep.

> 
> Thanks
> 
> Francis.Dupont@enst-bretagne.fr

Thank you,

Jonne.