RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

["Henry Sinnreich" <[e-mail]>]

Peter,

 

This is not the place to discuss NAT traversal issues. If you are comfortable with NAT traversal then more power to you.

 

As for the number of SIP related RFCs there are now 121, plus a much larger number of I-Ds in waiting.

Happy reading!

 

Henry

 

________________________________

From: [e-mail] [mailto:[e-mail]] 
Sent: Saturday, November 10, 2007 6:00 PM
To: Henry Sinnreich
Cc: [e-mail]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

 


Hi Henry, 

> ... What’s the use of a configuration that may not traverse NAT? 
I do not see ANY major NAT traversal issues for main-stream scenarios, assuming Outbound can be worked to also address non-Register usage (separate that issue, PLEASE!), and as long as we presume the Profile Delivery Server side is directly reachable (no NAT on that end, the main-stream case).   

What *specific* issues do you see??  Please be very specific, so we can fix them, or at least define the range of scenarios where currently defined approaches apply and look to further work to make the rest work.  Otherwise, I still feel very strongly we MUST progress, since basic configuration for mass deployment scenarios has been a very big issue for a very long time.   

> Check out http://rfc3261.net/ <http://rfc3261.net/>  
Sorry, based on the data presented here, the only thing I really see is the world woke up to SIP in around early '02.  The (prominent) arrow on 3GPP is meaningless ... just another sign of a particular group waking up.  As far as this data shows, this has nothing directly to do with configuration, NAT, or anything else relevant here.   (I can agree though, SIP's current popularity is actually one of its own worst enemy's ;-)   Please explain how this data applies in particular to the intersection of SIP, configuration, and NAT (or anything else relevant).     

Cheers, 
Peter 






 

"Henry Sinnreich" <[e-mail]> 

09.11.07 21:04 

        
        To:        <[e-mail]> 
        cc:        <[e-mail]> 
        Subject:        RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13




Peter, 
  
>??   It needs to be progressed -- I hope you agree. 
  
Well, we disagree here. What’s the use of a configuration that may not traverse NAT? 
There is already a flood of SIP related I-Ds not based on testing on the net and I am sorry that this particular document is just one more instance of this phenomenon. 
  
Check out http://rfc3261.net/ <http://rfc3261.net/>  
  
Does it make us comfortable? 
  
Henry 
  

 

________________________________


From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, November 09, 2007 11:41 AM
To: Henry Sinnreich
Cc: [e-mail]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13 
  

Hi Henry (Ted also), 
Thanks for the response.  Certainly agree NAT is something to always consider -- there are only limited practical cases where it is not an issue today, at least in some way.   

BUT, I hope your comment is not intended to add work to the already very overdue Config Framework??   It needs to be progressed -- I hope you agree.  (I know you have been a very long time supporter.)  In my mind at least, as long as we can crack the Outbound-related issues being discussed (in that document, not in Framework), then there is no more needs to be done in Framework at this point.   

If we need to crack cases where both device and profile delivery server (PDS) are behind NATs, then I think it would best be described in a separate document at this point.  (Framework assumes that the PDS is reachable at least, which is a valid assumption in most realistic scenarios, I think.)   

To facilitate NAT traversal, I do see there may be requirements on *profile data* getting delivered to the device, notably in local network profiles, but this work is already intentionally separated from the framework itself.   

-- Peter 

  

"Henry Sinnreich" <[e-mail]> 

09.11.07 10:24 

        
       To:        <[e-mail]>, <[e-mail]> 
       cc:        [e-mail] 
       Subject:        RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13





Peter,

➢ I think we can generally agree that NAT traversal is not a corner case -- > must be solved -- no "poll" really needed for that.  

I am glad you keep this on top of the stack, since we face major problems here and without NAT traversal SIP UAs cannot function. 

How does the SIP UA configuration determine its NAT scenario without running STUN and/or STUNT tests?

One cannot bet on any NAT traversal techniques over any other (about 4-5 alternatives), because 

1. We don’t have the statistical data to make an engineering judgment, and 

2. Several techniques in combination may be required, including STUNT and port scanning as examples. 

The start of a good judgment IMHO is the development and deployment of an UDP/TCP NAT test tool as described in STUNT (the Cornell University software download) and gather statistics on the Internet as has been done by the team at Cornell under Paul Francis.

