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:

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

   <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







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 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
>
>>-----Original Message-----
>>From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>>Sent: 22 December, 2006 20:12
>>To: Georgios Karagiannis; nsis@ietf.org
>>Cc: Ash, Gerald R (Jerry), ALABS
>>Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
>>
>>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.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
>>http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf
>>67ch4-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:karagian@cs.utwente.nl]
>>Sent: Friday, December 22, 2006 11:36 AM
>>To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
>>Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
>>
>>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
>>
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>>> > Sent: vrijdag 22 december 2006 16:37
>>> > To: Georgios Karagiannis; nsis@ietf.org
>>> > Cc: Ash, Gerald R (Jerry), ALABS
>>> > Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>> >
>>> > Georgios,
>>> >
>>> > > -----Original Message-----
>>> > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
>>> > > Sent: Friday, December 22, 2006 9:13 AM
>>> > > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
>>> > > Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>> > >
>>> > > 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.
>>> >
>>> > 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.
>>> >
>>> > > 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
>>> >
>>> > >
>>> > > 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
>>> > >
>>> > >
>>> > > > -----Original Message-----
>>> > > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>>> > > > Sent: vrijdag 22 december 2006 15:01
>>> > > > To: Georgios Karagiannis; nsis@ietf.org
>>> > > > Cc: Ash, Gerald R (Jerry), ALABS
>>> > > > Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>> > > >
>>> > > > Georgios,
>>> > > >
>>> > > > See below.
>>> > > >
>>> > > > > -----Original Message-----
>>> > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
>>> > > > > Sent: Thursday, December 21, 2006 9:22 AM
>>> > > > > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
>>> > > > > Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg'
>>> > > > > Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>> > > > >
>>> > > > > Hi Jerry
>>> > > > >
>>> > > > > Please see below! I have severe concerns about some changes
>>> > > > that have
>>> > > > > been done in the QSPEC template draft.
>>> > > > >
>>> > > > > > -----Original Message-----
>>> > > > > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>>> > > > > > Sent: woensdag 20 december 2006 14:20
>>> > > > > > To: Georgios Karagiannis; nsis@ietf.org
>>> > > > > > Cc: Ash, Gerald R (Jerry), ALABS
>>> > > > > > Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>> > > > > >
>>> > > > > > Hi Georgios,
>>> > > > > >
>>> > > > > > See below.
>>> > > > > >
>>> > > > > > > -----Original Message-----
>>> > > > > > > From: Georgios Karagiannis
>>[mailto:karagian@cs.utwente.nl]
>>> > > > > > > Sent: Wednesday, December 20, 2006 5:26 AM
>>> > > > > > > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
>>> > > > > > > Subject: Comments on draft-ietf-nsis-qspec-13.txt
>>> > > > > > >
>>> > > > > > > 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.
>>> > > > > >
>>> > > > > > 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
>>> > > >
>>> > > > 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.
>>> > > >
>>> > > > > > > Comment_2:
>>> > > > > > > -----------
>>> > > > > > >
>>> > > > > > > Section 6.1:
>>> > > > > > > Please reintroduce the format that is required
>>in order to
>>> > > > > > specify the
>>> > > > > > > QSPEC control information, see:
>>> > > > > > > Section 7.1 of:
>>> > > > > > >
>>> > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt
>>> > > > > >
>>> > > > > > 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"
>>> > > >
>>> > > > Yes, the text suggested by Dave will be added.
>>> > > >
>>> > > > > > > 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"
>>> > > > > >
>>> > > > > > That sentence was removed in Dave's proposed QOSM
>>> > > > re-definition, see
>>> > > > > >
>>> 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:
>>> > > > > >
>>> > > > > > "     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."
>>> > > > >
>>> > > > > 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.
>>> > > >
>>> > > > 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.
>>> > > >
>>> > > > > > > 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."
>>> > > > > >
>>> > > > > > 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.
>>> > > > >
>>> > > > > Georgios:
>>> > > > > No I am not trying to define QOS-NSLP functionality.
>>> > > > > This is related to QSPEC control information 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 QSPEC object were
>>> > > > associated with
>>> > > > > requirement 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."
>>> > > >
>>> > > > 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:
>>> > > > > > > -----------
>>> > > > > > > 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."
>>> > > > > >
>>> > > > > > 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:
>>> > > > > > >
>>> > > > > > > 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."
>>> > > > > >
>>> > > > > > 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.
>>> > > >
>>> > > > Please see above comments on 'control information' terminology.
>>> > > >
>>> > > > Thanks,
>>> > > > Jerry
>>> > > >
>>> > > > > > > Comment_7:
>>> > > > > > > ------------
>>> > > > > > > Section 6.1:
>>> > > > > > > I do not understand 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."
>>> > > > > >
>>> > > > > > Good catch, this is a typo, the sentence should be removed.
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > > Best Regards,
>>> > > > > Georgios
>>> > > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> nsis mailing list
>>> nsis@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>
>>
>>
>>_______________________________________________
>>nsis mailing list
>>nsis@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nsis
>>

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis