Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 18 Aug 2005 10:14:13 +0200

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-----
	From: Roy, Radhika (AEAD) [mailto:[email-masked]] 
	Sent: Mittwoch, 17. August 2005 20:17
	To: Kappler, Cornelia
	Cc: Tseno Tsenov; [email-masked]
	Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple
instances of defined parameters

	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
<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-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kappler, Cornelia
	Sent: Wednesday, August 17, 2005 4:22 AM
	To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; [email-masked]
	Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple
instances of defined parameters

	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

	> -----Original Message-----

	> From: Tseno Tsenov [mailto:[email-masked]] 

	> Sent: Mittwoch, 10. August 2005 20:30

	> To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS;
[email-masked]

	> Subject: Re: [NSIS] QSPEC extensibility and re-use of 

	> multiple instances ofdefined parameters

	> Hi Cornelia,

	> I agree that currently there might be no QoS model that uses 

	> multiple values

	> of one QoS parameter (except the DiffServ case). However the
current

	> encoding approach restricts the extensibility of the QSPEC.

	> Your example with usage of two different QoS classes which 

	> are mandatory

	> parameters (and are redundant in some sense) raises other 

	> question for me:

	> Again, we have a new QoS model does not use any of the
mandatory QSPEC

	> parameters and defines its own set of optional QSPEC 

	> parameters. Then, is it

	> expected that some mandatory QSPEC parameters will be
"artificially"

	> included which will provide From [email-masked] Thu Aug 18 04:30:05 2005
From: "Eric Klein" <[email-masked]>
To: [email-masked]
Subject: Madated adoption?
Date: Thu, 18 Aug 2005 11:27:12 +0300
Sender: [email-masked]

Based on my memory (and comments about I-D
ACTION:draft-baker-v6ops-end2end-00.txt )

Tim Chown seemed surprised that I had heard that there was a mandated
adoption date for the UK  (UK by 2008, Japan by 2010 etc - not sure about
years for either).

Now this WG had a conversation thread a little over a year ago where these
came up.

I was wondering if anyone knew if their (or other) countries had announced
compliance dates for the full IPv6 conversions.

The truth is that this has dual interest to me, as we as a WG should know
what the world (or at least individual nations) are doing or saying about
IPv6. But this is also related to a thesis that I am working on and I am
interested to see what is being done towards actual adoption at the national
levels.

Eric