Re: [Sipping] Purpose of camarillo-sipping-sbc-funcs-02

"Jani Hautakorpi (JO/LMF)" <jani.hautakorpi@ericsson.com> Wed, 26 October 2005 05:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUdwf-0006Zx-Q5; Wed, 26 Oct 2005 01:35:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUdwd-0006XN-5T for sipping@megatron.ietf.org; Wed, 26 Oct 2005 01:35:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24173 for <sipping@ietf.org>; Wed, 26 Oct 2005 01:35:12 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUe9e-0003gh-0z for sipping@ietf.org; Wed, 26 Oct 2005 01:48:59 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38E17C48; Wed, 26 Oct 2005 07:34:49 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 07:33:47 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 07:33:46 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 10BDB2366; Wed, 26 Oct 2005 08:33:47 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C8F101AB896; Wed, 26 Oct 2005 08:33:46 +0300 (EEST)
Message-ID: <435F153A.9040804@ericsson.com>
Date: Wed, 26 Oct 2005 08:33:46 +0300
From: "Jani Hautakorpi (JO/LMF)" <jani.hautakorpi@ericsson.com>
Organization: Ericsson
User-Agent: Debian Thunderbird 1.0.2 (X11/20050602)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>, sipping <sipping@ietf.org>
Subject: Re: [Sipping] Purpose of camarillo-sipping-sbc-funcs-02
References: <BF7FC410.56B14%fluffy@cisco.com>
In-Reply-To: <BF7FC410.56B14%fluffy@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 05:33:46.0809 (UTC) FILETIME=[D6248A90:01C5D9EE]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
Cc:
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hi Cullen,

See my comments inline.

Cullen Jennings wrote:
> When this draft was started, my recollection was that the purpose was
> 
>    This document gives an overview to Session Border Controllers (SBCs)
>    and to the functions they perform.  The way how SBCs relate to the
>    telecommunication architectures is also presented.  The purpose of
>    this document is to help the IETF community understand what
>    functionality existing SBCs provide so that the appropriate working
>    groups can decide whether or not new standard solutions need to be
>    developed to provide such functionality (or a subset of it) in a
>    standard way. 

My personal view is that we have at least tried to do just that; to give
an overview to SBCs and to the functions they perform.


> I like that idea - we need to develop requirements and understanding of why
> SBCs are used. Many people felt that we did not want to repeat the path that
> IETF did with NATs that eventually resulted in the behave group.
> 
> However, the document seem to be moving in the direction of 1) assuming
> specific ways to build SBC that may or may not reflect how they are all
> build 2) turning into a B2BUA are evil documentation which right or wrong,
> is not what I was hoping to get out of this document

Could you give some examples from 1)?

One problem that we faced during versions 00 and 01 was that people
wanted to see all the imaginable functions as a part of SBC. Due to
that, we took an approach that only those problems that directly break
SIP on one way or the other are included into the draft.


> What I want is a document that is a requirements document on the problems
> that people want to solve that they currently solve using a SBC. This would
> be informational - the BCP discussion leaves me feeling very unclear on what
> the purpose of this document is.

We have tried to document the 'functions' of SBC, and not the
'requirements' for usings SBC, as it was somewhat decided on the 61st IETF.


> So my questions is - what is the purpose of this document? I recognize it is
> individual and that as it was written, the authors may have changed it's
> purpose over time. 

I don't think that we have changed its purpose over time. The history of
the draft is the following:

- 61st IETF meeting: There was a SBC BOF. It was somewhat decided that a
  document describing the use of SBC, and the ways how they break SIP is
  needed.

- 62nd IETF meeting: We made a 00 version. The minutes from the sipping
  meeting were the following:

  Both I-Ds will be merged. The resulting I-D's scope will be to
  document functions that existing SBCs implement and that break SIP
  somehow. This work will be used as input by different WGs to decide
  whether or not new specifications or recommendations are needed in
  this area.

- 63rd IETF meeting: We merged the two draft and made a 01 version. The
  minutes from the sipping meeting were the following:

  The author presented the draft. The common reaction from people that
  read the draft was that the work is useful and that it should include
  more details on why things break in the different scenarios presented
  in the draft. The chairs need to talk to the AD to decide whether we
  want to use this document as input to other work without publishing as
  an RFC or whether we publish it as an RFC (when it is ready) to be
  able to point to the document every time we need to explain somebody
  why a particular way of implementing a function breaks SIP.

- 64th IETF meeting: We have added the requested, concrete details, and
  02 version is made.


-- 
Jani H.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP