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

[Ballot comment]
[...]

  The authorization token allows the
  authorization decision performed at the application layer can be

s/can/to ?

  associated with a corresponding QoS signaling session.


11.  Security Considerations

  Therefore, sufficient
  information needs to be made available to the Authorizing Entity to
  can make such an authorization decision.

This sentence doesn't read well.

[Ballot comment]
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.

[Ballot comment]
[...]

  The authorization token allows the
  authorization decision performed at the application layer can be

s/can/to ?

  associated with a corresponding QoS signaling session.


11.  Security Considerations

  Therefore, sufficient
  information needs to be made available to the Authorizing Entity to
  can make such an authorization decision.

This sentence doesn't read well.

[Ballot discuss]
Updated as per version 12:

I have several blocking comments, but I believe they should be easy to address:

1).
5.1.  QoS-Authorization Request (QAR)

  The message format is defined as follows:

This doesn't tell which formal syntax is used. Please add a reference to
in section 3.2 of RFC 3588:

If you change that not to say "ABNF", then you can also remove the following Normative Reference:
  [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

    ::= < Diameter Header: [TBD1], REQ, PXY >
                        < Session-Id >
                        { Auth-Application-Id }
                        { Origin-Host }
                        { Origin-Realm }
                        { Destination-Realm }
                        { Auth-Request-Type }
                        [ Destination-Host ]
                        [ User-Name ]
                      *  [ QoS-Resources ]
                        [ QoS-Authorization-Data ]
                        [ Bound-Auth-Session-Id ]
                      *  [ AVP ]


2). DISCUSS DISCUSS:

The draft defines:

    ::= < Diameter Header: 258, REQ, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Destination-Realm }
                              { Auth-Request-Type }
                              [ Destination-Host ]
                          *  [ QoS-Resources ]
                              [ Session-Timeout ]
                              [ Authorization-Session-Lifetime ]
                              [ Authorization-Grace-Period ]
                              [ Authorization-Session-Volume ]
                          *  [ AVP ]

RFC 3588 defines:
        ::= < Diameter Header: 258, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Destination-Host }
                { Auth-Application-Id }
                { Re-Auth-Request-Type }
                [ User-Name ]
                [ Origin-State-Id ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]

Can you explain why "{ Destination-Host }" became "[ Destination-Host ]"?
Also some other optional fields were removed entirely in the draft.

And a similar question in respect to section 5.6 versa RFC 3588, section 8.3.2.

3). DISCUSS DISCUSS:

In Section 10.2:

  Sub-registry: Auth-Application-Id  AVP Values (code 258)
  Registry:
  AVP Values          Attribute Name            Reference
  -------------  -------------------------------------------
  to be assigned    DIAMETER-QOS-NOSUPPORT      Section 5
  to be assigned    DIAMETER-QOS-SUPPORT        Section 5


  Sub-registry: Acct-Application-Id  AVP Values (code 259)
  Registry:
  AVP Values          Attribute Name            Reference
  -------------  -------------------------------------------
  to be assigned    DIAMETER-QOS-NOSUPPORT      Section 5
  to be assigned    DIAMETER-QOS-SUPPORT        Section 5

Is one of these values referenced as [TBD5] in section 5. Which one?

[Ballot comment]
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.

[Ballot comment]
Section 1

Would be nice to include a reference to RFC3588 early in this section.

---

Section 2 Network Element (NE)

      The Network Element corresponds to the Policy
      Enforcement Point (PEP) [RFC2753].

Not sure I like this interpretation of RFC 2753. Doesn't the NE here
correspond to the "Network Node" in 2753? In 2753, the PEP is located
within the Network Node (but not all Network Nodes contain a PEP).

Indeed, Figure 1 shows NEs without diameter clients.

How about changing to...
     
      The Diameter Client at an NE corresponds to the Policy
      Enforcement Point (PEP) [RFC2753].

---

Section 10.5

It would be helpful (and safer) to used the TBD1, TBD2, etc. as used in
section 5 and onwards.

TBD5 is present in section 5, but I can't correlate it to anything in
section 10.

===

Nits

---

Section 1 para 3

s/this note/this document/

---

Section 2 AAA Cloud                                                       

Can you make it clearer that "AAA" means "authentication, authorization
and accounting"

Perhaps just change the title to...

  Authentication, Authorization and Accounting Cloud (AAA Cloud)


---

Figure 4 is a bit messy around the sides of the AAA cloud.

---

Figures 3, 4, and 5

A bit confusing that the figures show "Entity requesting resource," but
the text refers to the RRE (Resource Requesting Entity".

---

Section 12
Does "Rajith R" have a full name?

[Ballot discuss]
A solid document, but I have a number of Discuss issues and some Comments that follow...

Section 3. Final paragraph.

  If defined properly, the interface between the NEs and AAA cloud
  would be identical whether the AE communicates with an AppS or not.
  Routers are therefore insulated from the details of particular
  applications and need not know that Application Servers are involved
  at all.  Also, the AAA cloud would naturally encompass business
  relationships such as those between network operators and third-party
  application providers, enabling flexible intra- or inter-domain
  authorization, accounting, and settlement.

This is a bit messy!

"If defined properly..." Well, have you done it or not? :-)
"Routers are therefore..." Because of the need for proper design?

How about...

  If the interface between the NEs and the AAA cloud is identical
  regardless of whether the AE communicates with an AppS or not,
  routers are insulated from the details of particular applications
  and need not know that Application Servers are involved.

"Also, the AAA cloud..." Does also apply to the interface definition?
"...naturally..." There is nothing natural about computers :-)

I think you should split the paragraph as

  The AAA cloud may also encompass business relationships such as
  those between network operators and third-party application
  providers. This enables flexible intra- or inter-domain
  authorization, accounting, and settlement.

---

Figure 2

Shouldn't the signaling flow be unidirectional in this figure.
As drawn, it appears that the Input Packet Processor is capable of
sending Signaling packets upstream!
                                                                               
It would be nice if you put arrow heads on the signaling flow from
Input Packet Processor, to the two signaling message processors,
and back to the Forwarding Engine.

I'm not clear why you have the signaling flow leaving the router
without classification of scheduling.

---

Section 3.2.2

  For Category 1 and 2 Application Endpoints, Push mode is required.
  For a Category 3 AppE, either Push mode or Pull mode MAY be used.

Either "REQUIRED" or "may".
I suspect that RFC 2119 language is not applicable in this section.

---

Section 3.2.2

  Diffserv-enabled IP/MPLS as defined by
  other SDOs (e.g., ETSI TISPAN and ITU-T}

I am nervous about the statement that other SDOs define DiffServ-enabled
IP/MPLS.

Would it be possible to truncate as

  Diffserv-enabled IP/MPLS.

---

Section 3.3.1

  In the two-party case no Diameter QoS
  protocol interaction is REQUIRED.

I don't think you need 2119 language, but if you do, you should use
"NOT REQUIRED."

---

Figures 3, 4, and 5 and Section 4.3

Each of these figures shows "Financial Settlement" as an interaction, and                                                                       
specifically shows it avoiding the AAA Cloud. Yet the description of the
term does not show up until section 4.3 some considerable time later. You
need to at least include a forward reference.

Or is this the "business relationship, such as a roaming agreement"
immediately after Figure 3?

In any case, I am not comfortable with the concept of an NE being
financially compensated for the services it performs. Surely the
financial compensation takes place between RRE and QosAuthz. We must
also recall that the magnitude of the compensation is part of the
policy consideration.

---

Section 3.4

  Inter-domain support
      In particular, users may roam outside their home network, leading
      to a situation where the NE and AE are in different administrative
      domains.

I'm not sure!

It is actually the AppE roaming that we are interested in, but that is
not important.

You are suggesting that *the* AE may be in different administrative
domain from at least one NE on the media flow. But I find it hard to
believe that a domain adminstator will allow this to be the case. The
only tools that can authorize resource administration in my domain are
my AEs.

This leads to a more complex situation where the RRE might belong to a
different administrative domain from the AE, and where AEs have to
cooperate (one AE acting as RRE for the next AE).

This is such a complex architectural requirement that I wonder why you
dont limit yourselves to a single administrative domain at least until
you have that working.

---

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.

---

Figure 10

Why is the QoS Response shown before the STA?
Surely the STA could say "not authorized."

Furthermore, is it really safe to delete the QoS State and send the
QoS Response to the End Host Requesting Reserveation before receiving
the QoS Response from the QoS Responder Node? Compare this with the
setup process in Figure 6 - I expected a degree of symmetry. Including
text to explain the lack of symmetry would be fine.

Additionally, the acronym STA is not explained.

---

BSD license.

The I-D includes ABNF fragments so we will need to include a BSD license.

---

ABNF reference

RFC Editor will catch this, but why not use RFC 5234?
On the other hand, see Alexey's comment. Either way, you need a normative reference to the form of BNF you are using.

[Ballot comment]
3.3.1.  Pull Mode Schemes

  In the 'Two Party Scheme', the QoS RRE is authenticated by the NE and
  the authorization decision is made either locally at the NE itself or
  offloaded to a trusted entity (most likely within the same
  administrative domain).  In the two-party case no Diameter QoS
  protocol interaction is REQUIRED.

Last sentence: this doesn't look like a proper use of RFC 2119 keywords,
as the sentence doesn't state any requirement.

[...]

  The authorization token allows the
  authorization decision performed at the application layer can be

s/can/to ?

  associated with a corresponding QoS signaling session.


4.3.  Session Re-authorization

  In addition, the AE may use a RAR to perform re-authorization with

The acronym RAR is mentioned here for the first time, so it should be
expanded.

  the authorized parameters directly when the re-authorization is
  triggered by service request or local events/policy rules.


11.  Security Considerations

  Therefore, sufficient
  information needs to be made available to the Authorizing Entity to
  can make such an authorization decision.

This sentence doesn't read well.

[Ballot discuss]
I have several blocking comments, but I believe they should be easy to address:

1).
5.1.  QoS-Authorization Request (QAR)

  The message format, presented in ABNF form [RFC4234], is defined as
  follows:

No, this is not a valid ABNF. This is using the format defined
in section 3.2 of RFC 3588, which in its turn is defined using ABNF.

If you change that not to say "ABNF", then you can also remove the following Normative Reference:
  [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

    ::= < Diameter Header: [TBD1], REQ, PXY >
                        < Session-Id >
                        { Auth-Application-Id }
                        { Origin-Host }
                        { Origin-Realm }
                        { Destination-Realm }
                        { Auth-Request-Type }
                        [ Destination-Host ]
                        [ User-Name ]
                      *  [ QoS-Resources ]
                        [ QoS-Authorization-Data ]
                        [ Bound-Auth-Session-Id ]
                      *  [ AVP ]


2). DISCUSS DISCUSS:

The draft defines:

    ::= < Diameter Header: 258, REQ, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Destination-Realm }
                              { Auth-Request-Type }
                              [ Destination-Host ]
                          *  [ QoS-Resources ]
                              [ Session-Timeout ]
                              [ Authorization-Session-Lifetime ]
                              [ Authorization-Grace-Period ]
                              [ Authorization-Session-Volume ]
                          *  [ AVP ]

RFC 3588 defines:
        ::= < Diameter Header: 258, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Destination-Host }
                { Auth-Application-Id }
                { Re-Auth-Request-Type }
                [ User-Name ]
                [ Origin-State-Id ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]

Can you explain why "{ Destination-Host }" became "[ Destination-Host ]"?
Also some other optional fields were removed entirely in the draft.

And a similar question in respect to section 5.6 versa RFC 3588, section 8.3.2.

3). DISCUSS DISCUSS:

In Section 10.2:

  Sub-registry: Auth-Application-Id  AVP Values (code 258)
  Registry:
  AVP Values          Attribute Name            Reference
  -------------  -------------------------------------------
  to be assigned    DIAMETER-QOS-NOSUPPORT      Section 5
  to be assigned    DIAMETER-QOS-SUPPORT        Section 5


  Sub-registry: Acct-Application-Id  AVP Values (code 259)
  Registry:
  AVP Values          Attribute Name            Reference
  -------------  -------------------------------------------
  to be assigned    DIAMETER-QOS-NOSUPPORT      Section 5
  to be assigned    DIAMETER-QOS-SUPPORT        Section 5

Is one of these values referenced as [TBD5] in section 5. Which one?

[Ballot discuss]
I have several blocking comments, but I believe they should be easy to address:

1).
5.1.  QoS-Authorization Request (QAR)

  The message format, presented in ABNF form [RFC4234], is defined as
  follows:

No, this is not a valid ABNF. This is using the format defined
in section 3.2 of RFC 3588, which in its turn is defined using ABNF.

    ::= < Diameter Header: [TBD1], REQ, PXY >
                        < Session-Id >
                        { Auth-Application-Id }
                        { Origin-Host }
                        { Origin-Realm }
                        { Destination-Realm }
                        { Auth-Request-Type }
                        [ Destination-Host ]
                        [ User-Name ]
                      *  [ QoS-Resources ]
                        [ QoS-Authorization-Data ]
                        [ Bound-Auth-Session-Id ]
                      *  [ AVP ]


2). DISCUSS DISCUSS:

The draft defines:

    ::= < Diameter Header: 258, REQ, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Destination-Realm }
                              { Auth-Request-Type }
                              [ Destination-Host ]
                          *  [ QoS-Resources ]
                              [ Session-Timeout ]
                              [ Authorization-Session-Lifetime ]
                              [ Authorization-Grace-Period ]
                              [ Authorization-Session-Volume ]
                          *  [ AVP ]

RFC 3588 defines:
        ::= < Diameter Header: 258, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Destination-Host }
                { Auth-Application-Id }
                { Re-Auth-Request-Type }
                [ User-Name ]
                [ Origin-State-Id ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]

Can you explain why "{ Destination-Host }" became "[ Destination-Host ]"?
Also some other optional fields were removed entirely in the draft.

And a similar question in respect to section 5.6 versa RFC 3588, section 8.3.2.

IANA questions/comments:

- In Action 2 (Section 10.2) the document requests allocation in
nonexistent registries. Do you want to create the
Auth-Application-Id AVP Values (code 258) and
Acct-Application-Id AVP Values (code 259) registries? If so,
you will need to specify the registry semantics.

- In Table 1 in Section 4.2.1 you mention "QoS-Authz-Data" but that
AVP is not registered. You probably mean "QoS-Authorization-Data,"
but the short-hand could be confusing to readers. Is this what you
mean? The document use similar shorthands in Figure 6.

- In Section 5 you again use short-hand names for commands. Shouldn't
you be consistent with the names?


IANA Notes: This document depends on the IANA Actions in
ietf-dime-qos-attributes


Action 1 (Section 10.1):

Upon approval of this document, IANA will make the following
assignments in the "AVP Codes" registry at
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

AVP Code Attribute Name Reference
-----------------------------------------------------------
TBD QoS-Authorization-Data [RFC-dime-diameter-qos-09]
TBD Bound-Auth-Session-Id [RFC-dime-diameter-qos-09]


Action 2 (Section 10.2):

TBD? (Do you want IANA to create these new registries?)


