Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06

Ben Campbell <ben@nostrum.com> Wed, 12 October 2011 21:27 UTC

Return-Path: <ben@nostrum.com>
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 8E30F21F8B71; Wed, 12 Oct 2011 14:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.447
X-Spam-Level:
X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, 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 0JAc1+M038JY; Wed, 12 Oct 2011 14:27:56 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 030D221F8BEC; Wed, 12 Oct 2011 14:27:55 -0700 (PDT)
Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9CLRs0r068717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2011 16:27:55 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06
Date: Wed, 12 Oct 2011 16:27:53 -0500
Message-Id: <24518BC2-479A-4413-B69B-7DC5589751DC@nostrum.com>
To: draft-ietf-cuss-sip-uui-reqs.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 13 Oct 2011 08:07:02 -0700
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@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: Wed, 12 Oct 2011 21:27:56 -0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-cuss-sip-uui-reqs-06
Reviewer: Ben Campbell
Review Date: 2011-10-12
IETF LC End Date: 2011-10-13

Summary: This draft is almost ready for publication as an informational RFC. I have a few minor questions and comments that may be worth addressing first.

Major issues:

None

Minor issues:

-- section 1, 2nd paragraph, last sentence: "In particular, this mechanism creates no requirements on intermediaries such as proxies."

What about SBCs, B2BUAs, etc?

-- REQ-4: "… any other form of redirection of the request."

"Any other form" seems a pretty strong statement. What about a b2bua doing weird stuff?

-- REQ-8: "If the UAS does not understand the UUI mechanism, the request will fail."

Based on the routing requirement, shouldn't that say that if the request cannot be routed to a UAS that understands the UUI mechanism, the request will fail?

-- REQ-12: 

What degree of certainty is required here? (i.e. strong identity?) If implied by the SIP dialog, does that impact expectations on what sort of authn must happen at the SIP layer?

-- REQ 13:

I'm not sure I understand how this interacts with the ability for intermediaries to remove UUI. Should this be detectable by the endpoints? Or is that ability limited to the hop-by-hop case, or require no integrity protection?

Nits/editorial comments:

-- section 4, 2nd paragraph: "The UUI mechanisim should support both of these approaches"

Should that be a numbered requirement? You've got requirements to support e2e and hop-by-hop, but no requirement that mentions SIP layer vs application layer.