[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt
Hi,
On Mon, 17 Feb 2003, Margaret Wasserman wrote:
>
> 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
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