Diameter Quality-of-Service Application
RFC 5866
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
(Dan Romascanu; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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
(Lisa Dusseault; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
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
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection