Subject: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Apr 2010 18:20:41 -0700

Hans Erik Von Elburg said:

"Also I think we need to be fair on this, martini is not addressing the 
issues
with existing solutions and fixing them, it is creating a new solution 
trying
to avoid some issues with existing solutions. That is a different 
approach."

[BA] Too often the IETF has attempted to solve an interoperability problem by
 creating yet another solution, rather than refining an existing 
deployed approach.  Very often, this approach has been (mis)guided by the need to meet an exhaustive set of "requirements" that exist mainly in the minds of the requirements document authors.  Typically, the result is an unnecessary new protocol that is either ignored by industry or actually makes the interoperability problem worse.  If there were one thing I would change about the IETF, it would probably
 be to discourage that kind of pointless meddling.  Mark Handley's excellent paper "Why the Internet Only Just Works" (see 
http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf ) 
describes why the IETF's protocol design methodology has failed so consistently. 

However, in this particular case, the Requirements document authors have been thoughtful in their arguments. The indictment against the existing solutions outlined in the 
Requirements document is not merely based on the diversity of existing 
deployed solutions;  if this were the case, then indeed adoption and 
refinement of one of the existing approaches would be preferred. 

The authors make the case that the problems with existing solutions are fundamental rather than merely representing a series of nits.  This indictment has been backed up by testimony from PBX vendors and SSPs who have experienced problems accommodating one or more of the existing approaches within their architectures. 

 The authors also do not appear to have fallen into the trap of making 
perfection the enemy of the good.  Rather than throwing together a list of "nice to haves" as many IETF requirements docs do, the document authors have attempted to put together a list representing the union of requirements. 

Essentially, the requirements document makes the argument that there is not any existing solution that "only just works" -- that is, a solution, that while not perfect, can meet the bare minimum of requirements necessary to address an essential need, thereby achieving widespread deployment.  Indeed, it appears that none of the existing deployed approaches 
is on a path to achieve a critical mass in both SSP and PBX 
implementations. 

If the requirements document is correct in its reasoning, then none of the existing solutions have what it takes to be successful in the real world.  Of course, that does not mean that a new approach will necessary be successful. But it does imply that the arguments made in the requirements document cannot be dismissed out of hand, and need to be argued on their merits.

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Sun, 4 Apr 2010 05:28:33 -0400

Speaking as a Service Provider, the solution being produced by Martini
does not address what is needed for current to mid-term deployments, and
creates interoperability problems in the long haul. 

Yet again, the IETF gives us the best of both worlds....

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Saturday, April 03, 2010 9:21 PM
To: [email-masked]
Subject: [martini] The IETF versus reality (was: problems with existing
SIP trunking solutions)

"Also I think we need to be fair on this, martini is not addressing the
issues with existing solutions and fixing them, it is creating a new
solution trying to avoid some issues with existing solutions. That is a
different approach."

[BA] Too often the IETF has attempted to solve an interoperability
problem by creating yet another solution, rather than refining an
existing deployed approach.  Very often, this approach has been
(mis)guided by the need to meet an exhaustive set of "requirements" that
exist mainly in the minds of the requirements document authors.
Typically, the result is an unnecessary new protocol that is either
ignored by industry or actually makes the interoperability problem
worse.  If there were one thing I would change about the IETF, it would
probably be to discourage that kind of pointless meddling.  Mark
Handley's excellent paper "Why the Internet Only Just Works" (see
http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf )
describes why the IETF's protocol design methodology has failed so
consistently. 

However, in this particular case, the Requirements document authors have
been thoughtful in their arguments. The indictment against the existing
solutions outlined in the Requirements document is not merely based on
the diversity of existing deployed solutions;  if this were the case,
then indeed adoption and refinement of one of the existing approaches
would be preferred. 

The authors make the case that the problems with existing solutions are
fundamental rather than merely representing a series of nits.  This
indictment has been backed up by testimony from PBX vendors and SSPs who
have experienced problems accommodating one or more of the existing
approaches within their architectures. 

The authors also do not appear to have fallen into the trap of making
perfection the enemy of the good.  Rather than throwing together a list
of "nice to haves" as many IETF requirements docs do, the document
authors have attempted to put together a list representing the union of
requirements. 

Essentially, the requirements document makes the argument that there is
not any existing solution that "only just works" -- that is, a solution,
that while not perfect, can meet the bare minimum of requirements
necessary to address an essential need, thereby achieving widespread
deployment.  Indeed, it appears that none of the existing deployed
approaches is on a path to achieve a critical mass in both SSP and PBX
implementations. 

If the requirements document is correct in its reasoning, then none of
the existing solutions have what it takes to be successful in the real
world.  Of course, that does not mean that a new approach will necessary
be successful. But it does imply that the arguments made in the
requirements document cannot be dismissed out of hand, and need to be
argued on their merits.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 5 Apr 2010 13:06:00 +0200

On Sun, Apr 4, 2010 at 3:20 AM, Bernard Aboba <[email-masked]>wrote:

> [BA] Too often the IETF has attempted to solve an interoperability problem
> by creating yet another solution, rather than refining an existing deployed
> approach.  Very often, this approach has been (mis)guided by the need to
> meet an exhaustive set of "requirements" that exist mainly in the minds of
> the requirements document authors.  Typically, the result is an unnecessary
> new protocol that is either ignored by industry or actually makes the
> interoperability problem worse.  If there were one thing I would change
> about the IETF, it would probably be to discourage that kind of pointless
> meddling.  Mark Handley's excellent paper "Why the Internet Only Just Works"
> (see http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf )
> solutions outlined in the Requirements document is not merely based on the
> diversity of existing deployed solutions;  if this were the case, then
> indeed adoption and refinement of one of the existing approaches would be
> preferred.
>
> The requirement document does not describe a solution, does it?
The requirement document does leave enough room for a common solution,
because as you say the requirement authors have done a thoughtful and
carefull work and take into account comments from other participants on the
list.

> It has been clarified already that these problems are less fundamental
properties of those solutions sometimes then opinions. For this reason some
discussion has taken place to improve the text.

> perfection the enemy of the good.  Rather than throwing together a list of
> "nice to haves" as many IETF requirements docs do, the document authors have
> attempted to put together a list representing the union of requirements.
>
> Essentially, the requirements document makes the argument that there is not
> any existing solution that "only just works" -- that is, a solution, that
> while not perfect, can meet the bare minimum of requirements necessary to
> address an essential need, thereby achieving widespread deployment.  Indeed,
> it appears that none of the existing deployed approaches is on a path to
> achieve a critical mass in both SSP and PBX implementations.
>
> I dont think that the requirement document makes that argument.

> If the requirements document is correct in its reasoning, then none of the
> existing solutions have what it takes to be successful in the real world.
> Of course, that does not mean that a new approach will necessary be
> successful. But it does imply that the arguments made in the requirements
> document cannot be dismissed out of hand, and need to be argued on their
> merits.
>
> I rather think the requirements document is listing some issues with
existing solutions and from that lists requirements that a solution without
such issues should fulfill. It does not imply a particular solution.