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

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>