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

[Stephen Farrell <[e-mail]>]

Thanks all. I've requested IETF LC. If there're any more changes
those can be handled during/after that.

Cheers,
S

On 10/03/16 16:53, Steve Donovan wrote:
> All,
> 
> I modifying the new requirement statements, making them MAY instead of
> SHOULD NOT, with the following wording:
> 
>    While done only in exceptional circumstances, Diameter agents MAY
>    modify priority information when relaying request and answer
>    messages.
> 
>       There might be scenarios where a Diameter agent does modify
>       priority information.  For instance, an edge agent might need to
>       modify the priority values set by an adjacent operator.
> 
>    While done only in exceptional circumstances, Diameter agents MAY add
>    priority information when relaying request and answer messages.
> 
>       There might be scenarios where a Diameter endpoint does not
>       support the DRMP mechanism and agents insert priority information
>       for that non supporting endpoint.
> 
> If there is not concensus on the wording of these requirement statements
> then we can update them as the review process progresses. Regards, Steve
> On 3/9/16 1:04 PM, Steve Donovan wrote:
>> Lionel, I'll work the suggested ordering and wording below into the
>> next draft. On the requirements I went with SHOULD NOT because it
>> really should be very rare that an agent changes or adds priority
>> information. The note is there to explain why the SHOULD NOT isn't a
>> MUST NOT. I think it is better to have a requirement, be it as it
>> currently exists or with a MAY, to be explicit. Steve
>> On 3/9/16 10:05 AM, [e-mail] wrote:
>>>
>>> Hi Steve,
>>>
>>> It is true that some scenarios will require action of agents on the
>>> DRMP AVP.
>>>
>>> in that case, I would be more explicit and change a little bit the
>>> order as "save the transaction priority" is valid in any case:
>>>
>>> è Note that the title of the bullet 2 should be " Agents handing the
>>> request " and not "Agents handling the request"
>>>
>>>    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.  Before forwarding request messages, agents
>>> generally do not
>>>
>>>        modify the priority information present in the received request
>>>
>>>        message nor include the priority information when absent in
>>> the received request message.
>>>
>>>        However, in some scenarios, agents
>>>
>>>        can modifythe priority information e.g. edge agents modifying the
>>>
>>>        priority  values set by an adjacent operator. There might be
>>> other
>>>
>>>        scenarios where a Diameter endpoint does not support the DRMP
>>>
>>>        mechanism and agents insert the priority information in the
>>> request messages for that non
>>>
>>>        supporting endpoint. When forwarding the request messages, the
>>> agent saves
>>>
>>>        the transaction priority in the transaction state, either as
>>>
>>>        locally managed state or using the Proxy-Info mechanism defined
>>>
>>>        in [RFC6733 <https://tools.ietf.org/html/rfc6733>].  This will
>>> be used when handling the associated
>>>
>>>        answer message for the transaction.
>>>
>>> The same kind of change should be done in bullet 5 that is about
>>> handling of answers:
>>>
>>>    5.  Agent handling the answer - By default, agents handling answer
>>>
>>>        messages use the priority information stored with the transaction
>>>
>>>        state to determine the priority of relaying the answer message.
>>>
>>>        However, priority information included in the answer message,
>>>
>>>        when present, is used in place of the stored priority
>>>
>>>        information.  The use of priority information implies that
>>>
>>>        answers for higher priority transactions are given preferential
>>>
>>>        treatment to lower priority transactions. When forwarding the
>>> answer messages, agents generally do not
>>>
>>>        modify the priority information present in the received answer
>>> messages
>>>
>>>        nor include the priority information when absent in the
>>> received answer messages.
>>>
>>>        However, in some scenarios, agents
>>>
>>>        can modifythe priority information e.g. edge agents modifying the
>>>
>>>        priority  values set by an adjacent operator. There might be
>>> other
>>>
>>>        scenarios where a Diameter endpoint does not support the DRMP
>>>
>>>        mechanism and agents insert the priority information for that non
>>>
>>>        supporting endpoint.
>>>
>>> If it is agreed that agents can modify/include the DRMP AVP, I think
>>> that the "SHOULD NOT" is not correct as it is a "MAY", even if not
>>> often.
>>>
>>> I think the proposed added requirements can be safely removed.
>>>
>>> Regards,
>>>
>>> Lionel
>>>
>>> *De :*Janet P Gunn [mailto:[e-mail]] *Envoyé :* mercredi 9
>>> mars 2016 16:23 *À :* Steve Donovan *Cc :* [e-mail]; DiME;
>>> MORAND Lionel IMT/OLN; Stephen Farrell *Objet :* Re: [Dime] AD review
>>> of draft-ietf-dime-drmp-03
>>>
>>> Sounds good to me. Janet This electronic message transmission
>>> contains information from CSRA that may be attorney-client
>>> privileged, proprietary or confidential. The information in this
>>> message is intended only for use by the individual(s) to whom it is
>>> addressed. If you believe you have received this message in error,
>>> please contact me immediately and be aware that any use, disclosure,
>>> copying or distribution of the contents of this message is strictly
>>> prohibited. NOTE: Regardless of content, this email shall not operate
>>> to bind CSRA to any order or other contract unless pursuant to
>>> explicit written agreement or government initiative expressly
>>> permitting the use of email for such purpose. From: Steve Donovan
>>> <[e-mail] <mailto:[e-mail]>> To:
>>> [e-mail], Stephen Farrell <[e-mail]
>>> <mailto:[e-mail]>>, "[e-mail]
>>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> Date:
>>> 03/09/2016 10:15 AM Subject: Re: [Dime] AD review of
>>> draft-ietf-dime-drmp-03 Sent by: "DiME" <[e-mail]
>>> <mailto:[e-mail]>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> All, I've commented on Stephen's and Lionel's suggested changes
>>> below. If there is agreement to my proposed changes outlined below
>>> then I will submit a new version of the document. Regards, Steve On
>>> 3/8/16 9:41 AM, [e-mail]
>>> <mailto:[e-mail]> wrote: i will let Steve react but I
>>> can give my feeling :)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.* SRD> I propose the
>>> following reworded last sentence: "Agents generally do no modify
>>> priority information and agents generally do not add new priority
>>> information in forwarded requests or answers." SRD> There is one
>>> scenario where I can see an agent does add add priority information,
>>> in a transition period when not all endpoints support the DRMP
>>> mechanism and the agent is used to insert priority information for
>>> the non supporting endpoint. SRD> I also see one scenario where an
>>> agent might modify priority values.  This would be an edge agent case
>>> where the priority values included by another operator's Diameter
>>> network aren't trusted and new values are needed. SRD> I propose that
>>> notes that address these scenarios be added to the new normative
>>> requirements proposed below. 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.
>>> SRD> I propose the following:    Diameter agents SHOULD NOT modify
>>> priority information when relaying  request and answer messages.    
>>>  There might be scenarios where a Diameter agent does modify    
>>>  priority information.  For instance, an edge agent might need to    
>>>  modify the priority values set by an adjacent operator.   Diameter
>>> agents SHOULD NOT add priority information when relaying   request
>>> and answer messages.      There might be scenarios where a Diameter
>>> endpoint does not      support the DRMP mechanism and agents insert
>>> priority information      for that non supporting endpoint. Just a
>>> proposal, waiting for Steve and WG comments. Regards, Lionel
>>> -----Message d'origine-----De : DiME [mailto:[e-mail]]
>>> De la part de Stephen FarrellEnvoyé : vendredi 4 mars 2016 18:07 À :
>>> [e-mail] <mailto:[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. SRD> Change made. - 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. SRD> Agreed, change made. - 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" :-) SRD>
>>> I'm open to wording suggestions here but the only real reason is that
>>> we needed a default and some thought it might be better to have the
>>> default allow for a few more higher-than-default values than
>>> lower-than-default values. I'm not sure saying this adds much value.
>>> - 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.
>>> SRD> The existing language was put in when we had 5 priority values. 
>>> The above is certainly a more elegant way of specifying it.  Changed
>>> to the following:    When setting and using priorities, for all
>>> integers x,y in [0,15]  treat PRIORITY_<x> as lower priority than
>>> PRIOIRTY_<y> when y<x.      Note: As a result PRIORITY_0 is the
>>> highest priority. SRD> I'm not sure this can be done in section 9.1,
>>> as this is listing the enumerated values for the AVP. I-D nits:  ==
>>> Unused Reference: 'RFC5226'  == Unused Reference: 'RFC4412' SRD>
>>> These references removed.
>>> _________________________________________________________________________________________________________________________
>>> 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.
>>> _______________________________________________DiME mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>>
>>> 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.
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>