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

["A. Jean Mahoney" <[e-mail]>]

Thanks for the changes!

Jean

On 2/1/16 9:24 AM, Steve Donovan wrote:
>
>
> On 1/27/16 2:35 PM, A. Jean Mahoney wrote:
>> Hi Steve and Lionel,
>>
>> On 1/27/16 12:27 PM, [e-mail] wrote:
>>> Steve,
>>>
>>> See below.
>>>
>>> Lionel
>>>
>>> -----Message d'origine----- De : Steve Donovan
>>> [mailto:[e-mail]] Envoyé : mercredi 27 janvier 2016
>>> 18:57 À : MORAND Lionel IMT/OLN; A. Jean Mahoney; [e-mail] Objet
>>> : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02
>>>
>>>
>>>
>>> On 1/27/16 11:34 AM, [e-mail] wrote:
>>>> Hi Steve,
>>>>
>>>> 1 comment and 1 question below.
>>>>
>>>> Regards,
>>>>
>>>> Lionel
>>>>
>>>> -----Message d'origine----- De : Steve Donovan
>>>> [mailto:[e-mail]] Envoyé : mercredi 27 janvier 2016
>>>> 18:20 À : A. Jean Mahoney; MORAND Lionel IMT/OLN; [e-mail]
>>>> Objet : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02
>>>>
>>>> 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."
>>>> [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] 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.
>>
> SRD> Change made.
>>
>>>>
>>>>> 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.
>>>> 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.
>>>>
>>>> [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?
>>> 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.
>>>
>>
>> [ajm] A note in section 8 would be helpful. It doesn't have to be
>> normative.
> SRD> I've replaced the relevent sentence in section 6 with the
> following: "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. "
>
> I've also changed the note in section 8 to the following:
>
> 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.  Another is
> to use the
>          Proxy-Info mechanism defined in RFC6733.
>
>>
>>>>
>>>>> 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
>>>> I re-worded to the following:
>>>>
>>>> "...By default the handler of the answer message uses the priority
>>>> saved in the transaction's state.
>>
>> [ajm] ok
>>
>> Thanks!
>>
>> Jean
>>
>>>>> 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, [e-mail] 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 [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.
>>>>
>>>
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>>
>>>  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.
>>>
>