Subject: RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP]

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 18:43:27 +0100

> > - we document a higher level solution and refer to 
 > SIP(PING) wg to make a generic solution
 > >
 > >     "This section presents higher level details of a 
 > solution based on
 > >     the use of a translator and SIP ALG. [3GPPtr] provides 
 > additional
 > >     information and presents a bit different solution 
 > proposal based on
 > >     SIP Edge Proxy and IP Address/Port Mapper. The authors 
 > recommend to
 > >     solve the general SIP/SDP IPv4/IPv6 transition problem 
 > in the IETF
 > >     SIP wg(s)."
 > 
 > Consider a slight rewording here.
 > 
 > s/"general SIP/SDP IPv4/IPv6 transition"/"SIP/SDP signalling"/

Makes little sense since the SIP WG already has SIP/SDP signalling
specs! I think it should stay since the SIP work will be on IPv6/v4
translation.

 > 
 > And add:
 > 
 >   NAT-PT header translation mechanism may be used in conjunction with
 >   the [3GPPtr] mechanism. NAT(P)T-PT will perform header translation,
 >   using the binding supplied by [3GPPtr].

Disagree as I explained in past emails.

 > 
 > >
 > > - because NAT-PT is the closest possible (=PS RFC) 
 > solution to be used in this "Interworking Unit" as a 
 > translator, we state:
 > >
 > >    " We call the combined network element on
 > >     the edge of the IPv6-only IMS an "Interworking Unit" in this
 > >     document. A SIP-specific translation mechanism, which 
 > could e.g.
 > >     re-use limited subsets of NAT-PT [RFC2766], needs to 
 > be specified.
 > >     The problems related to NAT-PT are discussed in appendix A. "
 > 
 > Replace
 > 
 >       A SIP-specific translation mechanism, which could e.g.
 >      re-use limited subsets of NAT-PT [RFC2766], needs to be 
 > specified.
 > 
 > with
 > 
 >      A SIP-specific mechanism to handle signalling traffic, 
 > that would
 >      work in conjunction with NAT-PT [RFC2766], needs to be 
 > specified.

Again disagree.

The analysis draft IMO is fine as is.

/Karim

---

From: <[email-masked]>
Date: Tue, 25 Nov 2003 15:57:14 +0200

Hello,
(chair hat on)
I believe NAT-PT is already standards track RFC. I'm at least not ready to deprecate it based on the information we have now. I believe the NAT-PT applicability work should give us a direction with the NAT-PT spec. Neutrally, we have three possibilities:

	1) Keep current NAT-PT specs and get it draft standard if possible
	2) Update the NAT-PT specs considerably and recycle it as PS
	3) Move it to historic

I'm not sure which way to go at this point. I hope the NAT-PT applicability work can help us on that.

Cheers,

Jonne.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Pekka Savola
> Sent: 19 November, 2003 14:35
> To: Jasminko Mulahusic
> Cc: [email-masked]
> Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT 
> Applicabilty
> fo r 3GPP]
> 
> 
> On Tue, 18 Nov 2003, Jasminko Mulahusic wrote:
> > > As you pointed out the 3gpp-analysis draft addresses these
> > > issues and I have no problems with that. It points to the
> > > work to be done in SIPPING and says that such a solution
> > > could reuse parts of NAT-PT.
> > 
> > i have a question to the wg chairs and/or ad:s:
> > 
> > do you plan to deprecate nat-pt before the work 
> (ims-translator) has 
> > been finished in the sipping wg?
> 
> I believe it's too early to plan either deprecating or embracing
> NAT-PT.
> 
> HTH..
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>