This will influence how the SIP UA should be configured. 

How high a % of call failures can we afford? How do we measure that?

Last but not least, this seems to be a running battle, analogous to the race between armor and guns of battleships and this race points to a continuous project rather than a one-time delivery.

...I know; IETF process says...

Henry


________________________________________
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, November 09, 2007 9:14 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13


Hi, 
I think we can generally agree that NAT traversal is not a corner case -- must be solved -- no "poll" really needed for that.  But I certainly agree with Sam and others here -- Config Framework needs to be progressed ASAP!!   It is waaaaaaay overdue.  Even aside from other SDOs moving ahead (which would just shoot everybody in the foot of course), real product vendors are also continuing to implement their own solutions, which can (and do) diverge from this, and become entrenched over time -- the problem only gets worse as even more time passes.     

I would counter-propose that we aggressively separate concerns, to allow Config Framework to move forward now.  In particular: 

o Outbound needs to describe usage during SUBSCRIBE (possibly other non-REGISTER cases as well).  Clearly out of scope for Config Framework.   

o Outbound or some other document should describe discovering the outbound proxy set.  It is a generic problem not specific to configuration, therefore should be out of scope for Config Framework.  Let's say that out loud in the document, and move on.   

o Markus' statement "... should be one of the basic requirements that the user MUST NOT need to manually configure such parameters as proxy addresses."  should also be declared out of scope for Config Framework itself.  It is really part of the point above (discovery of outbound proxy set).  And anyway, even if there is some still some manual configuration required in some scenarios, it becomes far simpler process with the aid of the Config Framework, so would be a major step forward.   

(Aside: On the 2nd point above, I also think outbound should not refer to config framework for this, but that's really a comment on that other document.)   

With the corrections Markus points to below (normative reference etc) and a few others we have seen, and with some cleanup to say what is out of scope (as above), plus waiting to see next rev of outbound with updates around the non-REGISTER usage (real soon now, right?!), can we agree to progress Config Framework?  (PLEASE ?!?!)   

-- Peter 

 


<[e-mail]> 
09.11.07 08:13 
       
       To:        <[e-mail]>, <[e-mail]> 
       cc:         
       Subject:        RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13



Hi,

Ganesan Sam-W00184 [mailto:[e-mail]] wrote:
>
>I see the corrections from Roni etc and that is great.  But 
>hanging this on to the progress of outbound is like saying we 
>wont do anything to sip until the essential corrections to sip 
>or done and finished and delivered as an RFC.  

Otherwise I agree with you, but currently config-framework relies on
functionality in sip-outbound that is not (yet) described in
sip-outbound. Building on work-in-progress is usually fine if things are
modular and the interface is clear, but building on non-existing
functionality is more dangerous, if you believe such functionality is
essential. In practice we should see the next rev of sip-outbound in a
matter of couple of weeks, and hopefully this clears the issue.

>They should be 
>kept independent of each other IMHO.  If something is in the 
>scope of outbound... It is not in the scope of 
>config-framework and we can state it as such.  But I most 
>definitely don't agree with holding this up until something 
>else is done.  BTW, TISPAN etc wil move ahead and mandate 
>their own version of config-framework independent of and with 
>no reference to ietf if we delay this until the planets are in 
>alignemnt again.  ATIS is also marching in that direction.  We 
>have been trying to get tispan and atis to wait until there is 
>a basic framework from IETF... So for heavens sake don't let 
>them take off in a random direction without any guidance from the IETF
>

Politics between SDOs is important and I agree ATIS and TISPAN should
follow IETF, but I am worried about having an RFC that can be
implemented and deployed for UAs behind NATs. 

Perhaps we should just take a poll to see how many people/vendors who
will implement this without Outbound (no NAT traversal, or some
proprietary method to do it between UA and proxy for SUBSCRIBEs before
registration). If there are enough of those, it makes sense to go ahead.
If most people think Outbound is essential for this, faster timeline
might not be that useful.

>Sam
>
>PS: Let us also not forget that it has been what 3 years since 
>this started....
>

I thought it was 7... :-( I agree that it would matter if I was
requesting some new corner-case features, but NAT traversal seems to me
like a major point.

Markus


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP