Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 4 Jan 2007 10:04:11 -0600

Hi John, All,

Happy New Year!

It appears we still have a few technical issues to resolve, as
summarized below by Georgios, in addition to the editorial issues that
have been raised on the list. 

I believe that Dave mostly pulled us out of the dead-lock we've been in
for the last several months, and that most of us agreed that the QSPEC
was overall simplified and the issues were largely resolved.  

I've commented on the 3 issues below; hopefully we can quickly reach
consensus so we can move forward: 

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Sunday, December 24, 2006 3:18 AM
> To: [email-masked]; Ash, Gerald R (Jerry), ALABS; 
> [email-masked]
> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
> 
> 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
> QSPEC 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 QSPEC
> 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 QSPEC
> template draft. Note that the name can be changed but the semantics
> should remain the same. Thus please change Section 4.3.3 as follows:
> 
> FROM:
> 
> 4.3.3 Traffic Handling Directives
> 
>    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:
> 
> 4.3.3  Traffic Handling Directives
> 
>    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].

I think most (perhaps all?) of us agree on this point: the QOSM
specification SHOULD NOT be allowed to define 'new RMF functions
required by a QOSM' UNLESS such NSIS signaling functionality is defined
in QoS NSLP.  I.e., a QOSM is not allowed to extend QoS NSLP signaling
functionality.  The above text seems to abide by the premise by stating
that new RMF functions are specified only 'within a QoS NSLP signaling
framework'.  If so, I think we're in agreement.

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

IMO we don't need to introduce the former "<QSPEC Control Information>"
terminology in addition to the "Traffic Handling Directives"
terminology.  Furthermore, "QSPEC control information" implies that the
information applies to control of the QSPEC itself rather than another
QoS parameter type like a handling directive.

> -------------------------------
> 
> Point_2: dictates that encapsulation of the original initiator QSPEC
> 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 
> dictates that
> these two features cannot be used together and 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 QSPEC 
> 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.
> 
> Thus 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 QSPEC
> into a local QSPEC) feature in order to satisfy Requirement 
> 5.4.2 of RFC
> 3726.

I don't see a reason to preclude using, at the same time, both
1. tunneling a QSPEC through a local domain by initiating a new RESERVE
at the domain edge,
AND
2. defining a local QSPEC and encapsulating the initiator QSPEC, as
defined in Section 5.1 of the QSPEC draft
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt.

Georgios provided an example based on the RMD-QOSM of when it would be
necessary to use both features at the same time.  I think we're in
agreement here.

> ---------------------------
> 
> Point_3: QSPEC 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 template draft should adapt the 
> definition 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.

I'm not sure I fully understand Georgios' phrasing here.  I agree that
signaling functionality should only be defined by the QoS NSLP draft and
that the QSPEC draft should not specify 'how the QoS NSLP functionality
should be used by QoS models'.  If that is the point, we're in agreement
here also.

It would really be good to get resolution and move on with
QoS-NSLP/QSPEC at long last.  If I understand correctly, I think we're
mostly in agreement on the above issues.

Thanks,
Jerry

> 
> Best Regards,
> Georgios
> 
> On 12/23/2006, "[email-masked]" <[email-masked]>
> wrote:
> 
> >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 technical 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

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 17:10:04 +0100

Hi Jerry

Regarding the following point, I think that we are not in agreement:

>> I think most (perhaps all?) of us agree on this point: 
>> the QOSM specification SHOULD NOT be allowed to define 
>> 'new RMF functions required by a QOSM' UNLESS such NSIS 
>> signaling functionality is defined in QoS NSLP.  I.e., a 
>> QOSM is not allowed to extend QoS NSLP signaling 
>> functionality.  The above text seems to abide by 
>> the premise by stating that new RMF functions are 
>> specified only 'within a QoS NSLP signaling framework'.  
>> If so, I think we're in agreement. 

Please see the last e-mails sent by Hannes!

