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

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 17:06:40 +0000

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'

---

From: <[email-masked]>
Date: Tue, 8 Mar 2016 15:41:58 +0000

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.*

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:[email-masked]] De la part de Stephen Farrell
> Envoyé : vendredi 4 mars 2016 18:07
> À : [email-masked]
> 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:
> 

_________________________________________________________________________________________________________________________

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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2016 09:37:53 +0000

Hi Lionel,

> 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.

---

From: <[email-masked]>
Date: Wed, 9 Mar 2016 09:56:08 +0000

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.

Regards,

Lionel

> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : mercredi 9 mars 2016 10:38
> À : MORAND Lionel IMT/OLN; [email-masked]
> Cc : Steve Donovan
> Objet : Re: [Dime] AD review of draft-ietf-dime-drmp-03
> 
> 
> Hi Lionel,
> 
> > In section 8, a new requirement could be added, right after " Diameter
> agents MAY use routing priority information..."
> >
> __________________________________________________________
> __________________________________________________________
> _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2016 10:02:00 +0000

On 09/03/16 09:56, [email-masked] 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.
> 

Will do,
Thanks,
S.

> 
> Regards,
> 
> Lionel
> 
>> -----Message d'origine----- De : Stephen Farrell
>> [mailto:[email-masked]] Envoyé : mercredi 9 mars 2016
>> 10:38 À : MORAND Lionel IMT/OLN; [email-masked] Cc : Steve Donovan 
>> 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.
>> 
>>> 
>>> 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.
>>> 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.
>>> 
>>> 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.
>>> 
>>>> -----Message d'origine----- De : DiME
>>>> [mailto:[email-masked]] De la part de Stephen Farrell 
>>>> Envoyé : vendredi 4 mars 2016 18:07 À : [email-masked] Objet :
>>>> [Dime] AD review of draft-ietf-dime-drmp-03
>>>> 
>>>> 
>>>> Hiya,
>>>> 
>>>> 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
>>>> policy reason.
>> Don't
>>>> you need to say that somewhere? (And apologies if you do say
>>>> it
>> somewhere
>>>> and I missed it:-)
>>>> 
>>>> Cheers, S.
>>>> the
>> Diameter
>>>> Agents to understand application specific AVPs." Isn't that a
>>>> bogus use of 2119 language since we're not expressing 
>>>> WG discussed
>> this
>>>> but iirc mostly didn't care too much but it might be nice to
>>>> justify 10 if
>> there's
>>>> just saying: "For all integers
>> x,y
>>>> in [0,15] treat PRIORITY_<x> as lower priority than
>>>> PRIOIRTY_<y> when
>> y<x"
>>>> == Unused Reference: 'RFC5226' == Unused Reference: 'RFC4412'
>>> 
>>> 
>>> 
>> __________________________________________________________ _____
>>> 
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>> avez recu ce
>> message par erreur, veuillez le signaler
>>> Orange decline toute responsabilite si ce message a ete altere,
>>> deforme ou
>> falsifie. Merci.
>>> 
>>> 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.
>>> 
> 
> 
> 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.
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 9 Mar 2016 08:59:11 -0600

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

>         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.
>     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.

>> example, I'd say expanding this will help any reader who's not a 3gpp
SRD> Change made.
>> requirements here? s/SHOULD NOT/does not/ would seem better.
SRD> Agreed, change made.
>> 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.
>> 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.

>>    == Unused Reference: 'RFC4412'
SRD> These references removed.

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 9 Mar 2016 10:22:56 -0500

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 <[email-masked]>
To:     [email-masked], Stephen Farrell 
<[email-masked]>, "[email-masked]" <[email-masked]>
Date:   03/09/2016 10:15 AM
Subject:        Re: [Dime] AD review of draft-ietf-dime-drmp-03
Sent by:        "DiME" <[email-masked]>

All,

Regards,

Steve

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

       *Agents are not supposed to modify or include priority information 
in
SRD> I propose the following reworded last sentence: "Agents generally do 
no modify priority

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.

The "not supposed" is used because it is difficult to use normative 
wording here.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Stephen Farrell
Envoyé : vendredi 4 mars 2016 18:07
À : [email-masked]
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:-)

Cheers,
S.

- 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:

      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:

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

---

From: <[email-masked]>
Date: Wed, 9 Mar 2016 16:05:04 +0000

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 modify the 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 modify the 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:[email-masked]]
Envoyé : mercredi 9 mars 2016 16:23
À : Steve Donovan
Cc : [email-masked]; 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 <[email-masked]<mailto:[email-masked]>>
To:        [email-masked]<mailto:[email-masked]>, Stephen Farrell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        03/09/2016 10:15 AM
Subject:        Re: [Dime] AD review of draft-ietf-dime-drmp-03
Sent by:        "DiME" <[email-masked]<mailto:[email-masked]>>
________________________________

All,

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, [email-masked]<mailto:[email-masked]> wrote:
i will let Steve react but I can give my feeling :)

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.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Stephen Farrell
Envoyé : vendredi 4 mars 2016 18:07
À : [email-masked]<mailto:[email-masked]>
Objet : [Dime] AD review of draft-ietf-dime-drmp-03

Hiya,

Cheers,
S.

- 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.

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:

     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:

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 9 Mar 2016 16:08:57 +0000

I forget to add that the security considerations should be updated as follow:

existing text in section 11:

   Diameter does not include features to provide end-to-end
   authentication, integrity protection, or confidentiality.  This opens
   the possibility that agents in the path of a request could modify the
   DRMP AVP to reflect a priority different than that asserted by the
   sender of the request.

new proposed text (adding malicious or compromised)

   Diameter does not include features to provide end-to-end
   authentication, integrity protection, or confidentiality.  This opens
   the possibility that malicious or compromised agents in the path of
   a request could modify the DRMP AVP to reflect a priority different
   than that asserted by the sender of the request.

regards,

Lionel

De : MORAND Lionel IMT/OLN
Envoyé : mercredi 9 mars 2016 17:05
À : 'Janet P Gunn'; Steve Donovan
Cc : [email-masked]; DiME; Stephen Farrell
Objet : RE: [Dime] AD review of draft-ietf-dime-drmp-03

Hi Steve,

Regards,

Lionel

De : Janet P Gunn [mailto:[email-masked]]
Envoyé : mercredi 9 mars 2016 16:23
À : Steve Donovan
Cc : [email-masked]<mailto:[email-masked]>; DiME; MORAND Lionel IMT/OLN; Stephen Farrell
Objet : Re: [Dime] AD review of draft-ietf-dime-drmp-03

Sounds good to me.

Janet

All,

Regards,

Steve

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Stephen Farrell
Envoyé : vendredi 4 mars 2016 18:07
À : [email-masked]<mailto:[email-masked]>
Objet : [Dime] AD review of draft-ietf-dime-drmp-03

Hiya,

Cheers,
S.

I-D nits:

---

From: Steve Donovan <[email-masked]>
Date: Wed, 9 Mar 2016 13:04:34 -0600

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, [email-masked] wrote:
> 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"
>
>        can modifythe priority information e.g. edge agents modifying the
>
>        in [RFC6733 <https://tools.ietf.org/html/rfc6733>].  This will 
> be used when handling the associated
>
>        can modifythe priority information e.g. edge agents modifying the
>
> 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.
>
> *De :*Janet P Gunn [mailto:[email-masked]]
> *Envoyé :* mercredi 9 mars 2016 16:23
> *À :* Steve Donovan
> *Cc :* [email-masked]; 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.
>
>
>
> To: [email-masked] <mailto:[email-masked]>, 
> Stephen Farrell <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Sent by: "DiME" <[email-masked] <mailto:[email-masked]>>
>
> ------------------------------------------------------------------------
>
>
>
>
> All,
>
> If there is agreement to my proposed changes outlined below then I 
> will submit a new version of the document.
>
> Regards,
>
> Steve
>
> À : [email-masked] <mailto:[email-masked]>
> 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 
> The above is certainly a more elegant way of specifying it.  Changed 
> to the following:
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> deforme ou falsifie. Merci.
>
> privileged information that may be protected by law;
> [email-masked] <mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 9 Mar 2016 13:05:07 -0600

I'm okay with this wording.

Steve

On 3/9/16 10:08 AM, [email-masked] wrote:
> *De :*MORAND Lionel IMT/OLN
> *Envoyé :* mercredi 9 mars 2016 17:05
> *À :* 'Janet P Gunn'; Steve Donovan
> *Cc :* [email-masked]; DiME; Stephen Farrell
> *Objet :* RE: [Dime] AD review of draft-ietf-dime-drmp-03
>
> Hi Steve,
>
> *Cc :* [email-masked] <mailto:[email-masked]>; DiME; MORAND Lionel 
> IMT/OLN; Stephen Farrell

---

From: Steve Donovan <[email-masked]>
Date: Thu, 10 Mar 2016 10:53:35 -0600

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.

    While done only in exceptional circumstances, Diameter agents MAY add
    priority information when relaying request and answer messages.

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
>> *De :*Janet P Gunn [mailto:[email-masked]] *Envoyé :* mercredi 9 
>> mars 2016 16:23 *À :* Steve Donovan *Cc :* [email-masked]; 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 
>> <[email-masked] <mailto:[email-masked]>> To: 
>> [email-masked], Stephen Farrell <[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> Date: 
>> 03/09/2016 10:15 AM Subject: Re: [Dime] AD review of 
>> draft-ietf-dime-drmp-03 Sent by: "DiME" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> 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, [email-masked] 
>> <mailto:[email-masked]> 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 
>> 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 
>> 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     
>>    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       
>> 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.     
>>  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:[email-masked]] 
>> De la part de Stephen FarrellEnvoyé : vendredi 4 mars 2016 18:07 À : 
>> [email-masked] <mailto:[email-masked]>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 
>> - 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. 
>> 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. 
>> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2016 19:03:33 +0000

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:
>>> avez recu ce message par erreur, veuillez le signaler
>>> If you have received this email in error, please notify the sender
>>> and delete this message and its attachments.