Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-13.txt

From: [email-masked]
Date: Wed, 13 Dec 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: QoS NSLP QSPEC Template
	Author(s)	: J. Ash, et al.
	Filename	: draft-ietf-nsis-qspec-13.txt
	Pages		: 52
	Date		: 2006-12-13
	
The QoS NSLP protocol is used to signal QoS reservations and is
   independent of a specific QoS model (QOSM) such as IntServ or
   DiffServ.  Rather, all information specific to a QOSM is encapsulated
   in a separate object, the QSPEC.  This document defines a template
   for the QSPEC including a number of QSPEC parameters.  The QSPEC
   parameters provide a common language to be re-used in several QOSMs
   and thereby aim to ensure the extensibility and interoperability of
   QoS NSLP.  The node initiating the NSIS signaling adds an initiator
   QSPEC, which indicates the QSPEC parameters that must be interpreted
   by the downstream nodes less the reservation fails, thereby ensuring
   the intention of the NSIS initiator is preserved along the signaling
   path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-nsis-qspec-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-qspec-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 13 Dec 2006 18:00:22 -0600

Hi All,

The updated 'QoS NSLP QSPEC Template' I-D is available at
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt.

The main changes are as follows:

1. notion of QOSMs played down
  o language e.g. 'QNSLP/QSPEC can signal for different QOSMs across
    multiple domains' replaced by notion that 'QNSLP/QSPEC allows
    QNEs on the path to implement different data plane QoS mechanisms
    that meet QSPEC constraints'
  o a QOSM describes common capabilities among QNEs to act
    consistently when requested to admit traffic & in treating
    admitted traffic
  o a QOSM ID need not be defined or signaled
  o a QNE need not support any particular QOSM although a  QNI
    normally includes a QSPEC corresponding to a particular QOSM
2. a 'QOSM specification'
  o still provides a rigorous specification of a QOSM & what it does
  o documents how a QNE interprets & treats various elements in QSPEC
  o can define additional QSPEC parameters
3. updated QOSM definition:
  a method to achieve QoS for a traffic flow, e.g., IntServ
  Controlled Load; specifies what sub-set of QSPEC QoS constraints &
  traffic handling directives a QNE implementing that QOSM is capable
  of supporting & how resources will be managed by the RMF
4. QSPEC1/QSPEC2 semantics replaced with following semantics:
  o source traffic description (mandatory to include by QNI &
    mandatory to interpret by downstream QNEs)
    > specified by traffic model (TMOD-1) parameter consisting of
      rate (r), bucket size (b), peak rate (p), minimum policed unit
     (m) (mathematically complete way to describe traffic source)
    > bandwidth only set r=p; b/m to large values (separate
      bandwidth parameter not needed)
    > TMOD-2 (optional to include)
  o constraints (optional to include):
    > Path Latency
    > Path Jitter
    > Path PLR
    > Path PER
    > Slack Term
    > Priority (Preemption, Defending, Admission, RPH Priority)
  o handling directives (optional to include):
    > Excess Treatment
  o traffic classifiers (optional to include):
    > PHB Class (PHB class set by downstream QNE to tell QNI how to
      mark traffic to ensure treatment committed by admission
      control)
    > DSTE Class Type
    > Y.1541 QoS class
  o eliminated:
    > Bandwidth
    > Ctot, Dtot, Csum, Dsum
5. concept of remapping QSPEC parameters eliminated
6. redefine 'interpret' a QSPEC parameter to mean 'must conform to
   RFCs defining parameter & procedures (formerly called 'strictly
   interpret')
7. concept of local QSPECs retained
  o allows simpler control plane in a local domain
  o edge nodes
    > must interpret initiator QSPEC parameters
    > can either initiate parallel session with local QSPEC or
      define a local QSPEC with encapsulated initiator QSPEC
  o local QSPEC interpreted by local domain QNEs
  o local QSPEC must be consistent with initiator QSPEC
    > e.g., RMD can initiate a local QSPEC that contains TMOD =
      bandwidth (sets r=p, b/m to large)
8. QSPEC flags modified as follows:
  o QNI sets M flag for each QSPEC parameter it populates that must
    be interpreted or reservation fails
  o if M flag set
    > downstream QNE MUST interpret parameter or reservation fails
    > if QNE does not support parameter it sets N flag & rejects
      reservation
    > if QNE supports parameter but cannot meet parameter, it sets E
      flag & rejects reservation
  o if M flag not set
    > downstream QNE SHOULD interpret parameter
    > if QNE does not support parameter it sets the N flag &
      optionally accepts or rejects reservation
    > if QNE supports parameter but cannot meet parameter, it sets E
      flag & optionally accepts or rejects reservation
  o R (remapped parameter) flag & Q (non QOSM) flag eliminated
9. QSPEC type defined and registry established in IANA section.

Please review the updated draft.

Thanks,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-13.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Next Steps in Signaling Working Group
of the IETF.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 13 Dec 2006 20:13:44 -0500

Folks:
 
This draft remains almost the so far the basic issues are concerned. The so-called Y.1451 QOS-classes are there as if these are the formal standardized QOS models (!!!) and their classes are the ones the whole world is begging to have. 
 
What a technical invention that the whole world is looking for as if IETF folks have missed this "original" invention that the world ever know - Y.1451 QOS models and their QOS classes! How about QOS SLAs based on DiffServ QOS models that all ISPs are using? Are those not to be included here too?
 
What are the properties that differentiate between QOS models and QOS SLAs?
 
Are "apples" and "oranges" still need to be mixed as if they are the same?
 
John L. asked question last time to remove so-called QOS SLAs like Y.1451 etc. These (Y.1451 QOS SLAs) are still here as if some how something will happen and "apples" and "oranges" will be mixed assuming they are the same.
 
One question to Chairs of the NSIS WG: Did you add another NEW editor/author to the draft? Even then all "apples" and "oranges" are being mixed despite serious technical problems as we all discussed.
 
Why has this been happening for about long two years?
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Wed 12/13/2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-13.txt

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Dec 2006 10:59:14 +0100

Hi Jerry

I have not yet finished reviewing the QSEPC template draft, 
but I have seen that you have removed the concept of QSPEC control
information.
Why is that?
The concept of QSPEC control information has to remain. 

Best Regards,
Georgios

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: donderdag 14 december 2006 1:00
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-13.txt 
> 
> Hi All,
> 
>     normally includes a QSPEC corresponding to a particular 
> QOSM 2. a 'QOSM specification'
>   o can define additional QSPEC parameters 3. updated QOSM definition:
>   of supporting & how resources will be managed by the RMF 4. 
> QSPEC1/QSPEC2 semantics replaced with following semantics:
> 5. concept of remapping QSPEC parameters eliminated 6. 
> redefine 'interpret' a QSPEC parameter to mean 'must conform to
>       bandwidth (sets r=p, b/m to large) 8. QSPEC flags 
> modified as follows:
>   o R (remapped parameter) flag & Q (non QOSM) flag 
> eliminated 9. QSPEC type defined and registry established in 
> IANA section.
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Dec 2006 11:26:05 +0100

Hi Jerry

Here are my comments on draft-ietf-nsis-qspec-13.txt:

Comment_1:
--------------
Please reinclude the concept of QSPEC control information 
that was included in all previous versions of the QSPEC template draft.
In http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt: this
concept
was described in Section 5.1.

------------------

Comment_2:
-----------

Section 6.1:
Please reintroduce the format that is required in order to specify the QSEPC
control information, see:
Section 7.1 of:
http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt

----------------

Comment_3:
----------
Section 4.1 :QoS Models
The definition of the QoS model is not complete. An important sentence that 
was used in the previous version of the draft is removed. 
Please add the following sentence to the definition of the QoS Model (QOSM):

The same as described above have to be applied in this section.
After the following sentence:

"A QOSM specification MAY include the following:"

include the following bullet:
"- it specifies how to use QOS NSLP to signal for this QOSM"

------------------

Comment_4:
-------------
Section 5.1 Local QSPEC definition and processing

By reading this section it gives the impression that 
the two methods a) and b) cannot be used by the same QoS model. 
Method a): translate the
   initiator QSPEC into a local QSPEC and encapsulate the initiator
   QSPEC in the RESERVE message
Method b): b) tunnel the initiator QSPEC
   through the local domain and reserve resources by generating a new
   RESERVE message through the local domain containing the local QSPEC.

Note that according to the discussions that we have had until now 
method a) should be able to be used in combination with method b) by the
same QoS model 
for the situation that the local QSPEC encapsulates the initiator QSPEC 
in order to satisfy requirement 5.4.2 that is specified in 
RFC 3726, see:
http://www.ietf.org/rfc/rfc3726.txt

Please add the following sentence at the end of the first paragraph of
Section 5.1.
"Note that when method b) is used, the encapsulation of the initiator QSPEC
into a
local QSPEC should also be possible when the local QoS model needs to
satisfy Requirement 
5.4.2 specified in RFC 3726, by adding and removing local QOSM-specific
Control 
Information parameters on top of the initiator QSPEC."

-----------------------------

Comment_5:
-----------
Section 5.1, last paragraph:

Please change the following:
"For example, RMD can define a local QSPEC that contains 
TMOD = bandwidth (sets r=p, b/m to large)."

Into:
"For example, in RMD the TMOD parameters contained in the original initiator
QSPEC 
are mapped into the equivalent TMOD parameter representing only the peak
bandwidth 
in the local QSPEC."

----------------------------

Comment_6:
-------------
In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to be followed regarding
the 
QSEPC control information are not given: 

Please include the following paragraph at the end of this section:
"Regarding QSPEC Control Information, the default rule is that all
   QSPEC parameters that have been included in the RESERVE message by
   the QNI are also included in the RESPONSE message by the QNR with the
   value they had when arriving at the QNR.  When traveling in the
   RESPONSE message, all QSPEC Control Information parameters are
   read-only.  Note that a QOSM specification may define its own
   QOSM-specific Control Information parameters and processing rules."

---------------------------

Comment_7:
------------
Section 6.1:
I do not undersatnd the second sentence from the below two sentences:
"N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2).
           For QSPEC parameters the value of this flag is always zero."

---------------------

Best Regards,
Georgios

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Wed, 20 Dec 2006 12:53:40 +0100

Hi Georgios, Jerry,

I think mostly just the name changed, the concept is still there. Control info is changed to traffic handling directives, see 4.3.3.. I assume that defining new control parameters or directives in QOS Model is still possible. The QoS Model should specify which QOS NSLP option is used, it also belongs to directives, is not it?

Best regards, Attila

>From: Georgios Karagiannis [mailto:[email-masked]] 
>Sent: Wednesday, December 20, 2006 10:59 AM
>To: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]
>Cc: Attila Báder (IJ/ETH)
>Subject: Why is QSPEC control information removed?
>
>Hi Jerry
>
>but I have seen that you have removed the concept of QSPEC 
>control information.
>Why is that?
>>       bandwidth (sets r=p, b/m to large) 8. QSPEC flags modified as 
>> follows:
>>   o R (remapped parameter) flag & Q (non QOSM) flag eliminated 9. 
>> QSPEC type defined and registry established in IANA section.
>>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 20 Dec 2006 06:27:14 -0600

Hi Georgios,

Attila is right.  No functionality has changed.  

In the previous draft the only 'control information' parameter was 'excess treatment'.  That parameter is now defined as a 'traffic handling directive' parameter in Sections 4.3.3 and 6.2.11.  

New QSPEC parameters can still be defined in QOSM specification documents, as specified in Section 5.4.

Thanks,
Regards,
Jerry

-----Original Message-----
From: Attila Báder (IJ/ETH) [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 6:54 AM
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: Why is QSPEC control information removed?

Hi Georgios, Jerry,

Best regards, Attila

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 20 Dec 2006 07:20:25 -0600

Hi Georgios,

See below. 

> Sent: Wednesday, December 20, 2006 5:26 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Comments on draft-ietf-nsis-qspec-13.txt 
> 
> Hi Jerry
> 
> In 
> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt: this
> concept

Please see previous email comment on QSPEC control information.

> Comment_2:
> -----------
> 
> Section 6.1:
> Please reintroduce the format that is required in order to 
> specify the QSPEC

Please see previous email comment on QSPEC control information.

> Comment_3:

That sentence was removed in Dave's proposed QOSM re-definition, see
http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.html.  It
was unclear what that sentence meant, QoS-NSLP specifies how to signal,
not QOSM specifications, so the sentence was removed.  

I believe the sentence was intended to mean that when QoS NSLP allows
various options to be selected, a QOSM should be able to determine which
option is used.  For that purpose the following sentence was added in
Section 4.1:

"     A QOSM specification MAY include the following:
     ...
     - can state which QoS-NSLP options a QOSM wants to use, when
     several options are available for a QOSM (e.g., local QSPEC to
     either be a) tunneled or b) encapsulate initiator QSPEC)."

Also, to avoid any misinterpretation that QOSMs are free to specify
additional constraints, state machines, protocol data, etc. for NSLP
beyond that which is specific  
in the QoS NSLP specification, the following was added to Section 4.1:

"  QOSMs affect the operation of the RMF in NSIS-capable nodes, the
   information carried in QSPEC objects, and may under some
   circumstances (e.g. aggregation) cause a separate NSLP session to be
   instantiated by having the RMF as a QNI. QOSMs all utilize the common
   data, state machines, and APIs of the underlying NSIS protocols and
   are not expected to re-define or extend these in any way."

> Comment_4:

Your comment here is not clear to me.  It would help to provide an
example to illustrate what you are trying to accomplish.  It seems that
you are trying to specify QoS-NSLP functionality, rather than QSPEC
functionality.  If so, that functionality should be specified in the
QoS-NSLP draft rather than the QSPEC draft, perhaps the QoS-NSLP authors
can comment.

> Comment_5:

OK with me.

> QSPEC control information are not given: 
> 

Please see previous email comment on QSPEC control information.

> Comment_7:
> ------------
> Section 6.1:
> I do not understand the second sentence from the below two sentences:

Good catch, this is a typo, the sentence should be removed.

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Dec 2006 17:12:48 +0100

Hi Attila and Jerry

Okay, but I would then like to introduce a sentence in Section 4.3.3 that
would say:
"Note that a QOS model could specify any QSPEC parameter that could be
considered
as a QoS model-specific control information parameter, which could 
specify any other traffic handling directive."

Best Regards,
Georgios

> Sent: woensdag 20 december 2006 12:54
> Subject: [NSIS] RE: Why is QSPEC control information removed?
> 
> Hi Georgios, Jerry,
> 
> I think mostly just the name changed, the concept is still 
> there. Control info is changed to traffic handling 
> directives, see 4.3.3.. I assume that defining new control 
> parameters or directives in QOS Model is still possible. The 
> QoS Model should specify which QOS NSLP option is used, it 
> also belongs to directives, is not it?
> 
> Best regards, Attila
>  
> 
> but I have 
> >seen that you have removed the concept of QSPEC control information.
> >Why is that?

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Dec 2006 17:24:52 +0100

Hi Jerry

Below is my comment_4 on the QSPEC template draft, 
(note that I am an author of QOS-NSLP draft):
What I am trying to say is that all the discussion that we 
have had regarding the encapsulation of the QSEPC object 
were associated with requiremet 5.4.2 of RFC 3726, see below:

-----------------
"5.4.2.  It SHOULD be Possible to Add and Remove Local Domain Information

   It SHOULD be possible to add and remove local scope elements.
   Compared to Requirement 5.3.5 this requirement does use the normal
   signaling process and message exchange for transporting local
   information.  For example, at the entrance to a domain, domain-
   specific information is added information is added, which is used in
   this domain only, and the information is removed again when a
   signaling message leaves the domain.  The motivation is in the
   economy of re-using the protocol for domain internal signaling of
   various information pieces.  Where additional information is needed
   within a particular domain, it should be possible to carry this at
   the same time as the end-to-end information.", from RFC 3726
------------------
Thus what I am saying is:
Please add the following sentence at the end of the first 
paragraph of Section 5.1.

"Note that when method b) is used, the encapsulation of the 
initiator QSPEC into a local QSPEC should also be possible when the local
QoS 
model needs to satisfy Requirement 5.4.2 specified in RFC 3726, by adding
and removing local 
QOSM-specific Control Information parameters on top of the initiator QSPEC."

Best Regards,
Georgios

> > By reading this section it gives the impression that the 
> two methods 
> > a) and b) cannot be used by the same QoS model.
> > Method a): translate the
> > method a) should be able to be used in combination with 
> method b) by 
> > the same QoS model for the situation that the local QSPEC 
> encapsulates 
> > the initiator QSPEC in order to satisfy requirement 5.4.2 that is 
> > specified in RFC 3726, see:
> > "Note that when method b) is used, the encapsulation of the 
> initiator 
> > QSPEC into a local QSPEC should also be possible when the local QoS 
> > model needs to satisfy Requirement
> > 5.4.2 specified in RFC 3726, by adding and removing local 
> > QOSM-specific Control Information parameters on top of the 
> initiator 
> > QSPEC."
> 
> Your comment here is not clear to me.  It would help to 
> provide an example to illustrate what you are trying to 
> accomplish.  It seems that you are trying to specify QoS-NSLP 
> functionality, rather than QSPEC functionality.  If so, that 
> functionality should be specified in the QoS-NSLP draft 
> rather than the QSPEC draft, perhaps the QoS-NSLP authors can comment.

> Sent: woensdag 20 december 2006 14:20
> To: Georgios Karagiannis; [email-masked]
> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt 
> 
> Hi Georgios,
> 
> See below. 
> 
> > Please reinclude the concept of QSPEC control information that was 
> > included in all previous versions of the QSPEC template draft.
> > In
> > 
> > concept was described in Section 5.1.
> 
> specify the 
> > QSPEC control information, see:
> > Section 7.1 of:
> > The definition of the QoS model is not complete. An 
> important sentence 
> > that was used in the previous version of the draft is removed.
> > Please add the following sentence to the definition of the 
> QoS Model 
> > (QOSM):
> > 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht
> ml.  It was unclear what that sentence meant, QoS-NSLP 
> specifies how to signal, not QOSM specifications, so the 
> sentence was removed.  
> 
> I believe the sentence was intended to mean that when QoS 
> NSLP allows various options to be selected, a QOSM should be 
> able to determine which option is used.  For that purpose the 
> following sentence was added in Section 4.1:
> 
> Also, to avoid any misinterpretation that QOSMs are free to 
> specify additional constraints, state machines, protocol 
> data, etc. for NSLP beyond that which is specific in the QoS 
> NSLP specification, the following was added to Section 4.1:
> 
> > By reading this section it gives the impression that the 
> two methods 
> > a) and b) cannot be used by the same QoS model.
> > Method a): translate the
> > method a) should be able to be used in combination with 
> method b) by 
> > the same QoS model for the situation that the local QSPEC 
> encapsulates 
> > the initiator QSPEC in order to satisfy requirement 5.4.2 that is 
> > specified in RFC 3726, see:
> > "Note that when method b) is used, the encapsulation of the 
> initiator 
> > QSPEC into a local QSPEC should also be possible when the local QoS 
> > model needs to satisfy Requirement
> > 5.4.2 specified in RFC 3726, by adding and removing local 
> > QOSM-specific Control Information parameters on top of the 
> initiator 
> > QSPEC."
> 
> Your comment here is not clear to me.  It would help to 
> provide an example to illustrate what you are trying to 
> accomplish.  It seems that you are trying to specify QoS-NSLP 
> functionality, rather than QSPEC functionality.  If so, that 
> functionality should be specified in the QoS-NSLP draft 
> rather than the QSPEC draft, perhaps the QoS-NSLP authors can comment.
> 
> > Comment_5:
> > -----------
> > "For example, RMD can define a local QSPEC that contains TMOD = 
> > bandwidth (sets r=p, b/m to large)."
> > 
> > Into:
> > "For example, in RMD the TMOD parameters contained in the original 
> > initiator QSPEC are mapped into the equivalent TMOD parameter 
> > representing only the peak bandwidth in the local QSPEC."
> 
> OK with me.
> 
> > Comment_6:
> > -------------
> > In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to be followed 
> > regarding the QSPEC control information are not given:
> > 
> >    the QNI are also included in the RESPONSE message by the 
> QNR with 
> > the
> > >     normally includes a QSPEC corresponding to a 
> particular QOSM 2. 
> > > a 'QOSM specification'
> modified as

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 20 Dec 2006 11:31:06 -0500

Georgios and all:

We have a fundamental problem here if those wordings are used as suggested by Georgios. We are suggesting to add one more sentence as follows in addition to Georgios's:

"[..... Georgios sentence + this one...] The QOS model-specific QSPEC parameters SHALL be specified in a separate QOSM draft/RFC for each QOS model as this QSPEC RFC deals with the general e2e-QSPEC parameter."

Best regards,
Raddhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, December 20, 2006 11:13 AM
To: 'Attila Báder (IJ/ETH)'; 'Ash, Gerald R (Jerry), ALABS'; [email-masked]
Subject: RE: [NSIS] RE: Why is QSPEC control information removed?

Hi Attila and Jerry

Best Regards,
Georgios

---

From: David R Oran <[email-masked]>
Date: Wed, 20 Dec 2006 12:08:25 -0500

> specify any other traffic handling directive."
I have a hard time understanding what this is actually saying, as  
opposed to what it is trying to say, which I believe is that QOSMs  
used in various domains may wish to extend the QSPEC in various ways,  
and those extensions may include any category of qspec parameter.

How about:
"QoSMs are free, subject to IANA registration and review rules, to  
extend QSPECs by adding parameters of any of the kinds supported by  
the standard QSPEC. This includes traffic description parameters,  
constraint parameters and handling directives. QoSMs are not  
permitted, however, to reinterpret or redefine the standard QSPEC  
parameters specified in this document"

Dave.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Dec 2006 18:18:50 +0100

Hi Dave

Thank you!
I agree with the provided text!

Best Regards,
Georgios

