[Dime] AD evaluation of draft-ietf-dime-load-06

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 16 December 2016 17:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2AE1293FD for <dime@ietfa.amsl.com>; Fri, 16 Dec 2016 09:38:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.197
X-Spam-Level:
X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Zt0GcWyeH-0N for <dime@ietfa.amsl.com>; Fri, 16 Dec 2016 09:38:32 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAC51279EB for <dime@ietf.org>; Fri, 16 Dec 2016 09:38:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DCECFBE4D for <dime@ietf.org>; Fri, 16 Dec 2016 17:38:27 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrTO5ojHobbL for <dime@ietf.org>; Fri, 16 Dec 2016 17:38:26 +0000 (GMT)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FFABBE3E for <dime@ietf.org>; Fri, 16 Dec 2016 17:38:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1481909906; bh=+h454cyGXAwWlYHz7+cLEvikxgCeFvxJ7Wc1u23ouNA=; h=To:From:Subject:Date:From; b=IzVtHQmKW9B49+NRACv2BgXZYmht5qyR0/2Jbt+HvKTPSgl1dVMG2qNuPgo2LQIx9 kIdUcG8pZs7I+s5NOH4Qlb4EgI22Nz4zdHhVk40Frm4R2QTHTXnlhzz30QW8KLHqvk 1Ph1itkasHL96czuySHpC2QOVmgcz6shIyoJJnWs=
To: "dime@ietf.org" <dime@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie>
Date: Fri, 16 Dec 2016 17:38:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090008090709030309070306"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/5vAc97Xviig6R-6PW8uvgivh06I>
Subject: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 17:38:35 -0000

Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

nits (fine to be considered last call comments):
-------------------------------------------------

abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)