Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT)

Ben,

Thank you for the review.  Our changes and responses are below.

Lyle

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Tuesday, June 09, 2015 1:56 PM
To: The IESG
Cc: dime-chairs@ietf.org; dime@ietf.org
Subject: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-dime-congestion-flow-attributes-01: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This mostly looks good. I have a few comments that are not show
stoppers:

substantive:

-- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.)

>>>> We responded to Stephen's comments regarding the intro.  If you could give your feedback on that thread it would be much appreciated.

-- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment?

>>>> We have not added one for Congestion-Treatment due to the similarity to Excess Treatment. The example we drafted were simplistic at best, "CE mark set the Diameter node declares congestion and acts according to the information included in the Congestion-Treatment AVP".  Because the AVP lets the node take immediate action the example was small and then it became a question of whether it should be its own subheading in the examples.  In that case you have a new subheading for roughly a one line sentence.

"If Excess-Treatment or Congestion-Treatment has occurred..."

Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been
 sent in a Diameter message”?

>>>> It is conditions associated with ...   The point of 5777 is to give the node receiving the Filter-Rule a plan of what to do when the conditions occur as opposed to the node querying a decision point for more direction.  We will change the text to "If conditions associated with Excess-Treatment [RFC5777] ... "

--6, first sentence.

I’d like to see a little more “show your work" here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs.

(I'm probably the other person that Stephen mentioned consider such sentences as a red flag.)

>>>> Ok.  Bigger update here.  We are dropping the first sentence and expanding upon the note we made in 5.2 about less reliance on DPI for at least congestion management.
>>>> This is the new Section 6.  The last paragraph is unchanged.

-------- New Section 6 --------
This document describes an extension of RFC5777 that introduces a new filter parameter applied to ECN as defined by [RFC3168].  It also defines a new Grouped AVP that expresses what action to take should congestion be detected.  The Grouped AVP reuses attributes defined in RFC5777. As these are extensions to RFC 5777, they do not raise new security concerns.

The Flow-Count and Packet-Count AVPs can be provided in conjunction with customary AVPs, e.g. Bytes, Time, Service Units, during Accounting activities as described in the base protocol [RFC6733] or other Diameter applications. These AVPs provide information that can be privacy sensitive.  The privacy sensitivity is directly related to traffic captured by Filters and associated reports.  Narrow filtering, which creates the highest level of privacy sensitivity, is too resource intensive to be practical on large networks.  Paradoxically, improving reporting information lessens the depth of inspection required to characterize traffic for many congestion management activities as noted in Section 5.2.

If an administrator can provide congestion actions without the need to report them to a Diameter application they should use the Congestion-Treatment AVP which also reduces Diameter traffic during congestion events.

The security considerations of the Diameter protocol itself have been discussed in RFC 6733 [RFC6733].  Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol.
___------------------------

>>>Other points (just piling on here at this point):
>>>1.  Some MIBs have this data but policy decision points have existing Diameter based sessions.
>>>2.  This solution works if the traffic is encrypted  or not - providing a necessary and sufficient baseline for congestion management.

>>> We thought that Section 5.2, 2nd last para, last sentence expressed our intent but highlighting it again in Section 6 is not an issue.  In summary, the addition of the AVPs lessens DPI requirements for congestion management and a need for the traffic to be unencrypted in order to take congestion management action.  Arguably there may be better management methods that require clear or other drivers for DPI but if one bases action on ECN, flow, packet and byte count then DPI are clear traffic is not required.
Editorial:

-- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.)

-- 3.2, first paragraph "In case..."

I suggest either "If..." or "In the case that..."

>>>> We will change to "In the case that..."

-- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..."

>>>> Yes. We will correct.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.