[cuss] TSVDIR review for draft-ietf-cuss-sip-uui-reqs

Joe Touch <touch@isi.edu> Fri, 04 November 2011 20:42 UTC

Return-Path: <touch@isi.edu>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D01C11E8088; Fri, 4 Nov 2011 13:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.219
X-Spam-Level:
X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9zCsiK--cFU; Fri, 4 Nov 2011 13:42:43 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5211E8082; Fri, 4 Nov 2011 13:42:37 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pA4KgJio022502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Nov 2011 13:42:19 -0700 (PDT)
Message-ID: <4EB44E2B.6090608@isi.edu>
Date: Fri, 04 Nov 2011 13:42:19 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "draft-ietf-cuss-sip-uui-reqs@tools.ietf.org" <draft-ietf-cuss-sip-uui-reqs@tools.ietf.org>, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, IETF discussion list <ietf@ietf.org>, CUSS@IETF.ORG
References: <C304DB494AC0C04C87C6A6E2FF5603DB5ABFF83236@NDJSSCC01.ndc.nasa.gov> <4E9ED4F2.7030302@isi.edu>
In-Reply-To: <4E9ED4F2.7030302@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Mailman-Approved-At: Fri, 04 Nov 2011 13:43:55 -0700
Cc: TSV Dir <tsv-dir@ietf.org>
Subject: [cuss] TSVDIR review for draft-ietf-cuss-sip-uui-reqs
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 20:42:44 -0000

Hi, all,

I've reviewed this document as part of the transport area directorate's 
ongoing effort to review key IETF documents. These comments were written 
primarily for the transport area directors, but are copied to the 
document's authors for their information and to allow them to address 
any issues raised. The authors should consider this review together with 
any other last-call comments they receive. Please always CC 
tsv-dir@ietf.org if you reply to or forward this review.

We appreciate that this doc went through last call Oct 13; this request 
was received after that event.

This document describes the issues in exchanging user-to-user call 
control information in SIP.

There are no transport protocol issues in this document.

The document does use the term "transport" frequently, most often as a 
verb meaning "exchange". I would encourage the authors to consider 
changing those uses to avoid confusion with "transport" as related to 
Layer 4 protocols.

The one exception is the Overview (Sec 1) sentence, where the term 
"transport" is used. Here I would encourage the authors to use the term 
"session":

   ..."Providing informatoin and
   understanding of the UUI to the transport layer (SIP in this case)
   ...

There are two additional issues:

- the term "screen pop" in Sec 2.1 is unclear (do you mean "popup"?)

- Sec 2.2 (Proxy Retargeting) talks about URI changes
	it's not clear whether the addresses referred to here
	are Transport Layer (e.g., IP addresses), or other
	addresses
If these are transport layer addresses, there may be interactions with 
NATs and/or transport protocols that should be addressed. This section 
would benefit from a specific example as well.

I would be glad to discuss these issues further if useful.

Joe