comments inline
Jukka MJ Manner wrote:
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.
May someone can correct me if I am wrong, but I think that the standard
track document specifies the operation between two routers and not how
it is implemented.
The API is part of the implementation space.
-lasse
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
|