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

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Oct 2005 10:25:20 -0700

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. 

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

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.

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. 

Cullen

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

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Wed, 26 Oct 2005 08:33:46 +0300

Hi Cullen,

See my comments inline.

>    developed to provide such functionality (or a subset of it) in a

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.

> 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.

> 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.

> individual and that as it was written, the authors may have changed it's

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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 29 Oct 2005 22:05:03 +0300

Hi Cullen,

my opinion is that this draft should focus on documenting functions that 
are needed (i.e., folks are currently implementing them) and that are 
implemented in a way that breaks SIP somehow. The fact that these 
functions are implemented by an SBC seems irrelevant to me.

A document with such a scope would be useful to:

1) clarify why if a function is implemented in a particular way, it 
breaks things. The document needs to go beyond "this is evil" and 
explain what problems you can expect if you implement things in that way.

2) provide input to the community so that we know which functions cannot 
be implemented with the current SIP toolbox. We may need to come up with 
extensions for those functions.

It may also be possible that a particular function can be implemented in 
a friendly way and in an unfriendly way. We may need to point out the 
advantages of choosing the former way.

 > be informational

Yes, we seem to be on the same page. I want to know which functions are 
implemented in a way that breaks SIP. You want to know which problems 
are resolved in a way that breaks SIP. Two different ways of saying the 
same thing.

In any case, if seems obvious that the terminology currently used in the 
draft is confusing. We will try and clarify its scope further in the 
next revision of the draft.

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo