Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt

Ted Hardie <> Tue, 11 January 2011 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E99B3A6A75; Tue, 11 Jan 2011 09:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.193
X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TyLuffr9oiOz; Tue, 11 Jan 2011 09:52:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 74CE828C2C3; Tue, 11 Jan 2011 09:52:39 -0800 (PST)
Received: by qyk34 with SMTP id 34so2961959qyk.10 for <multiple recipients>; Tue, 11 Jan 2011 09:54:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpeASiYId5ByZX1vx64VkXB+jbDVhaUmHjLJYX6EkWM=; b=phYbpm2M+auVbj3Gu0Zv//eFncayOi/g2ipfMhph0B66YntwaFX9/gt3nTLoVnoYlk x1dF6ICO415rK4TZPUE5T1I396o5SeXYk2cIzpyBF4CuSGSdtFuWAwz1o6rD74PJy3zb Yi+LSId+aDw0naUiTppu0J/H8FFNCKeTqBk8s=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O58+z1Zok17I0Y+KW9MFHZSlwsR4w3v4Ou48HYI3xgFmTb6PCZypkc4Ok2qJWsxkzJ R5oBO88w0iEkOJZCO3WCMxhjAh99Uu/B+s92xIS+9TznPbfP5OEjKnBeZGq7o1GQdair IOWyNyCsFcgsf0WXM1xl+oXs49yapuFYL1IKI=
MIME-Version: 1.0
Received: by with SMTP id h4mr26697609qcn.41.1294768496366; Tue, 11 Jan 2011 09:54:56 -0800 (PST)
Received: by with HTTP; Tue, 11 Jan 2011 09:54:56 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 11 Jan 2011 09:54:56 -0800
Message-ID: <>
From: Ted Hardie <>
To: Adam Roach <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Bernard Aboba <>, Spencer Dawkins <>, Apps Discuss <>, IESG <>
Subject: Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jan 2011 17:52:40 -0000

Hi Adam,

Thanks for the response; some discussion in-line.

On Mon, Jan 10, 2011 at 4:45 PM, Adam Roach <> wrote:
> Ted:
> Thank you for your detailed review. I have applied your comments to version
> -11 of the document (now available in the repository), except as noted
> below.
> On 11/30/10 4:11 PM, Ted Hardie wrote:
>> Section 7.4 contains two elements which it may be appropriate to consider
>> for inclusion in the Security Considerations.  The first of these is that
>> proxies will not be able to apply policy decisions on as granular a basis
>> as
>> before:
>>    Proxies will be unable to make policy decisions on a
>>    contact-by-contact basis regarding whether to include themselves in
>>    the path.  Second, and similarly, all AORs on the SIP-PBX that are
>>    registered with a common REGISTER request will be forced to share a
>>    common Service-Route.
> I tried to reiterate this issue in the security section with the following
> paragraph:
>   As noted in Section 7.4, intermediaries need to take care if they use
>   a policy token in the Path and Service-Route mechanisms, as doing so
>   will cause them to apply the same policy to all users serviced by the
>   same SIP-PBX.  This may frequently be the correct behavior, but
>   circumstances can arise in which differentiation of user policy is
>   required.

The only difference I see is that the first calls out the Service-Route as
common separately from the application of policy, where the second treats the
application of a particular Service-Route as the application of a
particular policy.
You might choose to call it out separately again, but if you have considered it
and feel the text is fine as it stands, I'm happy with that result.

> This text was in the version you reviewed. Do you think it needs to be
> amended in some way to capture the issue you highlight above, or does this
> text address your concern?
>> Would this extend to proxies including themselves for the purposes of
>> CALEA?  If so, this might be a privacy issue.
> Proxies can't use Path to insert themselves for LI purposes, as doing so
> would be inherently visible to user agents (which could potentially alert
> users to the condition). In my experience, LI in SIP is performed via
> mechanisms that are unrelated to any of the mechanisms described in this
> document.

Thanks for clarifying that this method would not be used for that purpose;
that resolves my concern here.



> /a