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

From: [email-masked]
Date: Fri, 16 Feb 2007 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-15.txt
	Pages		: 54
	Date		: 2007-2-16
	
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-15.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-15.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-15.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\), ATTLABS" <[email-masked]>
Date: Sun, 18 Feb 2007 17:17:56 -0600

Hi All,

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

The changes are as agreed in discussion on the list over the past
several weeks:

1. Section 4.1 (QoS Models), replace 2nd paragraph with following text:

"QOSM specifications may define RMF triggers that cause the QoS NSLP to
run semantics within the underlying QoS NSLP signaling state and
messaging processing rules, as defined in Section 5.2 of [QoS-SIG].  New
QoS NSLP message processing rules can only be defined in Standards Track
extensions to the QoS NSLP.  If a QOSM specification defines triggers
that deviate from existing standard QoS NSLP processing rules (must be
standards track in that case), the fallback for QNEs not supporting that
QOSM is to use the standard QoS NSLP state transition/message processing
rules."

2. Section 4.3.3 (Traffic Handling Directives), rewrite this section as
follows:

"4.3.3 Traffic Handling Directives

An application MAY like to reserve resources for packets and also
specify a specific traffic handling behavior, such as <Excess
Treatment>. In addition, an application MAY like to define RMF triggers
that cause the QoS NSLP to run semantics within the underlying QoS NSLP
signaling state and messaging processing rules, as defined in Section
5.2 of [QoS-SIG].  Note, however, that new QoS NSLP message processing
rules can only be defined in Standards Track extensions to the QoS NSLP.

As with constraints parameters and other QSPEC parameters,
traffic-handling-directives parameters may be defined in QOSM
specifications in order to provide support for QOSM-specific resource
management functions.  Such QOSM-specific parameters are already
defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM].

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."

3. Sections 5.3.1, 5.3.2, 5.3.3, add the following paragraph at the end
of each section:
 
"Regarding <Traffic Handling Directives>, 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 <Traffic Handling Directives> parameters are read-only.
Note that a QOSM specification may define its own <Traffic Handling
Directives> parameters and processing rules."

Hopefully we can now proceed with working group last call on the
document.

Thanks,
Jerry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.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: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 19 Feb 2007 14:22:28 +0100

Hi Jerry

I think that my comments have been worked out well!
Thank you very much!

Best regards,
Georgios 

> From: ASH, GERALD R (JERRY), ATTLABS [mailto:[email-masked]] 
> Sent: maandag 19 februari 2007 0:18
> To: [email-masked]
> Cc: ASH, GERALD R (JERRY), ATTLABS
> Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt 
> 
> Hi All,
> 
> The changes are as agreed in discussion on the list over the 
> past several weeks:
> 
> "QOSM specifications may define RMF triggers that cause the 
> QoS NSLP to run semantics within the underlying QoS NSLP 
> signaling state and messaging processing rules, as defined in 
> Section 5.2 of [QoS-SIG].  New QoS NSLP message processing 
> rules can only be defined in Standards Track extensions to 
> the QoS NSLP.  If a QOSM specification defines triggers that 
> deviate from existing standard QoS NSLP processing rules 
> (must be standards track in that case), the fallback for QNEs 
> not supporting that QOSM is to use the standard QoS NSLP 
> state transition/message processing rules."
> 
> An application MAY like to reserve resources for packets and 
> also specify a specific traffic handling behavior, such as <Excess
> that cause the QoS NSLP to run semantics within the 
> underlying QoS NSLP signaling state and messaging processing 
> rules, as defined in Section
> 5.2 of [QoS-SIG].  Note, however, that new QoS NSLP message 
> processing rules can only be defined in Standards Track 
> extensions to the QoS NSLP.
> 
> specifications in order to provide support for QOSM-specific 
> resource management functions.  Such QOSM-specific parameters 
> are already defined, for example, in [RMD-QOSM], [CL-QOSM] 
> and [Y.1541-QOSM].
> 
> 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."
> 
> 3. Sections 5.3.1, 5.3.2, 5.3.3, add the following paragraph 
> at the end of each section:
>  
> "Regarding <Traffic Handling Directives>, 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 
> <Traffic Handling Directives> parameters are read-only.
> Hopefully we can now proceed with working group last call on 
> the document.
> 
> Thanks,
> Jerry 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 20 Feb 2007 15:54:44 +0100

Dear all,

I would like to start the working group last call for the QSPEC draft
(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt).

The WGLC is starting today and will run for two weeks until Tuesday  
Feb 6th.

Please send your comments to the NSIS WG list.

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: <[email-masked]>
> Datum: 16. Februar 2007 21:50:02 MEZ
> An: <[email-masked]>
> Kopie: <[email-masked]>
> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt
>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 20 Feb 2007 18:38:16 +0100

Hi all,

The WGLC is actually running until March 6th and not Feb 6th.

Sorry for the confusion

   Martin

Am 20.02.2007 um 15:54 schrieb Martin Stiemerling:

>> <ATT61320.TXT>
>> <draft-ietf-nsis-qspec-15_URL.DEFANGED-0>
>> <ATT61321.txt>
>
>
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 21 Feb 2007 07:12:55 +0000

Hi Martin

I am not sure, but in order to run the WGLC on the Qspec draft I think
that the QoS-NSLP draft should be first finalised.

At the moment we are working on defining the possible RMF triggers that
could influence the QoS-NSLP protocol state machine.

Best Regards,
Georgios

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 22 Feb 2007 09:23:05 +0100

Hi Georgios,

Having a basic understanding of the QoS NSLP is required to  
understand the QSPEC, but from the discussion we have had in the last  
four weeks, I have seen that the QSPEC as it is, is rather self- 
contained.
The semantically operation of the QoS NSLP is independent of the  
QSPEC, i.e., the QSPEC can only trigger QoS NSLP behaviour but not  
change it.

The possible RMF triggers will be defined in the QoS NSLP, as decided  
earlier, i.e., no change required to the QSPEC.

So we can go ahead with the WGLC for the QSPEC document.

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Feb 2007 11:00:27 +0100

Hi Martin

If you think that this is possible and okay, then it is also okay for me!

Best regards,
Georgios

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: donderdag 22 februari 2007 9:23
> To: Georgios Karagiannis
> Cc: nsis
> Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt
> 
> Hi Georgios,
> 
> understand the QSPEC, but from the discussion we have had in 
> the last four weeks, I have seen that the QSPEC as it is, is 
> rather self- contained.
> The semantically operation of the QoS NSLP is independent of 
> the QSPEC, i.e., the QSPEC can only trigger QoS NSLP 
> behaviour but not change it.
> 
> The possible RMF triggers will be defined in the QoS NSLP, as 
> decided earlier, i.e., no change required to the QSPEC.
> 
> > At the moment we are working on defining the possible RMF triggers 
> > that could influence the QoS-NSLP protocol state machine.
> >
> > Best Regards,
> > Georgios
> >
> >>>>    and thereby aim to ensure the extensibility and 
> interoperability 
> >>>> of
> >>>> 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.
> >>>> logging in, type "cd internet-drafts" and then "get 
> >>>> draft-ietf-nsis-qspec-15.txt".
> >>>>
> >>>> http://www.ietf.org/shadow.html or 
> >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
> 
>

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Mon, 26 Feb 2007 05:41:36 -0600

Hi All,

Cornelia caught an editing glitch in Section 5.4 (QSPEC Extensibility),
first paragraph, of the QSPEC document
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt, where
the following text should be deleted:

"The set of QSPEC parameters defined herein is at this point in time
considered complete.  Additional QSPEC parameters may be defined in the
future.  However, since this requires an update of all QNEs, this should
be considered carefully.  The definition of new QSPEC parameter requires
standards action and an update of this document.  Such an update also
needs a new QSPEC version number.  Furthermore, all QOSM definitions
must be updated to include how the new QSPEC parameter is to be
interpreted in the respective QOSM."

Prior to our eliminating QSPEC1 ('mandatory') QSPEC parameters it used
to say:
"The set of QSPEC1 parameters defined herein is at this point in time
considered complete.  Additional QSPEC1 parameters may be defined in the
future.  However, since this requires an update of all QNEs, this should
be considered carefully.  The definition of new QSPEC1 parameter
requires standards action and an update of this document..."

Since QSPEC1 parameters had to be supported by all QNEs, this was the
reason for this text.  However the reason no longer exists, and the text
should be removed.  QSPEC parameters can of course be defined in QOSM
specification documents; that is clearly stated in the second paragraph
of Section 5.4.

Thanks,
Jerry

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 12:38 PM
To: nsis
Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt 

Hi all,

Sorry for the confusion

Martin

Am 20.02.2007 um 15:54 schrieb Martin Stiemerling:

