Subject: [Dime] (no subject)

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

*******
Wrong email for Part 2/2 response. Please drop it and see the attached
in this email.
********

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:

* 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

[ds] in pp 12 it refers to Push and Pull modes. in pp 16 it refers to
two types of Push mode. The texts in pp. 16 is modified as follows:

"A Category 1 AppE requires network-initiated Push mode and a Category 2
AppE may use either type of Push 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.

[ds] ok.

* 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."

[ds] ok.

* 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.

[ds] This session addresses two feature: discovery of peer Diameter QoS
node, and selection of right instances from the pool of peer nodes. I
think the discovery is defined in 3588, e.g. based on application ID, is
it correct? 
The selection is a new feature specific to QoS application, but only
required in either client or Server node. In fact, it is an application
level feature rather than protocol level.  

The subtitles are added to each paragraph.

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

Ok.

* 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.

Done.

* 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.

There are some new AVPs added into command. How to show them without the
ABNF?

* 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. .."

done

* 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))."
Done.

   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]:"
Done.

* 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
Done.

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

regards,
victor

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