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

[Pekka Savola <pekkas@netcore.fi>]

Feedback is sought from the WG -- see below..

On Tue, 20 Apr 2004 juha.wiljakka@nokia.com wrote:
[...]
> I fully agree that we need a referral with a deadline for the
> SIP/SDP community, and we could use stronger wording than we have in
> -09 (would a good deadline be by the end of this year?). It is clear
> that we leave the closer details of the solution to be specified by
> the SIPpish wgs - specifying new mechanisms is out of the scope of
> this document. The current text says:
> 
>    "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)."
> 
> Removal of [3GPPtr] informative reference is needed?
> 
> I understand that rewriting SDP is one of your concerns. But would
> it be acceptable in cases when a solution is needed, and there is no
> other way around to solve the problem? 

Clarification: do you mean, "no other way around to solve the problem 
_at the moment_"?

Note that such interop is not required when you communicate between
3GPP boxes as no translation is needed, just externals -- this might
not be the number one critical problem (not sure), so if we were able 
to find (or even publish) a solution before the year's end (for 
example), it might be good enough.

> We could state in the draft
> that alternative mechanisms will be developed in the future to solve
> the problem in some other way than rewriting the SDP, and when those
> mechanisms will be available, SDP rewriting should not be applied
> any more. And write text on the problems with rewriting SDP.
>
> Anyway, I wouldn't like to remove all details in section 4.1,
> because that would make our document less useful.
>
> Comments on the mailing list are more than welcome!

(co-chair hat on)
 
My understanding of Allison's concern was that the document goes on
too much depth describing a particular solution (or a class of
solutions), while this solution has a number of big problems, and
another approach would be better .. but the details of the approach 
would have to be worked out (in very short order).

So, if we agree with that that view, the options would appear to be 
like:

 1) describe the problems with currently proposed mechanisms, and 
    recommend against using them (if already being used) after a 
    better solution is found.  This has a problem that undeploying 
    stuff is very difficult, and if it's already out there, giving 
    IETF "blessing" to a temporary deployment may not be a good idea.
    (This may not clear Allison's Discuss.)

 2) just describe the problem, and get the balls rolling quickly to 
    find the good solution. The problem with this is that it 
    doesn't give any idea about what kind of solution that would be.
 
    2.a) include the justification why currently proposed mechanisms 
         are not good.

    2.b) omit the discussion.

 3) describe the problem, and try to give very high view details of
    a potential solution (e.g., as Allison already stated), and get 
    the balls rolling quickly to find the solution.  The problem with 
    this is that as the details are not yet clear, it might be 
    inappropriate to just describe a sketch here, as it could change 
    still.

    3.a) include the justification why currently proposed mechanisms
         are not good.
                                                                                                
    3.b) omit the discussion.

 4) delay this document until work has gone further.  That is, there 
    are a number generic suggestions, lacking the specifics.  Maybe 
    this is an indicator that we should try to work out more details 
    of the approaches first, and only publish the document when it has 
    enough details to be (more) useful.  The problem with this is that it
    delays the publication for parts which would already be considered 
    useful.

Is this a reasonably good representation of the possibilities? 

Thoughts on the way forward?  Send them on the list by next Tuesday,
27 April (at the latest).

Thanks!

(co-chair hat off)

(By the way, I wrote "get the ball rolling" -- but I'm REALLY, really 
hoping that the ball would already be going down the slope...)