Traffic Classification and Quality of Service (QoS) Attributes for Diameter
draft-ietf-dime-qos-attributes-15

[Ballot discuss]
Section 5.1:

I can't really understand how one can define actions without actually defining what one should do and how to provide the information necesaray for the action. Both Shaping and Marking clearly needs to define how the actions are going to be carried out and what the parameters are.

[Ballot comment]
I cleared by Discuss based on comments from Max Riegel that the filters already exist in equipment and can be configured manually. This work simply provides a protocol mechanism for distributing the configuration.

I would like the authors to consider two comments.

1. Should you at least tell the SDOs that own the technology that you have eveloped a protocol mechanism for distributing the filters that can be used in relation to their technology?

2. Would it be helpful if the I-D said somewhere "this type of filter already exists in lots of hardware especially WiMAX boxes and these protocol extensions simply allow the distribution of information to configure existing filters?

[Ballot discuss]
Half of my Discuss has been addressed with the revised text in v13. It is now clear that Ethernet encapsulation is intended to be in scope of the document.

That just leaves me with the high-level issue of whether we need to consult the IEEE about this work. Perhaps your Wg chairs or AD can discuss this with our IEEE liaisons.

[Ballot discuss]
Section 5.1:

I can't really understand how one can define actions without actually defining what one should do and how to provide the information necesaray for the action. Both Shaping and Marking clearly needs to define how the actions are going to be carried out and what the parameters are.

[Ballot discuss]
Please provide a normative reference to the formal lagnuage (notation) you are using in the document to describe the rules. Two IESG statements are relevant to this:

http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
http://www.ietf.org/IESG/STATEMENTS/syntax-format-def.txt

There are also missing references to imported definitions, like address in section 4.1.7.2

Section 5.1:

I can't really understand how one can define actions without actually defining what one should do and how to provide the information necesaray for the action. Both Shaping and Marking clearly needs to define how the actions are going to be carried out and what the parameters are.

Section 10.1:

The registry for where the registration is going to happen is not really specified: I assume that the registry intended is:

"Authentication, Authorization, and Accounting (AAA) Parameters" : "AVP codes" but that is not clear. Please write out the registries names.

Section 10.2 and 10.3: Also here the clarify of what the registration request is for is not clear. I assume that you are requesting to add a new registry for "AVP specific values" under the "Authentication, Authorization, and Accounting (AAA) Parameters" page.

Can you make this clear so it is easier to find the correct registries in the future.

[Ballot comment]
It is hard for me to see how the general security considerations for Diameter can be sufficient for QoS.  QoS features have a specific threat model, with some threats that other Diameter applications don't have and vice versa.

[Ballot comment]
Section 4.1.7.16., paragraph 1:
>    The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies
>    the first port number of an IP port range.

  Ports are not IP-layer entities. They only have meaning within
  specific transport protocols, you can't talk about them without tying
  them to a transport protocol. (Also note that DCCP for example also
  uses service codes in addition to ports!)

[Ballot discuss]
DISCUSS-DISCUSS: I fail to understand why matching on TCP options and
  flags (4.1.6.7.-10.) is necessary for QoS handling. QoS is meaningful
  for flows, not individual packets. Also, if you consider it essential
  for some reason to match on transport-header details, why aren't the
  other transport protocols included here?


Section 5.1., paragraph 4:
>      All traffic that is met by the condition part of a rule MUST be
>      dropped.  This action implements firewalling functionality.

  DISCUSS: Firewall functionality is NOT QoS. How is this in scope of
  the DIME work item on QoS?

[Ballot comment]
Figure 1 and figure 5 have minor alignment problems.

Section 5 says:
  This section illustrates the actions associated with a rule.
But it appears to me that the subsequent subsections *define* the actions.

It would be really nice if the IANA section named the registries from which the allocations are to be made.

[Ballot discuss]
I hope this is a minor Discuss that can be addressed with a clarifying email.

Section 4.1.8.14 through 4.1.8.23 apply to matching on Ethernet fields. It is unclear to me what this is doing in an IETF document.
- What happens if the L2 protocol is not Ethernet?
- Have you consulted the owning SDO for Ethernet?

If Ethernet encapsulation really is in scope, perhaps this could be highlighted in the Abstract and Introduction.

IANA questions/comments:

- Do you want a registry of the TCP-Flag-Type AVP Values (Section 4.1.8.10)?

- What are the maximum size of QoS-Semantics AVP Values and the
QoS-Action AVP Values in Actions 2 and 3?


Action 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-Resources | [RFC-dime-qos-attributes-12]
TBD |QoS-Rule | [RFC-dime-qos-attributes-12]
TBD |QoS-Rule-Precedence | [RFC-dime-qos-attributes-12]
TBD |Classifier | [RFC-dime-qos-attributes-12]
TBD |Classifier-ID | [RFC-dime-qos-attributes-12]
TBD |Protocol | [RFC-dime-qos-attributes-12]
TBD |Direction | [RFC-dime-qos-attributes-12]
TBD |From-Spec | [RFC-dime-qos-attributes-12]
TBD |To-Spec | [RFC-dime-qos-attributes-12]
TBD |Negated | [RFC-dime-qos-attributes-12]
TBD |IP-Address | [RFC-dime-qos-attributes-12]
TBD |IP-Address-Range | [RFC-dime-qos-attributes-12]
TBD |IP-Address-Start | [RFC-dime-qos-attributes-12]
TBD |IP-Address-End | [RFC-dime-qos-attributes-12]
TBD |IP-Address-Mask | [RFC-dime-qos-attributes-12]
TBD |IP-Mask-Bit-Mask-Width | [RFC-dime-qos-attributes-12]
TBD |MAC-Address | [RFC-dime-qos-attributes-12]
TBD |MAC-Address-Mask | [RFC-dime-qos-attributes-12]
TBD |MAC-Address-Mask-Pattern | [RFC-dime-qos-attributes-12]
TBD |EUI64-Address | [RFC-dime-qos-attributes-12]
TBD |EUI64-Address-Mask | [RFC-dime-qos-attributes-12]
TBD |EUI64-Address-Mask-Pattern | [RFC-dime-qos-attributes-12]
TBD |Port | [RFC-dime-qos-attributes-12]
TBD |Port-Range | [RFC-dime-qos-attributes-12]
TBD |Port-Start | [RFC-dime-qos-attributes-12]
TBD |Port-End | [RFC-dime-qos-attributes-12]
TBD |Use-Assigned-Address | [RFC-dime-qos-attributes-12]
TBD |Diffserv-Code-Point | [RFC-dime-qos-attributes-12]
TBD |Fragmentation-Flag | [RFC-dime-qos-attributes-12]
TBD |IP-Option | [RFC-dime-qos-attributes-12]
TBD |IP-Option-Type | [RFC-dime-qos-attributes-12]
TBD |IP-Option-Value | [RFC-dime-qos-attributes-12]
TBD |TCP-Option | [RFC-dime-qos-attributes-12]
TBD |TCP-Option-Type | [RFC-dime-qos-attributes-12]
TBD |TCP-Option-Value | [RFC-dime-qos-attributes-12]
TBD |TCP-Flags | [RFC-dime-qos-attributes-12]
TBD |TCP-Flag-Type | [RFC-dime-qos-attributes-12]
TBD |ICMP-Type | [RFC-dime-qos-attributes-12]
TBD |ICMP-Type-Number | [RFC-dime-qos-attributes-12]
TBD |ICMP-Code | [RFC-dime-qos-attributes-12]
TBD |ETH-Option | [RFC-dime-qos-attributes-12]
TBD |ETH-Proto-Type | [RFC-dime-qos-attributes-12]
TBD |ETH-Ether-Type | [RFC-dime-qos-attributes-12]
TBD |ETH-SAP | [RFC-dime-qos-attributes-12]
TBD |VLAN-ID-Range | [RFC-dime-qos-attributes-12]
TBD |S-VID-Start | [RFC-dime-qos-attributes-12]
TBD |S-VID-End | [RFC-dime-qos-attributes-12]
TBD |C-VID-Start | [RFC-dime-qos-attributes-12]
TBD |C-VID-End | [RFC-dime-qos-attributes-12]
TBD |User-Priority-Range | [RFC-dime-qos-attributes-12]
TBD |Low-User-Priority | [RFC-dime-qos-attributes-12]
TBD |High-User-Priority | [RFC-dime-qos-attributes-12]
TBD |Time-Of-Day-Condition | [RFC-dime-qos-attributes-12]
TBD |Time-Of-Day-Start | [RFC-dime-qos-attributes-12]
TBD |Time-Of-Day-End | [RFC-dime-qos-attributes-12]
TBD |Day-Of-Week-Mask | [RFC-dime-qos-attributes-12]
TBD |Day-Of-Month-Mask | [RFC-dime-qos-attributes-12]
TBD |Month-Of-Year-Mask | [RFC-dime-qos-attributes-12]
TBD |Absolute-Start-Time | [RFC-dime-qos-attributes-12]
TBD |Absolute-End-Time | [RFC-dime-qos-attributes-12]
TBD |Timezone-Flag | [RFC-dime-qos-attributes-12]
TBD |Timezone-Offset | [RFC-dime-qos-attributes-12]
TBD |QoS-Action | [RFC-dime-qos-attributes-12]
TBD |QoS-Profile-Id | [RFC-dime-qos-attributes-12]
TBD |QoS-Profile-Template | [RFC-dime-qos-attributes-12]
TBD |QoS-Semantics | [RFC-dime-qos-attributes-12]
TBD |QoS-Parameters | [RFC-dime-qos-attributes-12]
TBD |Excess-Treatment | [RFC-dime-qos-attributes-12]
TBD |QoS-Capability | [RFC-dime-qos-attributes-12]


Action 2:

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

Registry Name: QoS-Semantics AVP Values (code TBD)
Registration Procedures: Specification Required
Initial contents of this sub-registry will be:

AVP Value Attribute Name Reference
--------- -------------- ---------
(0) QoS-Desired [RFC-dime-qos-attributes-12]
(1) QoS-Available [RFC-dime-qos-attributes-12]
(2) QoS-Reserved [RFC-dime-qos-attributes-12]
(3) Minimum-QoS [RFC-dime-qos-attributes-12]
(4) QoS-Authorized [RFC-dime-qos-attributes-12]
5-XXX Unassigned


Action 3:

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

Registry Name: QoS-Action AVP Values (code TBD)
Registration Procedures: Specification Required
Initial contents of this sub-registry will be:

AVP Value Attribute Name Reference
--------- -------------- ---------
0 drop [RFC-dime-qos-attributes-12]
1 shape [RFC-dime-qos-attributes-12]
2 mark [RFC-dime-qos-attributes-12]
3-XXX Unassigned

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

AD review by Dan Romascanu

Please find below my AD review of draft-ietf-dime-qos-attributes-11.txt

T are Technical comments, E are editorial.

I believe that the document is in reasonable shape. Function of the responses to the review we may decide to do a revised ID or send it to IETF Last Call and consider the comments below as IETF LC comments.

Thanks and Regards,

Dan




T1. IP-Address in 4.15 and 4.16 should not include also a type AVP?
(IPv4 and IPv6) As written the specification and examples seem to deal with IPv4 only. SO I miss something?

T2. Was this specification sent for review to IEEE 802.1? I believe that it should - maybe during the IETF Last Call, especially because of the VLAN and priority AVPs semantics. For example one of the questions to ask is about the usage of the values 0 and 4095 for VLAN-IDs. These usually have special semantics in IEEE 802.1 headers and I would suggest that we get expert assessment about their usage in filters.

T3. In Section 5.1

      0: drop
      1: shape
      2: police
      2: mark

Should be 3: mark I guess

T4. Why is not the list of actions in 5.7 (Excess-Traffic-Action) consistent with the list of actions in 5.1?


E1. In section 3.3 the last sentence in the paragraph ('The lower the numerical value of Rule-Precedence AVP, the higher the rule
precedence.') should come second in the paragraph.

E2. Under fig.1 the text speaks about one Unmanaged Terminal, while the figure represents multiple Unmanaged Terminals.

E3. Section 4.1.4 s/both direction/both directions/

E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and 4.1.8.25 is slightly mis-leading. There is no such thing as Ethernet Priority, on an Ethernet there is no priority, and tagged packets are prioritized in the routers or switches. I suggest to drop ETH from the names and to use either 8021 or nothing.

E5. in Section 5.3 - Private Enterprise Number (PEN) is a preferred term to SMI Network Management Private Enterprise Code

E6. The registry policies in the IANA considerations section should be expressed in terms and with reference to RFC 5226.

PROTO WRITEUP for draft-ietf-dime-qos-attributes-11.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 set of QoS related AVPs that a Diameter application
can use to signal QoS rules and parameters. It is intended to replace the
IPFilterRule AVP defined in RFC3588 and therefore has received extensive
review within the WG. It has also been review by members of TSVWG,
interested
SDOs requiring Diameter based QoS signaling as well as folks with in-depth
QoS experience.

(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 no normative references that are work in progress.

(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 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

This document specifies a set of AVPs that is used to carry
QoS rules and parameters so that a Diameteter application
that needs QoS support can signal them. Information contained
in these AVPs are to be interpreted and consumed by QoS classifying
entities. The Rule-Set AVP is intended to replace the IPFilterRule
AVP defined in RFC 3588. It provides a clear and more extensible
format than the original text based approach provided by
IPFilterRule.

The AVPs defined in this document are designed to be general
enough to fit both PUSH and PULL QoS signalling models. The
document provides examples on how both models are accomplished
using existing Diameter applications.

Working Group Summary

There was consensus in the WG to publish the document.

Document Quality

The document has been sent for review to TSVWG and RADEXT. 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.