A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
draft-ietf-straw-b2bua-taxonomy-03

UPDATED:
An Applications Directorate review was just posted, and I'm sorry that it's so late (it was not the reviewer's fault, but a processing problem).  There's nothing in the review that I would mark as blocking, but the review makes a lot of reasonable suggestions:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09960.html

Before the document is final, please have a look at the review and address the suggestions that you think are good ones.

----------------------------------------------
My original comments:

There's an oddity in the shepherd writeup that I'd like to clear up, but it's not at the level of a blocking DISCUSS:

   Q: Why is this the proper type of RFC?
   A: It’s published for the general information of the Internet community,
      and does not represent an Internet community consensus or recommendation.

Other bits of the shepherd writeup do talk about working group consensus, so I presume that this is just a bad answer... but I want to be clear about the status of this document, which is a product of a working group and is asking to be published in the IETF Stream: This *is* intended to be an IETF consensus document, yes?

Another very small point: the text in the Acknowledgments section is part of ancient boilerplate, and doesn't belong here any more.

Your terminology section is not a terminology section, it "just" listing acronyms. This is weak for a taxonomy document ;-)
I was expecting:

       Back-to-Back User Agent [RFC3261] : A back-to-back user agent (B2BUA) is a
         logical entity that receives a request and processes it as a
         user agent server (UAS).  In order to determine how the request
         should be answered, it acts as a user agent client (UAC) and
         generates requests.  Unlike a proxy server, it maintains dialog
         state and must participate in all requests sent on the dialogs
         it has established.  Since it is a concatenation of a UAC and
         UAS, no explicit definitions are needed for its behavior.

      User Agent Client (UAC), [RFC3261]: A user agent client is a logical entity
         that creates a new request, and then uses the client
         transaction state machinery to send it.  The role of UAC lasts
         only for the duration of that transaction.  In other words, if
         a piece of software initiates a request, it acts as a UAC for
         the duration of that transaction.  If it receives a request
         later, it assumes the role of a user agent server for the
         processing of that transaction.

      User Agent Server (UAS) [RFC3261]: A user agent server is a logical entity
         that generates a response to a SIP request.  The response
         accepts, rejects, or redirects the request.  This role lasts
         only for the duration of that transaction.  In other words, if
         a piece of software responds to a request, it acts as a UAS for
         the duration of that transaction.  If it generates a request
         later, it assumes the role of a user agent client for the
         processing of that transaction.

Alternatively,

    The User Agent Client (UAC) and User Agent Server (UAS) are defined in [RFC3261].
    The User Agent Server (UAS) is redefined compared to [RFC3261] definition:

      Back-to-Back User Agent: a SIP Back-to-Back User Agent, which is the logical
      combination of a User Agent Server (UAS) and User Agent Client (UAC).


Later I see

   Furthermore, this document defines 'B2BUA' following the definition
   provided in [RFC3261], which is the logical concatenation of a UAS
   and UAC.  

That confuses me, specifically because I would have expecting this in the terminology section, and it does it "follow" the definition in RFC3261: the spirit maybe.
I don't mind the repeat here, but the terminology section must be clear
Close to a DISCUSS. Please engage in the discussion (if you don't plan on fixing this)

Editorial: 
- Expand a few acronyms with their respective first occurrence: SBC, PBX 


Thanks for this document. It will be useful.

form discuss, now cleared.

I can probably be convinced that I'm in the rough. This started out as a comment and ended up as a discuss so that we could dicuss it.

I am somewhat doubtful that the security considerations section is adequate. If you're going to survey them all you should be able to make some appropriate statement about the security considerations for back to back user agents of varying varieties. in particular a number of them eliminate the possibility of end-to-end security mechanisms being employed generally transparently...

otherwise no objections.

from dave crocker's review.

I'm pretty sympathetic with the assertion that the taxonomy should be a bit more accessible as well.



"For example, the abstract should be tweaked to make it more readable for non-experts.  The current text assumes very large amount of SIP background, such as by using an acronym soup.  Better to use fewer acronyms in abstract, unless they have extensive familiarity to /casual/ readers.

To the extent that this document can only reasonably be read by first having familiarity with specific RFCs, the requirements need to be stated early in the Introduction.  Equally, the terminology section should cite the documents from which it is importing terms.  And every acronym should be expanded the first time it is used and/or have a citation to its technical details."

The one nice thing about reviewing documents late is that everybody else has already said what needs to be said. Less typing for me. :-)

+1 support Joel.

I support Joel's DISCUSS and Barry's request to consider the Applications Directorate review.

In the Abstract

   There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
   performing different roles in different ways.  For Example IP-PBXs,
   SBCs and Application Servers.  This document identifies several
   common B2BUA roles, in order to provide taxonomy other documents can
   use and reference.

I don't think you can fix the middle sentence ("For Example ...") because you're just listing names with no details, and adding details probably isn't appropriate in an Abstract - it's probably clearer to delete the sentence altogether. Isn't it also pointed toward system types, more than roles? And the document says it's focused on roles.

At a minimum, in 3.1.  Signaling-plane B2BUA Roles

   This implies it does not modify SDP bodies,
   although it may save them and/or operate on other MIME body types.

It would be helpful to say more about "may save them" (for instance, why would the B2BUA do that?).

In 3.1.2.  Signaling-only

   An example of such a B2BUA would be some forms of Application Servers
   and PBXs, such as a server which locally processes REFER requests and
   generates new INVITEs on behalf of the REFER's target.  Another
   example would be an [RFC3323] Privacy Service Proxy performing the
   'header' privacy function.

I really like the examples you provided here. It would be great if you could provide examples for the descriptions as well.

In 3.2.  Media-plane B2BUA Roles

   A Media-plane B2BUA is one that operates at both the SIP and media
   planes, not only on SIP messages but also SDP and potentially RTP/
   RTCP or other media.  Such a B2BUA may or may not replace the Contact
   URI, modify or remove all Via and Record-Route headers, modify the To
   and From header fields, etc.  No SIP header field is guaranteed to be
   copied from the received request on the UAS side to the generated
   request on the UAC side, and SDP will also be modified.

I'm confused about a taxonomy where categories are described by what they might or might not do ... 

Is "and SDP will also be modified" typically true, always true, or something else?

In 3.2.1.  Media-relay (and in other places as well)

   A B2BUA which performs a media-relay role is one that terminates the
   media plane at the IP and UDP/TCP layers on its UAS and UAC sides,
   but neither modifies nor restricts which forms of UDP or TCP payload
   are carried within the UDP or TCP packets.  Such a role may only
   support UDP or only TCP or both, as well as other transport types or
   not.  Such a role may involve policing the IP packets to fit within a
   bandwidth limit, or converting from IPv4 to IPV6 or vice-versa.  This
   is typically similar to a NAT behavior, except a NAT operating in
   both directions on both the source and destination information; it is
   often found as the default behavior in SBCs.

naming TCP, UDP, or both repeatedly might be clearer if you replaced references with a more general "transport". 

In 4.  Mapping SIP Device Types to B2BUA Roles, as you point out, these are marketing category terms without strict definitions. Given that I could build a device and call it by any of these names, how helpful is this section (and its subsections)?

- Section 5: I support Joel's dicusss - some of the very clear
security and privacy implications of the different roles should
be called out here. (And they're not all bad implications.) So
I hope he's not convinced he's in the rough.

- Section 3: a table just listing the type names with or without
a one-line description and a pointer to the section where
they're defined migth be useful for the reader.

- 3.1: Why would a b2bua like this save SDP bodies? Wouldn't
that have some privacy implications?

- 3.2.1: A reference for "NAT behaviour" might be a good
addition.

- 4.6 & 4.7: lots of unexpanded acronyms, which seems like a bad
plan for a taxonomy document (even if they're IMS terms:-)

In 4.6 and 4.7, it would be helpful to expand the various CSCF acronyms, since it's not necessarily obvious to the reader what they stand for.

This is a really helpful document—thanks for writing it!