[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01

Hi Roland,

thanks for your review. Please find a few comments below:

Roland Bless wrote:

Hi Hannes and all,

Hannes Tschofenig wrote:


http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01


I'm not a AAA expert, so probably I don't get the point.
Unfortunately, I'm not very content with the draft, so I have some major
comments:
1) The draft says:
   "The payloads used to carry these QoS parameters are opaque for the
   AAA client and the AAA server itself and interpreted by the
   respective Resource Management Function."

   Since the rest of the draft seems to contain larger copy&paste
   regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not
   sufficient to use a QSPEC object as it is. To me it makes no sense
   to do another format rewriting when creating a Diameter request
   (QAR) from an NSIS RESERVE for example. Is there any technical
   reason to not use a QSPEC object as it is? This would allow for
   an easy interworking between NSIS and AAA and to re-use larger parts
   of the RMF code. Conveying the parameters for AAA
   in a different way is IMHO not necessary and source for new
   implementation errors...
   If there are technical reasons why using the QSPEC directly doesn't
   work, please state it in the draft.
There are a couple of reasons why we did not want to re-use the QSPEC draft as is.
The first reason is that the Diameter QoS attribute document and the Diameter QoS application document, see 
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt
are independent of NSIS. There is no dependency between NSIS and these documents although the Diameter interworking may also be used for NSIS.
The second reason is that the QSPEC draft has a different focus in the sense that the description that is used for the front-end protocol (in this case NSIS) is somewhat different to the interaction that takes place at the backend. If you go through the QSPEC draft then you will notice that many aspects in the draft are so specific to the NSIS interactions. Unfortunately, the QSPEC is not just a collection of parameters. We did not want to let the reader figure out which parts of the document are relevant for them even if they use the Diameter QoS work for a different purpose (such as in the interaction with RSVP). In fact, in previous draft versions we just made references to the QSPEC and when this was brought to other SDOs then this was a real show stopper since people got totally confused.
The third reason is that we are changing the format of the QSPEC headers. We tried to keep the changes at a minimum but still they are different. Some time back we even considered to use a Diameter specific format. There are still comments floating around suggesting it but at the moment the plain QoS parameters are still in the format of the QSPEC. We also make use of the registry created for the QoS parameters; some of my recent mails referred to the mismatch between the QSPEC registry and the registry created by a document in the TSVWG.
The final reason is that we are changing the semantic of the extensibility mechanism. The concept of QoS models (QoSM) as defined in the QSPEC and the requirements for defining a QoSM does not work with the Diameter usage. Hence, we had to change it. See Section 5 and 6 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt 

I believe these reasons justify a new document.


2) The draft doesn't provide a meaningful definition of which parameters
   should be present together etc. It is only an unstructured list of
   parameter objects and there is no hint given about which combinations
   are allowed or meaningful etc.
That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to say anything about it. draft-ietf-dime-diameter-qos-01.txt and draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For example, when someone wants to use the IntServ Controlled-Load Service QoSM http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt and if an interaction with the Diameter backend infrastructure is desired then they would take the respective parameters from the received NSIS message and copy them into a Diameter message. The QoS profile would be set to a value as defined in the IntServ Controlled-Load Service QoSM (note that it has not been done yet). If there are specific issues that need to be said about the backend infrastructure interaction then they may be discussed in the respective QoSM but so far I have not heard about anything.
For some other QoSMs, such as RMD, I have never heard that a AAA interaction would be desired. There, the usage model is different. 

Does this make sense to you?

Ciao
Hannes


Regards,
 Roland



_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>