Subject: 3gpp-analysis-05: editorial issues

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Sep 2003 11:41:04 +0300 (EEST)

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

---

From: <[email-masked]>
Date: Mon, 22 Sep 2003 17:00:07 +0300

Hi again!

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 22 September, 2003 14:31

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

BCP could have upper caps (as well as specific kinds of informational 
documents).  The problem here is that you're quoting directly what it says 
in the DNStrans document.  So, changing it in this document might not be 
appropriate.

So, I think there may be three ways around this issue:
 - define RFC2026 keywords,
 - just convert the uppercases to lowercases, or
 - in section 2.4, state it more clearly that the recommendations have 
been copied verbatim from DNStrans (which might imply that DNStrans is the 
authorative source here, not the uppercases in this document)

JW: Hmm, I might select the third alternative...

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

There is no strict rule of this, but ID-nits lists these in that order 
(and in most cases, that's what seems to make the most sense to me, 
because those are sections that will be either removed at publication or 
stay the same across all I-Ds):

http://www.ietf.org/ID-nits.html

 JW: Fine, I will use ID-nits as the reference and make the section order 
based on it.

BR,
	-Juha W.-