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

Hi Hannes,

[sorry for the long delay of my reply]

Hannes Tschofenig wrote:
> 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.

Ok.

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

Ok.

> 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?

Yes. Thanks.

Regards,
 Roland