[dispatch] draft-winterbottom-dispatch-locparam

James Winterbottom <a.james.winterbottom@gmail.com> Sun, 09 August 2015 08:41 UTC

Return-Path: <a.james.winterbottom@gmail.com>
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 932A41ACE5B for <dispatch@ietfa.amsl.com>; Sun, 9 Aug 2015 01:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 1YmIC3RIPJkb for <dispatch@ietfa.amsl.com>; Sun, 9 Aug 2015 01:41:52 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2041ACE5A for <dispatch@ietf.org>; Sun, 9 Aug 2015 01:41:52 -0700 (PDT)
Received: by pabyb7 with SMTP id yb7so84905353pab.0 for <dispatch@ietf.org>; Sun, 09 Aug 2015 01:41:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=dVnfbrH9QGZxEbZ4XkUJqe99PKyQuUSqdfWD3FF9IoA=; b=f7PqrQM71QpWupuhjG2rZ+SIfTwRQobyEpo60LanoFSI5JMDndEU1AHihuT/3uNQzM 4qfzkpS61e7gCcrCEGcrc74gfyESixq+rA8Go5jdB0r7RXymM+rCsBXkBx1RkknkjuXK GL7DHCptAvi4pJ2NDHaZDXeD6nEo7aB3wERchEsXAoHaxgZ2TFD3fbWQxLAZ/S4IWtbz LfVluLPOHLlpcRD4JS5KWqWq5WdVzhFXYugfI2lNtI7H07PeHokfHV+KGToWzZwgpvDG emk28VXYSfMsGTwGF6urE+OXBznEmDj+6Ah73aj3fRywoG+eudKaAByk0BqXRleiKV4J R+Lw==
X-Received: by 10.68.136.234 with SMTP id qd10mr33477607pbb.162.1439109711828; Sun, 09 Aug 2015 01:41:51 -0700 (PDT)
Received: from [192.168.1.100] ([1.144.24.185]) by smtp.gmail.com with ESMTPSA id bc10sm15792932pbd.14.2015.08.09.01.41.50 for <dispatch@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Aug 2015 01:41:51 -0700 (PDT)
From: James Winterbottom <a.james.winterbottom@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F1D38186-5664-4256-BB4C-FB704067D936"
Message-Id: <E04B87E7-9B63-40BF-BAFF-E3BFEA7A692C@gmail.com>
Date: Sun, 09 Aug 2015 18:41:47 +1000
To: DISPATCH list <dispatch@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/iwWkaRMP6FkUZrSewEX2MUxlDqk>
Subject: [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: Sun, 09 Aug 2015 08:41:53 -0000

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:
Add a tie in to RFC3325 with regards to trust
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