Subject: Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 4 Jan 2016 15:14:41 -0600

Hi all,

I'm good with the document, although I agree with Janet's feedback that 
someone in ecrit should take a look at it, and with Lionel's feedback on 
the security section.

Section 6, number 4:

I assume the sender's decision to change the priority for the answer is 
app-specific. Maybe add some words here and in Section 8 to that effect.

Section 8:

Section 6 talks about nodes saving priority information found in the 
request's DRMP AVP with the transaction state, and then checking it if 
the AVP is absent in the Diameter answer. This info should be captured 
in this section also.

Nits:

Section 5, 1st paragraph: s/discussed/discusses

Section 5.1, 4th paragraph: s/job/jobs

Section 5.4, 5th paragraph: s/command-code/command code

Section 6, number 6: s/transaction/transaction state

Section 7: Add a period to end of paragraph

Section 11: s/Diamter/Diameter

Happy New Year!

Jean

On 12/23/15 4:26 AM, [email-masked] wrote:
> As agreed during the Dime session at IETF94, a Working Group Last
> Call is asked on the following document:
>
> https://tools.ietf.org/html/draft-ietf-dime-drmp-02
>
> Please respond to this email to support the document and/or send
> comments by 2016-01-20.
>
> As this WGLC is initiated during the Xmas/end-of-year break, the WGLC
> period is extended to 4 weeks. For reviewer of the document, don't
> forget to state if you are fine with the document even if there is no
> comment. It is important for evaluating the quality of the document
> and gauge the WG consensus.
>
> In addition, following the strategy for promoting compliance with the
> IPR disclosure rules (RFC6702), the chairs would like to check
> whether there are claims of Intellectual Property Rights (IPR) on the
> document that need to be disclosed. Therefore, the following
> questions are addressed to the WG and Especially Authors and
> Contributors of the draft:
>
> * Are you personally aware of any IPR that applies to
> draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in
> compliance with IETF IPR rules?  (See RFCs 3979, 4879, 3669, and 5378
> for more details.)
>
> * If you are a document author or listed contributor on this
> document, please reply to this email message regardless of whether or
> not you are personally aware of any relevant IPR.  We might not be
> able to advance this document to the next stage until we have
> received a reply from each author and listed contributor.
>
> * If you are on the DIME WG email list but are not an author or
> listed contributor for this document, you are reminded of your
> opportunity for a voluntary IPR disclosure under BCP 79.  Please do
> not reply  unless you want to make such a voluntary disclosure.
>
> Online tools for filing IPR disclosures can be found at
> <http://www.ietf.org/ipr/file-disclosure>.
>
> Regards,
>
> Lionel and Jouni
>
> _________________________________________________________________________________________________________________________
>
>  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: Steve Donovan <[email-masked]>
Date: Wed, 27 Jan 2016 11:19:46 -0600

Jean,

Thanks for the review.  See my comments below.

Regards,

Steve

On 1/4/16 3:14 PM, A. Jean Mahoney wrote:
> Hi all,
>
> I'm good with the document, although I agree with Janet's feedback 
> that someone in ecrit should take a look at it, and with Lionel's 
> feedback on the security section.
SRD> I'll be addressing these comments in a separate email.
>
>
> Section 6, number 4:
>
> I assume the sender's decision to change the priority for the answer 
> is app-specific. Maybe add some words here and in Section 8 to that 
> effect.
SRD> I added the following to the end of the paragraph: "The priority 
included by the answer sender is application specific."
> the AVP is absent in the Diameter answer. This info should be captured 
SRD> The normative behavior is captured in this paragraph:

    When determining the priority to apply to answer messages, Diameter
    nodes MUST use the priority indicated in the DRMP AVP carried in the
    answer message, if it exists.  Otherwise, the Diameter node MUST use
    the priority indicated in the DRMP AVP of the associated request
    message.

Section 6 talks about one way to implement this.  I'm hesitant to 
include it as normative behavior.  As such, I added the following note:

       Note: One method to determine what priority to apply to an answer
       when there is no DRMP AVP in the answer message is to save the
       priority included in the request message in state associated with
       the Diameter transaction.
> Section 6, number 6: s/transaction/transaction state
I re-worded to the following:

"...By default the handler of the answer message uses the priority saved 
in the transaction's state.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 27 Jan 2016 11:29:31 -0600

Janet,

Thanks for the review.

See my comments inline.

Regards,

Steve

On 12/30/15 1:26 PM, Janet P Gunn wrote:
> A couple of late comments-
>
> I thought I had commented on this before (in the first draft), but 
> maybe it got lost.
>
> In sec 5.1 it says:
>
>    The United States Wireless Priority Services (WPS) and Government
>    Emergency Telecommunications Service (GETS) are examples of systems
>    designed to address these first responder needs.
>
> But this is not accurate.  GETS and WPS are used by the First 
> Responder “Command/Management”, but NOT by the First Responder “Rank 
> and File”.
>
> The web pages for WPS  ( 
> http://www.dhs.gov/wireless-priority-service-wps) and GETS ( 
> _http://www.dhs.gov/government-emergency-telecommunications-service-gets_) 
> say that typical users are “responsible for the command and control 
> functions critical to management of and response to national security 
> and emergency situations, particularly during the first 24 to 72 hours 
> following an event.”
>
> So the Fire  Chief might use WPS/GETS to call the local hospital (or 
> an individual firefighter), or the hospital administrator might use 
> WPS/GETS to call the State Health Department (or an individual 
> doctor), but individual  firefighters would not use WPS/GETS to call 
> each other.
>
> You might want to contact the ECRIT working group for examples of 
> priority systems that DO support the front-line  firefighters, etc.
>
> My suggestion for rewording the paragraph is
>
>    The United States Wireless Priority Services (WPS) and Government
>    Emergency Telecommunications Service (GETS) are examples of systems
>    designed to address the command and control aspects of these first
>    responder needs.
>
SRD> Change made.
> ---
>
> For section 5.2 Emergency Call Related Signaling, I would also suggest 
> that you coordinate with ECRIT for appropriate wording.  In the “911” 
> world, the bottleneck (scarce resource) is the people to answer the 
> phone.  Sometimes it is counterproductive to improve the probability 
> of success earlier in the call path, as it makes the congestion at the 
> PSAP itself worse.
>
SRD> We can pass this by ECRIT but this isn't just about making the 
calls setup faster, it is about helping to ensure that it is successful 
in the first place, especially in the face of an overloaded network.
> ---
>
> Security
> I am not a security expert, but I expect the security section needs to 
> be beefed up.  As it says in  RFC4412:
>
>
>    Any resource priority mechanism can be abused to obtain resources and
>    thus deny service to other users.  An adversary may be able to take
>    over a particular PSTN gateway, cause additional congestion during
>    emergencies affecting the PSTN, or deny service to legitimate users.
>    In SIP end systems, such as IP phones, this mechanism could
>    inappropriately terminate existing sessions and calls.
>
>    Thus, while the indication itself does not have to provide separate
>    authentication, SIP requests containing this header are very likely
>    to have higher authentication requirements than those without.
>
> I would expect similar verbiage would be appropriate for Diameter.
>
SRD> Agreed, I'll proposed a beefed up security section.
> ---
>
> Editorial nit
>  In the introduction, I think that this sentence
>    “As such, all requests are treated the same meaning that all 
> requests have the same probability of being  throttled.”
> Would read better with a comma
>    “As such, all requests are treated the same, meaning that all 
> requests have the same probability of being  throttled.”
SRD> Agreed.
>
>
> Happy New Year everyone,
>
> 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: <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Date: 12/23/2015 05:26 AM
> Subject: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02
> Sent by: "DiME" <[email-masked]>
> ------------------------------------------------------------------------
>
>
>
> As agreed during the Dime session at IETF94, a Working Group Last Call 
> is asked on the following document:
>
> period is extended to 4 weeks.
> For reviewer of the document, don't forget to state if you are fine 
> with the document even if there is no comment. It is important for 
> evaluating the quality of the document and gauge the WG consensus.
>
> document that need to be disclosed. Therefore, the following questions 
> are addressed to the WG and Especially Authors and Contributors of the 
> draft:
>
> * If you are a document author or listed contributor on this document, 
> please reply to this email message regardless of whether or not you 
> are personally aware of any relevant IPR.  We might not be able to 
> advance this document to the next stage until we have received a reply 
> from each author and listed contributor.
>
> * If you are on the DIME WG email list but are not an author or listed 
> contributor for this document, you are reminded of your opportunity 
> for a voluntary IPR disclosure under BCP 79.  Please do not reply 
>  unless you want to make such a voluntary disclosure.
>
> 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.
>
> 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.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 27 Jan 2016 17:34:47 +0000

Hi Steve,

1 comment and 1 question below.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mercredi 27 janvier 2016 18:20
À : A. Jean Mahoney; MORAND Lionel IMT/OLN; [email-masked]
Objet : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02

Jean,

Regards,

Steve

SRD> I added the following to the end of the paragraph: "The priority
included by the answer sender is application specific."
[LM] I think that the comment is about the "decision" and not the "value".

Section 6 talks about one way to implement this.  I'm hesitant to include it as normative behavior.  As such, I added the following note:

[LM] It is curious to see an expected behaviour described in section 6 and no related normative behaviour. Could you explain why you are reluctant to say that the priority value indicated in the request is saved?

"...By default the handler of the answer message uses the priority saved in the transaction's state.
>> _____________________________________________________________________
>> ____________________________________________________
>>
>>

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: Steve Donovan <[email-masked]>
Date: Wed, 27 Jan 2016 11:56:53 -0600

> [LM] I think that the comment is about the "decision" and not the "value".
SRD2> Yes, but the decision to be made it about the value.  Do you have 
a suggestion for alternate wording?
> [LM] It is curious to see an expected behaviour described in section 6 and no related normative behaviour. Could you explain why you are reluctant to say that the priority value indicated in the re…
SRD> Section 6 is non normative and, as such, only an example. 
Specifying this in the normative section would eliminate other methods 
of determining the value received in the request.  For instance, a 
stateless agent might choose to include the value in a Proxy-Info AVP.

---

From: <[email-masked]>
Date: Wed, 27 Jan 2016 18:27:58 +0000

Steve,

See below.

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mercredi 27 janvier 2016 18:57
À : MORAND Lionel IMT/OLN; A. Jean Mahoney; [email-masked]
Objet : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02

On 1/27/16 11:34 AM, [email-masked] wrote:
> De : Steve Donovan [mailto:[email-masked]] Envoyé : mercredi 
> 27 janvier 2016 18:20 À : A. Jean Mahoney; MORAND Lionel IMT/OLN; 
> [email-masked] Objet : Re: [Dime] Start of the WGLC on 
> draft-ietf-dime-drmp-02
>
> Jean,
>

[LM] I think that the first decision is to include a prioriity value in the answer... even if it is the same value. But I may be wrong.

>> request's DRMP AVP with the transaction state, and then checking it 
>> if the AVP is absent in the Diameter answer. This info should be 
>> captured in this section also.
SRD> Section 6 is non normative and, as such, only an example. 
Specifying this in the normative section would eliminate other methods of determining the value received in the request.  For instance, a stateless agent might choose to include the value in a Proxy-Info AVP.

[LM] Good point. Could be good to indicate both options in your example.

>>> As this WGLC is initiated during the Xmas/end-of-year break, the 
>>> WGLC period is extended to 4 weeks. For reviewer of the document, 
>>> don't forget to state if you are fine with the document even if 
>>> there is no comment. It is important for evaluating the quality of 
>>> the document and gauge the WG consensus.
>>>
>>> In addition, following the strategy for promoting compliance with 
>>> the IPR disclosure rules (RFC6702), the chairs would like to check 
>>> whether there are claims of Intellectual Property Rights (IPR) on 
>>> the document that need to be disclosed. Therefore, the following 
>>> compliance with IETF IPR rules?  (See RFCs 3979, 4879, 3669, and 
>>> 5378 for more details.)
>>>
>>> document, please reply to this email message regardless of whether 
>>> or not you are personally aware of any relevant IPR.  We might not 
>>> be able to advance this document to the next stage until we have 
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>>
>>> 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. As emails may be altered, Orange 
>>> is not liable for messages that have been modified, changed or 
>>> falsified. Thank you.
>>>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.
>
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 27 Jan 2016 14:35:52 -0600

Hi Steve and Lionel,

On 1/27/16 12:27 PM, [email-masked] wrote:
> Steve,
>
> See below.
>
> Lionel
>
> -----Message d'origine----- De : Steve Donovan
> [mailto:[email-masked]] Envoyé : mercredi 27 janvier 2016
> 18:57 À : MORAND Lionel IMT/OLN; A. Jean Mahoney; [email-masked] Objet
> : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02
>
>
>
>> -----Message d'origine----- De : Steve Donovan
>> [mailto:[email-masked]] Envoyé : mercredi 27 janvier 2016
>> 18:20 À : A. Jean Mahoney; MORAND Lionel IMT/OLN; [email-masked]
>>> I'm good with the document, although I agree with Janet's
>>> feedback that someone in ecrit should take a look at it, and with
>>> Lionel's feedback on the security section.
>>> I assume the sender's decision to change the priority for the
>>> answer is app-specific. Maybe add some words here and in Section
>>> 8 to that effect.
>> SRD> I added the following to the end of the paragraph: "The
>> priority included by the answer sender is application specific."
> SRD2> Yes, but the decision to be made it about the value.  Do you
> have a suggestion for alternate wording?
>
> [LM] I think that the first decision is to include a prioriity value
> in the answer... even if it is the same value. But I may be wrong.
>
[ajm] Hmm, section 8 implies that the DRMP AVP is included in the answer 
only when the answer sender modifies the priority:

    Diameter endpoints MAY include the DRMP AVP in answer messages.  This
    is done when the priority for the answer message needs to have a
    different priority than the priority carried in the request message.

How about the following for the end of section 6, number 4?

        The answer sender also has the option of modifying priority
        information and including it in the answer message. The sender's
        behavior with regard to priority modification is application-
        specific.

>>
>>> Section 8:
>>>
>>> Section 6 talks about nodes saving priority information found in
>>> the request's DRMP AVP with the transaction state, and then
>>> checking it if the AVP is absent in the Diameter answer. This
>>> info should be captured in this section also.
>> When determining the priority to apply to answer messages,
>> Diameter nodes MUST use the priority indicated in the DRMP AVP
>> carried in the answer message, if it exists.  Otherwise, the
>> Diameter node MUST use the priority indicated in the DRMP AVP of
>> the associated request message.
>>
>> [LM] It is curious to see an expected behaviour described in
>> section 6 and no related normative behaviour. Could you explain why
>> you are reluctant to say that the priority value indicated in the
>> request is saved?
> Specifying this in the normative section would eliminate other
> methods of determining the value received in the request.  For
> instance, a stateless agent might choose to include the value in a
> Proxy-Info AVP.
>

[ajm] A note in section 8 would be helpful. It doesn't have to be 
normative.

>> saved in the transaction's state.

[ajm] ok

Thanks!

Jean

>>>> As agreed during the Dime session at IETF94, a Working Group
>>>> Last Call is asked on the following document:
>>>>
>>>> Please respond to this email to support the document and/or
>>>> send comments by 2016-01-20.
>>>>
>>>> As this WGLC is initiated during the Xmas/end-of-year break,
>>>> the WGLC period is extended to 4 weeks. For reviewer of the
>>>> document, don't forget to state if you are fine with the
>>>> document even if there is no comment. It is important for
>>>> In addition, following the strategy for promoting compliance
>>>> with the IPR disclosure rules (RFC6702), the chairs would like
>>>> to check whether there are claims of Intellectual Property
>>>> Rights (IPR) on the document that need to be disclosed.
>>>> Therefore, the following questions are addressed to the WG and
>>>> Especially Authors and Contributors of the draft:
>>>>
>>>> compliance with IETF IPR rules?  (See RFCs 3979, 4879, 3669,
>>>> and 5378 for more details.)
>>>>
>>>> document, please reply to this email message regardless of
>>>> whether or not you are personally aware of any relevant IPR.
>>>> We might not be able to advance this document to the next stage
>>>> until we have received a reply from each author and listed
>>>> contributor.
>>>>
>>>> * If you are on the DIME WG email list but are not an author
>>>> or listed contributor for this document, you are reminded of
>>>> your opportunity for a voluntary IPR disclosure under BCP 79.
>>>> Please do not reply  unless you want to make such a voluntary
>>>> disclosure.
>>>>
>>>>
>>>>
>>>> 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,
>>>> 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
>>>>
>>
>> etant susceptibles d'alteration, Orange decline toute
>> responsabilite si ce message a ete altere, deforme ou falsifie.
>> Merci.
>>
>> 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.
>>
>
>