Re: [Dime] AD evaluation of draft-ietf-dime-load-06
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 12 January 2017 11:54 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 9EB9A1293DC for <dime@ietfa.amsl.com>; Thu, 12 Jan 2017 03:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 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.199, 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 3ybLlZ7ESxiH for <dime@ietfa.amsl.com>; Thu, 12 Jan 2017 03:54:12 -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 34A361279EB for <dime@ietf.org>; Thu, 12 Jan 2017 03:54:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DA5DBE4C; Thu, 12 Jan 2017 11:54:08 +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 lQzm5E2Ntzbm; Thu, 12 Jan 2017 11:54:04 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D987BE49; Thu, 12 Jan 2017 11:54:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484222044; bh=D4KHV1tmLPLHuqiSyit1eQxpAtd6BIPIEJcyifnFC4M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h5qKc3Sn5GO7I0+miR3yHNfbJ7jQUjL2lSRIlZwSJnd0UIKEU5SNYqQUwPVcUVcq+ DEFckX/pZwTHI7PBGZTT4I090iT1i9J4DVa3QOmYaffaC07pK3LdvF4frlZTxEH/fT Y1pl9PV/1R4hmGjFZoGq5tNO6EG1hvFj907RgU20=
To: Steve Donovan <srdonovan@usdonovans.com>, dime@ietf.org
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <86f38e04-292f-2463-95ac-a25bad4a51e6@cs.tcd.ie>
Date: Thu, 12 Jan 2017 11:54:02 +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: <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070803010904000501060303"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/AFMqhqwXRCV8756VWOAuLP4GD7M>
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: Thu, 12 Jan 2017 11:54:14 -0000
Hiya, Just one thing below I'd like to figure out before IETF LC... On 09/01/17 22:28, Steve Donovan wrote: > Stephen, > > Thanks for the review and for the ping. Comments below. > > Regards, > > Steve > > On 1/6/17 10:33 AM, Stephen Farrell wrote: >> 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. > SRD> Server selection is touched on in RFC7638 (DOIC) and the concept > carries over to Load. It refers to selection of the specific server > instance that will be handling the request. This is according to the > Diameter Client, Server model. I think it is well understood what is > meant by those who understand Diameter and would be implementing this > spec. We can, if needed, add some definition. That would have been best > do be in the DOIC RFC but it can go here if needed. Ok, let's handle that as an IETF LC comment. If others think a definition would be good you can add it later. If it's just me, don't bother. >>> >>> (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.) > SRD> There is no formal mechanism in place in Diameter to do "topology > hiding". There are many other places where topology information can > leak, so it isn't an issue specific to Load. It is addressed today > through proprietary implementations. Sure, that's not a good reason to make it harder though. But see below... > > SRD> Having a node that does not support would go against the Diameter > extensibility strategy. Nodes that don't understand an AVP are required > to pass it on. Nodes that do support the mechanism and see a Load > report of type peer that isn't of type peer are supposed to remove it. I don't understand what " a Load report of type peer that isn't of type peer" can mean. > Doing anything other than this would require a change to the base > Diameter specification. Either I'm mis-remembering the draft or we're talking at cross purposes. My reading was that nodes that do support the mechanism could delete a peer report that actually comes via a node that does not support the mechanism. Am I wrong? If so maybe there's a clarity issue. If not, I don't see why that makes sense. Cheers, S. PS: The rest below is fine to handle later as you suggest. >>> >>> (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. > SRD> I'll go back and review that discussion and see if there is > something that needs to be added. I'm hoping that the fact that we made > it through the discussion with DRMP will make it easier to do so with > Load (and maybe agent overload). I'm doubtful that we can fully > inoculate the draft from some of this level of discussion as we are > dealing with Diameter here. >>> >>> nits (fine to be considered last call comments): >>> ------------------------------------------------- > SRD> I'll deal with these as part of last call. >>> >>> 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 mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > 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