I still do not get your statement. I need more clarifications.
If we want to additional functionality to cope with a proxy and want to
add functionality to indicate for the end-point that a proxy are
answering the the messages sequence, this will require a new object
with control bits that can be set by the proxy.
This indication can be used by the initiating party to add more
infomration that makes the proxy operation better. Is this ok within
the your statement or not ?
2) Can we indicate add control infomration into NSIS to select
ECN-marking or indicate if the marking are not supported by the
router????
3) Is it allowed to add explicit route object as they have made within
RSVP for traffic engineeering ???
4) Is it allowed to extend the protocol to establish tunnels with NSIS
as they do with RSVP-TE ?
I consider in this case that different kinds of tunnels should be
possible so a number of control bits are required.
regards Lasse
Ash, Gerald R (Jerry), ALABS wrote:
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
|