Document: draft-ietf-sipping-sbc-funcs-04.txt
Reviewer: David L. Black
Review Date: 7 January 2008
IETF LC End Date: 16 January 2008

Summary:

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

Comments:

This draft is generally in good shape and well-written.  Most of these comments are nits, but I consider the following three to be minor open issues:
	a) NAT problem not explained (3.4.1)
	b) Scope of Protocol Repair needs to be broadened (3.6)
	c) Recommendations need to cross-reference problems (4) These are marked with *** in the comments below.

End of Section 2: the intuition behind the terms "inner network" and "outer network" should be explained.  It appears that the SBC is logically associated with the inner network and provides functions such as controlling and protecting access to the inner network from the outer network.

Section 2.2:

   Some endpoints may be behind enterprise or residential NATs.
   In cases where the access network is a private network, the
   SBC is the NAT for all traffic.

"the NAT" --> "a NAT" and add a sentence calling attention to the possibility that SIP traffic may get NAT'ed more than once (e.g., in Figure 3, traffic to/from UA3 may get NAT'ed at both the NAT and the SBC if the Access Network is a private network).

The last paragraph of section 3.1.3 rapidly switches from topology hiding to identity hiding.  The relationship between these two should be explained.

Section 3.2.1:

   Some operators do not want to manage the traffic (e.g.,
   allowing only certain codecs), but only to monitor it ...

The parenthetical example "(e.g., ..." is very poorly placed.
It should be moved into the previous paragraph.

Section 3.2.2 - Add "requirements of Authenticated Identity Management" just before the citation of [3] for clarity.

"o=mhandley" - while I realize this came from RFC 2327, please use an example other than Mark Handley's username.  "caller"
or "callee" would be fine.

*** Section 3.4.1 doesn't completely explain the NAT problem before it describes the solution.  It looks like the primary NAT problem is keeping the NAT binding for the control connection active, hence the decreased validity time to force an earlier REGISTER to refresh the binding state.  That needs to be explained in the first paragraph, and it needs to be clear that this is about a NAT outside the SBC (e.g., the NAT in Figure 3, not the NAT that may be in the SBC), as an SBC presumably does not need to resort to this sort of subterfuge to keep a NAT binding active in a NAT that's part of the SBC itself.

I presume that media traffic is sufficiently continuous that its NAT bindings are self-sustaining, right?  That should also be stated.

The fourth paragraph in Section 3.4.1 ("Operators implement
...") is about a lot more than NATs (e.g., it applies in the complete absence of NATs).  It probably belongs somewhere else; at a minimum, it's also related to access control (3.5).

Section 3.4.2 - please provide examples and citations for end-to-end confidentiality and integrity mechanisms used in practice.

Section 3.4.2, last sentence - surely there are rules of thumb that work for choosing NAT binding refresh periods that usually work.  Section 3.5 of draft-ietf-tsvwg-udp-guidelines-04.txt is one place to look, and this should probably be referenced.

Section 3.4.3:

   Naturally also other measures need to be taken in
   order to enable the NAT traversal, but this example
   illustrates only one mechanism for preserving the
   SIP related NAT bindings.

That's somewhat cryptic - a brief explanation of the "other measures" would be an improvement.

Section 3.6.1, end of first paragraph - explain what is meant by "protocol conversion": conversion of which protocol between what and what?

*** Section 3.6.1 describes repairing messages "generated by not-fully-standard clients" but the example in Section
3.6.3 involves a correct message sent to a client that doesn't implement the entire standard.  Section 3.6.1 needs to be rewritten to encompass the example.

Section 3.7.1 - provide an example of the encryption techniques used.

*** Section 4 should cross-reference the requirements back to subsections of Section 3.  I think the cross references
are:
- Req-1 (topology hiding): 3.1
- Req-2 (redirect via intermediary): 3.2, 3.4, 3.5, others?
- Req-3 (capability mismatch): 3.3
Section 4 should also list items not completely addressed, i.e., those for which SBC "hacks" and/or not-completely standard SBC interposition will continue to be needed.

The Security considerations section should point out the security motivations for some SBC functionality. This arises in a number of subsections of Section 3.

idnits 2.05.03 ran clean (no errors or warnings).