> From: David R Oran [mailto:[email-masked]] 
> Sent: woensdag 20 december 2006 18:08
> To: Georgios Karagiannis
> Cc: 'Attila Báder (IJ/ETH)' ; 'Ash, Gerald R (Jerry), ALABS'; 
> [email-masked]
> Subject: Re: [NSIS] RE: Why is QSPEC control information removed?
> 
> 
> > considered as a QoS model-specific control information parameter, 
> > which could specify any other traffic handling directive."
> >
> I have a hard time understanding what this is actually 
> saying, as opposed to what it is trying to say, which I 
> believe is that QOSMs used in various domains may wish to 
> extend the QSPEC in various ways, and those extensions may 
> include any category of qspec parameter.
> 
> How about:
> "QoSMs are free, subject to IANA registration and review 
> rules, to extend QSPECs by adding parameters of any of the 
> kinds supported by the standard QSPEC. This includes traffic 
> description parameters, constraint parameters and handling 
> directives. QoSMs are not permitted, however, to reinterpret 
> or redefine the standard QSPEC parameters specified in this document"
> 
> Dave.
> 
> 
> >
> > Best Regards,
> > Georgios
> >
> >
> >
> >
> >> I think mostly just the name changed, the concept is still there. 
> >> Control info is changed to traffic handling directives, 
> see 4.3.3.. I 
> >> assume that defining new control parameters or directives in QOS 
> >> Model is still possible. The QoS Model should specify 
> which QOS NSLP 
> >> option is used, it also belongs to directives, is not it?
> >>
> >> Best regards, Attila
> >>
> >>
> >>>>> must interpret initiator QSPEC parameters can either initiate 
> >>>>> parallel session with local QSPEC or
> >>>>> downstream QNE MUST interpret parameter or reservation fails if 
> >>>>> QNE does not support parameter it sets N flag & rejects
> >>>>       reservation
> >>>>> downstream QNE SHOULD interpret parameter if QNE does 
> not support 
> >>>>> parameter it sets the N flag &

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 20 Dec 2006 12:22:33 -0500

Dave:

Yes, we agree with your proposal with the adding of only ONE word "end-to-end (e2e)" before the word "QSPEC." That is, ".... standard end-to-end QSPEC..."

The whole things will read like this:

"QoSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the standard end-to-end QSPEC. This includes traffic description parameters, constraint parameters and handling directives. QoSMs are not permitted, however, to reinterpret or redefine the standard QSPEC parameters specified in this document"

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David R Oran
Sent: Wednesday, December 20, 2006 12:08 PM
To: Georgios Karagiannis
Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; 'Attila Báder (IJ/ETH)' 
Subject: Re: [NSIS] RE: Why is QSPEC control information removed?

How about:

Dave.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 20 Dec 2006 13:41:13 -0500

Dave:

In addition, as an editor (I think that you should be the ONLY editor of this draft as others took ITU-T things as standards in the IETF), you have the responsibility to define "Standard QSPEC."

The "standard" QSPEC template needs to be specified as a reference throughout the document.

As we discussed before, QOS SLAs like Y.1415, DSTE, etc. and any references of those QOS SLAs like Y.1451 QOS classes MUST be removed from this draft.

Please resubmit the draft accordingly.

Best regards,
Radhika

-----Original Message-----
From: Roy, Radhika R. 
Sent: Wednesday, December 20, 2006 12:23 PM
To: 'David R Oran'; Georgios Karagiannis
Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; 'Attila Báder (IJ/ETH)' 
Subject: RE: [NSIS] RE: Why is QSPEC control information removed?

Dave:

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David R Oran
Sent: Wednesday, December 20, 2006 12:08 PM
To: Georgios Karagiannis
Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; 'Attila Báder (IJ/ETH)' 
Subject: Re: [NSIS] RE: Why is QSPEC control information removed?

How about:

Dave.

---

From: <[email-masked]>
Date: Thu, 21 Dec 2006 06:42:46 +0200

>I have a hard time understanding what this is actually saying, 
>as opposed to what it is trying to say, which I believe is 
>that QOSMs used in various domains may wish to extend the 
>QSPEC in various ways, and those extensions may include any 
>category of qspec parameter.
>
>How about:

Sounds good to me.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Dec 2006 10:35:20 +0100

Hi Jerry

In order to emphasize the need of having QSPEC control information
parameters 
 I  would however appreciate if the name of Section 4.3.3 is changed 
From:
4.3.3 Traffic Handling Directives
INTO:
4.3.3 QSPEC control information
  
Best Regards,
Georgios

> Sent: woensdag 20 december 2006 13:27
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); [email-masked]
> In the previous draft the only 'control information' 
> parameter was 'excess treatment'.  That parameter is now 
> defined as a 'traffic handling directive' parameter in 
> Sections 4.3.3 and 6.2.11.  
> 
> New QSPEC parameters can still be defined in QOSM 
> specification documents, as specified in Section 5.4.
> 
> Thanks,
> Regards,
> Jerry
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Dec 2006 15:21:46 +0100

Hi Jerry

Please see below! I have severe concerns about some changes that have been
done
in the QSPEC template draft.

> Please see previous email comment on QSPEC control information.

Georgios: 
In order to emphasize the need of having QSPEC control information 
parameters  I  would however appreciate if the name of Section 4.3.3 is
changed
From:
4.3.3 Traffic Handling Directives
INTO:
4.3.3 QSPEC control information

> Please see previous email comment on QSPEC control information.