Best regards,
Georgios

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: donderdag 4 januari 2007 17:04
> To: [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> It appears we still have a few technical issues to resolve, 
> as summarized below by Georgios, in addition to the editorial 
> issues that have been raised on the list. 
> 
> I believe that Dave mostly pulled us out of the dead-lock 
> we've been in for the last several months, and that most of 
> us agreed that the QSPEC was overall simplified and the 
> issues were largely resolved.  
> 
> I've commented on the 3 issues below; hopefully we can 
> quickly reach consensus so we can move forward: 
> 
> > information concept is not removed but it is renamed to Traffic 
> > Handling Directives.
> > 
> definitions 
> > for the QSPEC control information as used in Section 5.3.1 of:
> > Thus my proposal is to change section 4.3.3 as given in v.13 of the 
> > QSPEC 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 QSPEC template draft. Note that the name can be changed but the 
> > semantics should remain the same. Thus please change 
> Section 4.3.3 as 
> > follows:
> > 
> > FROM:
> > 
> I think most (perhaps all?) of us agree on this point: the 
> QOSM specification SHOULD NOT be allowed to define 'new RMF 
> functions required by a QOSM' UNLESS such NSIS signaling 
> functionality is defined in QoS NSLP.  I.e., a QOSM is not 
> allowed to extend QoS NSLP signaling functionality.  The 
> above text seems to abide by the premise by stating that new 
> RMF functions are specified only 'within a QoS NSLP signaling 
> terminology.  Furthermore, "QSPEC control information" 
> implies that the information applies to control of the QSPEC 
> itself rather than another QoS parameter type like a handling 
> directive.
> 
> > possible, while now version 13 of the QSPEC template draft dictates 
> > that these two features cannot be used together and 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:
> > Therefore the encapsulation (of the original initiator QSPEC into a 
> > local
> it should 
> > be able to be used in combination with the tunneling (parallel 
> > session) feature that is used for another goal.
> > 
> > tunneling (parallel session) feature is used, it is also allowed to 
> > use, at the same time, the encapsulation (of the original initiator 
> > QSPEC into a local QSPEC) feature in order to satisfy Requirement
> > 5.4.2 of RFC
> > 3726.
> 
> I don't see a reason to preclude using, at the same time, 
> both 1. tunneling a QSPEC through a local domain by 
> initiating a new RESERVE at the domain edge, AND 2. defining 
> a local QSPEC and encapsulating the initiator QSPEC, as 
> Georgios provided an example based on the RMD-QOSM of when it 
> would be necessary to use both features at the same time.  I 
> think we're in agreement here.
> 
> > Point_3: QSPEC 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
> should refer 
> > to Section "3.1.2.  QoS Models and QoS Specifications"" of:
> definition 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.
> 
> I'm not sure I fully understand Georgios' phrasing here.  I 
> agree that signaling functionality should only be defined by 
> the QoS NSLP draft and that the QSPEC draft should not 
> specify 'how the QoS NSLP functionality should be used by QoS 
> models'.  If that is the point, we're in agreement here also.
> 
> QoS-NSLP/QSPEC at long last.  If I understand correctly, I 
> think we're mostly in agreement on the above issues.
> 
> Thanks,
> Jerry
> 
> > 
> > Best Regards,
> > Georgios
> > 
> > >that the changes were based upon previous discussions, on 
> the mailing 
> > >list and the meeting.
> > >
> > >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.
> > >

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 14:51:49 +0200

Hi Jerry,

I will reply to your points one by one, in separate mails.

>summarized below by Georgios, in addition to the editorial 
>we've been in for the last several months, and that most of us 
>agreed that the QSPEC was overall simplified and the issues 
>were largely resolved.  

Yes, I believe we have rough consensus on this.  I suggest we
move forward on this.

More in my next mails.

John

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 14:54:08 +0200

>> If that is the case then Jerry will have to use the same definitions 
>> control information that was given in Section 5.3.1 of version 12 of 
>> semantics should remain the same. Thus please change Section 
>4.3.3 as 
>> follows:
>> 
>> FROM:
>> 
>>    excess traffic, that is, out-of-profile traffic.  Excess traffic
MAY
>>    be dropped, shaped and/or remarked. The excess treatment parameter
is
>allowed to extend QoS NSLP signaling functionality.  The above 
>text seems to abide by the premise by stating that new RMF 
>functions are specified only 'within a QoS NSLP signaling 

I agree with Jerry's text, and I believe we have rough consensus on
this.
If anyone disagrees with consensus, a short mail stating that you
disagree is needed.

On point, in order to extend QoS NSLP signaling, a Standards Track RFC
is needed.

John

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 14:57:43 +0200

>> that these two features cannot be used together and at the same time 
>> by the same QoS model.
local
>> QSPEC) feature should be seen as an independent feature and it should

>1. tunneling a QSPEC through a local domain by initiating a 
>new RESERVE at the domain edge, AND 2. defining a local QSPEC 
>and encapsulating the initiator QSPEC, as defined in Section 
>5.1 of the QSPEC draft 

I agree as well.

John

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 15:01:01 +0200

>> This should be defined by the QOS-NSLP draft.
>> Therefore, regarding this issue  the QSPEC template draft should
refer 
>> Therefore the QSPEC template draft should adapt the definition of the

>the QoS NSLP draft and that the QSPEC draft should not specify 
>'how the QoS NSLP functionality should be used by QoS models'. 
> If that is the point, we're in agreement here also.

I agree with Jerry's view on this.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 5 Jan 2007 14:32:23 +0100

Hi John

I think that description and proposal of Jukka, 
please see e-mail sent by Jukka,
gives a solution to this problem. 

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 5 januari 2007 13:54
> To: [email-masked]; [email-masked]
> Subject: [NSIS] Consensus on: Removed the QSPEC control information
> 
> 
> I agree with Jerry's text, and I believe we have rough 
> consensus on this.
> If anyone disagrees with consensus, a short mail stating that 
> you disagree is needed.
> 
> On point, in order to extend QoS NSLP signaling, a Standards 
> Track RFC is needed.
> 
> John
>

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Fri, 5 Jan 2007 15:02:36 +0100

Hi John, 

I disagree, I think the right approach is what Yukka sent. 

"The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer QNE MUST BE preserved, and within those bounds a QOSM must operate."

This means that e.g.,
a) The resource request by the QNI and response from the QNR must be 
   followed and passed through intact by a QOSM X domain,
b) confirmation requests must be answered,
c) tear-down must be followed, etc. "

I think QoS NSLP operation can be extended in a local QoS domain without distroying e2e QoS-NSLP operation.

Best regards, Attila

>Sent: Friday, January 05, 2007 1:54 PM
>parameter

---

From: David R Oran <[email-masked]>
Date: Fri, 5 Jan 2007 10:01:58 -0500

On Jan 5, 2007, at 9:02 AM, Attila Báder (IJ/ETH) wrote:

> "The end-to-end semantic and QoS NSLP messaging by the QNI, or any  
> peer QNE MUST BE preserved, and within those bounds a QOSM must  
> operate."
>
> This means that e.g.,
> I think QoS NSLP operation can be extended in a local QoS domain  
> without distroying e2e QoS-NSLP operation.
>
John L. seemed to be of the view that if a particular domain-loal QoS  
scheme (e.g. RMD) wants to use QoS-NSLP for its local scheme, then it  
is free to modify it if and only if there is a standards track RFC  
documenting the extensions/changes. This represents my view as well.  
This is the only way we can ascertain upwards/downwards compatibility  
and interoperability. Otherwise what you would have is a completely  
private signaling scheme which claims conformance to a standard.

These QoS-NSLP extensions would have no effect on the QSPEC  
specification, unless the QSPEC itself is being extended, in which  
case I think it's still an open issue whether or not you need a  
standards track RFC for that. My guess would be yes if we adopt  
Yukka's encoding scheme (because otherwise you could not find or  
debug the end-to-end QSPEC when embedded in an extended local QSPEC),  
but possibly no if we adopt a more layered encoding like QSPEC  
stacking (so that the parser has a known regular encoding structure  
to deal with).

Cheers, Dave.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 5 Jan 2007 16:39:42 +0100

Hi Dave

But I think that Jukka emphasized that it does not need to be 
a standards track if it complies to:
* the constraints specified in the QOS-NSLP document (see Jukkas proposal), 
and of course if the QOS model draft is approved by the IESG for
publication. 

Best regards,
Georgios

> From: David R Oran [mailto:[email-masked]] 
> Sent: vrijdag 5 januari 2007 16:02
> To: Attila Báder (IJ/ETH)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [NSIS] Consensus on: Removed the QSPEC control 
> information
> 
> 
> John L. seemed to be of the view that if a particular 
> domain-loal QoS scheme (e.g. RMD) wants to use QoS-NSLP for 
> its local scheme, then it is free to modify it if and only if 
> there is a standards track RFC documenting the 
> extensions/changes. This represents my view as well.  
> This is the only way we can ascertain upwards/downwards 
> compatibility and interoperability. Otherwise what you would 
> have is a completely private signaling scheme which claims 
> conformance to a standard.
> 
> specification, unless the QSPEC itself is being extended, in 
> which case I think it's still an open issue whether or not 
> you need a standards track RFC for that. My guess would be 
> yes if we adopt Yukka's encoding scheme (because otherwise 
> you could not find or debug the end-to-end QSPEC when 
> embedded in an extended local QSPEC), but possibly no if we 
> adopt a more layered encoding like QSPEC stacking (so that 
> the parser has a known regular encoding structure to deal with).
> 
> Cheers, Dave.
> 
> > Best regards, Attila
> >
> >
> >>>>    required by a QOSM within a QoS NSLP signaling 
> framework, such 
> >>>> as
> consensus on 
> >> On point, in order to extend QoS NSLP signaling, a Standards Track 
> >> RFC is needed.
> >>
> >> John
> >>

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 19:06:21 +0200 (EET)

Hi Georgios,

I didn't imply that the constraints would include defining some new NSLP 
messages, or other things that are not already part of the QSPEC, or 
the NSLP.

Yet, a QOS Model might e.g., define new INFO_SPEC error/info codes, or a 
new object within the QSPEC, but I guess those would require standards 
action, and a standards track RFC.

A QOS Model should not change the end-to-end semantics of the NSLP, or of 
the QSPEC - this is what I wrote.

I haven't read lately the RMD spec, so I don't know what are the 
functionality that are introduced in addition to what is already in the 
QSPEC and the NSLP.

Cheers,
Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 5 Jan 2007 18:16:45 +0100

Hi Jukka

What I meant are your following statements:
" A certain domain running a QOSM X can well do certain optimizations, 
incl. separate signaling sessions and aggregation, provided that

1) it fulfils the original request of the QNIs, and

2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the 
   QNI, or any peer QNE are preserved.

Within those bounds a QOSM must operate, incl. any domain internal optimized
signaling."

Of course no additional QoS-NSLP messages and QOS-NSLP objects
can be defined by the QOS model. What a QOS model 
should be able to do is to define new 
QSPEC objects and to define how the QOS-NSLP siganling 
in the domains internal, as you suggested under certain bounds, 
can be optimized.

Best Regards,
Georgios

> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: vrijdag 5 januari 2007 18:06
> To: Georgios Karagiannis
> Cc: 'David R Oran'; 'Attila Báder (IJ/ETH)'; John Loughney; 
> Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control 
> information
> 
> 
> Hi Georgios,
> 
> I didn't imply that the constraints would include defining 
> some new NSLP messages, or other things that are not already 
> part of the QSPEC, or the NSLP.
> 
> Yet, a QOS Model might e.g., define new INFO_SPEC error/info 
> codes, or a new object within the QSPEC, but I guess those 
> would require standards action, and a standards track RFC.
> 
> A QOS Model should not change the end-to-end semantics of the 
> NSLP, or of the QSPEC - this is what I wrote.
> 
> 
> > > >>>>    The <Excess Treatment> parameter describes how 
> the QNE will
> > > >> process

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 19:33:08 +0200 (EET)

