[NSIS] Consensus on: Removed the QSPEC control information

>> Point_1):Removed the QSPEC control information
>> ---------------------------------------------------------------
>> Jerry mentioned in a previous e-mail that this QSPEC control 
>> information concept is not removed but it is renamed to Traffic 
>> Handling Directives.
>> 
>> If that is the case then Jerry will have to use the same definitions 
>> for the QSPEC control information as used in Section 5.3.1 of:
>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt
>> 
>> Thus my proposal is to change section 4.3.3 as given in v.13 of the 
>> QSPEC template draft and include the general concept of the QSPEC 
>> control information that was given in Section 5.3.1 of version 12 of 
>> the QSPEC template draft. Note that the name can be changed but the 
>> semantics should remain the same. Thus please change Section 
>4.3.3 as 
>> follows:
>> 
>> FROM:
>> 
>> 4.3.3 Traffic Handling Directives
>> 
>>    The <Excess Treatment> parameter describes how the QNE will
process
>>    excess traffic, that is, out-of-profile traffic.  Excess traffic
MAY
>>    be dropped, shaped and/or remarked. The excess treatment parameter
is
>>    initially set by the QNI and cannot be overwritten.
>> 
>> INTO:
>> 
>> 4.3.3  Traffic Handling Directives
>> 
>>    Traffic Handling Directives are used for signaling QOSM 
>>    RMF functions
>>    not defined in QoS NSLP.  It enables building new RMF functions
>>    required by a QOSM within a QoS NSLP signaling framework, such as
>>    specified, for example, in [RMD-QOSM] and [Y.1541-QOSM].
>
>I think most (perhaps all?) of us agree on this point: the 
>QOSM specification SHOULD NOT be allowed to define 'new RMF 
>functions required by a QOSM' UNLESS such NSIS signaling 
>functionality is defined in QoS NSLP.  I.e., a QOSM is not 
>allowed to extend QoS NSLP signaling functionality.  The above 
>text seems to abide by the premise by stating that new RMF 
>functions are specified only 'within a QoS NSLP signaling 
>framework'.  If so, I think we're in agreement.

I agree with Jerry's text, and I believe we have rough consensus on
this.
If anyone disagrees with consensus, a short mail stating that you
disagree is needed.

On point, in order to extend QoS NSLP signaling, a Standards Track RFC
is needed.

John

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