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

[Steve Donovan <[e-mail]>]

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