RE: 3gpp-analysis-05: editorial issues

[<juha.wiljakka@nokia.com>]

Hi, Pekka!

Some comments (JW) on the editorial issues:

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 18 September, 2003 11:41

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?")

 JW: My solution proposal: I just write "over the air" in the text and do not use 
that abbreviation at all. This abbreviation is not anyhow relevant from this
document point of view. Usual meaning for OTA is to send some configuration
information using SMS.

 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.

 JW: Another alternative is to write this text in 2.4 with lower case (question: 
Informational docs do not use capitalized keywords, but how is it in BCP docs?)
If that text will stay here in capital letters, I can add terminology part.

    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..)

 JW: Fine for me.

    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

 JW: Will do.

    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,/

 JW: ok.

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

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

 JW: ok.

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

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

 JW: ok.

    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.

 JW: Sounds rational.

    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/

 JW: ok.

    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") ?

 JW: Well, maybe writing interface changes the idea a little bit, how about:

    " ...the translation of the IMS traffic has
    to be done at two levels:  1) Session Initiation Protocol (SIP)
    [RFC3261], and Session Description Protocol (SDP) [RFC2327]
    [RFC3266] (Mm-interface), and 2) the user
    data traffic (Mb-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/ ?

 JW: yep.

    ([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/

 JW: ok.

 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.

 JW:  Looking at v6ops and other wg drafts, there seems not to be a
common practice.. Until you can show me a clear rule, I will keep the order
as it is now - and let RFC editor make the needed changes.  :-)

    [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.

 JW: True, will remove.

Thanks,
	-Juha-