Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
RFC 4215

Note: This ballot was opened for revision 11 and is now closed.

(David Kessens) Yes

(Harald Alvestrand) No Objection

Comment (2004-04-14 for -)
No email
send info
Reviewed by John Loughney and Brian Carpenter, Gen-ART
Brian's comment on the status of this document:

I've looked at this a number of times within v6ops. I am a little
surprised that it is proposed for BCP; and when thinking about that,
consider the rather strange first sentence in the Scope section:

>    The scope of this Best Current Practices document is to analyze and 
>    solve the possible transition scenarios in the 3GPP defined GPRS 
>    network

Scenarios aren't things you *solve*; they are things you *describe*. I
would see no objection to this as an Informational, but I think it
(and its future companion documents from v6ops) are hardly BCPs. There
is surely no current practice on which to base the assertion that this
draft describes the Best.

Apart from that I think the document is very useful and ready to publish.

(Steven Bellovin) (was Discuss) No Objection

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2004-03-29)
No email
send info
In section 3.1, this statement seems odd:

That also makes 
    it possible to burden the transition effects in the network and 
    make the 3GPP UEs simpler. 

Perhaps they mean "lessen the transition effects"?

In section 3.2, this statement:

   If the 3GPP operator has 
    deployed IPv6 in its backbone, but the upstream ISP does not 
    provide IPv6 connectivity to the Internet, the encapsulating node 
    can be the edge router. 

left me wondering about the topology. There are cases where
I think they would mean what is typically called a border router,
and there may also be cases where they mean the upstream
ISP's edge router.  Would "If the 3GPP operator has deployed IPv6
in its backbone but the upstream ISP has not, the encapsulating
node may be the router handing the traffic off to the upstream
ISP." be any clearer?

Section 3.5 seems to imply that v4 UEs and v6 UEs would never
trade traffic directly; there are no applications in which they
are not talking through an app server.  If this is correct, it
might be useful to make that explicit.

For this text:

Active IETF work on DNS discovery mechanisms is 
    ongoing and might result in other mechanisms becoming available 
    over time. The DNS server addresses can also be received over the 
    air (using SMS), or typed in manually in the UE. 
A pointer to which work they're talking about in the IETF would
be valuable; if the SMS message is a 3gpp-defined protocol,
a pointer would also be valuable.  If it's a text message which
is then typed/pasted in, then no pointer would be required.

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-05-26)
No email
send info
The new text in the Security Considerations addresses my comment, so I've cleared my discuss.

(Russ Housley) (was Discuss) No Objection

(Allison Mankin) (was Discuss, Abstain) No Objection

Comment (2004-11-23)
No email
send info
Gonzalo Camarillo worked with me to revise the discussion of the issues for SIP - the revision
indicates need for rapid work in SIPPING, but points to directions that make sense both for
SIP people and v6ops people.  (The new text was reviewed by v6ops - did not have a broad
SIPPING working group review yet, but did have review by a number of SIP expert readers besides

(Thomas Narten) No Objection

Comment (2004-04-15 for -)
No email
send info
>     plane mechanism). Same kind of mechanism is also available for 

s/Same/The same/

(Jon Peterson) No Objection

Comment (2004-04-02 for -)
No email
send info
The use of SIP ALGs has security implications - namely, it precludes certain security mechanisms (namely S/MIME) described in RFC3261 which mightprotect the integrity or confidentiality of SDP, or even SIP headers in some instances. While this document does suggest that more work needs to be done in the SIPpish WGs to address the SIP 6-to-4 problem, it describes no other solution than the use of SIP ALGs. Accordingly, a mention of the effects of ALGs on SIP security in the Security Considerations is probably warranted.

(Bert Wijnen) No Objection

Comment (2004-04-02 for -)
No email
send info
sect 1.1 says:
  The scope of this Best Current Practices document

Is that appropriate text to state in the doc itself?
I thought BCP is an external label only?

(Alex Zinin) No Objection

Comment (2004-07-06 for -)
No email
send info
Draft: draft-ietf-v6ops-3gpp-analysis-10.txt
Reviewer: Brian Carpenter
Date: 5 July 2004

The document is still very useful and still ready to publish.

I fully support the change to Informational.

(Margaret Cullen) (was No Objection, Recuse) Recuse