[Dime] AD review for draft-ietf-dime-diameter-qos-08.txt

["Romascanu, Dan (Dan)" <dromasca at avaya.com>]

Please find below the AS review for draft-ietf-dime-diameter-qos-08.txt.
I believe that there is a need for a revised ID before going to IETF
Last Call in order to clarify a number of questions and fix a few more. 

The comments below are divided into Technical and Editorial.

T1. Can the QoS application support multiple concurrent sessions between
an NE and an AE? I think that we need to clarify and add adequate text.

T2. Can an NE work with multiple AEs? The security considerations
section mentions this as a problem but provides no hints as to how to
solve it. I think that we need to clarify and add adequate text.

T3. Are different modes of operation supported for a given NE? I think
that we need to clarify and add adequate text.

T4. The Terminology section mentions that an AE corresponds to an RFC
2573 PDP and an NE corresponds to an RFC 2573 PEP. I am wondering why we
go through the pain of inventing a new set of terms (AE, NE) and we do
not just use the 2573 terminology all over. 

T5. In Section 2 - 'For example, a SIP Agent is one kind of Application
Endpoint.' - is this a SIP User Agent? 

T6.In section 4.2.1 

   The AE's identity, information about the application session and/or
   identity and credentials of the QoS RRE, requested QoS parameters,
   signaling session identifier and/or QoS enabled data flows
   identifiers MAY be encapsulated into respective Diameter AVPs and
   included in the Diameter message sent to the AE.  

Why is this a MAY? Is there another way to pass AE identity information
at session establishment (assuming we are doing Diameter and not
something else)

T7. In the table the data type of the QoS-Authorization-Data attribute
is Grouped, while in the textual description it shows as OctetString

T8. I find the security considerations section weak. I suggest that for
each threat the security mechanisms within Diameter or external to
Diameter that can be used for protection be explicitly mentioned. 

T9. Logging for security events related to authentication and
authorization should be enhanced by sending alerts to a management
system (if available)

T10. 'Failing to provide the required credentials should be subject to
logging.'. Why is this a non-capitalized should and not a capitalized
MUST? 



E1. Potential problems detected by idnits: 

 Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == The document seems to lack a disclaimer for pre-RFC5378 work, but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."


  Checking references for intended status: Proposed Standard
 
------------------------------------------------------------------------
----

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

 ...

  == Outdated reference: A later version (-12) exists of
     draft-ietf-dime-qos-attributes-11

  == Outdated reference: A later version (-11) exists of
     draft-ietf-dime-qos-parameters-10

  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)

  == Outdated reference: A later version (-20) exists of
     draft-ietf-nsis-ntlp-19

  -- Obsolete informational reference (is this intentional?): RFC 4346
     (Obsoleted by RFC 5246)

E2. In section 3.1 

   Note that the parameters passed to the Traffic
   Control function may be different from requested QoS (depending on
   the authorization decision). 

should rather be

  Note that the parameters passed to the Traffic
   Control function may be different from the ones in the requested QoS
(depending on
   the authorization decision). 

E3. In section 3.2.2 page 13:

either Push mode or Pull mode may be used

Better to use MAY with 2119 capitalization

E4. The language used in the requirements in section 3.4 is confusing.
Many of the requirements are being expressed on the 'QoS AAA protocol' -
should not they be rather on the 'Diameter QoS application'? 

E5. The term 'Bearer' in the Bearer Gating requirement should probably
be replaced with some other more IP-friendly term

E6. In the Accounting Correlation requirement 'may' should be
capitalized to MAY

E7. In the 'Interaction with other AAA Applications'  required should be
capitalized to REQUIRED

E8. 

   Authentication of the QoS reservation requesting entity to the AE is
   necessary if a particular Diameter QoS application protocol run
   cannot be related (or if there is no intention to relate it) to a
   prior authentication. 

Something is missing or wrong here. What is a 'Diameter QoS application
protocol run'? 

E9. In Section 4.2.1

   The
   NE generates a QAR message in which the required objects from the QoS
   signaling message that is converted to Diameter AVPs.

Bad syntax makes this phrase impossible to understand.

E10. In Section 4.2.2

   The indication of QoS reservation and activation of the data flow can
   be provided by the QoS-Install-Answer message immediately.  In the
   case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS,
   (see Section 7.1)) information is provided in the QIA message.  Note
   that the reserved QoS resources reported in the QIA message MAY be
   different than those initially authorized with the QIR message, due
   to the QoS signaling specific behavior (e.g., receiver-initiated
   reservations with One-Path-With-Advertisements) or specific process
   of QoS negotiation along the data path.  When path coupled signaling
   is used for QoS reservation along the data path, QAR/QAA may be used
   to update the results of QoS reservation and enforcement following
   the establishment of data flows.

The usage of keywords seems to be wrong in this paragraph. The first MAY
should rather be a 'may' while in the last phrase the 'may' seems to
indicate a requirement, so it should rather be capitalized as MAY.

E11. Last sentence in section 4.2.3 s/or globally routable IP address/or
a globally routable IP address/

E12. In section 5 s/Diameter nodes conforming to this specification MAY
advertise support by including/Diameter nodes conforming to this
specification MAY advertise support for the Diameter QoS Application by
including/  

E13. It is recommended to put all the ABNF definitions in section 5 in
an Annex that can also include in one place the copyright notice. 

E14. In section 6/1 s/This MUST be supported/These MUST be supported/
 

Thanks and Regards,

Dan