Georgios: If you rename section 4.3.3 to QSPEC control information then I
think that reformatting 
of section 6.1 is not needed.
Please add the proposed sentence by Dave (but change the term "handling
directives" to "QSPEC control 
Information"). I am not sure where it is better to add this sentence, maybe
in Section 5.4.

"QoSMs are free, subject to IANA registration and review rules, to extend
QSPECs by adding parameters of any of the kinds supported by the standard
QSPEC. This includes traffic description parameters, constraint parameters
and QSPEC control information. QoSMs are not permitted, however, to
reinterpret or redefine the standard QSPEC parameters specified in this
document"

>    are not expected to re-define or extend these in any way."

Georgios:
Regarding the sentence in Section 4.1:
"QOSMs all utilize 
the common data, state machines, and APIs of the underlying NSIS protocols
and
are not expected to re-define or extend these in any way."

This sentence restricts the possibility of QoS model to use RMF states and
data 
that are not been defined in neither QoS-NSLP or QSPEC.
This sentence should be removed.

> paragraph of 

Georgios:
No I am not trying to define QOS-NSLP functionality.
This is realted to QSPOEC control informtaion that has to be carried 
by end-to-end messages.
What I am trying to say is that all the discussion that we have had 
regarding the encapsulation of the QSEPC object were associated 
with requiremet 5.4.2 of RFC 3726, see below:

-----------------

Please add the following sentence at the end of the first paragraph 
of Section 5.1.

"Note that when method b) is used, the encapsulation of the 
initiator QSPEC into a local QSPEC should also be possible 
when the local QoS model needs to satisfy Requirement 
5.4.2 specified in RFC 3726, by adding and removing local 
QOSM-specific Control Information parameters on top of the 
initiator QSPEC."

> Please see previous email comment on QSPEC control information.

Georgios: I think that a description of how the QSPEC control information is
handled 
is needed.

Best Regards,
Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 22 Dec 2006 08:01:14 -0600

Georgios,

See below. 

> Sent: Thursday, December 21, 2006 9:22 AM
> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg'
> > > that was 

The updated QSPEC parameter terminology/semantics are as suggested by
Dave Oran (see slides presented at IETF-67
http://www3.ietf.org/proceedings/06nov/index.html).  I think the current
terminology is more clear/descriptive of the QSPEC parameters so I don't
favor going backwards to less clear terminology.  I was never clear on
why we used the 'control information' terminology in the first place,
e.g., I don't think it's a very good descriptor of the 'excess
treatment' parameter.

Perhaps Dave can comment on this point also when he gets a chance.

> rules, to extend

Yes, the text suggested by Dave will be added.

> the common data, state machines, and APIs of the underlying 
> NSIS protocols and
> This sentence restricts the possibility of QoS model to use 
> RMF states and data 

I disagree.  The quoted text was introduced by Dave Oran in addition to
removing the phrase implying that a QOSM could specify signaling
protocol changes, and I agree with this.  Any changes/extensions to the
signaling protocol or state machines are within the scope of QoS-NSLP
draft and not the QSPEC draft or a QOSM specification draft.  I think
you have noted that also in your subsequent posting at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html.  

If any extensions are required to the NSIS signaling protocol as a
result of the 'severe change on QoS Model definition and capabilities'
you have noted, those proposed changes/extensions should be addressed to
the QoS NSLP draft IMO.

Perhaps Dave can comment here also when he gets a chance.

> This is related to QSPEC control information that has to be carried 
> by end-to-end messages.
> regarding the encapsulation of the QSPEC object were associated 
> with requirement 5.4.2 of RFC 3726, see below:
> 
> -----------------

First, the suggested text isn't clear.  If method b) is used (tunneling)
then presumably method a) is not also used at the same time.  However,
the phrasing of the above makes it sound that way.

Second, an example would help here.  I presume you are referring e.g.,
to RMD adding 'control information' (i.e., 'handling directive')
parameters to the local QSPEC that are not included in the initiator
QSPEC.  I think the requirement would be that the RMD QOSM provides a
local QSPEC that is consistent with the initiator QSPEC, as we agreed on
the list (see also slide 8 of the IETF-67 presentation).

If the local QSPEC introduces functionality inconsistent with the
initiator QSPEC by appending the handling directive parameters, then it
is not allowed.

> > >    QNR with the
> Georgios: I think that a description of how the QSPEC control 
> information is handled is needed.

Please see above comments on 'control information' terminology.

Thanks,
Jerry

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Fri, 22 Dec 2006 15:10:22 +0100

I have a severe problem with the procedure of changing the draft. 
The changes you are refereing to has to be discussed before the draft is
changed. 

I therefore requesting that the new draft should be an working group
draft.

Regard Lasse 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: den 22 december 2006 15:01
To: Georgios Karagiannis; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Georgios,

See below. 

> Please see below! I have severe concerns about some changes that have 
> been done in the QSPEC template draft.
> 

> parameters  I  would however appreciate if the name of Section 4.3.3 
> is changed
> From:

> Georgios: If you rename section 4.3.3 to QSPEC control information 
> then I think that reformatting of section 6.1 is not needed.
> Please add the proposed sentence by Dave (but change the term 
> "handling directives" to "QSPEC control Information"). I am not sure 
> where it is better to add this sentence, maybe in Section 5.4.
> 
> constraint parameters and QSPEC control information. QoSMs are not 

> > > Comment_3:
> > > ----------
> > > Section 4.1 :QoS Models
> > > The definition of the QoS model is not complete. An important 
> > > sentence that was used in the previous version of the draft is 
> > > removed.
> > > Please add the following sentence to the definition of the QoS 
> > > Model
> > > (QOSM):
> > > 

> > ml.  It was unclear what that sentence meant, QoS-NSLP specifies how

> > to signal, not QOSM specifications, so the sentence was removed.
> > 
> > I believe the sentence was intended to mean that when QoS NSLP 
> > allows various options to be selected, a QOSM should be able to 
> > determine which option is used.  For that purpose the following 
> > sentence was added in Section 4.1:
> > 

> > beyond that which is specific in the QoS NSLP specification, the 
> > following was added to Section 4.1:
> > 
> the common data, state machines, and APIs of the underlying NSIS 
> protocols and are not expected to re-define or extend these in any 
> way."
> 
> This sentence restricts the possibility of QoS model to use RMF states

> and data that are not been defined in neither QoS-NSLP or QSPEC.

> > > By reading this section it gives the impression that the two 
> > > methods
> > > QSPEC in the RESERVE message Method b): b) tunnel the initiator 
> > > QSPEC through the local domain and reserve resources by generating

> > > a new RESERVE message through the local domain containing the 
> > > local QSPEC.
> > > 
> > > method a) should be able to be used in combination with method b) 
> > > by the same QoS model for the situation that the local QSPEC 
> > > encapsulates the initiator QSPEC in order to satisfy requirement 
> > > 5.4.2 that is specified in RFC 3726, see:
> > > initiator QSPEC into a local QSPEC should also be possible when 
> > > the local QoS model needs to satisfy Requirement
> > example to illustrate what you are trying to accomplish.  It seems 
> > that you are trying to specify QoS-NSLP functionality, rather than 
> > QSPEC functionality.  If so, that functionality should be specified 
> > in the QoS-NSLP draft rather than the QSPEC draft, perhaps the 
> > QoS-NSLP authors can comment.
> 
> Georgios:
> This is related to QSPEC control information that has to be carried by

> end-to-end messages.
> regarding the encapsulation of the QSPEC object were associated with 
> requirement 5.4.2 of RFC 3726, see below:
> 
> -----------------

> Section 5.1.
> 
> "Note that when method b) is used, the encapsulation of the initiator 

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 15:13:18 +0100

Hi Jerry

By just saying that "these changes are suggested by Dave in the e-mail" 
does not work.

The proposal of Dave was not clear on the QoS model changes that 
you wanted to do. 
Now I understand which changes you want to include in the 
QSPEC template draft.
This is also the reason of disagreeing with you now and 
sending comments to the nsis list.

Furthermore, note that the QOS-NSLP draft defines which capabilities 
should be supported by the QoS models and not the 
QSPEC template draft.

Best Regards,
Georgios

> Sent: vrijdag 22 december 2006 15:01
> The updated QSPEC parameter terminology/semantics are as 
> suggested by Dave Oran (see slides presented at IETF-67 
> http://www3.ietf.org/proceedings/06nov/index.html).  I think 
> the current terminology is more clear/descriptive of the 
> QSPEC parameters so I don't favor going backwards to less 
> clear terminology.  I was never clear on why we used the 
> 'control information' terminology in the first place, e.g., I 
> don't think it's a very good descriptor of the 'excess 
> treatment' parameter.
> 
> specifies how 
> RMF states 
> I disagree.  The quoted text was introduced by Dave Oran in 
> addition to removing the phrase implying that a QOSM could 
> specify signaling protocol changes, and I agree with this.  
> Any changes/extensions to the signaling protocol or state 
> machines are within the scope of QoS-NSLP draft and not the 
> QSPEC draft or a QOSM specification draft.  I think you have 
> noted that also in your subsequent posting at 
> If any extensions are required to the NSIS signaling protocol 
> as a result of the 'severe change on QoS Model definition and 
> capabilities'
> you have noted, those proposed changes/extensions should be 
> addressed to the QoS NSLP draft IMO.
> 
> method b) 
> provide an 
> First, the suggested text isn't clear.  If method b) is used 
> (tunneling) then presumably method a) is not also used at the 
> same time.  However, the phrasing of the above makes it sound 
> that way.
> 
> Second, an example would help here.  I presume you are 
> referring e.g., to RMD adding 'control information' (i.e., 
> 'handling directive') parameters to the local QSPEC that are 
> not included in the initiator QSPEC.  I think the requirement 
> would be that the RMD QOSM provides a local QSPEC that is 
> consistent with the initiator QSPEC, as we agreed on the list 
> (see also slide 8 of the IETF-67 presentation).
> 
> If the local QSPEC introduces functionality inconsistent with 
> the initiator QSPEC by appending the handling directive 
> parameters, then it is not allowed.
> 
> > > > Comment_5:
> > > > -----------
> > > >            For QSPEC parameters the value of this flag 
> is always 
> > > > zero."
> > >

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Fri, 22 Dec 2006 15:13:47 +0100

