3gpp-analysis-05: editorial issues

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I've looked into 3gpp-analysis-05; I'll be sending some comments in 
separate mails.

editorial
---------

    OTA         Over The Air 

==> s/The/the/?
==> one should probably expand this a bit, because a reader not intimate
with 3GPP doesn't know what OTA refers to ("configuration protocol named
OTA?", "interface named OTA?", "generic reference to something done over the
air?")

 1.3 Terminology

==> as SHOULD/MUST use was added, in section 2.4, one should also add the
terminology blurb on what those mean and refer to RFC2026.

    This chapter briefly introduces some transition mechanisms
    specified by the IETF. The applicability of different transition
    mechanisms to 3GPP networks is discussed in chapters 3 and 4. DNS
    recommendations related to IPv4/IPv6 transition are briefly
    summarized in section 2.4.

    The IPv4/IPv6 transition methods can be divided to:

       - dual IPv4/IPv6 stack
       - tunneling
       - protocol translators

==> consider rewording to something like? :

    This chapter briefly introduces some transition mechanisms and guidelines
    specified by the IETF. The applicability of different transition
    mechanisms to 3GPP networks is discussed in chapters 3 and 4.

    The IPv4/IPv6 transition methods and guidelines relevant to this
    document can be divided to:

       - dual IPv4/IPv6 stack
       - tunneling
       - protocol translators
       - DNS recommendations

(just trying to move the DNS stuff under the same format as the rest of
them..)

    The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider
    the 3GPP GPRS core network, dual stack implementation in the GGSN

==> spell out GGSN here, as used for the first time

    However, the UE may attach to a 3GPP network, in which the Serving
    GPRS Support Node (SGSN), the GGSN and the Home Location Register

==> s/GGSN/GGSN,/

    In initial IPv6 deployment, where a small number of IPv6 in IPv4

==> s/IPv6 in IPv4/IPv6-in-IPv4/ (or some other consistent style)

    tunneling of IPv4 in IPv6 will be required from the GGSN to 

==> s/tunneling of IPv4 in IPv6/IPv4-in-IPv6 tunneling/ ?

    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.

==> I'd recommend starting a new paragraph at "Therefore,"; it seems like a
conclusion to this section, and could stand on its own as separate as well.

    mail and web-browsing. These applications will, of course, be 
    supported in the IPv6 Internet of the future. However, the legacy

==> s/IPv6 Internet of the future/future IPv6 Internet/

    As control (or signaling) and user (or data) traffic are separated  
    in SIP, and thus, the IMS, the translation of the IMS traffic has
    to be done on two levels - Session Initiation Protocol (SIP)
    [RFC3261], and Session Description Protocol (SDP) [RFC2327]
    [RFC3266] on the one hand (Mm-interface), and on the actual user
    data traffic level on the other (Mb-interface).

==> reword "hand" ? ("interface") ?

    Internet. Here both the UEs and the IMS islands are IPv6-only.    
    However, the IPv6 islands are not native IPv6 connected. 

==> s/are not native IPv6 connected/connected natively with IPv6/ ?

    ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA or manual
    configuration can also be possible. IMS subscriber authentication

==> s/can also be/is also/

 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt
 8. Intellectual Property Statement
 9. Copyright

==> these sections could be after the Editor's contact information section,
but that isn't really set in stone.

    [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: 
    Multiprotocol Extensions for BGP-4, RFC 2283, February 1998.    

==> this ref is not used anymore so it can be removed.

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