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

[Stephen Farrell <[e-mail]>]

On 09/03/16 09:56, [e-mail] wrote:
> Hi Stephen,
> 
> If it is straightforward, as I assume it is, Steve can quickly
> produce a new version of the draft based on my proposed
> modifications. If it is not, it would mean that we will have to
> discuss a little bit more this point in the WG.
> 
> So please wait for Steve and WG feedback before issuing the official
> LC.

Will do,
Thanks,
S.

> 
> Regards,
> 
> Lionel
> 
>> -----Message d'origine----- De : Stephen Farrell
>> [mailto:[e-mail]] Envoyé : mercredi 9 mars 2016
>> 10:38 À : MORAND Lionel IMT/OLN; [e-mail] Cc : Steve Donovan 
>> Objet : Re: [Dime] AD review of draft-ietf-dime-drmp-03
>> 
>> 
>> 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.
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
>
>  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.
>