Hi Georgios,

I guess new QSPEC objects could be allowed

a) flexibly if their are only used within the local domain, and not e2e 
(which would require all QNEs to be upgraded),

b) through NSLP standards action, if they need to be understood by all 
   QNEs on the e2e path.

I would expect the same goes with the NSLP, ie., if RMD changes the NSLP 
message processing in some way, it can do so, but only for the local 
domain, without affecting any QNEs (incld QNI and QNR) outside the RMD 
domain). And this must still preserve the e2e messaging semantics.

Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 5 Jan 2007 18:36:55 +0100

Hi Jukka

> I would expect the same goes with the NSLP, ie., if RMD 
> changes the NSLP message processing in some way, it can do 
> so, but only for the local domain, without affecting any QNEs 
> (incld QNI and QNR) outside the RMD domain). And this must 
> still preserve the e2e messaging semantics.

Agreed, the change in the NSLP message processing holds only for the 
QNEs within the local domain, not outside the domain.

Best regards,
Georgios

> Sent: vrijdag 5 januari 2007 18:33
> To: Georgios Karagiannis
> Cc: 'David R Oran'; 'Attila Báder (IJ/ETH)'; 'John Loughney'; 
> 'Ash, Gerald R \(Jerry\), ALABS'; [email-masked]
> a) flexibly if their are only used within the local domain, 
> and not e2e (which would require all QNEs to be upgraded),
> 
> I would expect the same goes with the NSLP, ie., if RMD 
> changes the NSLP message processing in some way, it can do 
> so, but only for the local domain, without affecting any QNEs 
> (incld QNI and QNR) outside the RMD domain). And this must 
> still preserve the e2e messaging semantics.
> 
> Jukka
> 
> > Within those bounds a QOSM must operate, incl. any domain internal 
> > optimized signaling."
> > 
> > 
> > Of course no additional QoS-NSLP messages and QOS-NSLP 
> objects can be 
> > defined by the QOS model. What a QOS model should be able 
> to do is to 
> > define new QSPEC objects and to define how the QOS-NSLP 
> siganling in 
> > the domains internal, as you suggested under certain bounds, can be 
> > optimized.
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > 
> >  
> > 
> > > Cc: 'David R Oran'; 'Attila Báder (IJ/ETH)'; John Loughney; Ash, 
> > > Gerald R (Jerry), ALABS; [email-masked]
> > > I didn't imply that the constraints would include 
> defining some new 
> > > NSLP messages, or other things that are not already part of the 
> > > QSPEC, or the NSLP.
> > > 
> > > Yet, a QOS Model might e.g., define new INFO_SPEC 
> error/info codes, 
> > > or a new object within the QSPEC, but I guess those would require 
> > > standards action, and a standards track RFC.
> > > 
> > > A QOS Model should not change the end-to-end semantics of 
> the NSLP, 
> > > or of the QSPEC - this is what I wrote.
> > > 
> > > 
> > > functionality that are introduced in addition to what is 
> already in 
> > > the QSPEC and the NSLP.
> > > 
> > > Cheers,
> > > Jukka
> > > 
> > > > But I think that Jukka emphasized that it does not need to be a 
> > > > standards track if it complies to:
> > > > > > peer QNE MUST BE preserved, and within those bounds a QOSM 
> > > > > > must operate."
> > > > > >
> > > > > > This means that e.g.,
> > > > > domain-loal QoS scheme (e.g. RMD) wants to use 
> QoS-NSLP for its 
> > > > > local scheme, then it is free to modify it if and 
> only if there 
> > > > > is a standards track RFC documenting the extensions/changes. 
> > > > > This represents my view as well.
> > > > > which case I think it's still an open issue whether 
> or not you 
> > > > > need a standards track RFC for that. My guess would 
> be yes if we 
> > > > > adopt Yukka's encoding scheme (because otherwise you 
> could not 
> > > > > find or debug the end-to-end QSPEC when embedded in 
> an extended 
> > > > > local QSPEC), but possibly no if we adopt a more layered 
> > > > > encoding like QSPEC stacking (so that the parser has a known 
> > > > > regular encoding structure to deal with).
> > > > > 
> > > > > Cheers, Dave.
> > > > > 
> > > > > > Best regards, Attila
> > > > > >
> > > > > >
> > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC 
> > > > > >>>> control information concept is not removed but it is 
> > > > > >>>> renamed
> > > to Traffic
> > > > > >>>> Handling Directives.
> > > > > >>>>
> > > > > >>>> Section
> > > > > >>> required by a QOSM' UNLESS such NSIS signaling 
> functionality
> > > > > >> is defined
> > > > > >>> in QoS NSLP.  I.e., a QOSM is not allowed to 
> extend QoS NSLP
> > > > > >> signaling
> the premise
> > > > > >> by stating
> > > > > >>> that new RMF functions are specified only 'within 
> a QoS NSLP
> > > > > >> signaling

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 19:52:34 +0200 (EET)

Good. Then I don't see what the problem is. The e2e semantics of the 
NSLP messaging are preserved, and the request by the QNI is supported 
(provided the resources are there).

Jukka

---

From: <[email-masked]>
Date: Sat, 6 Jan 2007 10:10:29 +0200

Hi all,

My bigger concern is - how will implementations work?  Will we need 2
completely different implementations to work in different scenarios?
What is the reuse of implementations conforming to the base Qos NSLP
spec?

I agree with Dave's point:

> I think the constraints are stronger than this, if you want the domain-local 
> elements to be able to claim conformance to the QOS NSLP specification. If not, 
> the entire argument is moot, since then your domain-local signaling is 
> completely proprietary and non-standard.

John

>From: ext Jukka MJ Manner [mailto:[email-masked]] 
>Sent: 05 January, 2007 19:53
>To: Georgios Karagiannis
>Cc: 'David R Oran'; 'Attila Báder (IJ/ETH)'; Loughney John 
>(Nokia-NRC/PaloAlto); 'Ash, Gerald R \\\(Jerry\\\), ALABS'; 
>[email-masked]
>Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information
>
>
>Good. Then I don't see what the problem is. The e2e semantics 
>of the NSLP messaging are preserved, and the request by the 
>QNI is supported (provided the resources are there).
>
>Jukka
>
>changes the 
>> > NSLP message processing in some way, it can do so, but 
>only for the 
>> > local domain, without affecting any QNEs (incld QNI and 
>QNR) outside 
>> > the RMD domain). And this must still preserve the e2e messaging 
>> > semantics.
>> 
>> > Cc: 'David R Oran'; 'Attila Báder (IJ/ETH)'; 'John 
>Loughney'; 'Ash, 
>> > Gerald R \(Jerry\), ALABS'; [email-masked]
>> > a) flexibly if their are only used within the local 
>domain, and not 
>> > e2e (which would require all QNEs to be upgraded),
>> > 
>changes the 
>> > NSLP message processing in some way, it can do so, but 
>only for the 
>> > local domain, without affecting any QNEs (incld QNI and 
>QNR) outside 
>> > the RMD domain). And this must still preserve the e2e messaging 
>> > semantics.
>> > 
>> > Jukka
>> > 
>> > > the domains internal, as you suggested under certain bounds, can 
>> > > be optimized.
>> > > 
>> > > Best Regards,
>> > > Georgios
>> > > 
>> > > 
>> > > 
>> > >  
>> > > 
>> > > > or a new object within the QSPEC, but I guess those would 
>> > > > require standards action, and a standards track RFC.
>> > > > 
>> > > > > > >>>> Thus my proposal is to change section 4.3.3 
>as given in
>> > > > > > v.13 of the
>> > > > > > >>>> QSPEC template draft and include the general 
>concept of
>> > > > > > the QSPEC
>> > > > > > >>>>    not defined in QoS NSLP.  It enables building new 
>> > > > > > >>>> RMF
>> > > > > > functions

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 6 Jan 2007 17:17:48 +0200 (EET)

Hi John,

That is actually a good point. So far I have hoped that we can clearly 
de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP 
implementation can run with all different RMFs and QOSMs.

If a QOSM affects the common message processing, we need different 
implementations. Yet, I guess this also applies to various tunneling, 
session binding, and separate signaling sessions that might be used within 
a domain.

Do we need to document how the RMF and QoS NSLP fit together, what is 
passed between the RMF and NSLP, what are the API issues, what kind on 
asymmetric triggers the RMF can send to the NSLP, etc. I think we need to 
write such a draft, and document all the interactions. If we have that 
written down, we can more easily define what is a standards-compliant 
implementation of a QOSM/RMF, and what is not.

If you think that would be good, I could write a first draft.

Jukka

---

From: <[email-masked]>
Date: Mon, 8 Jan 2007 06:45:48 +0200

Hi Jukka,

>That is actually a good point. So far I have hoped that we can 
>clearly de-couple QSPEC+RMF and the NSLP, and therefore a 
>single NSLP implementation can run with all different RMFs and QOSMs.

I think that is a good goal.

>If a QOSM affects the common message processing, we need 
>different implementations. Yet, I guess this also applies to 
>various tunneling, session binding, and separate signaling 
>sessions that might be used within a domain.

I agree.

>Do we need to document how the RMF and QoS NSLP fit together, 
>what is passed between the RMF and NSLP, what are the API 
>issues, what kind on asymmetric triggers the RMF can send to 
>the NSLP, etc. I think we need to write such a draft, and 
>document all the interactions. If we have that written down, 
>we can more easily define what is a standards-compliant 

I think this is a good idea for a draft, and probably QoSM documents
might need to have some of this information, as it specifically 
applies for the specific QoSM.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 8 Jan 2007 10:31:04 +0100

Hi John and Jukka

I think that the idea of writting such a draft is a very good point!
As an example the RMD-QOSM affects the common message processing, and 
therefore we need different implementations. This applies to various 
tunneling, session binding, and separate signaling sessions (such as
refresh, release, 
Unsuccessful resdervations, bi-directional reservations, severe congestion
handling, 
congestion notification handling, etc.) that can  be used 
within a domain.

It will be great to have such a draft andf I would very 
much like to help Jukka, if Jukka agrees, on writting it!

Best Regards,
Georgios

> Sent: maandag 8 januari 2007 5:46
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> >session binding, and separate signaling sessions that might be used 
> >within a domain.
> 
> I agree.
> 
> >asymmetric triggers the RMF can send to the NSLP, etc. I 
> think we need 
> >to write such a draft, and document all the interactions. If we have 
> >that written down, we can more easily define what is a 
> >standards-compliant implementation of a QOSM/RMF, and what is not.
> >
> I think this is a good idea for a draft, and probably QoSM 
> documents might need to have some of this information, as it 
> specifically applies for the specific QoSM.
> 
> John
>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 9 Jan 2007 16:49:45 +0100

Hi Jukka, all, 

> Sent: Saturday, January 06, 2007 4:18 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> That is actually a good point. So far I have hoped that we 
> can clearly de-couple QSPEC+RMF and the NSLP, and therefore a 

I see the way of de-coupling the QSPEC+RMF and the NSLP as a fundamental concept of NSIS. Otherwise, we really run into troubles if we need an NSLP implementation per QSPEC+RMF. 

> sessions that might be used within a domain.

If a QOSM affects the common message processing, aren't we in the need for another NSLP? A different common message processing would be the effect of a different semantics, isn't it?

> If you think that would be good, I could write a first draft.

I would be in favour of such an informational document, as implementors and operators could benefit of it. 

  Martin

> > > I think the constraints are stronger than this, if you want the 
> > > domain-local elements to be able to claim conformance to the QOS 
> > > NSLP specification. If not, the entire argument is moot, 
> since then 
> > > your domain-local signaling is completely proprietary and 
> non-standard.
> > 
> > John
> > 
> > 
> > >> Agreed, the change in the NSLP message processing holds only for 
> > >> the QNEs within the local domain, not outside the domain.
> > >> 
> > >> 
> > >> Best regards,
> > >> Georgios
> > >>  
> > >> 
> > >> > b) through NSLP standards action, if they need to be 
> understood 
> > >> > by all
> > >> >    QNEs on the e2e path.
> > >> > 
> > >> > 
> > >> > > the domains internal, as you suggested under certain bounds, 
> > >> > > can be optimized.
> > >> > > 
> > >> > > Best Regards,
> > >> > > Georgios
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > >  
> > >> > > 
> > >> > > > > > > "The end-to-end semantic and QoS NSLP 
> messaging by the
> > >> > > > QNI, or any
> > >> > > > > > have is a completely private signaling scheme which 
> > >> > > > > > claims conformance to a standard.
> > >> > > > > > 
> > >> > > > > > >>>> If that is the case then Jerry will have 
> to use the 
> > >> > > > > > >>>> same
> > >> > > > > > >> definitions
> > >> > > > > > >>>> for the QSPEC control information as used 
> in Section
> > >> > > > 5.3.1 of:
> > >> > > > > > >>>> 
> > >> > > > 
> > >> > > > > > >>>> control information that was given in 
> Section 5.3.1 
> > >> > > > > > >>>> of
> > >> > > > > > >> version 12 of
> > >> > > > > > >>>> the QSPEC template draft. Note that the 
> name can be
> > >> > > > > > changed but the
> > >> > > > > > >>>>    excess traffic, that is, 
> out-of-profile traffic. 
> > >> > > > > > Excess traffic

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 9 Jan 2007 10:10:17 -0600

Hi Martin, All,

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Tuesday, January 09, 2007 10:50 AM
> To: Jukka MJ Manner; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> I see the way of de-coupling the QSPEC+RMF and the NSLP as a 
> fundamental concept of NSIS. Otherwise, we really run into 
> troubles if we need an NSLP implementation per QSPEC+RMF. 

Agreed.
 
> If a QOSM affects the common message processing, aren't we in 
> the need for another NSLP? A different common message 
> processing would be the effect of a different semantics, isn't it?

Right.  Your statement is consistent with the consensus stated at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html:

"the QOSM specification SHOULD NOT be allowed to define 'new RMF
functions required by a QOSM' UNLESS such NSIS signaling functionality
is defined in QoS NSLP.  I.e., a QOSM is not allowed to extend QoS NSLP
signaling functionality...new RMF functions are specified only 'within a
QoS NSLP signaling framework'."

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 9 Jan 2007 17:23:21 +0100

Hi Martin

> processing would be the effect of a different semantics, isn't it?
 
Well this relates to what you define as common message processing!
As Jukka already emphasized in a previous message:
If a QOSM, e.g., RMD changes the NSLP message processing in some way, 
it can do so, but only for the local (RMD) domain, without affecting any 
QNEs (incld QNI and QNR) outside the local (RMD) domain). 
And this must still preserve the e2e messaging semantics.

Best regards,
Georgios

> Sent: dinsdag 9 januari 2007 16:50
> can clearly 
> I would be in favour of such an informational document, as 
> implementors and operators could benefit of it. 
> 
>   Martin
> 
> > 
> > Jukka
> > 
> > > >> > > incl. separate signaling sessions and aggregation, 
> provided 
> > > >> > > that
> > > >> > > 
> > > >> > > > > * the constraints specified in the QOS-NSLP 
> document (see
> > > >> > > > Jukkas proposal),
> > > >> > > > > > > a) The resource request by the QNI and 
> response from
> > > >> > > > the QNR must be
> > > >> > > > > > > I think QoS NSLP operation can be extended 
> in a local
> > > >> > > > QoS domain
> > > >> > > > > > >>> specification SHOULD NOT be allowed to 
> define 'new
> > > >> > > > RMF functions

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 9 Jan 2007 13:08:35 -0600

Hi All,

See below. 

> Sent: Tuesday, January 09, 2007 11:23 AM
> To: 'Martin Stiemerling'; 'Jukka MJ Manner'; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; 

