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

Re: [NSIS] QSPEC document



I have sent a technical question to Jerry that I expect to get an answer.

I would like to know if we can extend the protocol in the same way as RSVP has been extended.

I think the whole statement should be deleted because I haven't see any such statement within any other RFC.
If a protocol spec has to be change, the protcol-spec has to be updated. This is the normal way of designing protocols. Many protocol have been extended without re-writing the basic protocol spec so this statement are very strange. 


regards Lasse


john.loughney at nokia.com wrote:
RE: [NSIS] QSPEC document

Georgios / Lars,

How do you feel about the text that Jerry states below.  Does this
cause more or less problems to you?

John

>-----Original Message-----
>From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash at att.com]
>Sent: 22 January, 2007 16:33
>To: Loughney John (Nokia-NRC/PaloAlto);
>attila.bader at ericsson.com; nsis at ietf.org
>Cc: Ash, Gerald R (Jerry), ALABS
>Subject: RE: [NSIS] QSPEC document
>
>Hi John,
>
>> -----Original Message-----
>> From: john.loughney at nokia.com [mailto:john.loughney at nokia.com]
>> Sent: Monday, January 22, 2007 9:25 AM
>> To: attila.bader at ericsson.com; Ash, Gerald R (Jerry), ALABS;
>> nsis at ietf.org
>> Subject: RE: [NSIS] QSPEC document
>>
>> Hi Jerry & Attilla,
>>
>> I have a question about the following text:
>>
>> >>"Note that QOSM specifications SHOULD NOT define new RMF functions
>> >>required by a QOSM UNLESS such NSIS signaling functionality
>> is defined
>> >>in QoS NSLP [QoS-SIG].  That is, a QOSM is not allowed to
>> extend QoS
>> >>NSLP signaling functionality; new RMF functions are specified only
>> >>within a QoS NSLP signaling framework."
>>
>> I would say that the real restriction is that QOSM should not modify
>> the QoS NSLP state machine & operation.
>
>I agree.  What this is saying is that QOSM specifications can
>define whatever new RMF functionality they wish, but must not
>define new QoS NSLP signaling functionality and should not
>modify QoS NSLP state machine and operation.
>
>Thanks,
>Jerry
>
>> The QoS NSLP <-> RMF
>> interface
>> is out-of-scope of NSIS in my opinion. 
>>
>> I am misunderstanding something here?
>>
>> thanks,
>> John
>>
>

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

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