[RAI] Expert review of draft-sinnreich-sip-tools-03

[Paul Kyzivat <[e-mail]>]

Draft: draft-sinnreich-sip-tools-03
Reviewer: Paul Kyzivat
Review Date:
Review Deadline:
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.

	Thanks,
	Paul Kyzivat


_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai