Subject: Re: [Sip] INFO considered harmful

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Jan 2003 16:01:09 -0500

Frank W. Miller wrote:
> Greetings,
> 
> I would take issue with the basic premise of the draft, which is that the
> SIP and SIPPING groups need to have control over every bit that passes
> through a SIP message.  It is not possible for the standard to anticpate
> every situation that people might want to use the protocol.  It's
> interesting how many times I've heard WG members say, "thats not what I
> intended it for".  The beauty of SIP is that its basic framework and
> semantic level endear it to so many different signaling situations.  The use
> of INFO to supplement the corners of specific applications is a very
> important part of that versatility.

It is the job of the IETF to define protocols that interoperate, that 
scale well, that have good security, that don't congest the internet, 
and so on. Sometimes, there is a need for vendor proprietary extensions 
to such protocols. However, all vendor extensions need to live within a 
"sandbox" that limits the scope of what can be done. Specifically, that 
sandbox has to draw the line around issues of scale, security, and 
congestion control, which affect *other* networks and other vendors. 
IETF protocols are used on networks where other things live too.

The problem with INFO is that it defines no such sandbox. It allows 
anything, and can be used in ways which will cause problems when those 
messages flow through other vendors equipment or run on other networks. 
The clearest example of that is the rate. A record-routing proxy in some 
other domain might get a flood of INFO messages because some app in 
someone elses server thought INFO was a good way to tunnel voice.

Let me take this to the extreme. By your argument, TCP should allow for 
vendor-specified plug ins for congestion control. After all, why should 
IETF prevent me from using something that works well for MY application? 
Indeed, there is lots of research on different congestion control 
algorithms. TCP should allow those to be used! But, would you really 
want someone to be able to plug in a congestion control algorithm that 
basically doesn't do congestion control algorithm? I should hope not.

> 
> JR cites three specific problems with INFO:
> 
> Lack of interoperability: This is not a problem.  Since the INFO contents
> are explicitly outside the standard, this must be assumed by the
> implementor.  If they persist with INFO to implement some signaling
> situtations, there are likely other good reasons for doing so.

You have not properly interpreted my draft. THe interoperability failure 
is that there is know what to know the intent of the INFO method. There 
is no way to signal that this is the "frank's extension usage" as 
opposed to anyone elses.

> 
> Inappropriateness: As I've already stated, I do not feel that the SIP and
> SIPPING working groups should (let alone can) realistically expect that they
> can determine how and when the protocol will be applied in applications at
> this late date.

Please see my above comments on this. I believe that this is a 
fundamental issue about the role of IETF in protocols.

> 
> Incorrectness: Jonathan is eluding to the possiblity of errors being present
> in the protocol extensions.  Well, this is not the SIP and SIPPING groups
> problem.  These extensions are outside the scope of the standard.  If the
> purveyors of the extension design the error, they're responsible for it, not
> the SIP and SIPPING groups.

Except where those extensions impact other servers, vendors or service 
providers. And they can.

> 
> As has already been noted in this thread, there are a number of fine
> implementations (including Dynamicsoft) in the field, many, if not all,
> including a punt to the application of the INFO body.  

Frank, pointing a finger at me and saying "but your company does it!" is 
neither a compelling argument or, IMHO, a civilized way to conduct a 
discussion on the list. It is frequently the case that ones company does 
something that one does not like, because a customer asked, or a partner 
is doing it, or because of one reason or another. Does that mean that we 
should be promoting such things as IETF standards?

> This is very useful
> functionality to implementors and as such it makes very little sense to
> deprecate this method.  Another will take its place as the abused.  For
> example, I've had discussions with people about doing extensions using
> SUBSCRIBE/NOTIFY that had nothing whatever to do with events just because of
> the "political incorrectness" of INFO. 

Unlike INFO, SUB/NOT defines a very well-scoped and limited repetoire of 
behavior for packages. So, while someone may violate the spec and do 
something inappropriate, it would not be IETF compliant. WIth INFO, one 
can do bad things and still claim to be compliant to the specifications.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 2 Jan 2003 18:33:31 -0500

Thanks for the thoughtful reply.

Comments inline...

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Frank W. Miller" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 02, 2003 4:01 PM
Subject: Re: [Sip] INFO considered harmful

>
> Sometimes, there is a need for vendor proprietary extensions
> "sandbox" that limits the scope of what can be done.

I think this is really the crux of the issue for me.  Because this is a
signaling protocol and not a routing or transport protocol, the need to
provide for corner cases and extensions over time is greater.

> The problem with INFO is that it defines no such sandbox.

Absolutely correct and absolutely a potential problem for a variety of
reasons, including clobbering the intermediary servers.  But, the reality
is, application implementors need some kind of app-to-app tunneling for
stuff that isn't explictily handled.  Also a reality is that INFO has been
around for awhile and people are using it.  In lieu of something better, the
mechanism has to be there.  In a way, using INFO can actually be a good
thing because it paints a great big red "A" on the packet as soon as it show
up somewhere.  If it were in some other legal method that was being abused,
the potential for abuse might not be as easy to spot.

> basically doesn't do congestion control algorithm? I should hope not.

Your point is well taken, but I would refer back to my earlier statement.
This is a signaling protocol, and has different, higher-level semantic
requirements placed on it.  The need for various congestion control
algorithms (to continue your example) is mitigated by the fact that the
existing protocol covers a huge portion of the requirement space.  This is
not as clear with a signaling protocol.

> should be promoting such things as IETF standards?

My apologies.  I should have realized that just because it might be in your
product, that would not necessarily affect your opinion in the IETF forum.
But that was not really the intent of my comment.  I was simply trying to
point out that the need for tunneling is apparent since all the major
vendors are supporting what their customers have required, nothing more.

> can do bad things and still claim to be compliant to the specifications.

So, there it is.  What we really need is a substitute for INFO that works
the way implementors need but also has the appropriate scaling and safety
properties.  I think the substitute consists of two parts.

1) A method/methods that allow for some degree of application-to-application
tunneling
2) An IETF process associated with this method that allows for incorporation
of this tunneling into the mainline protocol over time

Ideally, if 1) is done right, very little syntactic change to extensions
would be necessary for 2) to happen.  The split of SIP into SIP/SIPPING was
a step down the road to 2)  What was missing from that was 1).  If there was
a a 1), the flow of new elements coming into these WGs and subsequently into
the standard might have more rigor and hopefully progress more quickly.

Thanks again,
FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Networks, Inc.
[email-masked]