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:karagian@cs.utwente.nl] 
> Sent: Sunday, December 24, 2006 3:18 AM
> To: john.loughney@nokia.com; Ash, Gerald R (Jerry), ALABS; 
> nsis@ietf.org
> 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, "john.loughney@nokia.com" <john.loughney@nokia.com>
> 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
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis