[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] QSPEC document
John et al.,
Isn't the fundamental issue here that a new QOSM _MUST NOT_ break the
future QSPEC and QoS NSLP standards, nor harm the provision of e2e QoS.
The QOSM, or other documents,_MAY_ introduce new extensions - that is why
we have the so-called AB-flags in GIST and the two NSLPs.
Jukka
On Tue, 23 Jan 2007, john.loughney at nokia.com wrote:
> Hi Lars,
>
> I think we are approaching agreement on this issue, so I'll give people
> a chance to comment and then see if we can get text.
> I have been concerned about different QoS Models introducing too many
> changes to the basic operation that it becomes hard to deploy
> end-to-end, or that implementations would have to be customized quite
> heavily for each QoS Model.
>
> But I think we are getting close to resolving this.
>
> thanks,
> John
>
>
>
> ________________________________
>
> From: ext Lars Westberg [mailto:Lars.westberg at ericsson.com]
> Sent: 23 January, 2007 10:26
> To: Loughney John (Nokia-NRC/PaloAlto)
> Cc: "Attila Báder (IJ/ETH)"; gash at att.com; nsis at ietf.org
> Subject: Re: [NSIS] QSPEC document
>
>
> sure, extendabillity is the key thing.
> Thats why I have problems with statement into a new protocol without any deployment and experience of commercial acceptance. Especially if the statement is unclear.
>
> from my view, the QoS-model template should be a template and each QoS-model should be registered by IANA. I think that's according to the normal rule.
>
>
>
> regards Lasse
>
> john.loughney at nokia.com wrote:
>
>
> Hi Lars,
>
> All Standards Track documents are required to have an IANA Considerations section, which describes how protocols can be extended.
>
> You might be familiar with RFC 3936 "Procedures for Modifying the Resource reSerVation Protocol"
>
> The IETF has certain rules with respect to protocol extensibility.
> You cand find some of them in (for example) RFC3692 & RFC2434.
>
>
> John
>
>
> ________________________________
>
> From: ext Lars Westberg [mailto:Lars.westberg at ericsson.com]
> Sent: 23 January, 2007 09:01
> To: Loughney John (Nokia-NRC/PaloAlto)
> Cc: "Attila Báder (IJ/ETH)"; gash at att.com; nsis at ietf.org
> Subject: Re: [NSIS] QSPEC document
>
>
> comments inline
>
> john.loughney at nokia.com wrote:
>
>
> Hi Attila,
>
> >Hi John and Jerry, I think there is a misundersatnading here.
> >The QoS NSLP functionality surely cannot be changed without
> >modifying QoS NSLP.
>
> I think we agree here. I think we are trying to discuss
> how much change is possible.
>
>
> why are we discussing it ??
>
> If we need to add a new function in the future ?
> should we have statement into the protocol spec how this should be solved without knowing about the problem to solve?
>
> I have never seen any statements within RFCs how extention of future protocol problems should be solved. So what are we discussion ????
>
>
>
> >Regarding the QoS-NSLP state machine, I think it is not
> >definitive and it is determined by QoS NSLP and QOSM together.
> >The RMF functions are clearly determined the QOSM. It does not
> >mean to define new QoS NSLP signaling functionality.
>
> I agree.
>
>
> First of all, does internal desing model determine the protocol operation?
> According to my understanding, the standard only covers the protocol operation between routers, not how they are implemented.
>
> I do not know but I thought that API:s does not make sense as a restriction and internal implementation model is only as an information and does not determine a standard track.
>
> I would appreciate to more clarification of this.
>
>
>
>
> 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