[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] QSPEC document
Hi Jukka
What we aimed from the beginning is a combinbation of a) and b)!
Best Regards,
Georgios
> -----Original Message-----
> From: Jukka MJ Manner [mailto:jmanner at cs.Helsinki.FI]
> Sent: donderdag 25 januari 2007 9:46
> To: David R Oran
> Cc: john.loughney at nokia.com; nsis at ietf.org
> Subject: Re: [NSIS] QSPEC document
>
>
> Hi Dave,
>
> it seems people are truly talking past each other. I hope no
> one belongs to camp (b).
>
> Camp (a) is truly what we are aiming for, and we should end
> this discussion, and move forward.
>
> Jukak
>
>
> On Wed, 24 Jan 2007, David R Oran wrote:
>
> >
> > On Jan 23, 2007, at 4:38 AM, Jukka MJ Manner wrote:
> >
> > >
> > >Good. Don't we then have quite a clear statement as to what is
> > >allowed by a QOSM to define, and what is not?
> > >
> > That's what I thought, but reviewing the mailing list,
> there are four
> > people who do not think we've got it right. To some extent
> we may be
> > just talking past each other, but to some extent I think
> there is in
> > fact real technical disagreement. The best way I can think of to
> > capture that disagreement is
> > whether:
> >
> > a) The QSPEC and the RMF that operates on it have some basic,
> > universally known semantics. Particular QOSMs can provide different
> > semantics, but the RMF for such a QOSM is not permitted to admit
> > traffic unless the parameters in the well-known QSPEC
> parameters that
> > have been marked "mandatory" by the QNI can be satisfied by
> the QNE.
> > In addition, a QNE wishing to be QOS-NSLP-compliant for
> whatever QOS
> > Model it implements must either map its operation directly onto the
> > existing API and state machine operation of the QOS-NSLP, or, must
> > have a standards-track RFC which extends the QOS-NSLP in a backward
> > compatible and interoperable way. A QOSM is *not* allowed to simply
> > require that the QOS-NSLP operate in a different way than
> is specified in the standards track RFC(s).
> >
> > b) The QSPEC is a set of suggested useful parameters than
> an RMF can
> > decide to use or not use at its discretion and the QOSM is
> free to add
> > new parameters or re-interpret existing parameters as long
> as such is
> > documented in an RFC. Further, if the QOSM requires new signaling
> > functionality or a change to the way the QOS-NSLP operates (message
> > flows and state machines) it is free to specify those as
> part of the
> > QOSM without explicitly extending QOS-NSLP and
> demonstrating both interoperability and backward compatibility.
> >
> > I am firmly in camp (a). I think the existing words in the QSPEC
> > document (with the exception of the one glitch we've
> already discussed
> > and resolved) capture (a).
> >
> > If we have consensus around (a) I think we can move forward and do
> > more word smithing if really necessary. If we don't and what a
> > significant fraction of the WG wants is (b), then I think
> we really do
> > have a problem and we are more-or-less back where we were
> before the San Diego IETF.
> >
> > Dave Oran.
> >
> > >Jukka
> > >
> > >On Tue, 23 Jan 2007, john.loughney at nokia.com wrote:
> > >
> > > >Jukka,
> > > >
> > > > >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.
> > > >
> > > >Yes basically. We want to ensure that we have e2e
> interoperability
> > > >and good interworking between different QoS domains. Unbounded
> > > >flexibility (and I am not claiming anyone is planning unbounded
> > > >flexibility) doesn't help with interoperability.
> > > >
> > > >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
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis