Re: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06

Ben,First, thanks for the comments!
 Regarding the major comment, agree this should be added, it was already agreed in the meeting we had in IETF96, but somehow slipped :-(

Sections 12: all the AVPs mentioned in this section exists in RFC4006, and has values that are already registered. As part of RFC4006bis we did not add any AVP that requires values enumeration (this was actually one of the issue we tried to tackle). What would you like to see different in this section?What is the process for updating IANA with the references to the new doc? Can this happen before RFC4006bis is officially accepted?

Appendix B: the new AVPs do not impact the flows, therefore not added to the sample flows

8.34 agree, this is pretty bad. How about:If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
   and the classification of the restricted traffic cannot be expressed
   using IPFilterRule, or different actions (e.g., QoS) than just
   allowing traffic needs to be enforced, then the QoS-Final-Unit-
   Indication AVP SHOULD be used instead of the Final-Unit-Indication
   AVP.
14. agree we should simplify as you suggested

Best Regards,
Yuval
    On Tuesday, February 13, 2018, 1:33:22 AM GMT+2, Ben Campbell <ben@nostrum.com> wrote:  

 Hi,

This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the work on this; it’s overall a good update. However, I have one major comment and a few minor or editorial comments. I’d like to discuss the major comment prior IETF last call. The rest can be handled along with any last call feedback.

Note that for all but the major comment, I mostly reviewed the diff from RFC 4006.

Thanks!

Ben.

—————————————

Major Comment:

I strongly suggest that you add more privacy considerations. I realize that it inherits its existing privacy considerations from RFC 4006, but that was published in 2005. The IETF’s focus on privacy has evolved considerably since then, and I think this draft will get objections during IESG review without adding some more.

I suggest the following:
— Create a “Privacy Considerations” section separate from the security considerations.
— Enumerate the AVPs that you think contain user identifiable information, persistent identifiers, or other privacy sensitive data.
— Make some non-normative recommendations concerning data minimization. That is, add a few sentences recommending that clients and servers avoid capturing and/or log personal information beyond that needed for the application's purpose.

Minor Comments:

-Section 12 and subsections: Please clarify that many of these elements were already registered by RF 4006, and are not being “re-registered” here. ( It’s perfectly okay to pull the registration information forward into the bis draft; it just needs clarification.) Also, please consider wether existing registrations should be updated to point to this document rather than 4006.

Appendices: Would any of the example flows benefit from including one or more of the new AVPs?

Editorial and Nits:

-Section 8.34: “ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic cannot be expressed
using IPFilterRule, or different actions (e.g., QoS) than just
allowing QoS needs to be enforced traffic, … “

I have trouble parsing the sentence.

-14: "Even without any modification to the messages, an adversary can
  invite a security threat by eavesdropping, as the transactions contain private information about the user.
”
I suggest “ … an adversary can eavesdrop on transactions that contain privacy-sensitive imformation”

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime