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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 03 Aug 2009 18:32:01 -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?)

---

From: "Sun, Dong (Dong)" <[email-masked]>
Date: Mon, 3 Aug 2009 18:51:57 -0500

Joel,

Thanks for review and comments. See inline...

The revised version will be uploaded if you are ok with the resolutions.

Regards,
Dong 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 6:32 PM
To: Mary Barnes; General Area Review Team; [email-masked]
Cc: [email-masked]
Subject: [Gen-art] review: draft-ietf-dime-diameter-qos-10.txt

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.

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.

>> The QAR is used to send a trigger for the authorization process in the Diameter QoS Server (DQS). The NE will not perform the QoS service (resource reservation/allocation) until receiving the QAA with authorization result/permission from DQS server.

The START mainly refers to a separate accounting session, it is decoupled from QoS authorization session. I think we could remove the related call flows for accounting from the diagram. Any objection?

>> it is not part of QoS authorization process. See resolution above.

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.

>> The dynamic discovery refers to the peer discovery described in section 5.2 of RFC 3588. Then it uses the selection criteria to nail down the related Diameter cilent that has a relationship with the affected user. The clarification is added as follow:
- section 4.2.3, a) "... or dynamic discovery as described in section 5.2 of [RFC3588]"; b) "the Diameter QoS application node selects and retrieves the location information of the peer node that is associated with the affected user based on some .."

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.

>> good catch. Corrected.

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

>> QAA is sent by Diameter QoS server towards client. Not sure what you mean? Do you actually say 'QAR'? If the case, there is no change from state machine specified by existing RFCs e.g. RFC 3588/4005.

---

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

Make sure you check with the AD / Shepard before releasing the revision.

With regard to the proposed solution to the START message, if I 
understand you right you are proposing getting rid of any reference to 
that message.  This proposal is unclear in two regards.

Firstly, the message shown is a QAR.  Clearly, since this document 
introduces that message, there was no other document talking about 
sending a QAR as an accounting start.  If the intent was that this 
document instruct clients to issue QAAR to accounting servers as 
accounting-starts, then you need to say that.

If those QAR(START ...) references were supposed to be ordinary, 
existing, accounting start messages, then the question is whether 
existing documents indicate that the QoS information should be included 
in those accounting start messages.  The information is needed for 
proper accounting, so something has to tell folks to send it.  If that 
was the intent, and if other documents already say it, then you can 
remove it.

If I have understood the intended clarification on dynamic discovery, 
then that looks fine.  I will look at it upon the re-review when the 
final document comes out.

Yours,
Joel

---

From: "Sun, Dong (Dong)" <[email-masked]>
Date: Mon, 3 Aug 2009 19:27:38 -0500

Joel,
Thanks for quick response. 

In order to avoid the conflict with accounting as described in section 8, where it states ACR will be used to report the QoS usage info, the QAR (Start) could be replaced by ACR. Is it ok?

Anyway, as shown in Fig 6, it is not part of QoS authorization process.

Thanks,
Dong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 8:13 PM
To: Sun, Dong (Dong)
Cc: 'Mary Barnes'; 'General Area Review Team'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [Gen-art] review: draft-ietf-dime-diameter-qos-10.txt

With regard to the proposed solution to the START message, if I understand you right you are proposing getting rid of any reference to that message.  This proposal is unclear in two regards.

Firstly, the message shown is a QAR.  Clearly, since this document introduces that message, there was no other document talking about sending a QAR as an accounting start.  If the intent was that this document instruct clients to issue QAAR to accounting servers as accounting-starts, then you need to say that.

If those QAR(START ...) references were supposed to be ordinary, existing, accounting start messages, then the question is whether existing documents indicate that the QoS information should be included in those accounting start messages.  The information is needed for proper accounting, so something has to tell folks to send it.  If that was the intent, and if other documents already say it, then you can remove it.

If I have understood the intended clarification on dynamic discovery, then that looks fine.  I will look at it upon the re-review when the final document comes out.

Yours,
Joel

Sun, Dong (Dong) wrote:
> To: Mary Barnes; General Area Review Team; 
> [email-masked]