>> interoperability of
>> the intention of the NSIS initiator is preserved along the  
>> signaling path.
>>

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Mon, 26 Feb 2007 11:36:14 -0600

Hi All,

We caught another editing glitch in Section 8 (IANA Considerations) of
the QSPEC document
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt, which
defines the registry for QSPEC parameters as follows:

"  Parameter ID (12 bits):
   The following values are allocated by this specification:
   1-14: assigned as specified in Section 6.2:
   Parameter ID 1: <TMOD-1>
                2: <TMOD-2>
                ...

   The allocation policies for further values are as follows:
   15-63: Standards Action (for QSPEC parameters)
   64-127: Specification Required (for QSPEC parameters)
   128-255: Private/Experimental Use
   255-4095: Reserved

   A specification is required to depreciate, delete, or modify
   Parameter IDs.  Note that if additional QSPEC parameters are
   defined in the future, this requires a standards action equivalent to
   reissuing this document as a QSPEC-bis."

Prior to our eliminating QSPEC-1 ('mandatory') and QSPEC-2 ('optional')
parameters this text used to read:

"  The allocation policies for further values are as follows:
   15-63: Standards Action (for QSPEC-1 parameters)
   64-127: Specification Required (for QSPEC-2 parameters)
   128-255: Private/Experimental Use
   255-4095: Reserved

   A specification is required to depreciate, delete, or modify
   Parameter IDs.  Note that if additional QSPEC-1 parameters are
   defined in the future, this requires a standards action equivalent to
   reissuing this document as a QSPEC-bis."

Rather this text should now say:

"  The allocation policies for further values are as follows:
   15-127: Specification Required
   128-255: Private/Experimental Use
   255-4095: Reserved

   A specification is required to depreciate, delete, or modify
   Parameter IDs."

Note also that all that is required is a specification document (not a
QOSM specification document) to define new QSPEC parameters in the
registry.  So the text in Section 5.4 (QSPEC Extensibility) needs to be
modified accordingly.

Thanks,
Jerry

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 12:38 PM
To: nsis
Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt 

Hi all,

Sorry for the confusion

Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 28 Feb 2007 05:36:34 +0000

Hi

I was busy updating some of the QOSM drafts and I have seen that starting
from version 13 of the QSPEC draft, the QOSM ID field  is removed form
the common header of a QSPEC object and instead of this, the field QSPEC
type is used.
I agree that QSPEC type (shows if the QSPEC object is initial or a local)
 is useful and it should be used, but by removing the QOSM ID field it
will mean that a QNE can always support only one type of initial
(end-to-end) QOSM and one type of local QOSM.
That is not reasonable. A QNE should be able to support many QOSMs and it
should be able to distinguish and associate a QSPEC object with a
certain QOSM.

Therefore, I think that it is required that the QOSM ID field should be
reintroduced in the QSPEC common header. The field QSPEC type is also
useful ant it should be kept.

Best regards,
Georgios

On 2/20/2007, "Martin Stiemerling" <[email-masked]> wrote:

>> signaling
>> Internet-Draft.)

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 28 Feb 2007 07:42:49 -0600

Georgios, All,

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 12:37 AM
> To: Martin Stiemerling; nsis
> Subject: [NSIS] comment on reintroduction of QOSM-ID in qspec draft
> 
> Hi
> 
> the common header of a QSPEC object and instead of this, the 
> field QSPEC type is used.

The QSPEC Type was introduced to support Roland's QSPEC
stacking/encapsulation method (see
http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.html), it
does not replace QOSM ID.

The QOSM ID was removed in the discussion around the QSPEC-13 draft
update, see the post on 1 November 2006
http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.html, where
it says "A QOSM ID
need not be defined or signaled and a QNE need not support any
particular QOSM".  Slide 3 of the QSPEC presentation at IETF-67 makes
the same point.  The same point is made again in the announcement of the
draft to the NSIS list at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.html and the
point is also made in Appendix A of the QSPEC draft itself.  There were
no objections to this point.

> should be able to distinguish and associate a QSPEC object with a

There is no mention in any QSPEC draft as to how or why a QOSM ID field
is needed or used.  A QNE can support any QOSM it wants, it does not
depend on a QOSM ID field from the QNI to determine which one.

At a minimum, we would need to have a bit-level example of how/why such
a field is needed to justify reintroducing the QOSM ID field.

> useful ant it should be kept.

We need clear justification to reintroduce the complexity of having the
QOSM ID field and the IANA registry to maintain the parameter.

Jerry
 
> >> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce