Re: [Gen-art] Gen-ART LC review of draft-ietf-sipping-cc-transfer-10.txt

[Alan Johnston <[e-mail]>]

Brian,

Some suggested text below.

Thanks,
Alan

Brian E Carpenter wrote:
> Thanks Alan, there are clearly no show stoppers here,
> just a few points where you can consider clarifying the
> text.
>
>   
>> AJ>  No, the call flows are not normative - there are too many
>> variations to do this.
>>     
>
> I definitely suggest saying that in the text in a slightly more
> formal way.
>
>   
How about if we paraphrase text from RFC 3665 and RFC 3666 to say:

"  This document does not prescribe the flows precisely as they are
   shown, but rather the flows illustrate the principles for best
   practice for the transfer feature.  The call flows represent 
well-reviewed
   examples of SIP usage to implement transfer with REFER,
   which are best common practice according to IETF consensus."
>> AJ>  Are you concerned about being in a video session with one party
>> then suddenly being in a video session with another party? Or are you
>> concerned that an audio call could suddenly add video after a transfer
>> without getting the user's permission?  If the latter, this is an issue
>> that we should have dealt with in Replaces RFC 3891.
>>     
>
> The latter. It might be worth a small note in the Security section; I can
> see that it's a generic issue with Replaces, but it seems especially
> acute in the case of a transfer to a 3rd party, and the UA should at
> least warn the user. ("Smile, you're on TV" ;-)
>   

I agree - I say this about Replaces in the Security Considerations section:

   An INVITE containing a Replaces header field should only be accepted
   if it has been properly authenticated and authorized using standard
   SIP mechanisms, and the requestor is authorized to perform dialog
   replacement.  Special care is needed if the replaced dialog utilizes 
additional
   media streams compared to the original dialog.  In this case, the 
user MUST authorize the addition
   of new media streams in a dialog replacement.  For example, the same 
mechanism
   used to authorize the addition of a media stream in a re-INVITE could 
be used.


>    Brian
>
> On 2008-10-07 04:25, Alan Johnston wrote:
>   
>> Brian,
>>
>> Thanks for your review of the document.  See my answers and comments
>> below marked with AJ>
>>
>> Thanks,
>> Alan
>>
>>
>> Brian E Carpenter wrote:
>>     
>>>
>>>
>>>
>>>
>>>
>>>   
>>>       
>> 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.
>>
>> AJ> You are correct - when these requirements were written (about 5
>> years ago), this was common but perhaps it is not now.  I'm fine with
>> removing the RFC 2119 keywords.
>>
>>     
>>> 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?
>>
>> AJ> Yes - there are many approaches to achieve a call transfer with
>> SIP.  It can be done using 3PCC, re-INVITE, or a B2BUA.  However, only
>> the usage of REFER requires SIP extensions and conventions - hence this
>> document.
>>
>> I found no MUSTs, two SHOULDs,
>> one NOT RECOMMENDED, and one MAY. There are some lower case
>> "shoulds" - are they normative?
>> AJ> Here are the lower case shoulds and one lower case must:
>>
>> Section 5:
>>
>> "If the nature of
>>   the Contact URI is not known or if support for the target-dialog
>>   extension is not known, the REFER should be sent inside the existing
>>   dialog.  A Transferee must be prepared to receive a REFER either
>>   inside or outside a dialog. "
>>
>> Section 6:
>>
>> "The participants in a basic transfer should indicate support for the
>>   REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to
>>   INVITE, and OPTIONS messages.  Participants should also indicate
>>   support for Target-Dialog in the Supported header field."
>>
>> Section 7.3:
>>
>> "   The Contact URI of the Transfer Target SHOULD be used by the
>>   Transferor as the Refer-To URI, unless the URI is suspected or known
>>   to not be routable outside the dialog.  Otherwise, the Address of
>>   Record (AOR) of the Transfer Target should be used.  That is, the
>>   same URI that the Transferor used to establish the session with the
>>   Transfer Target should be used.  In case the triggered INVITE is
>>   routed to a different User Agent than the Transfer Target, the
>>   Require: replaces header field should be used in the triggered
>>   INVITE.  (This is to prevent an incorrect User Agent which does not
>>   support Replaces from ignoring the Replaces and answering the INVITE
>>   without a dialog match.)"
>>
>> AJ> I'm OK with making these shoulds normative and the one must.
>>
>> Are the call flows normative? If so,
>> I think this should be stated explicitly in section 5.
>>
>> AJ>  No, the call flows are not normative - there are too many
>> variations to do this.
>>
>> [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.
>>
>> AJ>  No, it is not the only way.  See Section 5:
>>
>> " One way that a Transferor could know
>>   that a Contact URI is routable outside a dialog is by validation
>>   (e.g. sending an OPTIONS and receiving a response) or if it satisfies
>>   the properties described in the GRUU specification
>>   [I-D.ietf-sip-gruu]."
>>
>> Also, note that this spec doesn't require the GRUU specification and
>> mechanism, but just GRUU properties in the Contact URI.  The working
>> group has discussed this a few times and each time agreed to not make
>> GRUU mandatory or normative to this document.
>>
>> ≠≠≠≠____________________________________________________________
>> 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?
>>
>> AJ> No, once either side has sent a BYE, the session is dead and there
>> is no way to perform a transfer.
>>
>>     
>>> 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?
>>
>> AJ>  Are you concerned about being in a video session with one party
>> then suddenly being in a video session with another party? Or are you
>> concerned that an audio call could suddenly add video after a transfer
>> without getting the user's permission?  If the latter, this is an issue
>> that we should have dealt with in Replaces RFC 3891.  RFC 3891 tends to
>> assume that the same media types are in both the replaced and replacing
>> sessions.  It does talk about rejecting the INVITE if the replacing
>> media type is incompatible, but this doesn't cover a case of adding a
>> new media type.  The solution to this would be for the recipient of the
>> INVITE with Replaces alert the user of any new media types before
>> accepting them, or only accept the same media types as the replaced
>> session and declining any new media types.  The new media types could
>> then be explicitly turned on by either party using a re-INVITE which
>> would trigger normal authorization policies and procedures.
>>
>>
>>
>> ≠≠≠≠____________________________________________________________
>> 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/
>>
>>
>>
>>     
>
>
>
>   

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art