Per the consensus stated at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html:

Hence a QOSM must not be allowed to change QoS NSLP message processing
in some local domain that is somehow inconsistent with what is specified
in QoS NSLP; that would be contrary to the consensus above.

John and Dave stated this pretty clearly, see
http://www1.ietf.org/mail-archive/web/nsis/current/msg07427.html:

"the constraints are stronger than this, if you want the domain-local
elements to be able to claim conformance to the QOS NSLP specification.
If not... then your domain-local signaling is completely proprietary and
non-standard."

Thanks,
Jerry

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 9 Jan 2007 22:30:59 +0200 (EET)

Hi all,

I agree on this, too. I think John wrote it well when saying that we 
should only need a single QoS NSLP implementation. If the common 
implementation can not work with a QOSM or RMF, then there is a problem 
with the QOSM/RMF.

Changing the QOSM deployed in a domain should only involve changing the 
RMF. To me that would be the ideal case. (but probably that would be too 
simple, since e.g. a new QOSM might involve the discussed parallel 
intra-domain sessions being bound to the e2e sessions)

Jukka

---

From: <[email-masked]>
Date: Tue, 9 Jan 2007 22:00:54 -0600

I believe we can move forward on this now.

John 

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 09 January, 2007 18:10
>To: Martin Stiemerling
>Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
>> > clearly de-couple QSPEC+RMF and the NSLP, and therefore a single 
>> > NSLP implementation can run with all different RMFs and QOSMs.
>> 
>troubles if 
>> we need an NSLP implementation per QSPEC+RMF.
>
>Agreed.
> 
>> > 
>> > implementations. Yet, I guess this also applies to various 
>> > tunneling, session binding, and separate signaling sessions that 
>> > might be used within a domain.
>> 
>> If a QOSM affects the common message processing, aren't we 
>in the need 
>> for another NSLP? A different common message processing would be the 
>> effect of a different semantics, isn't it?
>
>"the QOSM specification SHOULD NOT be allowed to define 'new 
>RMF functions required by a QOSM' UNLESS such NSIS signaling 
>allowed to extend QoS NSLP signaling functionality...new RMF 
>functions are specified only 'within a QoS NSLP signaling framework'."
>
>Thanks,
>Jerry
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 10 Jan 2007 09:21:52 +0100

Hi Jerry

Regarding the following:

> Hence a QOSM must not be allowed to change QoS NSLP message 
> processing in some local domain that is somehow inconsistent 
> with what is specified in QoS NSLP; that would be contrary to 
> the consensus above.
> 
> "the constraints are stronger than this, if you want the 
> domain-local elements to be able to claim conformance to the 
> QOS NSLP specification.
> If not... then your domain-local signaling is completely 
> proprietary and non-standard."

I do not remember to had as consensus on the above!

Best Regards,
Georgios

> Sent: dinsdag 9 januari 2007 20:09
> To: Georgios Karagiannis; Martin Stiemerling
> > Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; [email-masked]; 
> > [email-masked]
> > > If a QOSM affects the common message processing, aren't we in the 
> > > need for another NSLP? A different common message 
> processing would 
> > > be the effect of a different semantics, isn't it?
> >  
> > it can do so, but only for the local (RMD) domain, without 
> affecting 
> > any QNEs (incld QNI and QNR) outside the local (RMD) domain).
> Hence a QOSM must not be allowed to change QoS NSLP message 
> processing in some local domain that is somehow inconsistent 
> with what is specified in QoS NSLP; that would be contrary to 
> the consensus above.
> 
> "the constraints are stronger than this, if you want the 
> domain-local elements to be able to claim conformance to the 
> QOS NSLP specification.
> If not... then your domain-local signaling is completely 
> proprietary and non-standard."
> 
> Thanks,
> Jerry
>

---

From: Bernd Schloer <[email-masked]>
Date: Fri, 12 Jan 2007 18:45:37 +0100 (MET)

Hi,

I also think that such a draft is very useful. It is preferable to
have a single QoS NSLP implementation which operates with the different
QOSMs. Implementing a QOSM gets easier. I would like to contribute to it.

Best Regards,
Bernd

Georgios Karagiannis wrote:
>>tunneling, 
>>>Do we need to document how the RMF and QoS NSLP fit 
>>
>>together, what is 
>>
>>>passed between the RMF and NSLP, what are the API issues, 
>>
>>what kind on 
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 12 Jan 2007 19:02:14 +0100

Hi all

Lets clarify some issues.
According to the previous discussions I could conclude that
a common QOS-NSLP message processing will mean 
in this case that the QOS-NSLP has to support 
all features that are related to various signaling features such as:

* tunneling, 
* stateless and bypassing, 
* session binding, 
* and separate and parallel signaling sessions that support the 
  edge-to-edge and end-to-edge signaling 
(such as refresh, release, Unsuccessful resdervations, 
 modification of reservations
 severe congestion handling, congestion notification 
handling, etc. for unidirectional and bi-directional reservations) 
that can  be used within a domain.

Thus this will mean that the QOS-NSLP specification 
should provide signaling means for all the above.

Best Regards,
Georgios

