Re: 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nsis
>