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

[<juha.wiljakka@nokia.com>]

Pekka,

thank you very much for your review and the comments! Jonne S. may have
some additional comments, but I start giving comments below (marked JW):

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 27 February, 2003 23:14

   However, the IPv4 addresses might be a scarce resource for the mobile
   operator or an ISP. In that case, it might not be possible for the UE
   to have a globally unique IPv4 address allocated all the time. Hence,
   the UE should either activate the IPv4 PDP Context only when needed,
   or be allocated an IPv4 address from a private address space.

==> should "should" be really "could"?  This document is not meant to give
solution(s), or advacate IPv4 NAT.

 JW: Yep, we do not want to advocat v4 NAT, that's for sure. "Could" (or
even "can") makes sense to me.

5. Security Considerations

   This document does not generate any additional security
   considerations.

==> as many, many drafts will try to pass with security considerations
like these, it might be best to be pre-emptive, and explain that there
really *are* no additional security considerations here (try to answer the
"why"), like:

   This document describes possible transition scenarios for 3GPP
   networks for future study.  Solutions and mechanism are explored in 
   other documents: the description of the 3GPP network does not have
   any security considerations.

 JW: Thanks for your suggestion! This text is ok at least for me. 

Below, a few editorial nits.

Internet Draft                                            J. Soininen,
Document: draft-ietf-v6ops-3gpp-cases-02.txt                    Editor

==> I'd replace the two lines in the right with, like, "J. Soininen (ed.)"

 JW: Hmm, why not. I can do the same for the 3GPP analysis doc too
(revision -02 with minor changes shall be published soon).

   This document will describe the transition scenarios in 3GPP packet

==> s/will describe/describes/

 JW: Agreed.

   The main purpose of this document is to identify, and document those
   scenarios for further discussion, and for study in the v6ops working
   group.

==> minor rewording could clarify this: this use of multiple ", and" make 
it a bit difficult to connect the sentences.  For example:

   The main purpose of this document is to identify and document those
   scenarios for further discussion and study in the v6ops working
   group.

 JW: Sounds ok.

   This document gives neither an overview, nor an explanation of 3GPP
   or the 3GPP packet data network, GPRS. A good overview of the 3GPP
   specified GPRS can be found from [1]. The GPRS architecture
   specification is defined in [2].

==> Is this entirely accurate?  Section 3 includes a very brief
description (of the relevant part of the architecture), including the
title "GPRS architecture basics".

 JW: Ok... this text was written when there was no environment description
in the document (yet). This kind of text might work better:
"This document gives a very brief overview on the 3GPP packet data network, GPRS. 
A good overview of the 3GPP specified GPRS can be found from [1].  The 
GPRS architecture specification is defined in [2]."

2. Scope of the document

==> s/d/D/, similar in certain other titles.

 JW: Yep, this is the US style. :-) I have to do the same for the 3GPP analysis doc...

   scenarios with and without the usage of the SIP based IP Multimedia 
   Core Network Subsystem (IMS).   

==> the use of "SIP" for the first time, without reference or spelling out 
the acronym.  I'd suggest at least the latter.

 JW: ok.

==> "SIP based" or "SIP-based" ? (I have no idea...), same with "SIP 
capable" later on.

   The scope of this document does not include scenarios inside the GPRS
   network, i.e. on the different interfaces of the GPRS network.

 JW: I would use hyphen, but maybe some native speaker can enlighten us...

==> observation: the term "interfaces" could be misleading to those who 
nowadays think of interfaces as in "network adapters/interfaces", not the 
interfaces defined by GPRS architecture.  Not sure if it's worth changing.

 JW: We have to check this... No opinion yet.

3. Brief description of the 3GPP network environment

==> s/Brief description of the // (and the upper-casigns) -- I agree that 
it is *very* brief, but the title should be shorter!

 JW: Maybe... Short subsection can not have too long title. Just using e.g.
"3GPP network environment" and just tell in the text that the description is 
a short one?

   There is a dedicated link between the UE, and the GGSN called the
   Packet Data Protocol (PDP) Context. This link is created through the

,

   or to different GGSNs. The PDP Context can be either of the same, or
   different types. 

and:

   possibility to have simultaneous IPv4, and IPv6 PDP Contexts open.

==> s/,// (the lists are so short a comma looks only confusing)

 JW: Yep, we'll check those.

   A simplified overview of the IMS is depicted in figure 2.
             +-------------+  +-------------------------------------+

==> add an empty line between these

 JW: Agreed.

   The SIP proxies, servers, and registrars shown in Figure 2 are as
   follows.

==> s/./:/

 JW: OK.

     - I-CSCF (Interrogating-CSCF) is the contact point within an
        operatorÆs

==> s/Æ/'/g (wrong charset/typo?) -- in a few other places too

 JW: Clearly a non-ASCII char, have to check it.

   PDP Type IPv6. This means that an 3GPP IP Multimedia terminal uses

==> s/an/a/

 JW: Yep.

    This, of course, does not prevent the usage of other unrelated
   services (e.g. corporate access) on IPv4.

==> s/ This/This/ (extra space)

 JW: Got it.

   Thus, in cases where the UE is dual stack capable, and in the network
   there is a GGSN (or separate GGSNs) that supports both connection to
   IPv4 and IPv6 networks, it is possible to connect to both at the same
   time. Figure 3 depicts this scenario.

==> "both connection to [...] networks" sounds strange; a singular/plural 
mistake, need to reword, or something?

JW: We consider small rewording, that is needed.

   In this scenario an IPv6 UE connects to an IPv4 node in the IPv4
   Internet.

==> s/scenario/scenario,/ (not really necessary..)

 JW: I would also use the comma here.

    | IPv4 |    | GPRS Core | |      |     |   |    |      |
    +------+    +-----------+ +------+     +---+    +------+
                       Figure 7: IPv4 node communicating with IPv6 node

==> aliging the figure text with the figures would be nice, but probably 
something best left to the rfc editor process.

 JW: Ok, we see if something can be done.

   The authors would like to thank Basavaraj Patil, Tuomo SipilD, Fred

==> s/D/a/ :-)

 JW: Yup, let's make him Mr. Sipila, not Sipilä. :-)

Informative references

    [1] Wasserman, M., "Recommendations for IPv6 in Third Generation
    Partnership Project (3GPP) Standards", September 2002, RFC3314.

Normative References

==> Normative References are should be listed first, by 
http://www.rfc-editor.org/policy.html

 JW: Yes, this small fix will be done.

Thanks once again!

	-Juha-