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: ietf@ietfa.amsl.com
Delivered-To: ietf@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
Subject: TSVDIR review for draft-ietf-cuss-sip-uui-reqs
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
Cc: TSV Dir <tsv-dir@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-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