Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
RFC 4215
Yes
No Objection
Recuse
Note: This ballot was opened for revision 11 and is now closed.
(David Kessens; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
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.
(Allison Mankin; former steering group member) (was Discuss, Abstain) No Objection
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 Gonzalo.
(Bert Wijnen; former steering group member) No Objection
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?
(Bill Fenner; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
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.
(Jon Peterson; former steering group member) No Objection
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.
(Russ Housley; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) (was Discuss) No Objection
The new text in the Security Considerations addresses my comment, so I've cleared my discuss.
(Steven Bellovin; former steering group member) (was Discuss) No Objection
(Ted Hardie; former steering group member) (was Discuss) No Objection
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.
(Thomas Narten; former steering group member) No Objection
> plane mechanism). Same kind of mechanism is also available for s/Same/The same/
(Margaret Cullen; former steering group member) (was No Objection, Recuse) Recuse