I am sorry spelling error.

The new draft should NOT be a working group draft!!
It should be a indiviual submission!!!!

Regards Lasse
-----Original Message-----
From: Lars Westberg (KI/EAB) [mailto:[email-masked]] 
Sent: den 22 december 2006 15:10
To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; [email-masked]
Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Regard Lasse 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
Sent: den 22 december 2006 15:01
To: Georgios Karagiannis; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Georgios,

See below. 

Thanks,
Jerry

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Fri, 22 Dec 2006 15:31:08 +0100

Let's discuss it once more regarding the control information in the
QoS-model,.

The basic purpose with the QOS-model is to have modularity and
extendabillity for future needs. We have discussed into the protocol
design and I am very suprised that it suddently disappear from the
draft.

We have one very good example: RSVP-proxy.

If one wan't to have NSIS-proxies, 
	we need to control information such as: Proxy is found!! 
							    Proxy is
located at this address!

This could very well be described by QoS-model control information!!!

The basic problem is that this drafts tries to limit the extendabillity
to exactly the same as RSVP!!! I completely disagree with that approach.

There are no need to re-design RSVP with exactly the same
functionality!! We already have RSVP but RSVP is better designed from
scalabillity perspective and have support for Mutlicast support. We are
designing exactly the same protocol but with limited functional support
and without Multicast!!!!!
Note, that we can't use NSIS for TV-broadcast !!! 

I do not beleive that NSIS can replace RSVP!!! 
Therefore, QOS-NSLP must support other usage than RSVP!!!

I agree that the description of control information may be explained
better but it has to be possible to have control information in the
QoS-model.

But the statement into this draft makes the QoS-NSLP useless!!

Regards Lasse

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: den 22 december 2006 15:01
To: Georgios Karagiannis; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Georgios,

See below. 

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 15:46:49 +0100

Hi Lars

I agree with you! Furthermore, by limiting the capabilities of the QOS
models
also the modularity and flexibility characteristrics and advanteges of NSIS
are limited.

Best regards,
Georgios

> Sent: vrijdag 22 december 2006 15:31
> Let's discuss it once more regarding the control information 
> in the QoS-model,.
> 
> The basic purpose with the QOS-model is to have modularity 
> and extendabillity for future needs. We have discussed into 
> the protocol design and I am very suprised that it suddently 
> disappear from the draft.
> 
> The basic problem is that this drafts tries to limit the 
> extendabillity to exactly the same as RSVP!!! I completely 
> disagree with that approach.
> 
> functionality!! We already have RSVP but RSVP is better 
> designed from scalabillity perspective and have support for 
> Mutlicast support. We are designing exactly the same protocol 
> but with limited functional support and without Multicast!!!!!
> I agree that the description of control information may be 
> explained better but it has to be possible to have control 
> information in the QoS-model.
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 22 Dec 2006 09:36:47 -0600

Georgios, 

> Sent: Friday, December 22, 2006 9:13 AM
> By just saying that "these changes are suggested by Dave in 
> the e-mail" does not work.
> 

All changes to the draft have been extensively discussed on the list and
are all contained in the slides presented at IETF-67.  You were there at
IETF-67 and participated in all the list discussion.  The summary of
changes in the slides is quite specific and clear, take another look.
Have a look at the minutes as well
http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt.  The only
disagreements noted are with regard to stacking, which is an issue that
we later resolved on the list.  Go back and check it out.

> sending comments to the nsis list.

I responded to your further comments, see below.  Others are encouraged
to comment as well.

Jerry

> rules, to

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 22 Dec 2006 10:40:43 -0500

Lars and all:
 
The root cause has been that this draft has only one purpose: "Sell so-called ITU-T's QOS SLA  - Y.1415 as QOS Model in the IETF."
 
No matter what you suggest technically, the so-called "like-minded-people" will come back with different arguments even modifying the basic thing like - deform the very definition of QOS model or make QOS-NSLP useless. 
 
But they will NEVER remove QOS SLA Y.1415!!!
 
Now is the time to appoint of a NEW (single) EDITOR for this draft.
 
Otherwise, let is be an individual non-WG draft, and no one will make any comments and let the "like-minded-people" work as they like.
 
Best regards,
Radhika

From: [email-masked] on behalf of Lars Westberg (KI/EAB)
Sent: Fri 12/22/2006 9:10 AM
To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; [email-masked]
Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Regard Lasse

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 22 Dec 2006 10:47:55 -0500

All those changes do not reflect the work group discussions as some of them Georgios mentioned.
 
It does not have to the way you so-called co-editors think so. If the WG agrees with the changes that you have made in the draft, then why do these WG people disagree with you?
 
Do you have technical explanations to answer Georgeo's points?
 
If not, it is the time to leave this draft to a NEW editor who work based on WG technical consensus. Or, submit as individual non-WG draft. It is so simple.
 
Best regards,
Radhika

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Fri 12/22/2006 10:36 AM
To: Georgios Karagiannis; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Georgios,

Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 17:28:12 +0100

Hi Jerry

The changes that are included in version 13 of the QSEPC template draft 
regarding the QSPEC control information and the
limitations of the QoS models have never been 
discussed because they were never stated clearly. 

If they would have been stated clearly then I would 
have sent my comments at that time instead 
of sending them now!

Best Regards,
Georgios

> Sent: vrijdag 22 december 2006 16:37
> > By just saying that "these changes are suggested by Dave in the 
> > e-mail" does not work.
> > 
> > The proposal of Dave was not clear on the QoS model changes 
> that you 
> > wanted to do.
> 
> All changes to the draft have been extensively discussed on 
> the list and are all contained in the slides presented at 
> IETF-67.  You were there at
> IETF-67 and participated in all the list discussion.  The 
> summary of changes in the slides is quite specific and clear, 
> take another look.
> http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt.  The 
> only disagreements noted are with regard to stacking, which 
> is an issue that we later resolved on the list.  Go back and 
> check it out.
> 
> > Now I understand which changes you want to include in the QSPEC 
> > template draft.
> > This is also the reason of disagreeing with you now and sending 
> > comments to the nsis list.
> 
> I responded to your further comments, see below.  Others are 
> encouraged to comment as well.
> 
> Jerry
> 
> > 
> > should be supported by the QoS models and not the QSPEC template 
> > draft.
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> suggested 
> > > by Dave Oran (see slides presented at IETF-67 
> > > http://www3.ietf.org/proceedings/06nov/index.html).  I think the 
> > > current terminology is more clear/descriptive of the QSPEC 
> > > parameters so I don't favor going backwards to less clear 
> > > terminology.  I was never clear on why we used the 'control 
> > > information' terminology in the first place, e.g., I don't think 
> > > it's a very good descriptor of the 'excess treatment' parameter.
> > > 
> important 
> > > I disagree.  The quoted text was introduced by Dave Oran 
> in addition 
> > > to removing the phrase implying that a QOSM could specify 
> signaling 
> > > protocol changes, and I agree with this.
> machines 
> > > are within the scope of QoS-NSLP draft and not the QSPEC 
> draft or a 
> > > QOSM specification draft.  I think you have noted that 
> also in your 
> > > subsequent posting at 
> > > (tunneling) then presumably method a) is not also used at 
> the same 
> > > time.  However, the phrasing of the above makes it sound that way.
> > > 
> > > Second, an example would help here.  I presume you are referring 
> > > e.g., to RMD adding 'control information' (i.e., 'handling 
> > > directive') parameters to the local QSPEC that are not 
> included in 
> > > the initiator QSPEC.  I think the requirement would be 
> that the RMD 
> > > QOSM provides a local QSPEC that is consistent with the initiator 
> > > QSPEC, as we agreed on the list (see also slide 8 of the IETF-67 
> > > presentation).
> > > 
> > > initiator QSPEC by appending the handling directive 
> parameters, then 
> > > it is not allowed.
> > > 
> > > > > > Comment_5:
> > > > > > -----------

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 17:36:27 +0100

Hi Jerry

The changes that are included in version 13 of the QSEPC 
template draft regarding the QSPEC control information and 
the limitations of the QoS models have never been discussed 
because they were never stated clearly. 

If they would have been stated clearly then I would have sent 
my comments at that time instead of sending them now!

Furthermore, from what I have seen in v. 13 of the draft 
you also have not solved the 
stacking issue, because you are actually dictating that 
encapsulation cannot be combined and used together with 
the tunneling (parallel sessions) method.

Best Regards,
Georgios

> the list 
> > and are all contained in the slides presented at IETF-67.  You were 
> > there at
> summary of 
> > disagreements noted are with regard to stacking, which is an issue 
> > that we later resolved on the list.  Go back and check it out.
> > 
> > > > > >    instantiated by having the RMF as a QNI. QOSMs 
> all utilize 
> > > > > >    the common
> referring 
> > > > > > >    QSPEC parameters that have been included in 
> the RESERVE 
> > > > > > >    message by

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 22 Dec 2006 12:12:11 -0600

Georgios,

It's not true as you and 2 others have stated that the changes were not
discussed.  They were discussed, at length.  For example, the revised
definition of QOSM was clearly stated and discussed on the list, see
http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.html and
also see all the list discussion following that post.  The revised
definition and all the other changes were clearly presented in the
slides at IETF-67, see minutes and slides at
http://www3.ietf.org/proceedings/06nov/index.html.  You can listen to
the complete IETF-67 presentation/discussion again at
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch4-thu
-am.mp3.  

You can review the slides, meeting discussion, list discussion, meeting
minutes, and verify that for yourself.

So the editors did not 'make up the changes without discussion' as you
and 2 others have suggested.  That is certainly wrong and I think you
should acknowledge that.

It is not useful going forward to debate the past, but incendiary wrong
statements should not go unanswered.

Once again, I've responded to your technical comments, you can comment
further if you wish. 

It would be good for others to comment on the technical points.

Jerry 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Friday, December 22, 2006 11:36 AM
To: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Hi Jerry

Best Regards,
Georgios

---

From: <[email-masked]>
Date: Sat, 23 Dec 2006 19:27:00 +0200

Rahdhika,
 
I have tried to politely ask you to restrain from content-free posting.
You are not the working group chair, so you are not in a position to
declare working group concensus.  Additionally, it is clearly within our
charter to work with QoS defined by other SDOs.
 
If you continue in your inappropriate postings, I will be forced to
consider revoking your posting rights.
 
John

	From: ext Roy, Radhika R. [mailto:[email-masked]] 
	Sent: 22 December, 2006 17:48
	To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis;
[email-masked]
	Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt

	All those changes do not reflect the work group discussions as
some of them Georgios mentioned.
	 
	It does not have to the way you so-called co-editors think so.
If the WG agrees with the changes that you have made in the draft, then
why do these WG people disagree with you?

	If not, it is the time to leave this draft to a NEW editor who
work based on WG technical consensus. Or, submit as individual non-WG
draft. It is so simple.
	 
	Best regards,
	Radhika

	From: [email-masked] on behalf of Ash, Gerald R (Jerry),
ALABS

	Georgios,
	
	> The proposal of Dave was not clear on the QoS model changes
that
	> you wanted to do.
	
	All changes to the draft have been extensively discussed on the
list and
	are all contained in the slides presented at IETF-67.  You were
there at
	IETF-67 and participated in all the list discussion.  The
summary of
	changes in the slides is quite specific and clear, take another
look.
	Have a look at the minutes as well
	http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt.  The
only
	disagreements noted are with regard to stacking, which is an
issue that
	we later resolved on the list.  Go back and check it out.

encouraged
	to comment as well.
	
	Jerry
	
	> > > Please see below! I have severe concerns about some
changes
	> > that have

---

From: <[email-masked]>
Date: Sat, 23 Dec 2006 19:36:05 +0200

Georgios and Lars,

As has been discussed earlier, the IESG does not approve of unlimited
extensibility and flexibility in protocols.  This type of thing actually
harms interoperability more than helps.  If we want flexibility in the
protocols, we need to be able to bound that extensibility & have some
explanations of the trade-offs.  My understanding of the current draft
text is that the editors were trying to clarify some ambiguity in
the draft.

I don't think it is good to have ambiguity in the document, so we need
to have some clarification of the text. If you are unhappy with
the current text, please submit new text. If you wish to support
more extensibility, then we need to have some text in the document
that explains the trade-offs.

thanks,
John

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 22 December, 2006 16:47
>To: 'Lars Westberg (KI/EAB)'; 'Ash, Gerald R (Jerry), ALABS'; 
>[email-masked]
>I agree with you! Furthermore, by limiting the capabilities of 
>the QOS models also the modularity and flexibility 
>characteristrics and advanteges of NSIS are limited.
>
>Best regards,
>Georgios
>
>> extendabillity to exactly the same as RSVP!!! I completely disagree 
>> with that approach.
>> 
>designed from 
>> scalabillity perspective and have support for Mutlicast support. We 
>> are designing exactly the same protocol but with limited functional 
>> support and without Multicast!!!!!
>suggested by 
>> so I don't favor going backwards to less clear terminology.  I was 
>> never clear on why we used the 'control information' terminology in 
>> the first place, e.g., I don't think it's a very good descriptor of 
>> the 'excess treatment' parameter.
>> 
>> I disagree.  The quoted text was introduced by Dave Oran in addition 
>> to removing the phrase implying that a QOSM could specify signaling 
>machines are 
>> within the scope of QoS-NSLP draft and not the QSPEC draft or a QOSM 
>> specification draft.  I think you have noted that also in your 
>> subsequent posting at 
>have had 
>> (tunneling) then presumably method a) is not also used at the same 
>referring e.g., 
>> local QSPEC that is consistent with the initiator QSPEC, as 
>we agreed 
>> on the list (see also slide 8 of the IETF-67 presentation).
>> 
>> initiator QSPEC by appending the handling directive parameters, then 
>> it is not allowed.
>> 
>> > > > Comment_5:
>> > > > -----------

---

From: <[email-masked]>
Date: Sat, 23 Dec 2006 19:31:46 +0200

Hi all,

When Jerry posted the draft with the change log, I basically noted
that the changes were based upon previous discussions, on the 
mailing list and the meeting.

I am unsure of the techincal issues that are being raised.  Rather
than get into a discussion of what was discussed or not, what I
would like to understand better is more understanding what are 
the technical issues behind Georgios' issues.

Additionally, I would like to hear from others about their opinions
on this issue.

