Re: [Gen-art] Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06

Alan Johnston <> Thu, 27 October 2011 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A82021F8C10; Thu, 27 Oct 2011 08:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.372
X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uusjsE3vVMhU; Thu, 27 Oct 2011 08:53:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A7F621F8C0B; Thu, 27 Oct 2011 08:53:32 -0700 (PDT)
Received: by qadc10 with SMTP id c10so3438044qad.31 for <multiple recipients>; Thu, 27 Oct 2011 08:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=t4AHj/L25dyYWwlGc75S7lsMt7cqP1A6wDrfPEoSKWY=; b=dQVQjF50SxpZn8ePUlC30SuRprQ75HD8wKsCgcdqCYzv0GOPWklTFp0uUq55ikBiDB F9Jc03IJ9hw+UaUoVJ5wgWLa/HaEnHQRSrqyzw4ArzCQNgbi3q4nvgN6dWP7KmwqQguN MXrgDL5NtNIdTIxerRbCEuuSBLYTz1cl87mSQ=
Received: by with SMTP id i2mr30439092qac.58.1319730810806; Thu, 27 Oct 2011 08:53:30 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id v6sm8742588qaz.7.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 08:53:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Alan Johnston <>
In-Reply-To: <>
Date: Thu, 27 Oct 2011 10:53:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Campbell <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Thu, 27 Oct 2011 08:56:29 -0700
Cc: " Review Team" <>, "" <>,
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2011 15:53:38 -0000


Thanks for your review of the draft.  See my comments below.  I have also revised the draft as draft-ietf-cuss-sip-uui-reqs-07 which I  believe addresses all the issues.

- Alan -

On Oct 12, 2011, at 4:27 PM, Ben Campbell wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.
> 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?

There are no requirements on them either - we'll add text saying that.

> -- 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?

Sure, no protocol mechanism can prevent a B2BUA from doing something.  We will clarify to just say redirection, since that operation is well defined in RFC 3261.

> -- 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?

Yes, this is clearer.

> -- 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?

This is not meant to imply strong identity.  And since UUI data can appear in a response, there aren't really any strong methods available with SIP.   The UUI mechanism does not introduce stronger authorization requirements for SIP, but instead the mechanism needs to be able to utilize existing SIP approaches.

> -- 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?

Yes, there are tradeoffs between this requirement and requirement REQ-9.  Hop-by-hop protection is one way to resolve this interaction.

> 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.

Actually, this sentence is misplaced.  There isn't really a requirement to support both of these.  I'll remove it to avoid confusion.