Subject: 3gpp-analysis-04: Editorial issues

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jul 2003 15:54:46 +0300 (EEST)

Hi,

I've looked a bit into 3GPP Analysis document, and I'll be sending out 
issues I found out separated in different messages, a day or so apart.  

<chair hat on>
Whether they should be filed in an issue tracker (like
Roundup), a web page, etc. is up to the 3GPP design team, and especially 
the editor.
</chair hat off>

editorial
---------

    This document analyzes the transition scenarios in 3GPP packet
    data networks that might come up in the deployment phase of IPv6.
    The transition scenarios are documented in [3GPP-SCEN] and this
    document will further analyze them. The scenarios are divided into
    two categories: GPRS scenarios and IMS scenarios.

==> first use of "IMS", so spell it out.

 1.1 Scope of this Document
                                                                                                       
    The scope of this informational document is to analyze and solve
    the possible transition scenarios in the 3GPP defined GPRS network
 
==> note that the category will be BCP, so perhaps it's better to 
substitute s/informational/Best Current Practices/, or even "informational 
Best Current Practices/, as you prefer considering the audience (i.e. 
whether they're aware of what BCP really means)

   where a UE connects to, or is contacted from the Internet, or

==> s/from/from,/, s/Internet,/Internet/ ?

    of the SIP based IP Multimedia Core Network Subsystem (IMS). This
    document is not focused on radio interface issues; both 3GPP Second
 
==> s/is not focused/does not focus/ ?

 1.2 Abbreviations
                                                                                                       
==> I note that SGSN, HLR and DNS (at least) are not listed.  At least the 
first two should be added.

 1.3 Terminology
                                                                                                       
    Dual Stack UE  Dual Stack UE is a 3GPP mobile handset having dual
                   stack implemented. It is capable of activating
                   both IPv4 and IPv6 PDP contexts. Dual stack UE may
                   be capable of tunneling.
  
==> there is a slight circular definition here, "DS UE is something with 
dual stack".  Maybe some rewording would be needed?  Not a major issue.

    This chapter briefly introduces some transition mechanisms
    specified by the IETF. Applicability of different transition
    mechanisms to 3GPP networks is discussed in chapters 3 and 4.
                                                                                                       
==> s/Applicability/The applicability/ ?

    The following scenarios described by [3GPP-SCEN] are analyzed here.
    In all of the scenarios, the UE is part of a network where there is
    at least one router of the same IP version, i.e. GGSN, and it is
    connecting to a node in a different network.

==> s/it is/the UE is/

    In this scenario, the dual stack UE is capable of communicating
    with both IPv4 and IPv6 nodes. It is recommended to activate an
    IPv6 PDP context when communicating with an IPv6 peer node and an
 
==> spell out PDP.

    However, the UE may attach to a 3GPP network, in which the SGSN
    (Serving GPRS Support Node), the GGSN and the HLR (Home Location
    Register) support IPv4 PDP contexts by default,

==> change the order of term and abbreviation:
Serving GPRPS Support Node (SGSN), Home Location Register (HLR) 

   One deployment scenario example is using laptop computer and a UMTS
    UE as a modem.

==> s/laptop/a laptop/
==> I don't think UE is a modulator/demodulator  and calling it a modem 
may be a bit confusing ?

    When analyzing a dual stack UE behavior, an application running on
    a UE can identify whether the endpoint required is an IPv4 or IPv6
    capable node by examining the address to discover what address
    family category it falls into. 

==> reword "application": typically, this function is performed at a lower 
layer (operating system, IP stack), and the use of applciation gives IMHO 
the wrong picture that the applications themselves would have to somehow 
distinguish the end-point address family.

==> s/category//

               Since the UE is capable of native communication
    with both protocols, one of the main concerns of an operator is
    correct address space and routing management.

==> s/correct/the correct/ ?

    Keeping the Internet name space unfragmented is another important
    issue for both IPv4 and IPv6. It means that any record in the
    public Internet should be available unmodified to any nodes, IPv4
    or IPv6, regardless of the transport being used.

==> s/any record/any DNS record/ (maybe even spell out DNS)

   served by at least an IPv4 reachable DNS server. This
 
==> s/an/one/

    be used. In a 3GPP network, one IPv6 island could contain the GGSN
    while another island contains the operator's IPv6 application
    servers. However, manually configured tunnels can be an
 
==> s/contains/could contain/

   "6to4" nodes use special IPv6 addresses with a "6to4" prefix
    containing the IPv4 address of the corresponding "IPv6 in IPv4"
    tunnel endpoint ("6to4" router) which performs encapsulation /
    decapsulation. When connecting two nodes with "6to4" addresses, the
 
==> s/"6to4"/6to4/ (could explain it the first time 6to4 is stated if 
necessary)

 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
                                                                                                       
    3GPP networks are expected to support both IPv4 and IPv6 for a long
    time, on the UE-GGSN link and between the GGSN and external
    networks. For this scenario it is useful to split the end-to-end
    IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-
    v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and
    IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4
    link (PDP context) to connect to the GGSN without the need to
    communicate over an IPv6 network. Regarding the GGSN-to-v4NODE
    communication, typically the transport network between the GGSN and
    external networks will support only IPv4 in the early stages and
    migrate to dual stack, since these networks are already deployed.
    Therefore it is not envisaged that tunneling of IPv4 in IPv6 will
    be required from the GGSN to external IPv4 networks either. In the
    longer run, 3GPP operators may need to phase out IPv4 UEs and the
    IPv4 transport network. This would leave only IPv6 UEs. Therefore,
    overall, the transition scenario involving an IPv4 UE communicating
    with an IPv4 peer through an IPv6 network is not considered very
    likely in 3GPP networks.

==> the paragraph is too long and should be reorganized slightly so that 
it can be split to two or more paragraphs.

    However, since it is difficult to anticipate all possible
    applications, there is a need for translators that can translate
 
==> s/all/all the/

       2. Additional forwarding delays due to further processing, when
         compared to normal IP forwarding.
                                                                                                       
       3. Problems with source address selection due to the inclusion of
         a DNS ALG on the same node [NATPT-DNS].

==> start these with "There are ..."

    Furthermore, high reliability is expected for 3GPP networks.
    Consequently, a single point of failure on the GGSN external
    interface, would raise concerns on the overall network reliability.

==> s/interface,/interface/

    The legacy IPv4 nodes are mostly nodes that support the
    applications that are popular today in the IPv4 Internet: mostly e-
    mail, and web-browsing.

==> s/mail,/mail/

    applications. As these application are designed for IPv6, and to
    use the advantages of newer platforms,

==> s/application/applications/

   Taking the above into account, the traffic to and from the legacy
    IPv4 UE is restricted to a few applications. These applications
    already today mostly rely on proxies or local servers to
    communicate between private address space networks and the
    Internet.

==> remove "today" from "already today mostly rely" (too complex otherwise 
:-)

 4. IMS Transition Scenarios
                                                                                                       
    As the IMS is exclusively IPv6, the number of possible transition
    scenarios is reduced dramatically. In the following, the possible
    transition scenarios are listed.

==> reword: (or something to the effect).

    As the IMS is exclusively IPv6, the number of possible transition
    scenarios is reduced dramatically and are listed below.
                                         
    The recommended approach (as documented in [DNStrans]) currently is
    that every recursive DNS server should be either IPv4-only or dual

==> s/currently is/is currently/ ?

    stack and every single DNS zone should be served by at least an
    IPv4 reachable DNS server. The recommendation rules out IPv6-only
 
==> s/an/one/

    There will probably be few legacy IPv4 nodes in the Internet that
    will communicate with the IMS UEs. It is assumed that the solution
    described here is used for limited cases, in which communications
    with a small number of legacy IPv4 SIP equipment are needed.

==> did you really mean "few" (like, "hardly any"), or "a few" ?

   Figure 1 shows a possible configuration scenario where the SIP ALG
    is separate to the CSCFs.

==> s/separate to/separated from/ (or something else, I'm not sure what 
the text is intended to mean) ?

    The authors notify that work is being done on analyzing 3GPP
    IPv4/IPv6 translators related to IMS scenario 1, and a personal
    draft is expected shortly.

==> note that the IMS scenario 1 is really *this* scenario, should this be 
reworded?

 7. Copyright
                                                                                                       
==> please also add the IPR section

 8. References
 8.1 Normative

    [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
    Protocol, RFC 2327, April 1998.
                                                                                                       
   [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
    in Session Description Protocol (SDP), June 2002.

==> are these meant as normative references?  No harm in having them, I 
guess, but I guess they're more like informational in nature..

    [ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP
    Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work
    in progress.

==> replace by Mikael Lind's document (I think)
                                                                                                       
    [ISP-analysis] Mickles, C. (Editor): "Transition  Analysis for ISP
    Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt,
    work in progress.

==> this should be removed for now (I think)                                                                                                       

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: <[email-masked]>
Date: Tue, 22 Jul 2003 00:19:27 +0300

Hi, Pekka! 

Many thanks for your comments, some comments below
marked with JW.

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 21 July, 2003 15:55

<chair hat on>

JW: Using the tracker is a good idea, I consider that after my holidays.

editorial
---------

JW: Yep.

 

JW: That's correct, I will use BCP.

JW: Hmm, good question is, whether any commas are needed in that 
sentence at all - can any native speaker confirm?

JW: ok

 1.2 Abbreviations

JW: Yes, the abbreviations HLR and SGSN (mentioned only once) are missing,
and so is DNS also. I will add all three, and check the doc through for
any other missing abbreviations.

 1.3 Terminology

JW: Yep, dual stack has dual stack... I'll make some rewording, such as
the UE has both IPv4 and IPv6 stacks.

JW: That can be correct...

==> s/it is/the UE is/

JW: got it.

==> spell out PDP.

JW: PDP context needs to be spelled out. I will do it already in section 2.1 or even in 1.3.

JW: You mean alphabetical order? Anyway, I would like to list the
network elements in a more logical order, according to their functionalities.

==> s/laptop/a laptop/

JW: 1. ok, 2. That is the common language used, e.g. GPRS phones are shown
as modems and AT commands are used for contorl. Another term we could 
use is dial-up (emulation).

JW: Hmm, some applications can participate in that decision making? 
But what kind of rewording would you suggest?

==> s/category//

JW: got it.

JW: ok

JW: DNS record sounds good.

==> s/an/one/

JW: yup.

JW: I would put "can contain" to both.

JW: Yep, actually those quotation marks are not needed, I will spell out 6to4
when it pops up for the first time.

JW:  The paragraph is not that long, but because it is the
whole section, I'll do it.

==> s/all/all the/

JW: ok

JW: fine for me. However, parts of that text may be removed once
we can refer to NAT-PT appl- statement doc.

JW: ok

==> s/mail,/mail/

JW: ok

JW: good point.

JW: OK, this is not an EU directive document, will do something to it.

JW: I try to do something.

JW: I'd keep the order as it is.

==> s/an/one/

JW: got it

JW: Our intention was to say, that the number of legacy IPv4 SIP
nodes that need to communicate with IMS UEs probably is (really) small, so
few is correct.

JW: At least "separated from" sounds good. I don't actually know whether 
"separate to" is incorrect..?

JW: I will reword that anyway and tell about Karim's draft.

 7. Copyright

JW: Yep, can add that, even though we don't have any IPRs on this doc.
Is it a needed section in every draft / RFC?

 8. References
 8.1 Normative

JW: It was easy putting them as normative references, because they are
RFCs. As you commented. those RFCs contain relevant background information for
IMS scen 1 / SIP functionality related to that. But anyway, we are not considering
SIP parts that deeply.

==> replace by Mikael Lind's document (I think)
JW: Yep, needs to have the latest doc.

==> this should be removed for now (I think)                                                                                                       
JW:  Yes, at least until Lind's team manages to puglish their -00 analysis.

I will start my 3,5 week holiday on Tuesday afternoon and will be back on week
34. I will produce a new version of our document that week. Hopefully other
members in the design team can reply to the comments sent on the
mailing list.

Cheers,
	-Juha-