thanks,
John

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 22 December, 2006 20:12
>It's not true as you and 2 others have stated that the changes 
>were not discussed.  They were discussed, at length.  For 
>example, the revised definition of QOSM was clearly stated and 
>discussed on the list, see 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm
>l and also see all the list discussion following that post.  
>The revised definition and all the other changes were clearly 
>presented in the slides at IETF-67, see minutes and slides at 
>http://www3.ietf.org/proceedings/06nov/index.html.  You can 
>listen to the complete IETF-67 presentation/discussion again 
>at 
>You can review the slides, meeting discussion, list 
>discussion, meeting minutes, and verify that for yourself.
>
>So the editors did not 'make up the changes without 
>discussion' as you and 2 others have suggested.  That is 
>certainly wrong and I think you should acknowledge that.
>
>It is not useful going forward to debate the past, but 
>incendiary wrong statements should not go unanswered.
>
>Once again, I've responded to your technical comments, you can 
>comment further if you wish. 
>
>template draft regarding the QSPEC control information and the 
>limitations of the QoS models have never been discussed 
>Furthermore, from what I have seen in v. 13 of the draft you 
>also have not solved the stacking issue, because you are 
>actually dictating that encapsulation cannot be combined and 
>used together with the tunneling (parallel sessions) method.
>
>
>Best Regards,
>Georgios
>
>> 
>>  
>> 
>> > > > > "5.4.2.  It SHOULD be Possible to Add and Remove 
>Local Domain 
>> > > > > Information
>> > > > > 
>> > > > > > > I do not understand the second sentence from the 
>below two
>> > > > > > > sentences:

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 23 Dec 2006 12:45:57 -0500

John;
 
I am sorry if you think so.
 
One thing is not clear: Did we define QOS model?
 
Best regards,
Radhika

From: [email-masked] [mailto:[email-masked]]
Sent: Sat 12/23/2006 12:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: warning (was:: Comments on draft-ietf-nsis-qspec-13.txt )

Rahdhika,
 
I have tried to politely ask you to restrain from content-free posting.  You are not the working group chair, so you are not in a position to declare working group concensus.  Additionally, it is clearly within our charter to work with QoS defined by other SDOs.
 
If you continue in your inappropriate postings, I will be forced to consider revoking your posting rights.
 
John

	 

	 
	Best regards,
	Radhika

	Georgios,

	

	Jerry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 23 Dec 2006 13:39:59 -0500

John:
 
In addition to Georgio's comments, here are some as follows:
 
1. We have to define what is "standard" QSPEC as Dave's proposed modifications.
 
2. Our understanding with respect to "standard" QSPEC is the end-to-end QSPEC template only as proposed by Roland. This needs to be clarified throughout the whole draft. Any inconsistencies to this must be removed from the draft. (If needed, a separate detail proposal will be posted in the Web site of this draft "showing" what needs to be done throughout the draft and people can see and then can make comment if the draft is not modified to change as proposed here.)
 
3. If we refer to QOS model in this draft, what does it mean? What is the definition of QOS model? Do RSVP, IntServ, and DiffServ qualify as standard QOS model? If so, why? Do QOS SLAs qualify as standard QOS models? If not, why do this draft refer Y.1451, DSTE, and 3GPP/Y.1415 as QOS models? If Y.1451, DSTE, and 3GPP/Y.1415 qualify as QOS models, will all the QOS SLAs based on DiffServ that are being performed throughout the world be included in this draft as a part of it? If not, why not?
 
4. Why do we want to include Y.1451 QOS classes extensions for this "generic" standard QSPEC draft as proposed in item 1 proposed by Dave mixing between "apples" and "oranges" bring technical inconsistencies like non-interoperability?
 
5. Why do the draft NOT refer all QOSM drafts as mentioned in item 1 for all QOS model-specific extensions of the standard generic QSPEC template and "remove" all QOS model-specific extensions like Y.1415? What happen to this when this question was resolved through agreement that there is no consensus on this point? The reply from an editor had been that these Y.1415 QOS SLAs were in the draft from the beginning, but was expected to be removed as they mix between "apples" and "oranges?" Why do these remain in this draft yet? Why are we keeping this technical inconsistency despite all those discussions and consensus?
 
6. The general "tone" of this draft should be to "describe" the generic "standard" QSPEC template parameters. It must NOT describe how this template be used by NSIS QOS signaling protocol. The NSIS QOS protocols be free to use this QSPEC template the way the applications like to use any specific parameters to serve its purpose. (If needed, a separate detail proposal will be posted in the Web site of this draft "showing" what needs to be done throughout the draft and people can see and then can make comment if the draft is not modified to change as proposed here.)
 
7. (By the way, all QOSM drafts that describe QOS model-specific will deal with all specific use of the generic "standard" QSPEC template as mentioned item 1.)
 
Best regards,
Radhika

From: [email-masked] on behalf of [email-masked]
Sent: Sat 12/23/2006 12:31 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 

Hi all,

thanks,
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 24 Dec 2006 07:28:30 +0000

Hi John

The modularity, flexibility and extensibility bounds of the QSEPC
template draft and the of the QoS models are set at ther starting time
of the NSIS WG.
These modularity, flexibility and extensibility bounds cannot be changed
after the completion of the QoS model work without having convincing
arguments.

My main diagreement on the current changes is that they are introduced
without any discussion, while their impact is very severe on the
functionality of other current and ongoing NSIS specifications.

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 24 Dec 2006 08:17:39 +0000

Hi John

I mainly disagree with the following three points that were never
discussed before:

Point_1):Removed the QSPEC control information
---------------------------------------------------------------
Jerry mentioned in a previous e-mail that this QSPEC control information
concept is not removed but it is renamed to Traffic Handling Directives.

If that is the case then Jerry will have to use the same definitions for
the
QSEPC control information as used in Section 5.3.1 of:
http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt

Thus my proposal is to change section 4.3.3 as given in v.13 of the QSEPC
template draft and include the general concept of the QSPEC control
information that was given in Section 5.3.1 of version 12 of the QSEPC
template draft. Note that the name can be changed but the semantics
should remain the same. Thus please chnage Section 4.3.3 as follows:

FROM:

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and cannot be overwritten.

INTO:

   Traffic Handling Directives are used for signaling QOSM RMF functions
   not defined in QoS NSLP.  It enables building new RMF functions
   required by a QOSM within a QoS NSLP signaling framework, such as
   specified, for example, in [RMD-QOSM] and [Y.1541-QOSM].

   <QSPEC Control Information> = <Excess Treatment>

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and is read-only.

-------------------------------

Point_2: dictates that encpasulation of the original initiator QSEPC
feature cannot be used in combination with the tunneling (parallel
session) feature.

In the discussion that we have had in the nsis mailing list and during
the IETF meeting it was stated that both these features should be
possible, while now version 13 of the QSPEC template draft dicates that
these two feratures cannot be used togetherand at the same time by the
same QoS model.
As I mentioned in all the discussions the encapsulation of the original
QSPEC feature is needed to satisfy Requirement:
"5.4.2.  It SHOULD be Possible to Add and Remove Local Domain
Information" given in: http://www.ietf.org/rfc/rfc3726.txt
Therefore the encapsulation (of the original initiator QSEPC into a local
QSPEC) feature should be seen as an independent feature and it should be
able to be used in combination with the tunneling (parallel session)
feature that is used for another goal.

Thius my proposal is that it should be mentioned that even when the
tunneling (parallel session) feature is used, it is also allowed to use,
at the same time, the encapsulation (of the original initiator QSEPC
into a local QSPEC) feature in order to satisfy Requirement 5.4.2 of RFC
3726.
---------------------------

Point_3: QSEPC template draft dictates which QOS-NSLP signaling features
should be used by QOS models.

We have never discussed an agreed that the QSPEC template draft defines
how the QOS-NSLP functionality should be used by QoS models. This should
be defined by the QOS-NSLP draft.
Therefore, regarding this issue  the QSPEC template draft should refer to
Section "3.1.2.  QoS Models and QoS Specifications"" of:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt

Therefore the QSPEC tempate draft should adpat the definitiojn of the QoS
models according to what Section 3.1.2 of the QOS-NSLP draft is saying
and refer to Section 3.1.2 of the QOS-NSLP draft.

Best Regards,
Georgios