Diameter Quality-of-Service Application
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' **)
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' **)
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.