Subject: [Dime] PROTO writeup review of draft-ietf-dime-diameter-qos-07.txt

From: Victor Fajardo <[email-masked]>
Date: Tue, 21 Apr 2009 11:24:00 -0400

Hi,

Just a few comments on draft-ietf-dime-diameter-qos-07.txt:

* In Figure 2, the legend depicts "signaling flow". Is this QoS 
signaling flow ?

* Can we simplify this sentence:

      "A Category 1 Application Endpoint has QoS capability at neither
      the application nor the network level.  This type of AppE may set.."
 to

      "A Category 1 Application Endpoint has no QoS capability at either
      the application nor the network level.  This type of AppE may set.."

* In the sentence:

  "It is obvious that the eligible QoS scheme is correlated to the
   AppE's capability in the context of QoS authorization.  Since
   Category 1 and 2 AppEs cannot initiate the QoS resource requests by
   means of network signaling, the IntServ model is not applicable to
   them in general."

  Why is IntServ not applicable to Category 2 ? Will DiffServ cover Cat 2 ?

* Can we clarify the follow:

  "When the IntServ scheme is employed by a Category 3 endpoint, the
   authorization process is typically initiated by a NE when a trigger
   such as network signaling is received from the endpoint."

  to:

  "When the IntServ scheme is employed by a Category 3 endpoint, the
   authorization process is typically initiated by a NE when a trigger
   is received from the endpoint such as network signaling (what kind ?
   is it Qos signaling ?)."

* Can we re-phrase this sentence:

   "Three basic authorization schemes for Pull mode exist: one two-party
   and two three-party schemes.  The notation adopted here is in respect ..."

   Is it one-party, two-party and three-party scheme ?

I'm still half-way through the review. I'll try to finish ASAP and send out the proto writeup once everything is cleared.

best regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Apr 2009 10:00:07 -0400

Review Part 2/2:

* Some contradictions ? In page 12, it says:

   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.

In page 16 it says:

  A Category 1 AppE requires network-initiated Push mode and a Category
  2 AppE may use either mode

* In the sentence:

  "or a link layer signaling protocol.  A description of these protocols
   is also outside the scope of this document and a tight coupling with
   these protocols is not desirable since this applications aims to be
   generic."

   Is the last sentence a recommendation to implementations regarding coupling ? I'm not sure if that is needed If so, it maybe better to re-word to:

   or a link layer signaling protocol.  A description of these protocols
   is outside the scope of this document.

* Editorial:

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

   to:

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

* Sec 4.2.3. Is this section talking about how to connect to an adjacent diameter peer ? or is it talking about discovery of another Diameter Qos node ?
  If its the former then there maybe no need to talk about it. If its the later, we have to keep in mind that there is no such functionality as discovering
  diameter nodes supporting specific applications that are several diameter peer hops away.

* Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[ Acct-Multisession-Id ]/

* In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused with some other AVPs. Maybe this check should be done for the whole document.

* Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a reference to 3588. Same goes for RAA, STR and STA.

* In Sec 6. we can re-word:

   "The QoS application reuses the authorization state machine defined in
   Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as
   defined in Section 5 and QoS AVPs as defined in Section 7. .."

  to:

   "The QoS application defines its own state machine that is based on 
   the Base Protocol authorization state machine defined in
   Section 8.1 of ([RFC3588]). The Qos state machine uses own messages as
   defined in Section 5 and QoS AVPs as defined in Section 7. .."

* Sec 6.1. we can re-word:

   "In addition to the reused state machines, the following states are
   supplemented to first 2 state machines in which the session state is
   maintained on the Server, and MUST be supported in any QoS
   application implementations in support of server initiated push mode
   (see (Section 4.2.2))."

   to:

   "Using the Base Protocol state machine as a basis, the following states
    are supplemented to first 2 state machines in which the session state is
    maintained on the Server. This MUST be supported in any QoS
    application implementations in support of server initiated push mode
    (see (Section 4.2.2))."

   AND fix this:

    "The following states are supplemented to the state machine on the
     client when state is maintained on the server as defined in Section
     8.1 of the Base Protocol [RFC3588]:

   to:

    "The following states are supplemented to the state machine on the
     client when state is maintained on the client as defined in Section
     8.1 of the Base Protocol [RFC3588]:"

* In Sec 7.2, It maybe time to remove: 

   |P - Indicates the need for encryption for end-to-end security.    |

  and it's associated column

I'll send out the PROTO writeup once these issues have been resolved.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Apr 2009 10:14:39 -0400

Can we also fix the following nits (other than the TBDs):

idnits 2.11.08 

tmp/draft-ietf-dime-diameter-qos-07.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** You're using the IETF Trust Provisions Section 6.b License Notice from
     10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
     required now.  (See http://trustee.ietf.org/license-info/)

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

     No issues found here.

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

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == 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)

  == Missing Reference: 'TBD1' is mentioned on line 1376, but not
     defined
'<QoS-Request> ::= < Diameter Header: [TBD1], REQ, PXY >...'

  == Missing Reference: 'TBD2' is mentioned on line 1401, but not
     defined
'<QoS-Answer> ::= < Diameter Header: [TBD2], PXY >...'

  == Missing Reference: 'TBD3' is mentioned on line 1430, but not
     defined
     '<QoS-Install-Request> ::= < Diameter Header: [TBD3], REQ, PXY >...'

  == Missing Reference: 'TBD4' is mentioned on line 1455, but not
     defined
'<QoS-Install-Answer> ::= < Diameter Header: [TBD4], PXY >...'

  == Missing Reference: 'TBD5' is mentioned on line 1348, but not defined
     'by including the value of [TBD5] in the Auth-Application-Id or th...'

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

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

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

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

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

     Summary: 2 errors (**), 10 warnings (==), 1 comment (--).

---

From: "Sun, Dong (Dong)" <[email-masked]>
Date: Wed, 29 Apr 2009 20:23:25 -0500

Victor,
Thanks for review and comments. See inline... 

Cheers,
Dong
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor Fajardo
Sent: Tuesday, April 21, 2009 11:24 AM
To: [email-masked]
Subject: [Dime] PROTO writeup review of
draft-ietf-dime-diameter-qos-07.txt

Hi,

[ds]yes. You may see the flow goes up to "Signaling msg processing" box.

      "A Category 1 Application Endpoint has QoS capability at neither
      the application nor the network level.  This type of AppE may
set.."
 to

      "A Category 1 Application Endpoint has no QoS capability at either
      the application nor the network level.  This type of AppE may
set.."

[ds] done.

* In the sentence:

  Why is IntServ not applicable to Category 2 ? Will DiffServ cover Cat
2 ?

[ds] as said, Cat 2 is unable to send a RSVP like on path signaling. 
Therefore the flow spec of IntServ model cannot be signaled across the
network
by this means. In fact the IntServ might be applicable. The texts are
modified as follows:

"Since Category 1 and 2 AppEs cannot initiate the QoS resource requests
by
means of network signaling, using the current mechanism of IntServ model
to 
signal QoS information across the network is not applicable to them in
general."

  to:

[ds] yes. Refers to RSVP like. So modified as follows:

"When the IntServ scheme is employed by a Category 3 endpoint, the
   authorization process is typically initiated by a NE when a trigger
   is received from the endpoint such as network QoS signaling"

   "Three basic authorization schemes for Pull mode exist: one two-party
   and two three-party schemes.  The notation adopted here is in respect
..."

[ds] my understanding is one type of two-party scheme, two types of
three-party schemes. The texts are updated accordlingly.
"Three types of basic authorization schemes for Pull mode exist: one
type of two-party scheme
   and two types of three-party schemes. "

I'm still half-way through the review. I'll try to finish ASAP and send
out the proto writeup once everything is cleared.

best regards,
victor

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong (Dong)" <[email-masked]>
Date: Wed, 29 Apr 2009 20:23:51 -0500

See inline...

Please let me know if have further comments. The draft will be updated
accordingly.

Thanks,
Dong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor Fajardo
Sent: Wednesday, April 22, 2009 10:00 AM
To: [email-masked]
Subject: Re: [Dime] PROTO writeup review
ofdraft-ietf-dime-diameter-qos-07.txt

Review Part 2/2:

In page 16 it says:

[ds] good catch. pp 12 is correct, pp 16 is aligned.

* In the sentence:

   Is the last sentence a recommendation to implementations regarding
coupling ? I'm not sure if that is needed If so, it maybe better to
re-word to:

* Editorial:

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

   to:

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

* Sec 4.2.3. Is this section talking about how to connect to an adjacent
diameter peer ? or is it talking about discovery of another Diameter Qos
node ?
  If its the former then there maybe no need to talk about it. If its
the later, we have to keep in mind that there is no such functionality
as discovering
  diameter nodes supporting specific applications that are several
diameter peer hops away.

* Editorial in Sec 5.2., s/[ Acc-Multisession-Id ]/[
Acct-Multisession-Id ]/

* In Sec 5.3, Pls expand /Authz/Authorization/ so as not be confused
with some other AVPs. Maybe this check should be done for the whole
document.

* Sec 5.5, We don't need to repeat the ABNF for RAR. We can just add a
reference to 3588. Same goes for RAA, STR and STA.

   "The QoS application reuses the authorization state machine defined
in
   Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as
   defined in Section 5 and QoS AVPs as defined in Section 7. .."

  to:

   "The QoS application defines its own state machine that is based on 
   the Base Protocol authorization state machine defined in
   Section 8.1 of ([RFC3588]). The Qos state machine uses own messages
as
   defined in Section 5 and QoS AVPs as defined in Section 7. .."

   to:

   "Using the Base Protocol state machine as a basis, the following
states
    are supplemented to first 2 state machines in which the session
state is
    maintained on the Server. This MUST be supported in any QoS
    application implementations in support of server initiated push mode
    (see (Section 4.2.2))."

   AND fix this:

   to:

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 29 Apr 2009 22:08:09 -0400

Sounds good. I'll send out the writeup after the draft gets updated.