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

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Feb 2003 12:04:56 -0500

Hi All,

This is a WG Last Call for comments on sending the 3GPP scenarios
document to the IESG for consideration as an Informational RFC:

Title:     Transition Scenarios for 3GPP Networks
Filename:  draft-ietf-v6ops-3gpp-cases-02.txt
Editor:    J. Soininen
Date:      January 2003

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt

Abstract

    This document describes different scenarios in Third Generation
    Partnership Project (3GPP) defined packet network, i.e. General
    Packet Radio Service (GPRS) that would need IP version 6 and IP
    version 4 transition. The focus of this document is on the scenarios
    where the User Equipment (UE) connects to nodes in other networks,
    e.g. in the Internet. GPRS network internal transition scenarios,
    i.e. between different GPRS elements in the network, are out of scope
    of this document.

    The purpose of the document is to list the scenarios for further
    discussion and study.

Since this is the first WG last call that we have had in the v6ops
WG, we would like to remind you of the process that we discussed for
WG last calls when we started this WG.

The WG Last Call is a final check that the WG has rough consensus
to advance the document to the IESG.  Advancing a document to the
IESG indicates that the WG believes that this document is both
technically sound and useful.  It also indicates that we believe
that the document meets all of the requirements for publication
as an RFC.

To pass WG last call, this document must be reviewed and actively
supported by a significant number of people, including experts in
all applicable areas, or it will not be sent to the IESG.

Silence does NOT indicate consent during this phase.

So, please review this document carefully, and send your feedback
to the list, indicating whether or not you believe that this
document is ready to go to the IESG.  Unless sufficient support
is demonstrated on the list, the document will not be send to
the IESG.

Thanks,
Margaret, Itojun and Bob
v6ops WG Chairs

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Feb 2003 22:22:13 -0500

To clarify, this last call will remain open through Sunday,
March 2nd, 2003.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 23:14:03 +0200 (EET)

Hi,

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt

I've re-read the document, and it seems excellent.

I have only two non-editorial issues (well, you could argue these are 
kinda editorial too :-):

   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.

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.

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

   This document will describe the transition scenarios in 3GPP packet

==> s/will describe/describes/

   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.

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

2. Scope of the document

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

   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.

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

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

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!

   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)

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

==> add an empty line between these

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

==> s/./:/

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

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

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

==> s/an/a/

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

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

   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?

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

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

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

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

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

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

-- 
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: Randy Bush <[email-masked]>
Date: Fri, 28 Feb 2003 07:56:33 +0800

> I've re-read the document

thank you!  there are two keys to ietf success, writing of good
documents and serious peer review.

randy

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Feb 2003 16:10:49 -0800

My colleagues (Sebastien Roy & Jim Paugh) from Sun & I wrote a draft
on dual stack implementations and turning IPv6 on by default on them.

http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-00.txt

We would like to offer it as a contribution to v6ops
and would like to receive feedback from the wg.

	- Alain.

Abstract

    The dual stack model is based on the assumption that applications can
    try communicating to destinations over IPv6 first and fall back to
    IPv4 if IPv6 doesn't work.  Before turning the dual stack on by
    default, we need to make sure that this assumption holds even in
    cases where IPv6 connectivity is not perfect.

    This document looks at scenarios in which things can go wrong if the
    IPv6 dual stack is enabled by default.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Feb 2003 13:32:53 -0500

>I've re-read the document, and it seems excellent.

Thanks, Pekka.

>    any security considerations.

I agree with both of these points.

Margaret