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

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

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.

> 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" ;-)

   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