Re: [Dime] AD evaluation of draft-ietf-dime-load-06
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 06 January 2017 16:33 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 B47AC1294C1 for <dime@ietfa.amsl.com>; Fri, 6 Jan 2017 08:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level:
X-Spam-Status: No, score=-7.401 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=-3.1, 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 uzobq981kVoh for <dime@ietfa.amsl.com>; Fri, 6 Jan 2017 08:33:25 -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 195C7129411 for <dime@ietf.org>; Fri, 6 Jan 2017 08:33:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6567BE51 for <dime@ietf.org>; Fri, 6 Jan 2017 16:33:22 +0000 (GMT)
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 Tu1OaoTdbhHs for <dime@ietf.org>; Fri, 6 Jan 2017 16:33:22 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AA78BE3E for <dime@ietf.org>; Fri, 6 Jan 2017 16:33:22 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483720402; bh=y38HZDumP0ZHr+uNozZKC6qRIOYBG3bboWwyQTr13v0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QUiH9zgHzCwFVvZkO5U9TNjt8a//8rquXb+DDmPiHTIvPwHqK04w3IxxnWGooeH7u QMEXehvTYiYFhuYrZV3JDpAdiX5ac85O/b30ePwxeCLIORG+lCbf84QCDskHHrkM2O OZ6SIWHysECPFHO4zp1zqgnFr2BsayAyaCW7x5lU=
To: "dime@ietf.org" <dime@ietf.org>
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie>
Date: Fri, 06 Jan 2017 16:33:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030608050004000004090204"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/iQlhaSK9drfOVNRku5NraYst2Lk>
Subject: Re: [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, 06 Jan 2017 16:33:27 -0000
Just bumping this, post holidays. I believe the ball is not in my court for this one:-) Cheers, S. On 16/12/16 17:38, Stephen Farrell wrote: > > 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.) > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >
- [Dime] AD evaluation of draft-ietf-dime-load-06 Stephen Farrell
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Stephen Farrell
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Stephen Farrell
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Misha Zaytsev
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Misha Zaytsev
- Re: [Dime] AD evaluation of draft-ietf-dime-load-… Steve Donovan