Re: [Dime] AD review of draft-ietf-dime-drmp-03

[Stephen Farrell <[e-mail]>]

Hi Lionel,

On 08/03/16 15:41, [e-mail] wrote:
> i will let Steve react but I can give my feeling :)

Grand. All below is fine by me. As chair, would you
prefer that I just start IETF LC and you handle this
issue as a LC comment, or would you prefer to let the
WG figure this out first? I'm fine either way.

Cheers,
S.

> 
> The priority is set by the Diameter or Diameter server, not by agent.
> 
> It is somehow describe in section 6 Theory of Operation
> 
>    2.  Agents handing the request - Agents use the priority information
>        when making routing decisions.  This can include determining
>        which requests to route first, which requests to throttle and
>        where the request is routed.  For instance, requests with higher
>        priority might have a lower probability of being throttled.  The
>        mechanism for how the agent determines which requests are
>        throttled is implementation dependent and is outside the scope of
>        this document.  The agent also saves the transaction priority in
>        the transaction state, either as locally managed state or using
>        the Proxy-Info mechanism defined in [RFC6733].  This will be used
>        when handling the associated answer message for the transaction.
> 
> Agents are just using this information if present. They are not modify it or include it if absent.
> It is said in section 8.  Normative Behavior
> 
>       Note: This guidance on the handling of messages without a priority
>       does not result in a Diameter agent inserting a DRMP AVP into the
>       message.  Rather, it gives guidance on how that specific
>       transaction should be treated when its priority is compared with
>       other requests.  When a Diameter agent relays the request it will
>       not insert a DRMP AVP with a priority value of 10.
> 
> It could be possible to clarify it as follow:
> 
> in section 6, the end of the point 2 could be enhanced as follow:
> 
>    2.  Agents *handling* the request - Agents use the priority information
>        when making routing decisions.  This can include determining
>        which requests to route first, which requests to throttle and
>        where the request is routed.  For instance, requests with higher
>        priority might have a lower probability of being throttled.  The
>        mechanism for how the agent determines which requests are
>        throttled is implementation dependent and is outside the scope of
>        this document.  The agent also saves the transaction priority in
>        the transaction state, either as locally managed state or using
>        the Proxy-Info mechanism defined in [RFC6733].  This will be used
>        when handling the associated answer message for the transaction.
>        *Agents are not supposed to modify or include priority information in
>        in forwarded requests or answers.*
> 
> The "not supposed" is used because it is difficult to use normative wording here.
> 
> In section 8, a new requirement could be added, right after " Diameter agents MAY use routing priority information..."
> 
>    Diameter agents SHOULD NOT modify or include the DRMP AVP when 
>    relaying request and answer messages.
> 
> Just a proposal, waiting for Steve and WG comments.
> 
> Regards,
> 
> Lionel
> 
> 
>> -----Message d'origine-----
>> De : DiME [mailto:[e-mail]] De la part de Stephen Farrell
>> Envoyé : vendredi 4 mars 2016 18:07
>> À : [e-mail]
>> Objet : [Dime] AD review of draft-ietf-dime-drmp-03
>>
>>
>> Hiya,
>>
>> I just have one question I'd like to ask the wg about before I start IETF LC.
>>
>> You don't say if priorities are intended to be modified after they have been
>> set. In the security considerations you do say that this could be done
>> maliciously, and you do say that priorities need to be dropped if received
>> from a source not trusted for that, but you never say if it's considered ok or
>> not for e.g. an agent to change a priority for some local policy reason. Don't
>> you need to say that somewhere? (And apologies if you do say it somewhere
>> and I missed it:-)
>>
>> There are some nits below, you can handled these before or after IETF LC,
>> whichever is best.
>>
>> Cheers,
>> S.
>>
>>
>> - Section 5: URL and MME aren't expanded. Since you're just using it as an
>> example, I'd say expanding this will help any reader who's not a 3gpp
>> afficionado.
>>
>> - Section 8, "The priority marking scheme SHOULD NOT require the Diameter
>> Agents to understand application specific AVPs."
>> Isn't that a bogus use of 2119 language since we're not expressing
>> requirements here? s/SHOULD NOT/does not/ would seem better.
>>
>> - Section 8, People will ask "why default to 10?" I recall the WG discussed this
>> but iirc mostly didn't care too much but it might be nice to justify 10 if there's
>> a way to do it that doesn't amount to "just because" :-)
>>
>> - Section 8, The "When setting and using..." paragraphs are quite verbose.
>> It'd be no harm to make that shorter, e.g. by just saying: "For all integers x,y
>> in [0,15] treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x"
>> You could do something similar in 9.1.
>>
>> I-D nits:
>>
>>   == Unused Reference: 'RFC5226'
>>   == Unused Reference: 'RFC4412'
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>