Re: [dispatch] draft-winterbottom-dispatch-locparam

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 10 August 2015 13:22 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A321B3553 for <dispatch@ietfa.amsl.com>; Mon, 10 Aug 2015 06:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqNJzmmho1Dl for <dispatch@ietfa.amsl.com>; Mon, 10 Aug 2015 06:22:41 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5BB1B3551 for <dispatch@ietf.org>; Mon, 10 Aug 2015 06:22:41 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id 31Mj1r0072Udklx011Ngbg; Mon, 10 Aug 2015 13:22:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id 31Ng1r00A3Ge9ey011NgG8; Mon, 10 Aug 2015 13:22:40 +0000
Message-ID: <55C8A59F.5060809@alum.mit.edu>
Date: Mon, 10 Aug 2015 09:22:39 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <E04B87E7-9B63-40BF-BAFF-E3BFEA7A692C@gmail.com>
In-Reply-To: <E04B87E7-9B63-40BF-BAFF-E3BFEA7A692C@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1439212960; bh=ZnIUl8lxZU/wA1FTIfuDrZ7L6+Qf3k/Jv7LpyqotFUo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uolJ4X5F7bLDa3o+zfFQe93PuUm4jEgt5EtrWQi8DQdGNPcz0bASspRrIk+j8V96R MDRINxIZTmRIx0wgaFjaiYTko63HvEqNa6lXo12OGpKf3ghD2otg00pkccFOK51006 YxFVwHqD9PEN+CX/nlKU9Vm9NaualnR4LRq04wNV/pg1Ps6xRdCJZKZ5DDi7BkYIqU DyMEKON5I8WI7X9xoRWN+c408Rq7p4a7g1EpSa9mNtnQ65DYAsNQsda1wW4ejUwkOD FcZtwjc/y4UCamc5M9S7rvaStAaP5ovyMtO9aQRjAuBSllB4SuYAdMwP+/OBqrhu0F uh3zphwr3Cq0g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/nta53E1LvKEV3SAndADcqcqk1W8>
Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 13:22:42 -0000

On 8/9/15 4:41 AM, James Winterbottom wrote:
> Hi All,
>
> I have gone through the note of the dispatch meeting for this draft as
> well as relying only my memory for what was discussed and I am at a bit
> of a loss as to how to update this draft in a way so that it can proceed.
>
> I totally agree with Keith’s assessment about the relevancy of the
> privacy issue raised by Cullen.
>
> Keith is right, in that the current primary intended use is not “inside”
> and IMS network, though I believe that the nodes employing this
> mechanism will have strong relationships with IMS nodes, most likely an
> E-CSCF or something resembling one.
>
> Paul is also right. While IMS is not the chief customer, it is likely to
> be one of the downstream recipients and as such it does rely on strong
> trust relationships. So to this end a tie to RFC3325 is probably warranted.
>
> Would it be reasonable then to:
>
>  1. Add a tie in to RFC3325 with regards to trust

This would make me happy. Without an explanation of the expectations of 
the trust relationship the contents of this header field are meaningless.

	Thanks,
	Paul

>  2. Explicitly say that the loc-src needs to be a fully qualified host
>     name and that IP address must not be used?
>
>
> These seem to be be the two main points I took away. If this were done
> could we do a list-based dispatch for this draft?
>
> Cheers
> James
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>