Skip to main content

Diameter Quality-of-Service Application
draft-ietf-dime-diameter-qos-15

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 IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2009-10-24) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2010-03-07) Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (2009-08-12) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown