Draft:  draft-ietf-sipping-sbc-funcs-00.txt
Reviewer:  Francois Audet
Review Date:  Thursday 11/30/2006 7:19 PM CST
Review Deadline: 20 Dec 2006
Status:  WGLC

Summary:	
I really do not believe that this document is ready for Working Group Last Call.

General:
I have started to review it, but I'm having difficulties because it just isn't ready yet.

There are a number of comments (unresolved issues) from the authors 
still embedded in the document, illustrating that it is not ready for WGLC. 
It is pretty entertaining to read the dialog between
the co-authors, but it does emphasise that the text is not ready.

I also find that the wording needs lots of improvement. 

The purpose of the document is not very clear either. And the introduction 
is more confusing than helpful.

Some specific comments:

- In the Scenario section, I'd like to see an Enterprise border scenario.  (I.e., where an enteprise uses an SBC at the edge of it's network, in 
the DMZ). On the other side, it could be the open internet with "normal" 
SIP DNS based connectivity, or it could be a SIP service provider.

- The problem in section 3.1.2 is not "theoretical". It will happen in 
all but the smallest of Enterprise scenarios (as per the scenario 
described in previous bullet).

- The term "SIP Profiles" in section 3.3.1 is probably something
we want to avoid (i.e., say "implement  SIP differently" instead 
of "implement different SIP Profiles").

- The section about NAT should explain more media anchoring, and 
the difference between anchoring in one direction or in two direction 
(i.e., some SBCs only anchor media for IP addresses on the private side,
like "ALGs").

- Section 3.5.2: SBCs do introduce a scalabiliy problem because it forces 
the funneling of signalling and media into a single point of failure.

- I don't see the point of the list of "bugs" fixed in 3.6.3 by an SBC. 

- Architectural issues in 3.7.2 for Media encryption should describe the extra delay affecting voice quality, as well as the processing requirement. 
It should also describe that it introduces another layer of routing
on top of IP and generate sub-optiomal routing.

- Security consideration section needs to be written. There are lots
of security considerations to talk about. SBCs are Man-in-the-Middle
by definition. It has impact on RFC 4474 that needs to be described. 
Also on signalling security (explain that SBC is a TLS hop). The 
implications of Topology hiding for security needs to be explored. 

In summary, I think it needs quite a few more cycles of editing.