> From: Bernd Schloer [mailto:[email-masked]] 
> Sent: vrijdag 12 januari 2007 18:46
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> I also think that such a draft is very useful. It is 
> preferable to have a single QoS NSLP implementation which 
> operates with the different QOSMs. Implementing a QOSM gets 
> easier. I would like to contribute to it.
> 
> Best Regards,
> Bernd
> 
> 
> 
> > refresh, release, Unsuccessful resdervations, bi-directional 
> > reservations, severe congestion handling, congestion notification 
> > handling, etc.) that can  be used within a domain.
> > 
> much like to 
> > help Jukka, if Jukka agrees, on writting it!
> > 
> > 
> > Best Regards,
> > Georgios
> > 
> >  
> > 
> > 
> documents

---

From: Bernd Schloer <[email-masked]>
Date: Sun, 14 Jan 2007 18:01:41 +0100 (MET)

Hi,

a few comments to some of the recent consensus calls:

I agree, that the QOSM specification SHOULD NOT be allowed to
define new RMF functions and extend signaling functionality.

Either tunneling a QSPEC or encapsulating it makes sense in my opinion.
Where additional information in a local domain are needed the QOSM
specification could define additional parameters.

Which QoS NSLP signaling feature is used by QOSMs should be defined in
the QoS NSLP draft rather than in the QSPEC draft. I agree here.

Best Regards,
Bernd

Bernd Schloer wrote:
>> reservations, severe congestion
>> handling, congestion notification handling, etc.) that can  be used 
>> within a domain.
>>
>> It will be great to have such a draft andf I would very much like to 
>>> From: [email-masked] [mailto:[email-masked]] Sent: 
>>> maandag 8 januari 2007 5:46

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 15 Jan 2007 09:44:58 +0100

Hi Bernd

Thus you also agree with the below:
According to the previous discussions I could conclude that a common
QOS-NSLP message processing will mean in this case that the QOS-NSLP has to
support all features that are related to various signaling features such as:

* tunneling,
* proxy functionality
* aggregation functionality 
* stateless and bypassing,
* session binding,
* and separate and parallel signaling sessions that support the
  end-to-end, edge-to-edge and end-to-edge signaling such as:
  reservation initiation (ssuccessful reservation), refresh, release, 
  unsuccessful resdervations,  modification 
  of reservations, severe congestion (or pre-emption) handling, 
  congestion notification handling, etc. for sender initiated and receiver
initiated 
  unidirectional and bi-directional reservations 
  that can  be used end-to- end and within a domain.

Thus this will mean that the QOS-NSLP specification should 
provide signaling means for all the above.

Best Regards,
Georgios

> Sent: zondag 14 januari 2007 18:02
> To: [email-masked]
> Where additional information in a local domain are needed the 
> QOSM specification could define additional parameters.
> 
> Which QoS NSLP signaling feature is used by QOSMs should be 
> defined in the QoS NSLP draft rather than in the QSPEC draft. 
> I agree here.
> 
> Best Regards,
> Bernd
> 
> 
> Bernd Schloer wrote:
> > Hi,
> > 
> > have a single QoS NSLP implementation which operates with the 
> > different QOSMs. Implementing a QOSM gets easier. I would 
> like to contribute to it.
> > 
> > Best Regards,
> > Bernd
> > 
> > 
> > 
> different 
> >>>> to write such a draft, and document all the interactions. If we 
> >>>> have that written down, we can more easily define what is a

---

From: Lars Westberg <[email-masked]>
Date: Mon, 15 Jan 2007 10:09:38 +0100

I agree that we should have these features then.

regards Lasse

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 15 Jan 2007 10:30:50 +0100

Hi All, 

I think these functions are important to support by QOS NSLP, and QSpec Template should not contain restriction. 

As far as the control info is concerned, I think that RMD control information is similar to Excess Treatment. They control what to do with the traffic in case of special conditions. Whether these parameters should be standardized or not is another question. RMD document is an informational doc. describing how to use NSIS in case of such signaling cases.  

Best regards, Attila

>Sent: Monday, January 15, 2007 9:45 AM
>To: 'Bernd Schloer'; [email-masked]
>According to the previous discussions I could conclude that a 
>common QOS-NSLP message processing will mean in this case that 
>the QOS-NSLP has to support all features that are related to 
>various signaling features such as:
>
>* tunneling,
>* proxy functionality
>  congestion notification handling, etc. for sender initiated 
>and receiver initiated

---

From: "Edmundo Monteiro" <[email-masked]>
Date: Mon, 15 Jan 2007 21:41:58 -0000

Hi All

In my opinion we should not restrict QoS-NSLP functionality that should
support end-to-end signaling.

I agree with Attila, the QoS NSLP can be extended in a local QoS domain,
preserving the end-to-end operation.

Regards

Edmundo Monteiro

-----Original Message-----
From: Attila Báder (IJ/ETH) [mailto:[email-masked]] 
Sent: segunda-feira, 15 de Janeiro de 2007 9:31
To: Georgios Karagiannis; Bernd Schloer; [email-masked]
Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information

Hi All, 

I think these functions are important to support by QOS NSLP, and QSpec
Template should not contain restriction. 

As far as the control info is concerned, I think that RMD control
information is similar to Excess Treatment. They control what to do with the
traffic in case of special conditions. Whether these parameters should be
standardized or not is another question. RMD document is an informational
doc. describing how to use NSIS in case of such signaling cases.  

Best regards, Attila

----
If you feel this message is spam, please address complaints to [email-masked].
Full e-mail headers and the message will help us process the problem more swiftly.