Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

[Steve Donovan <[e-mail]>]

Comments inline...

Steve

On 5/10/16 11:49 AM, Ben Campbell wrote:
> I'm going to clear the discuss at this point--I wanted discussion to 
> happen and it is happening. More inline:
>
> On 10 May 2016, at 9:38, Steve Donovan wrote:
>
>> See inline.
>>
>> On 5/6/16 3:45 PM, Ben Campbell wrote:
>>> On 6 May 2016, at 14:48, Steve Donovan wrote:
>>>
>>>
>
> [...]
>
>>>>>
>>>>> The potential "priority scheme" might help here. But why does a 
>>>>> trusted environment matter? Lets say you have trusted clients from 
>>>>> vender A and from vendor B, but they select priorities differently?
>>>> SRD> They aren't trusted if they aren't using the defined standards.
>>>
>>> What standard? The application specification? (See my question in 
>>> Alissa's thread about whether DRMP can be applied to legacy 
>>> applications that don't (yet) define it's use.)
>> SRD> I mean application specification or operator policy. DRMP can 
>> apply to legacy applications in two ways.  First, the default 
>> priority applies if no priority is explicitly included in the 
>> message.  Second, operators can define their own priority scheme.
>
> Okay. That seems to imply a need for configurability, but I'll leave 
> it to you whether that should be a standard requirement, or a market 
> requirement.
SRD> I don't see the need to make configurability a standards level 
requirement.
>
>>>
>>>> In addition, trusted environment generally means operated by a 
>>>> single entity.  That operator has the job of ensuring that what you 
>>>> are proposing would not happen.
>>>
>>> I can accept if that is the case, but it's not a very satisfying 
>>> answer. It leads to having profiles for each operator. (I realize 
>>> that the primary users of Diameter have always had operator-specific 
>>> profiles of standards, so maybe there's nothing to do here.) This 
>>> might at least imply a requirement that priority definitions need to 
>>> be configurable.
>> SRD> I don't see that it means a profile per operator.  3GPP is 
>> likely to create a profile that spans all of its applications and 
>> could be used by all operators following the 3GPP standards.
>
> Sure, but it still _might_ require per-operator profiles, right? Even 
> 3GPP networks tend to have operator specific "flavors" of protocols.
SRD> Per operator profiles can exist.  This mechanism certainly doesn't 
mandate them.
>
> But I recognize this is not unusual for most (if not all) of the 
> environments that Diameter is used in.
>
> [...]
>
>>> So this may be down to a nit--but the text as written says that the 
>>> receiver of a _request_ "SHOULD" use the included priority, but the 
>>> receiver of a response "MUST" use the priority. Now, maybe these are 
>>> just different ways of encoding the idea that the node may not 
>>> implement DRMP. But the former seems to allow the node to override 
>>> the priority in the message if it has good reason, but the latter 
>>> does not allow the same for a response.
>>>
>>> As I mention in the discussion about my last discuss point, it seems 
>>> odd that a client cannot choose it's own idea of priority over the 
>>> servers if it thinks it has a good reason.
>> SRD> Thanks for bearing with me on this one.  I see your point now 
>> and agree it should be reworded to include allowing for local policy 
>> to override what is carried in the message.
>>>
> Thanks--I realize my first round of comments obscured the point a bit :-)