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

[Steve Donovan <[e-mail]>]

Misha,

I've added the DIME WG mailing list.

See my comments inline.

Regars,

Steve

On 1/11/17 12:03 PM, Misha Zaytsev wrote:
> Hi Steve,
>
> I'm a newcomer in DiME working group - so, may not be familiar with 
> all rules.
> So, excuse me in advance if it is not a good manner to comment the 
> ongoing draft review.
SRD> Welcome to the working group!
>
> But let me still put my 5 cents here.
>
> Regarding this question from Stephen:
>
> - 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?
>
> Why can't we re-phrase the related statement in the following way?
>
> This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>
SRD> This actually doesn't work for the peer report case.  The 
Origin-Host AVP is inserted by the Diameter client and it remains the 
same as the request passes through Diameter agents.  For peer reports, 
it is necessary to know the peer that sent the request, not the client.  
Thus the need to look at the DiameterID associated with the Diameter 
connection.

> Also if it does not bother you, could you explain what is the official 
> way to comment DiME drafts?
SRD> The official way is to do exactly what you are doing, but by 
sending the questions and comments to the DIME WG mailing list.
>
> Thanks a lot in advance!
>
> /Misha
>
>
>
> 2017-01-10 1:28 GMT+03:00 Steve Donovan <[e-mail] 
> <mailto:[e-mail]>>:
>
>     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.
>>>     (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. 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.  Doing anything other than this would
>     require a change to the base Diameter specification.
>>>     (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
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/dime
>>>     <https://www.ietf.org/mailman/listinfo/dime>
>>>
>>     _______________________________________________
>>     DiME mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/dime
>>     <https://www.ietf.org/mailman/listinfo/dime>
>     _______________________________________________ DiME mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dime
>     <https://www.ietf.org/mailman/listinfo/dime> 
>