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

["Ben Campbell" <[e-mail]>]

I'm jumping in here because part of it also relates to some of my 
DISCUSS points:

On 6 May 2016, at 11:03, Steve Donovan wrote:

> All,
>
> I was on jury duty yesterday so I wasn't able to fully engage.
>
> I agree that we are close to resolving issues and I will produce an 
> updated draft that addresses IESG review comments, along with one 
> change requested by IANA.
>
> I also need to respond to Ben's last email.
>
> My proposal, modulo Ben's comments, is to add the following to the 
> draft:
>
> - Emphasizing that the mechanism only works when one of the following 
> is true:
>
>   - Agents only handle a single DRMP application.

What does that mean from a standards perspective? A "relay agent" is 
assumed to be application-agnostic. So in some ways, it supports all 
applications. Even ones that don't exist yet. A proxy, OTOH, is assumed 
to know application semantics--but I don't think that is what we are 
talking about, is it?

Or do this just mean that the operator makes sure that messages from 
only one application traverse the agent? (There's risk that they will 
forget that part when adding a 2nd application down the road.)  (But see 
next comment...)

>   - All Diameter applications that support DRMP used in a Diameter 
> network must have consistent and synchronized priority definitions. 
> I'll add some words around what is meant by consistent and 
> synchronized.

Those would help, but I don't think handling a single DRMP application 
necessarily removes the need for consistent priority definitions.

As with DOIC, you may see cases where vendors and or operators wish to 
apply DRMP to applications even though the specifications for that 
application do not define its use. (or perhaps before the owners of the 
standard for legacy applications get around to doing so.) I'm not sure 
if the intent is to allow that, but if it is, then you need consistent 
policies across nodes.

If the expectation is that DRMP can only be used when documented in the 
"standard" for the application, then it would be good to include some 
high-level detail about what we expect to be documented.

>
> - Strengthening wording indicating that this mechanism is designed to 
> work in trusted environments.  This includes recommending stripping or 
> modifying priority settings for requests received from untrusted 
> sources.  The determination of what is a trusted and untrusted source 
> would be out of the scope of the DRMP draft.
>
> - Adding the other updates that have been agreed to as part of this 
> review cycle.
>
> This leaves as future work, should there be a need, the handling 
> multiple "priority schemes" within a single network.  This is a very 
> hard problem and not a use case that is currently needed by existing 
> users of Diameter.
>
> I'll wait for feedback, especially from the Dime working group, before 
> I start updating the document.
>
> Regards,
>
> Steve
>
> On 5/5/16 9:39 AM, Stephen Farrell wrote:
>> Great. I think we're maybe at the point where pushing out a
>> revised I-D that has the fixes we now know we want would be a
>> good plan and then we can go back around the discuss holders
>> and see where we're at.
>>
>> Make sense? If not, then please continue the discussion to
>> get us there.
>>
>> Cheers,
>> S.
>>
>> On 05/05/16 15:25, Steve Donovan wrote:
>>> I'm okay with this addition.
>>>
>>> Steve
>>>
>>>
>>> On May 5, 2016 8:21:22 AM Stephen Farrell 
>>> <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> On 05/05/16 14:19, Alissa Cooper wrote:
>>>>> I think the gap is in Section 5, where it should be noted that in
>>>>> order for priority information to be reliably usable in the way 
>>>>> that
>>>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and
>>>>> consuming it must have pre-established trust relationships of the
>>>>> sort described in Section 11.
>>>> Sounds reasonable to me. Authors?
>>>>
>>>> S.
>>>>
>>>