Skip to main content

Diameter Quality-of-Service Application
RFC 5866

Yes

(Dan Romascanu)

No Objection

(Alexey Melnikov)
(Lisa Dusseault)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

(Dan Romascanu; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2009-10-24)
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.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-03-07)

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2009-08-12)
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.

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection ()