I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sipping-cc-transfer-10.txt
Reviewer: Brian Carpenter
Review Date: 2008-10-06
IETF LC End Date: 2008-10-10
IESG Telechat date: (if known)

Summary: Almost ready

Comments: 

This looks almost ready but I have some  questions for clarification.
I have not reviewed the call flows and examples in detail.

> 4.  Requirements

I'm not sure why the RFC2119 upper case keywords are used in
this section; it isn't specifying either a protocol or operational
practices.

> 5.  Using REFER to achieve Call Transfer
>
>    A REFER [RFC3515] can be issued by the Transferor to cause the
>    Transferee to issue an INVITE to the Transfer-Target.  

Conversely, I found it hard in sections 5 through 11 to figure out
what was normative and what was illustrative. Does that "can be"
imply that there may be another method? I found no MUSTs, two SHOULDs,
one NOT RECOMMENDED, and one MAY. There are some lower case
"shoulds" - are they normative?  Are the call flows normative? If so,
I think this should be stated explicitly in section 5.

[I-D.ietf-sip-gruu] seems to me to be a normative reference.
It's the only mechanism offered to solve the problem of knowing whether
a "Contact URI is routable outside a dialog" and it's used in 6.1
and 7.3 and listed as "supported" throughout the examples.

ญญญญ____________________________________________________________
Minor questions:

> 4.  Requirements
>
>    1.  Any party in a SIP session MUST be able to transfer any other
>        party in that session at any point in that session.

Does "at any point" include session establishment and teardown?

> 5.  Using REFER to achieve Call Transfer
...
>        The media negotiated between the transferee and the
>    transfer target is not affected by the media that had been negotiated
>    between the transferor and the transferee.

I have a small concern about privacy issues there. For example, could the 
Transfer-Target find itself in a video session after a transfer, both
unexpectedly and unintentionally from the user's point of view?

ญญญญ____________________________________________________________
Typo at the end of section 11.1:

(This might easily be missed in editing.)

>           If the
>    gateway supports more than one truck group, 

s/truck/trunk/