Draft: draft-sinnreich-sip-tools-03
Reviewer: Paul Kyzivat
Review Date: 13 October 2008
Review Deadline: 16 October 2008
Status: Expert Review

Review Summary:

I'll start by saying that the concept behind this draft is attractive:
that a relatively small number sip RFCs are sufficient to provide a rich and functional communications environment.

However, I remain unconvinced by the document as written. While I'm not convinced that the document is wrong about the sufficiency of this set of tools, I don't find enough meat in the document to convince me it is right.

Following are more detailed comments.

Sufficiency of these Tools:

For the document to convince me of its utility, it needs to provide an existence proof that a "sufficient" set of basic features/services can be constructed using this small set of "tools". There are three parts to
that:
- enumerate a set of basic features/services
- make a case that they are "sufficient"
- show that they can be constructed using this small set of tools.

The document does make a start at this. Section 3 says:

    SIP applications in the endpoints can however accomplish most
    telephony functions as well. This has been well documented in SIP
    related work in the IETF, such as:

   o "A Call Control and Multi-party usage framework for SIP" [13] ...
   o "SIP Service Examples" [14] ...

The two referenced documents do enumerate a set of features/services.
They also illustrate how to realize those using sip. But they do not make a case that this set of services is either necessary or sufficient for any particular environment. And not all of them can be accomplished with the nine standards selected in this document. I didn't do an exhaustive study, but among the additional standards needed to accomplish all of those services are:

- RFC3857 (watcherinfo)
   (Referenced from RFC3856}

- RFC3515 (REFER), RFC3891 (Replaces)
   (referenced from service-examples [14],
    used for MoH, transfer, park, click to dial)

- RFC4235 (Dialog evt pkg)
   (referenced from service-examples,
    only used (I think) for rendering tag!)

- RFC4579 (CC)
   (referenced from service-examples,
    only for description of use of isfocus tag!)

- 3911 (Join)
   (referenced from draft-ietf-sipping-cc-framework-10 [13])

- draft-ietf-sip-answermode-07
   (referenced from draft-ietf-sipping-cc-framework-10.)

I can't decide which conclusion to draw from this:
- the list of required RFCs accidentally omitted these.
- the services that use these aren't considered essential
- the services that use these can be done some other
   way (unspecified) that doesn't require these.

I suspect that all of my concerns above could be resolved by adding some additional text to the document and possibly by adding a few additional required documents to the existing set of nine.

Security Concerns:

For security, this draft has called for the use of sips URIs and TLS for sip signaling security, but with only 3261 for the definition of SIPS.

I believe there is a problem here because the use of the sips URI to provide signaling security is underspecified in RFC 3261. There is work in progress to improve on this situation: draft-ietf-sip-sips-08.
Without that there does not seem to be a good security solution here.

For identity, RFC 4474 is specified. However RFC 4474 requires an Authentication Service. This draft seems to eschue the use of external servers. The alternative seems to be for the UAC to act as its own authentication service, which is allowed by RFC 4474. However that requires that the UAC be able to obtain its own certificate, which in turn requires it to have its own domain name. These may be hurdles that are too high for many UAs to surmount. If this is intended as a prerequisite for the use of this tool set then it would be good to spell that out in detail.

Possible Overlap with Current or Planned Chartered Work:

I'm not sure if this is a valid concern for this kind of document, but its worth considering. At the moment I don't think so. If there were a conflict, I think it would most likely be with the Bliss WG, or perhaps the Hitchhiker's Guide.

The Hitchhiker's Guide intends to point out documents of relevance to sip implementors, but it is much more expansive. I expect one of the motivations for this document is the daunting extent of the list presented in the Hitchhiker's Guide. So, if the intent of this document can be realized it won't conflict with the Hitchhiker's Guide.

Since this document currently only references other sipping documents for examples of  feature definition, I don't think a conflict with Bliss will occur unless Bliss does something in conflict with those examples.
This is perhaps best sorted out after this document gets more specific.
But for now I'm not concerned.