Diameter Quality-of-Service Application
RFC 5866

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

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-10-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Thanks for working hard on my Discusses and Comments.

One minor issue from the Discuss remains, but it is so small that I have cleared.

If you are working on the I-D for a further spin, through an RFC Editor note, or in Auth48, perhaps you could look at it.

I wrote...

> Section 3.4
> This section seems to drift in and out of RFC 2119 language.
> Probably, since this is stating requirements, you should move
> to using 2119 in each bullet point.

In an email exchange I expanded this to highlight the specific paragraphs...

> non-2119 language I see...
> Accounting Records
>    The Diameter QoS application may define QoS accounting records
>    containing duration, volume (byte count) usage information and
>    description of the QoS attributes (e.g., bandwidth, delay, loss
>    rate) that were supported for the flow.
> Accounting Correlation
>    The Diameter QoS application may support the exchange of
>    sufficient information to allow for correlation between accounting
>    records generated by the NEs and accounting records generated by
>    an AppS.
> Interaction with other AAA Applications
>    Interaction with other AAA applications such as Diameter Network
>    Access (NASREQ) application [RFC4005] is required for exchange of
>    authorization, authentication and accounting information.
> Looks like may/MAY and required/REQUIRED

I don't think there was any follow-up email on this, so it probably  just got missed.

(Russ Housley) No Objection

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) No Objection

(Robert Sparks) No Objection

Comment (2009-08-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The illustrative flows throughout the document focus on messages where requests succeed. Should there be any discussion of what happens when something fails? (For a twisted example, consider 4.4.1)

The example in 9.2 suggests the SIP Server delay forwarding the 200 OK
it is processing until the RAR/RAA round completes. Unless that's really what you meant, please consider adding text noting that the 200 could be sent while the NE was being touched. If it _is_ really what you meant, then
more discussion of what to do if that activation fails or takes a long time is in order.