Skip to main content

Diameter Congestion and Filter Attributes
draft-ietf-dime-congestion-flow-attributes-02

Yes

(Kathleen Moriarty)
(Terry Manderson)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)

Note: This ballot was opened for revision 01 and is now closed.

Kathleen Moriarty Former IESG member
Yes
Yes (for -01) Unknown

                            
Terry Manderson Former IESG member
Yes
Yes (for -01) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-06-09 for -01) Unknown
If this means folks are using ECN more then I'm glad to hear it. :)

In Section 5.1 there are three instances of "ECP-IP-Codepoint." I think these are meant to be "ECN-IP-Codepoint" right?

In Section 6, I had the same thought as Ben. There could be some sensitivity about the fact that a particular user experienced congestion, and that's worth calling out.

Comment for the WG: I note that RFC 6733 requires Diameter nodes to be able to negotiate TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA (among other cipher suites) for use with TLS and DTLS. Given the publication of RFC 7465, those requirements should be revisited.
Alvaro Retana Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-06-09 for -01) Unknown
I think IANA gets what they need to do, but the RFC Editor will have to replace four different "TBD" with four different values.  It'd have been better to use "TBD1", "TBD2", "TBD3", and "TBD4", to make it less likely that something will go amiss.  It's probably fine to just say that you need to check it closely during AUTH48, to make sure that the right values got into the right places.
Ben Campbell Former IESG member
No Objection
No Objection (2015-07-02) Unknown
Thanks for addressing my comments. I still think the abstract is overly long (the first paragraph would have been enough), but that's up to you.  Otherwise, I think all my comments have been covered.
Benoît Claise Former IESG member
No Objection
No Objection (2015-06-10 for -01) Unknown
With some DIAMETER background, I can understand what the document specifies.
However, I agree with Martin's COMMENT, and Stephen's abstract-related COMMENT. The document should be improved
Brian Haberman Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-06-11 for -01) Unknown
the opsdir reviewer noted some questions which I think fall in line with some observations about document improvement:

from linda dunbar:

> I have reviewed this document as part of the Operational directorate's> ongoing effort to review all IETF documents being processed by the IESG.> These comments were written primarily for the benefit of the operational> area directors. Document editors and WG chairs should treat these> comments just like any other last call comments.> >  > > I have some questions for the proposed AVPs by this document.> > -          The ECN is marked on packets by network nodes in the middle.> Is it the Receiver of ECN marked data packets sending the proposed AVPs> to the Diameter Server?> > -          If no ECN marked data packets are received, does it mean the> receiver won’t send the AVPs being proposed by the draft?> > -          Diameter is the protocol for Authentication, Authorization,> and Accounting.  Is it the “originator” sending the AAA request? If yes,> the “Originator” may not even have any ECN marked packets, how does the> flow “Originator” constructed the proposed AVPs?>
Martin Stiemerling Former IESG member
(was Discuss) No Objection
No Objection (2015-07-09) Unknown
Sorry for taking so long and thank you for addressing David's and my concerns.
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-06-10 for -01) Unknown
I support Martin's Discuss, based on David's Gen-ART review.
Stephen Farrell Former IESG member
No Objection
No Objection (2015-06-08 for -01) Unknown
- abstract: This isn't clear enough that you're talking about
using Diameter to help manage networks in which ECN may be
used, as opposed to dealing with Diameter packets with the ECN
bit set. While that may be obvious when one reads the text,
some people will only see the abstract so I'd say maybe
consider clarifying that here too.

- intro: "the document" in 1st sentence is ambiguous - do you
mean 3168 or this document? I assume s/the/this/ would be
better.

- intro: 2nd last para: what is an "ECN application"? Maybe you
mean "networks deploying/using ECN" or something?

- 3.3: is a 64-bit counter maybe too big for a number of flows?
Would it be worth adding guidance to the effect that Diameter
nodes ought have some max-believeable-flows setting just to
avoid fat-finger or similar errors resulting in someone
thinking there are 2^64-1 flows and trying to iterate over that
number of things or allocate O(that) much memory?

- 3.4: do you need to specify some kind of wrap-around rule for
this? What value do I need to use if I've seen 2^64 packets?

- 5.2: Please expand CCR on 1st use and provide a reference if
one is needed. (Is it "Credit Control Request"?)

- 5.2: 2nd last para, last sentence: Thanks! I think it's good
that folks are including this consideration in ongoing work.

- Section 6: 1st sentence is not needed and is usually a red
flag statement (for me, but not only me:-) Actually, you could
just lose the first para entirely.

(Two more quite nitty things below, but I'll ask anyway:-)

- section 6: does this define any new way in which a bad
sending Diameter node could cause bad things to happen elsewhre
in the network? (see comment above about section 3.3) 

- section 6: When I took a glance at the security
considerations in 5777, it doesn't seem to consider that the
"treatment" field could cause bad things to happen.  Is that
worth mentioning here (if real) even if it ought be more
properly handled in some kind of update of 5777 sometime in the
(probably far;-) future?