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

[Steve Donovan <[e-mail]>]

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