Subject: [Gen-art] review: draft-ietf-dime-diameter-qos-10.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 03 Aug 2009 18:18:26 -0400

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dime-diameter-qos-10.txt
     Diameter Quality of Service Application
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 4-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as a Proposed 
Standard

Minor issues:  If I am understanding the message flows in section 4.2.1 
and 4.2.2 properly, the QAR which serves as a notification that QoS 
service is taking place (rather than as a request for authorization) 
uses "START" as a special indicator of this difference in usage.  I can 
not determine what this "START" indication actually is.  When I look at 
the ABNF in section 5.1 for the QAR, I can not determine where this 
indication would go.

In a related question, is there a reason that the data flows in section 
9 do not show this QAR(START...) message?

Nits/editorial comments:
Section 4.2.2 suggests that the AE may be able to dynamically discover 
the correct NE which is to be the target of a push operation to push out 
QoS authentication information.  It then points to section 4.2.3. 
Section 4.2.3 points to the Diameter base specification, which as far as 
I understand it, would not have any way to provide for a Diameter server 
to discover a diameter client.  I realize that this is a hard problem, 
and that in reality various heuristics or configuration are used.  The 
text appears to lead the reader into a wild goose chase looking for the 
magic answer.  I am not sure what correction could or should be applied, 
because I can not guess the assumptions being made in regard to the 
problem of push target selection.  If the assumption is that the push 
target is a DIME client associated in some way with the affected user, 
that could be usefully stated.

I think there is a typo in the second paragraph of section 6.1.  The 
text reads "The following states are supplemented to the state machine 
on the client ...:"  I am pretty sure that for this paragraph it should 
read "...the state machine on the server..."  The header reads "SERVER, 
STATEFUL", and the events are events seen at the server and the actions 
are server actions.  The paragraph after the table, and the following 
table, are really about and for the client.

In a related question, is there no change in server state when either 
the initial QAA or that "START" QAA are received?  (Or are these only 
related to accounting state, which is not covered in this document?)