|
Hi, Cornelia:
Whatever you
may say, the draft is NOT technically consistent with respect to QSPEC
extensions specific to QOS models as you yourself has admitted (e.g., you tried
.. "..
accommodate as many QoS Models as
possible .." Hi Radhika, frankly, I dont see the point of your
questions, and my impression is nor does anybody else. Rather than taking a lot
of time trying to explain (again) everything I'd like to quote rough working
group consensus that the QSPEC is ok the way it is. Cornelia -----Original Message----- Cornelia: In
response to one of Tseno's questions, you have mentioned as follows: "..
accommodate as many QoS Models as
possible .." In fact,
it is NOT true. Even
the QOS model like Y.1541 that has been trying to be accommodated fully
in the draft has been failed. Please see the following draft: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt The above
draft shows that more extensions in QSPEC template are needed. The basic
question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft? What you have
done is this: Included Y1541 QOS model (which is also incomplete) and DSTE
QOS model (a cheap shot - basically only one parameter).
Tseno has
mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ.
You have failed to explain why you have not included those in the
draft. What do
you mean that you have accommodated as many QOS models as possible? Why do
you NOT "delete" all so-called QOS
model-specific extensions
from this draft? The way
you should proceed is
as follows: 1.
Make the
draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific
to y1541using all "specific values." Also, show how to create y1541
domains using specific values without contradicting the end-to-end values from
end users' and/or
applications' point of view so that people can implement without creating any
confusions or contradictions. 2.
Do the same writing another draft for DSTE model as explained in item
1. 3.
Delete all QOS model-specific
extensions in the generalized QSPEC draft. In this
way, all drafts will
be clean. If you
have any questions, please let us know. Best
regards, Radhika PS: I
also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS
model-specific QSPEC template will create contradictions if domains are not
created carefully. The present QSPEC draft does not explain how to create
respective QOS domains using specific values in the
first place. -----Original
Message----- Hi Tseno
- and John and Jerry, so there
doesnt seem to be much concrete use for this additional kind of extensibility.
Therefore my suggestion is to not support it. Regarding
your (Tseno) 2nd paragraph: In the
QSPEC we tried to balance two mutually exclusive requirements -
accommodate as many QoS Models as
possible - make
the QSPEC as widely understood as possible without defining too many
parameters. We solved
this problem by defining mandatory parameters which we expect to be
used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_
the mandatory parameters. That is, for a QOSM that has no use of
the mandatory parameters (which is quite unlikely by the way) these parameters
_dont need to be included_ in the QSPEC. However this makes it
unlikely that this QSPEC will be understood outside the domain of this
QOSM. I guess
we have to explain this better in our document as this is not the first
time somebody (particularly someone really familiar with NSIS) didn't
really get the idea. Cornelia |
_______________________________________________ nsis mailing list nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis