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

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Dec 2016 17:38:26 +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.)