RE: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1

["Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>]

 > 3GPP Analysis has -09 received some comments from the IESG 
 > and I start the mailing list discussion with the comments 
 > considering IMS Scenario 1. There are two comments from 
 > Allison and Jon:
 > 
 > =====================================
 > (1)
 > Commented by:Mankin, Allison  
 > Comment:My understanding is that this analysis is for 3GPP, 
 > rather than reflecting an existing
 > fully-formed 3GPP analysis, so that we influence what 3GPP thinks.
 > 
 > 3GPP desperately needs to grapple with a robust model for 
 > IMS systems when
 > they communication with IPv4 only hosts.  (They also needs a 
 > model for those
 > systems to deal with expressing a preference for IPv6 usage 
 > should vendors
 > provide IPv4 IMS capability). 
 > 
 > The document wisely says that the SIP WG can do a good job 
 > of providing this
 > model, but then unwisely both describes a model and references a more
 > detailed draft.  Both models are not good cross-area 
 > products, since they
 > design a SIP ALG and a NAT-PT structure for SIP's SDP.
 > 
 > Since SIP terminates the connection endpoints at proxies, it 
 > can change
 > the Internet protocol at those points, therefore, it would 
 > be possible to
 > provide a reverse NAT for IPv4 addresses and route them to 
 > translating
 > proxies at a boundary point where the IMS system had dual stack
 > capability (this is just one idea).  The media situation is 
 > harder, but
 > the review of this needs to consider capabilities such as terminating
 > the media at a mixer and changing the Internet protocol there (SDP
 > rewriting is not OK), using only DNS names by policy, so both ends
 > of the media user could use a generic transition mechanism not
 > specialized into 3GPP.

I assume that the more detailed reference draft mentioned above is
draft-elmalki-sipping-3gpp-translator-00 [3gpptr].
This draft does not design a SIP ALG and NAT-PT but avoids SDP editing
since this had been pointed out by some SIP experts already. So the purpose 
was exactly to address a number of the comments you bring up and continue
working on a solution in SIPPING. Regarding the 3gpp analysis draft I think
it could state the issues more clearly (esp. SDP editing consequences) but
I am afraid that if it doesn't provide any guidance on SIP IMS it won't be
as helpful to 3gpp.

/Karim