Action 3 (Section 10.4):

Upon approval of this document, IANA will make the following
assignment in the "Application IDs" registry at
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml


ID values Name Reference
-----------------------------------------------------------
TBD Diameter QoS application [RFC-dime-diameter-qos-09]


Action 4 (Section 10.5):

Upon approval of this document, IANA will make the following
assignments in the "Command Codes" registry at
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Code Value Name Reference
-----------------------------------------------------------
TBD QoS-Authorization-Request (QAR) [RFC-dime-diameter-qos-09]
TBD QoS-Authorization-Answer (QAA) [RFC-dime-diameter-qos-09]
TBD QoS-Install-Request (QIR) [RFC-dime-diameter-qos-09]
TBD QoS-Install-Answer (QIA) [RFC-dime-diameter-qos-09]


We understand the above to be the only IANA Actions for this document.

PROTO WRITEUP for draft-ietf-dime-diameter-qos-08.txt
======================================================

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The document shepherd is Victor Fajardo. I have personally reviewed the
document and I believe it is ready for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document defines a new Diameter QoS application. It is designed to
provide a general method for signaling QoS authorization decisions and
associated QoS parameters. Since it encompasses a very visible and highly
used aspect of the core network, it has had thorough review from WG members
as well as participants from other SDOs who maybe impacted by the work.
The document shepherd has no concerns about the depth of the reviews.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

There are no concerns with this document.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no concerns with this document. 

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is consensus in the WG behind the document. The problem space is
well understood and the solution is acceptable to the WG, as well
as other interested SDOs.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

There is no opposition to this document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document does not contain nits.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document has been split into normative and informative references.
There are normative references that are work in progress. These are the
following:

  [I-D.ietf-dime-qos-attributes]
              Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
              and A. Lior, "Quality of Service Attributes for Diameter",
              draft-ietf-dime-qos-attributes-08 (work in progress),
              October 2008.

  [I-D.ietf-dime-qos-parameters]
              Korhonen, J. and H. Tschofenig, "Quality of Service
              Parameters for Usage with the AAA Framework",
              draft-ietf-dime-qos-parameters-07 (work in progress),
              November 2008.

It is expected that these referenced documents will complete
standardization
well before the diameter-qos application document. There are no normative
references that are downward referenced.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The document has an IANA considerations section that is consistent with
the body.
The document only request allocations of new Application-Id, Command
codes and AVP
codes in the IETF namespace. Following RFC 3588, IETF consensus is
required for the
block allocations needed in this doc. The consensus process given to
this doc by the
DIME WG serves as consensus for IANA allocation requirements.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The document contains ABNF rules specified in RFC 3588. The ABNF content
has been validated.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

  Technical Summary

    The document specifies a framework, messages and AVPs for
    performing QoS authorization operations. It defines a QoS Diameter
    application that allows network elements (QoS aware routers) to
    interact with Diameter servers to authorize QoS request. It
    has been designed to operate in both 'Push' or 'Pull' mode
    where QoS authorization state is either sent to the network
    element pro-actively (Push) or the network element directly
    request QoS authorization from the Diameter server.

    A set of commands and AVPs has been defined to support both
    operating modes. A supplemental state machine that augments
    the Diameter base protocol (RFC3588) state machine has also been
    defined to cleanly support Push mode operations. The document
    also describes QoS authorization session establishment as well
    as re-authorization. It provides examples and call flows that
    describes how QoS authorization can be used other applications
    (e.g. NSLP, SIP).

  Working Group Summary

    There was consensus in the WG to publish the document.

  Document Quality

    The document has been sent for review to NSIS and relevant QoS folks.
    This document defines a core component of a Network Operators QoS
    architecture and thus have gone through a long review process
    both within DIME WG and outside of it. It has also traversed
    several re-start iteration before its current acceptable state.

  Personnel

    Victor Fajardo is the document shepherd for this document.