Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments
draft-ietf-sipping-sbc-funcs-09

Section 3.3.1 - might want a reference for history and diversion

Section 3.3.2 - first sentence is hard for me to understand

Section 3.2.1:

  Additionally, traffic management can be used to implement intercept
  capabilities where required to support audit or legal obligations.

I am not aware of legal requirements to implement intercept functions
by network operators that are not parties in the communication or
setup of the communication for other reasons already. There are
requirements for intercepting Internet communications by ISPs, but
this interception is to be done at the level of they provide
service. For instance, if they merely act as a DSL provider they would
be able to store/inspect IP traffic. Similarly, an operator that
provides voice service might have a legal requirement to provide
interception capabilities. Traffic management as defined in your
document is one way of doing this. However, in this case the operator
would already have SIP proxies in their network that can act as B2BUAs
and perform traffic management. So the introduction of additional
devices to do this may not be justified.

Some discussion of the above nuances would be useful in the document.

Section 3.3.1:

   For example, user-
   agents on networks which implement SIP differently (for example 3GPP
   or SIP [1] network etc)

Is the issue really that they implement SIP differently, or that they
require differing sets of extensions? Perhaps this needs to be written
in a way similar to the previous sentence which said "SBCs fixing
capability mismatches enable communications between user-agents with
different capabilities or extensions." Or simply say "For example,
connecting to a 3GPP network via a plain SIP phone."

Section 3.4.1:

   SBCs' NAT traversal function is required in scenarios
   where the NAT is outside the SBC 

I have a hard time imagining networks where this arrangement
exists. If my Linksys router had an SBC function and it fixed
the lack of NAT traversal support in my SIP client, that would
be one. But somehow I suspect that I would get an upgrade to 
my client software sooner than an upgrade to the router.

Suggestions for editorial improvements/clarifications:

Section 2.1: I read the first paragraph while looking at Figure 2, and
was very confused. Does this section describe two different cases, one
without SBC and one with SBC? If so, having two figures as well would
help. If not, figure and text should use consistent names for the
network elements (e.g., which of these is the "originating gateway"
etc.).

Section 2.1, Figure 2: explain acronym SSB

Section 4, s/exiting/existing/

  Section 3.4.2 says:
  >
  > There is also a problem related to the method how SBCs choose the
  > value for the validity of a registration period.  This value should
  > be as high as possible, but it still needs to be low enough to
  > maintain the NAT binding.  Typically SBCs do not have any
  > deterministic method for choosing a suitable value.  However, SBCs
  > can just use a sub-optimal, relatively small value which usually
  > works.
  >
  This text begs for an additional sentence.  Please provide an example
  of "a sub-optimal, relatively small value which usually works".

  Section 3.1.3: s/beeing/being/

This is a rather nice document  I very much appreciate the clear and
consistent organization.

A few minor issues:

(1) Section 3.5, Access Control

This section seems to have multiple definitions of "access control".

The opening sentence focuses on controlling "what kind of signaling and
media traffic their network carries" but the closing sentence of the
same paragraph talks about access control based on "link-layer
identifiers, IP addresses or SIP identities".

The implications of these two definitions are very different, imho.
As a result, the requirements and issues presented in 3.5 are somewhat
confusing.  The example only addresses one aspect of the problem, as
well.

I suggest revising 3.5 to more clearly explain why these two
definitions of access control are related, or breaking this into
two sections each devoted to one problem.

(2) Section 3.5 would also benefit from more detail regarding the
range of policies that need to be expressed and enforced by an SBC.
The references to policies and policy servers need detail.

editorial nits:

Section 3.1.3

s/identity of subscribers in beeing hidden/identity of subscribers is hidden/

Section 4

s/exiting/existing/