Draft:  		draft-ietf-sipping-sbc-funcs-00.txt
Reviewer: 		Michael Procter
Review Date:	5 Dec 2006
Review Deadline: 	20 Dec 2006
Status: 		WGLC

Summary:	
This draft is on the right track but has open issues, described in the
review.

General:
I found the title somewhat misleading.  Instead of a collection of
requirements obtained from SBC deployments, this document seems to be
a collection of useful SBC techniques.  The requirements in section 4
seem
to be added as an afterthought, rather than being the main purpose of
the
document as suggested by the title.  The introduction states that the
goal
of this document is 'to describe all the functions of SBCs', which seems
to
conflict with the title.

I found that the division of each function in section 3, into 'General 
Information', 'Architectural Issues' and 'Example' useful.  But the 
'General Information' section seems to mix statements of the problem
with statements of approaches to fix it.  Maybe clearly separating out
what
problem is to be solved from how it is solved would be helpful.

3.1.3:
Given the discussion of Via handling, it would be useful to see this
used
in the example, in addition to Record-Routes.

3.2:
CODEC restriction strikes me as being one of the more important
applications of traffic shaping, but it only gets mentioned half-way
through the Example section.  I would find it helpful to have it
mentioned
in the General Information section, as a statement of the sort of
problem
being tackled by this section.

3.4.1:
This section discusses NAT binding maintenance, and then throws in a
comment at the end about 'other measures may be taken'.  It strikes me
that
in a section about NAT traversal, some discussion of techniques such as
Path, or Contact rewriting should be included, or some similar 
discussion.  Whilst there are some comments about this subject in the 
'Topology hiding' section, I'm not sure that that is an obvious place to
look.

3.4.3:
The last comment says:
	Naturally also other measures need to be taken in order to
	enable the NAT traversal...
Can they be listed at least?  The introduction states that 'the goal of
this document is to describe all the functions of SBCs', after all.

3.5.3:
'the SBC first identifies the caller'.  Since this occurs before the
INVITE
is received, I think a little more explanation is required.  If this is
TLS
or TCP specific, then that should be called out.  If the action is
really
performed once the INVITE has been received but before additional
processing, then the diagram and text should reflect this.  The missing
ACKs in the diagram are minor, but such things have caused confusion in
the
past.

3.6:
This section doesn't seem to have much content apart from a list of bugs
that can be worked around.  Whilst this list may be a good source of
stories, do they all need to be listed?  Can a couple be selected as
indicative of the sorts of incompatibility that can be fixed, and the
section shortened?

3.7:
I am not sufficiently experienced with secure media to be able to review
this section, although I note that the ACKs are missing from the call
flow.

Minor
=====

2.2, third line:
'to the operator' should read 'to the operator's'

3, fourth line:
'explanation on any impact' should read 'explanation of any impact'

3.1.2, second para, first line:
'Unifor Resource Indetifiers' should read 'Uniform Resource Identifiers'

3.1.3, second para, second line:
'is receiving an INVITE' might be clearer as 'receives an INVITE'

3.1.3, fourth para, fifth line:
'then restarts losing state,' might be clearer as 'restarts, thus losing
state,'

3.1.3, last para, first line:
'topology hiding, in some cases,' might be clearer as 'topology hiding.
In
some cases,'

3.2.1, first para, fourth line:
'subscibers' should be 'subscribers'

3.2.1, first para, fifth line:
'differently than' should be 'differently to'

3.2.3, first para, fifth and sixth lines:
'user agent', or 'user-agent', but not both!

3.2.3, second para, seventh line:
'alarming' in this context is jargon.  Prefer 'raise an alarm'.

3.2.3, third para, second line:
'from the one network' might be 'from the outer network', but this isn't
clear from context. 

3.6.1, first para, third line:
'many client as possible' should read 'many clients as possible'