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

[Brian E Carpenter <[e-mail]>]

OK, this looks good to me.

Thanks

   Brian

On 2008-10-08 03:42, Alan Johnston wrote:
> 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