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

[Janet P Gunn <[e-mail]>]

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]>
To:     [e-mail], Stephen Farrell 
<[e-mail]>, "[e-mail]" <[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]>



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] 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 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.
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]
https://www.ietf.org/mailman/listinfo/dime