Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

From: Gerald Ash <[email-masked]>
Date: Fri, 15 Feb 2008 08:55:10 -0800 (PST)

Martin,

Many thanks for your careful review.

Please see comments in line below.

Please let us know of any further comments.  We'll resubmit the document
prior to cutoff date.

Jerry

> Hi all,
>
> Please find my review of draft-ietf-nsis-qspec-18.txt.
>
> There are some minor technical issues to fix. In general the document
> seems
> to be ready to go for AD review,  once the editorials and technical
> issues
> have been fixed.
>
> Please address the issues and submit an updated version of the draft if
> d
> one so. I will go ahead with the updated draft for the protocol write
> up
> (i.e., the step before sending to Magnus and the IESG).
>
>  Martin
>
> ****
> General
> ****
> I found the first part of the document (i.e., until section 5) quite
> confusing and after section five quite clear. This does not mean that
> there
> is an issue, as typically Internet drafts have the need to sketch tech
> things in the beginning without having the reader already at the
> technical
> level. I assume that the text is fine right now, as the WG has not
> pushed to
> change it.

These sections have been rewritten many times.  Please let us know if you
have any particular suggestion to improve clarity.

>
> ****
> Editorial:
> ****
>
> - the idnits tool has found some issues (see below)

OK, will address.

> - Add line in memo heading with: Intended Status: Informational

Although the NSIS milestone says "Informational", the ID tracker lists the
status as "Proposed Standard"
https://datatracker.ietf.org/idtracker/draft-ietf-nsis-qspec/.  IMO the
QSPEC document should be a PS document, in close alignment with the 
  NSLP PS document.  Many IANA registries are created, etc.  I can't see the
  rationale for NSLP being PS and QSPEC being Informational.  I do recall a 
  discussion on this point earlier and several WG members expressed the same
  view.  Perhaps the WG members and chairs can comment.

> -  Section 1: Move to the very end of memo. It it is good to
> acknowledge
> other people, but it is fair enough to do it at the very end, as
> technical
> protocol stuff comes first.

OK.

> - section 2: Adding a line saying that QSPEC readers should (or better
> must?) read the QoS NSLP in advance would be advantageous for the whole
> document.

Note that the first sentence of Section 2 references QoS NSLP since the
documents are closely tied.  The QSPEC document is intended to be (and
should be) self contained so that one doesn't have to ("must") read
something else first before reading and understanding QSPEC.  However, your 
point is well taken.  We can add a sentence in Section 2 such as "See
  [QoS-SIG] for further details on QoS NSLP."

> - section 2, page 5, para starting with "Interoperability between QoS
> NSIS
> entities (QNEs)..." says that parameters can be flagged or not flagged.
> I
> suggest to put the terms "flagged"/"non flagged" in brackets and write
> mandatory and optional parameters. This makes it easier for first time
> readers.

We've eliminated the terminology "mandatory" and "optional" parameters.
Parameters can be flagged by the M flag if they MUST be interpreted, or
otherwise, as follows:

 M Flag: When set indicates the subsequent parameter MUST be
           interpreted. Otherwise the parameter can be ignored if not
           understood.

We don't want to get back into the mandatory/optional terminology at this
point.

> - - section 2, page 5, para starting with " A local QSPEC can be
> defined in
> a local domain with the initiator QSPEC encapsulated, ...". This
> paragraph
> is brief but describes a very powerful mechanism of the QSPEC. I would
> suggest to remove the hint the TMOD parameter and just write that the
> QSPEC
> allows local QPSECs that are domain specific. This also helps first
> time
> readers to understand a basic feature of  QPSEC but not the full
> implementation of it.

OK.

> - section 4.1, 2nd para, text in para starting with " New QoS NSLP
> message
> processing rules can only be defined in Standard...". Is it required to
> say
> this at this part of the document at all? I remember this again stated
> in
> the document somewhere later on at an appropriate place.

It's an important point and I think it appropriate to mention it in Section 
4.1.  Furthermore, I recall extensive discussion on this sentence and I 
  believe it was explicitly agreed to include it here as well as later in the
  document.  Also, mentioning important points more than once often helps
  clarity.

> - section 4.2 two paras below figure 1. Suddenly there is text about
> RESERVE
> and QUERY, but no hint to the QoS NSLP at all. Adding a reference to
> the QoS
> NSLP at this occasion would be excellent. Otherwise it  is hard to see
> where
> those terms are coming from

Good point, will do.

> - section 4.3.1, para starting with " When the TMOD parameter in
> included in
> QoS Available, it..." should read " When the TMOD parameter are
> included in
> QoS Available, it..."

I think the English is correct as it stands.  However, we could say "When
the TMOD sub-parameters are included ..."

> - section 4.3.1. This section nevers talks about tmod-2! tmod-2 is
> mentioned only  in sections 6.2.1 and 6.2.2.

Right, good point.  We'll revise the text to refer to TMOD-1 and TMOD-2 and
explain the difference.  We could include the example of the need for the 
TMOD-2 parameter in Section 4.3.1 (see discussion/example below of the need 
for the TMOD-2 parameter).

> - section 5, 1st and 2nd para suddenly use the E-/N-flag without every
> explaining their meaning.

Well, this is where the M flag, E flag, and N flag are being explained.  The
first paragraph introduces them and there are details later.  We could add
text in the beginning such as "Three flags are used in QSPEC, the M flag, E
flag, and N flag, which are explained in this section."

> - section 5.1, again the support of local QSPECs is quite powerful but
> never
> really good explained with a figure. For instance, the first para of
> section
> 5.1 could refer to a simple figure showing a network configuration for
> a
> single flow, but with indications where which QSPEC is used. This
> instantly
> makes the whole concept better undestandable.

OK, we could add a figure analogous to Figure 3 in the Y.1541-QOSM document
http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-05.txt to
explain the concept.

> - section 5.2.5. formatting error

OK.

> - section 5.3.1 and related. You use tables to define cases and also
> refer
> to them later in the object definition. Thus it would be good to label
> those
> tables.

OK, good suggestion.

> - section 5.3.5 has one formatting issue and one spelling error
> (s/described
> In [QoS-SIG]/ described in [QoS-SIG])

OK.

> - section 5.4. remove reference to NSIS extensibility document, as we
> do not
> have it ready by now.

OK.

> - section 6.1. I got confused by all the different header definition. I
> would propose to split 6.1. in subsections, i.e., one for each header
> definition. This improves readability.

OK, good suggestion.

> - section 6.2.1: Why is there this line    <TMOD-1> = <r> <b> <p> <m>
> [RFC2210, RFC2215]? It is now required for the object definition.

Right, the format is inconsistent with the other subsections and will be
revised accordingly.

> - section 8, text says " Object Types (12 bits):" but should read
> "QSPEC
> Object Types (12 bits):".

But then Section 6.1 would have to be revised to be consistent in
terminology.  While I have no big objection to changing all of this, IMO it
should stay as is; I think it is clear that this is a QSPEC object type.

> - appendix b: add a note in the first line that this appendix should be
> removed by the RFC editor before publication.

OK.

>
>
>
> ***
> Technical
> ***
> - section 5.3.1, para starting with " The QSPEC parameter IDs and
> values
> included in the QoS Reserved...". This paragraph talks about how to set
> the
> parameters in the RESPONSE message for case 2. It is basically fine,
> but the
> second sentence is for me not understandable (" For those QSPEC
> parameters
> that were also included in the QoS Available object in the RESERVE
> message,
> their value is copied into the QoS Desired object.")
> The paragraph is talking about responses, but in RESPONSE there is no
> QoS
> desired object anymore (at least according to the table above). I
> probably
> do misunderstand something here?

Good catch.  The sentence needs to be corrected.  It should be: "For those
QSPEC parameters that were also included in the QoS Available object in the
RESERVE message, their value is copied from the QoS Available object (in
RESERVE) into the QoS Reserved object (in RESPONSE) ."

> - section 6.1 qspec header element definition. The length definition in
> the
> qspec header definition contradicts the length definition at the
> beginning
> of section 6.1 One says "total length of qspec" the other "length is
> always
> exept header"

Very good catch!  IMO the section definition should be revised as
follows:

 Length: The total length of the QSPEC -->
 Length: The total length of the QSPEC excluding the common header

> - section 6.2.2., see also my comment above about tmod-2. Even after
> reading
> section 6.2.2. I do not have any clue why there two tmod parameters.

This is based on discussions with David Black, who recommended the second
TMOD parameter to support DiffServ applications (as noted in Section 6.2.2).
Earlier versions of QSPEC included the following example (due to David), 
which can be added back into the draft (probably in Section 4.3.1):

"It is typically assumed that DiffServ EF traffic is shaped at the ingress
by a single rate token bucket.  Therefore, a single TMOD parameter is
sufficient to signal DiffServ EF traffic.  However, for DiffServ AF traffic
two sets of token bucket parameters are needed, one token bucket for the
average traffic and one token bucket for the burst traffic.  [RFC2697]
defines a Single Rate Three Color Marker (srTCM), which meters a traffic
stream and marks its packets according to three traffic parameters,
Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess
Burst Size (EBS), to be either green, yellow, or red.  A packet is marked
green if it does not exceed the CBS, yellow if it does exceed the CBS, but
not the EBS, and red otherwise.  [RFC2697] defines specific procedures using
two token buckets that run at the same rate.  Therefore 2 TMOD parameters
are sufficient to distinguish among 3 levels of drop precedence.  An example
is also described in the Appendix to [RFC2597]."

Also, the first sentence in Section 6.2.2 should be changed slightly to: ''A
second, QSPEC <TMOD-2> parameter is specified, as could be needed for
example to support some Diffserv applications." (added word "some").

> - section 6.2.7. The slack term is 32 bits as integer. However the
> slack
> term must only be non-negative, i.e., it is actually an unsigned int.
> Why is
> is not specified as unsigned int? However, the current value range
> definition is broken, as an integer of 32 bits cannot have a maximum
> range
> to  2**32-1 (there are only 31 bits left...).

The coding of the slack term is based on RSVP coding:

RFC 2210 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11  |  Slack Term [S]  (32-bit integer)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC 2212 says:
"The Slack term, S, can be represented as a 32-bit integer.  Its value
   can range from 0 to (2**32)-1 microseconds."

I agree it should be specified as an unsigned integer, and the notation
revised to (2**32)-1 as the maximum, to be clear.  I believe the range 0 to
(2**32)-1 is correct for an unsigned integer.

> This also holds true for
> other
> occasions where integer values are used (e.g. section 6.2.3!

Same comments as above.

> - section 6.2.11. para starting with " When excess treatment is set to
> 'shape', ". What is the error handling if excess treatment is set to
> 'shape'
> and no TMOD parameter is given?

The E flag is set for the parameter and the reservation fails.  This can
be specified in Section 6.2.11.

> - section 7. This section is extremely short. This might a non-issue,
> but I
> personally had the feeling the security discussion is too brief. This
> might
> be OK, but the document authors and the WG should be prepared for tough
> questions regarding this when going to the IESG. What about this
> document
> defining just the basics, but other documents defining the real
> behaviour?
> Is it assumed that this does not raise any new security issue?

Good points and questions.  QSPEC security is directly tied to QoS NSLP
security, and the QoS NSLP document has a very detailed security section.
All these considerations apply to QSPEC and that should be noted at the
beginning of Section 7.  I'm not aware of any new security issues introduced
by QSPEC beyond the point made already in Section 7 on priority.
Suggestions welcome from the WG on other security issues that might arise
from QSPEC.

> - section 8 says in several places " A specification is required to
> depreciate, delete, or modify QSPEC versions." What happens to deleted
> IANA
> values? Is IANA allowed to re-assign those or should they be treated as
> deprecated values, i.e., they cannot be used anymore, but the value is
> blocked for ever?

These are IANA specific rules that I don't think need to be reviewed in
Section 8.

>
> ****
> idnits 2.06.01
>
> tmp/draft-ietf-nsis-qspec-18.txt:
> tmp/draft-ietf-nsis-qspec-18.txt(2867): Found possible IPv4 address
> '7.2.9.4' in position 6; this doesn't match RFC3330's suggested
> 192.0.2.0/24
> address range.
>
>  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
> 4748:
>
> ----------------------------------------------------------------------------
>
>     No issues found here.
>
>  Checking nits according to
> http://www.ietf.org/ietf/1id-guidelines.txt:
>
> ----------------------------------------------------------------------------
>
>  == No 'Intended status' indicated for this document; assuming
> Proposed
>     Standard
>
>  == The page length should not exceed 58 lines per page, but there was
> 3
>     longer pages, the longest (page 6) being 59 lines
>
>  == It seems as if not all pages are separated by form feeds - found 0
> form
>     feeds but 55 pages
>
>
>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
> ----------------------------------------------------------------------------
>
>  == There are 1 instance of lines with non-RFC3330-compliant IPv4
> addresses
>     in the document.  If these are example addresses, they should be
> changed.
>
>
>  Miscellaneous warnings:
>
> ----------------------------------------------------------------------------
>
>  == The copyright year in the IETF Trust Copyright Line does not match
> the
>     current year
>
>
>  Checking references for intended status: Proposed Standard
>
> ----------------------------------------------------------------------------
>
>     (See RFC 3967 for information about using normative references to
>     lower-maturity documents in RFCs)
>
>  == Missing Reference: 'S' is mentioned on line 1730, but not defined
>     '|  Slack Term [S]  (32-bit integer)
> |...'
>
>  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'S'
>
>  == Unused Reference: 'RFC4506' is defined on line 2363, but no
> explicit
>     reference was found in the text
>     '[RFC4506] Eisler, M., "XDR: External Data Representation
> Standard,"...'
>
>  == Unused Reference: 'IEEE754' is defined on line 2375, but no
> explicit
>     reference was found in the text
>     '[IEEE754] Institute of Electrical and Electronics Engineers,
> "IEEE
> S...'
>
>  == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2381,
> but no
>     explicit reference was found in the text
>     '[NETWORK-BYTE-ORDER] Wikipedia, "Endianness,"
> http://en.wikipedia.or...'
>
>  -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1'
>
>  -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2'
>
>  -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3'
>
>  -- Possible downref: Non-RFC (?) normative reference: ref. 'GIST'
>
>  -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG'
>
>
>     Summary: 0 errors (**), 9 warnings (==), 6 comments (--).
> ----------------------------------------------------------------------------
> ----
>
>
> [email-masked]
>
> NEC Laboratories Europe - Network Research Division
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London
> W3 6BL | Registered in England 2832014
>

---------------------------------
Never miss a thing.   Make Yahoo your homepage.

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

---

From: David R Oran <[email-masked]>
Date: Sun, 17 Feb 2008 07:23:03 -0500

Sorry for being completely out of touch on this. I didn't even get to  
read the thread until today. I've been utterly consumed with IAB work  
and my day job. I likely won't have any spare cycles until after IETF,  
so I too would like to deeply thank Jerry for stepping in out of  
retirement (although not even Junior Seau could save the Super bowl  
for the Patriots...sigh).

I will however do my utmost to read the final version after it's  
submitted.

Best to all,

Dave.

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 19 Feb 2008 14:26:22 +0100

Hi Jerry,

Thanks for getting back this. I hope you're doing fine in retirement.

I have just a few things below. How fast can you post an updated version?

> > seems to be ready to go for AD review,  once the editorials and 
> > technical issues have been fixed.
> >
> > Please address the issues and submit an updated version of 
> the draft 
> > if d one so. I will go ahead with the updated draft for the 
> protocol 
> > write up (i.e., the step before sending to Magnus and the IESG).
> >
> >  Martin
> >
> > ****
> > General
> > ****
> > there is an issue, as typically Internet drafts have the need to 
> > sketch tech things in the beginning without having the 
> reader already 
> > at the technical level. I assume that the text is fine 
> right now, as 
> > the WG has not pushed to change it.
> 
> These sections have been rewritten many times.  Please let us 
> know if you have any particular suggestion to improve clarity.

I can't say how to improve it. As said, if the WG is otherwise fine with it, we just leave it as is.

> Although the NSIS milestone says "Informational", the ID 
> tracker lists the status as "Proposed Standard"
> https://datatracker.ietf.org/idtracker/draft-ietf-nsis-qspec/ 
> <mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000038/!x
> -usc:https://datatracker.ietf.org/idtracker/draft-ietf-nsis-qs
> pec/> .  IMO the QSPEC document should be a PS document, in 
> close alignment with the NSLP PS document.  Many IANA 
> registries are created, etc.  I can't see the rationale for 
> NSLP being PS and QSPEC being Informational.  I do recall a 
> discussion on this point earlier and several WG members 
> expressed the same view.  Perhaps the WG members and chairs 
> can comment.

I remember to have discussed this with the ADs and agreement was that the QSPEC is informational. The charter has the final say.

> > acknowledge other people, but it is fair enough to do it at 
> the very 
> > end, as technical protocol stuff comes first.
> 
> OK.
> 
> > must?) read the QoS NSLP in advance would be advantageous for the 
> > whole document.
> 
> Note that the first sentence of Section 2 references QoS NSLP 
> since the documents are closely tied.  The QSPEC document is 
> intended to be (and should be) self contained so that one 
> doesn't have to ("must") read something else first before 
> reading and understanding QSPEC.  However, your point is well 
> taken.  We can add a sentence in Section 2 such as "See 

Adding the sentence would be great!

> > NSIS entities (QNEs)..." says that parameters can be flagged or not 
> > flagged.
> > I
> Parameters can be flagged by the M flag if they MUST be 
> interpreted, or otherwise, as follows:
> 
> We don't want to get back into the mandatory/optional 
> terminology at this point.

Ok, fine with me.

> > defined in a local domain with the initiator QSPEC 
> encapsulated, ...". 
> > This paragraph is brief but describes a very powerful 
> mechanism of the 
> > QSPEC. I would suggest to remove the hint the TMOD 
> parameter and just 
> > write that the QSPEC allows local QPSECs that are domain specific. 
> > This also helps first time readers to understand a basic 
> feature of  
> > QPSEC but not the full implementation of it.
> 
> OK.
> 
> > message processing rules can only be defined in Standard...". Is it 
> > required to say this at this part of the document at all? I 
> remember 
> > this again stated in the document somewhere later on at an 
> appropriate 
> > place.
> 
> It's an important point and I think it appropriate to mention 
> it in Section 4.1.  Furthermore, I recall extensive 
> discussion on this sentence and I believe it was explicitly 
> agreed to include it here as well as later in the document.  
> Also, mentioning important points more than once often helps clarity.

Ok, fine with me.

> > RESERVE and QUERY, but no hint to the QoS NSLP at all. Adding a 
> > reference to the QoS NSLP at this occasion would be excellent. 
> > Otherwise it  is hard to see where those terms are coming from
> 
> Good point, will do.
> 
> > included in QoS Available, it..." should read " When the TMOD 
> > parameter are included in QoS Available, it..."
> 
> I think the English is correct as it stands.  However, we 
> could say "When the TMOD sub-parameters are included ..."

I would prefer your suggestion, as this improves readability for non-native speakers (as I'm).

> Right, good point.  We'll revise the text to refer to TMOD-1 
> and TMOD-2 and explain the difference.  We could include the 
> example of the need for the
> TMOD-2 parameter in Section 4.3.1 (see discussion/example 
> below of the need for the TMOD-2 parameter).
> 
> Well, this is where the M flag, E flag, and N flag are being 
> explained.  The first paragraph introduces them and there are 
> details later.  We could add text in the beginning such as 
> "Three flags are used in QSPEC, the M flag, E flag, and N 
> flag, which are explained in this section."

Please add this sentence, it also improves readability.

> > never really good explained with a figure. For instance, the first 
> > para of section
> > a single flow, but with indications where which QSPEC is used. This 
> > instantly makes the whole concept better undestandable.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm
> -05.txt 
> <mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000038/!x
> -usc:http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541
> -qosm-05.txt>  to explain the concept.

This would be great!

> > refer to them later in the object definition. Thus it would 
> be good to 
> > label those tables.
> 
> OK, good suggestion.
> 
> > (s/described In [QoS-SIG]/ described in [QoS-SIG])
> 
> OK.
> 
> > do not have it ready by now.
> 
> OK.
> 
> > - section 6.1. I got confused by all the different header 
> definition. 
> > I would propose to split 6.1. in subsections, i.e., one for each 
> > header definition. This improves readability.
> 
> OK, good suggestion.
> 
> Right, the format is inconsistent with the other subsections 
> and will be revised accordingly.
> 
> > "QSPEC Object Types (12 bits):".
> 
> But then Section 6.1 would have to be revised to be 
> consistent in terminology.  While I have no big objection to 
> changing all of this, IMO it should stay as is; I think it is 
> clear that this is a QSPEC object type.

Ok.

> 
> > - appendix b: add a note in the first line that this 
> appendix should 
> > be removed by the RFC editor before publication.
> 
> OK.
> 
> >
> >
> >
> > ***
> > Technical
> > ***
> > values included in the QoS Reserved...". This paragraph talks about 
> > how to set the parameters in the RESPONSE message for case 2. It is 
> > basically fine, but the second sentence is for me not 
> understandable 
> > (" For those QSPEC parameters that were also included in the QoS 
> > Available object in the RESERVE message, their value is copied into 
> > the QoS Desired object.") The paragraph is talking about responses, 
> > but in RESPONSE there is no QoS desired object anymore (at least 
> > according to the table above). I probably do misunderstand 
> something 
> > here?
> 
> Good catch.  The sentence needs to be corrected.  It should 
> be: "For those QSPEC parameters that were also included in 
> the QoS Available object in the RESERVE message, their value 
> is copied from the QoS Available object (in
> > - section 6.1 qspec header element definition. The length 
> definition 
> > in the qspec header definition contradicts the length definition at 
> > the beginning of section 6.1 One says "total length of qspec" the 
> > other "length is always exept header"
> 

OK.

> > reading section 6.2.2. I do not have any clue why there two tmod 
> > parameters.
> 
> This is based on discussions with David Black, who 
> recommended the second TMOD parameter to support DiffServ 
> applications (as noted in Section 6.2.2).
> Earlier versions of QSPEC included the following example (due 
> to David), which can be added back into the draft (probably 
> in Section 4.3.1):
> 
> "It is typically assumed that DiffServ EF traffic is shaped 
> at the ingress by a single rate token bucket.  Therefore, a 
> single TMOD parameter is sufficient to signal DiffServ EF 
> traffic.  However, for DiffServ AF traffic two sets of token 
> bucket parameters are needed, one token bucket for the 
> average traffic and one token bucket for the burst traffic.  
> [RFC2697] defines a Single Rate Three Color Marker (srTCM), 
> which meters a traffic stream and marks its packets according 
> to three traffic parameters, Committed Information Rate 
> (CIR), Committed Burst Size (CBS), and Excess Burst Size 
> (EBS), to be either green, yellow, or red.  A packet is 
> marked green if it does not exceed the CBS, yellow if it does 
> exceed the CBS, but not the EBS, and red otherwise.  
> [RFC2697] defines specific procedures using two token buckets 
> that run at the same rate.  Therefore 2 TMOD parameters are 
> sufficient to distinguish among 3 levels of drop precedence.  
> An example is also described in the Appendix to [RFC2597]."

This would be good!

> 
> Also, the first sentence in Section 6.2.2 should be changed 
> slightly to: ''A second, QSPEC <TMOD-2> parameter is 
> specified, as could be needed for example to support some 
> Diffserv applications." (added word "some").

Ok.

> > slack term must only be non-negative, i.e., it is actually 
> an unsigned 
> > int.
> > Why is
> > range to  2**32-1 (there are only 31 bits left...).
> 
> I agree it should be specified as an unsigned integer, and 
> the notation revised to (2**32)-1 as the maximum, to be 
> clear.  I believe the range 0 to

Right.

> The E flag is set for the parameter and the reservation 
> fails.  This can be specified in Section 6.2.11.

Fine.

> > but I personally had the feeling the security discussion is 
> too brief. 
> > This might be OK, but the document authors and the WG should be 
> > prepared for tough questions regarding this when going to the IESG. 
> > What about this document defining just the basics, but 
> other documents 
> > defining the real behaviour?
> Good points and questions.  QSPEC security is directly tied 
> to QoS NSLP security, and the QoS NSLP document has a very 
> detailed security section.
> All these considerations apply to QSPEC and that should be 
> noted at the beginning of Section 7.  I'm not aware of any 
> new security issues introduced by QSPEC beyond the point made 
> already in Section 7 on priority.
> Suggestions welcome from the WG on other security issues that 
> might arise from QSPEC.

I'm fine with leaving the section as short as it is. However, adding a reference to the QOS NSLp would be beneficial.

> > IANA values? Is IANA allowed to re-assign those or should they be 
> > treated as deprecated values, i.e., they cannot be used 
> anymore, but 
> > the value is blocked for ever?
> 
> These are IANA specific rules that I don't think need to be 
> reviewed in Section 8.

Ok, I'm just noting now to have misread this sentence, as a result of reading too much at the same time.

Thanks,

  Martin

[email-masked]   <== NEW ADDRESS

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
nsis mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nsis

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 19 Feb 2008 17:24:34 +0100

Hello,

For memory, the next rev of nsis-qspec is also expected to be aligned  
with the Resolution of the issue related to QoS Parameters encoding  
in <dime-qos-parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>. For  
convenience, I included below the recap on the corresponding  
resolution as announced on NSIS, DIME and TSVWG lists.

Just to make sure this does not fall through the cracks.

Cheers

Francois

>
> Begin forwarded message:
>> From: Francois Le Faucheur IMAP <[email-masked]>
>> Date: 3 December 2007 12:05:42 GMT+01:00
>> To: [email-masked], [email-masked], tsvwg tsvwg <[email-masked]>
>> Cc: Francois Le Faucheur IMAP <[email-masked]>, David Oran R  
>> <[email-masked]>, Hannes Tschofenig <[email-masked]>,  
>> ken carlberg <[email-masked]>, Magnus Westerlund  
>> <[email-masked]>, James Polk <[email-masked]>,  
>> [email-masked], "(IJ/ETH) Báder Attila"  
>> <[email-masked]>, [email-masked], Jukka  
>> Manner MJ <[email-masked]>, tsvwg chair <tsvwg- 
>> [email-masked]>, [email-masked], dime- 
>> [email-masked], "[email-masked]>"  
>> <[email-masked]>
>> Subject: Resolution of issue QoS Parameters encoding in <dime-qos- 
>> parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>
>>
>> Hello,
>>
>> The Issue:
>> =======
>> Three different documents (dime-qos-parameters, nsis-qos-nslp,  
>> tsvwg-emergency-rsvp) need to convey an overlapping set of QoS  
>> parameters (specifically RPH-Priority and Admission Priority) and  
>> currently do that in an inconsistent manner. This has been brought  
>> up and partially discussed on the WG mailing lists.
>>
>> The Proposed Resolution
>> ===================
>> Co-authors of the three I-Ds as well as WG chairs of the  
>> corresponding WGs converged on the following proposed resolution.  
>> Please let us know if you have an issue/concern with this.
>>
>> o Regarding RPH-Priority:
>> 	* tsvwg-emergency-rsvp will go ahead with its requests to IANA to  
>> provide numerical registry for RPH priority (via extending  
>> existing RPH registry). See IANA Considerations section of tsvwg- 
>> emergency-rsvp.
>> 	* nsis-qspec (in section 6.2.10) will point to this registry  
>> instead of defining its own values
>> 	* dime-qos-parameters (in section 4.11) will point to this  
>> registry instead of defining its own values
>> 	* tsvwg-emergency-rsvp (in section 3.2) will keep pointing to  
>> this registry.
>>
>> o Regarding Admission Priority:
>> 	* every protocol spec will only indicate that "higher value means  
>> higher priority".
>> 	* there is no attempt to define what specific values should be  
>> used for what. this is left outside the scope of the protocol specs.
>> 	* each protocol spec will add a statement clarifying that a given  
>> Admission Priority is to be encoded with the same value in each of  
>> the three protocol spec. For example, in tsvwg-emergency-rsvp,  
>> under section 3.1.  we will add:
>> "      A given Admission Priority is encoded in this information  
>> element
>> 	using the same value as when encoded in the Admission Priority
>> 	parameter defined in section 6.2.9 of [nsis-qspec], or in the  
>> Admission
>> 	 Priority parameter defined in section 4.10 of [dime-qos- 
>> parameters].
>> 	In other words, a given value in any of the [emergency-rsvp]  
>> Admission
>> 	Priority information element, the [nsis-qspec] Admission Priority  
>> parameter
>> 	or the [dime-qos-parameters] Admission Priority parameter, refers to
>> 	the same Admission Priority.
>> "
>> 	* the mirror statement will be added in nsis-qspec (section  
>> 6.2.9) and dime-qos-parameters (section 4.10)
>>
>> Francois
>>

---

From: <[email-masked]>
Date: Tue, 19 Feb 2008 13:58:36 -0600

Thanks Francois,

This is something that needs to be updated in the current draft.

John 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Francois Le Faucheur IMAP
>Sent: 19 February, 2008 08:25
>To: Martin Stiemerling
>Cc: [email-masked]; nsis
>Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt
>
>Hello,
>
>For memory, the next rev of nsis-qspec is also expected to be 
>aligned with the Resolution of the issue related to QoS 
>Parameters encoding in <dime-qos-parameters>, <nsis-qspec> & 
><tsvwg-emeregncy-rsvp>. For convenience, I included below the 
>recap on the corresponding resolution as announced on NSIS, 
>DIME and TSVWG lists.
>
>>> <[email-masked]>, Hannes Tschofenig 
><[email-masked]>, ken 
>>> carlberg <[email-masked]>, Magnus Westerlund 
>>> currently do that in an inconsistent manner. This has been 
>brought up 
>>> and partially discussed on the WG mailing lists.
>>>
>>> The Proposed Resolution
>>> ===================
>>> provide numerical registry for RPH priority (via extending existing 
>>> RPH registry). See IANA Considerations section of tsvwg- 
>>> emergency-rsvp.
>>> 	* nsis-qspec (in section 6.2.10) will point to this 
>registry instead 
>>> 	* dime-qos-parameters (in section 4.11) will point to 
>this registry 
>>> 	* tsvwg-emergency-rsvp (in section 3.2) will keep 
>pointing to this 
>>> registry.
>>>
>>> 	* there is no attempt to define what specific values 
>should be used 
>>> for what. this is left outside the scope of the protocol specs.
>>> the three protocol spec. For example, in 
>tsvwg-emergency-rsvp, under 
>>> section 3.1.  we will add:

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 20 Feb 2008 09:27:59 +0100

Hello Francois,

Thanks for bringing this back to attention. I've forgotten about this.

Jerry: Please fix this in the new version of the QSPEC draft.

Thanks,

  Martin

> From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
> Sent: Tuesday, February 19, 2008 5:25 PM
> To: Martin Stiemerling
> Cc: Francois Le Faucheur IMAP; Gerald Ash; nsis; 
> [email-masked]
> existing

---

From: Gerald Ash <[email-masked]>
Date: Wed, 20 Feb 2008 07:58:17 -0800 (PST)

Francois,

  > The Proposed Resolution
   
  I saw no discussion of this proposed resolution on the NSIS list.  Who were the QSPEC co-authors who worked with you on the proposed resolution?
   
> * tsvwg-emergency-rsvp will go ahead with its requests to
  > IANA to provide numerical registry for RPH priority (via 
  > extending existing RPH registry). See IANA Considerations
  > section of tsvwg-emergency-rsvp.
   
  OK.
   
> * every protocol spec will only indicate that "higher value
  > means higher priority".
  > * there is no attempt to define what specific values should
  > be used for what. this is left outside the scope of the
  > protocol specs.
* each protocol spec will add a statement clarifying that a
  > given Admission Priority is to be encoded with the same
  > value in each of the three protocol spec. For example, in
  > tsvwg-emergency-rsvp, under section 3.1. we will add:
  > element using the same value as when encoded in the
  > Admission Priority parameter defined in section 6.2.9 of
  > [nsis-qspec], or in the Admission Priority parameter
  > defined in section 4.10 of [dime-qos-parameters].
  > In other words, a given value in any of the
  > [emergency-rsvp] Admission Priority information element,
  > the [nsis-qspec] Admission Priority parameter or the
  > [dime-qos-parameters] Admission Priority parameter,
  > refers to the same Admission Priority.

  The above proposed paragraph is really unclear.  Which draft is setting up IANA Registries to assign Admission Priority parameters?  The way it reads it sounds like all three drafts are setting up registries but that somehow (magically) all refer "to the same Admission Priority".  How can that be if they assign different values?  Right now emergency-rsvp and nsis-qspec set up registries for Admission Priority and dime-qos-parameters is using the nsis-qspec registry as I recall.
   
  Please clarify the proposal as to which draft is setting up a registry for Admission Priority.  Also, please provide clearer proposed text to include in the drafts.  
   
  It would be good to see some discussion of the proposal on the list, to confirm and validate agreement of the WG.
   
  Jerry

Francois Le Faucheur IMAP <[email-masked]> wrote:
  Hello,

in , & . For 

Cheers

Francois

>
> Begin forwarded message:
>> From: Francois Le Faucheur IMAP 
>> To: [email-masked], [email-masked], tsvwg tsvwg 
>> Cc: Francois Le Faucheur IMAP , David Oran R 
>> , Hannes Tschofenig , 
>> ken carlberg , Magnus Westerlund 
>> , James Polk , 
>> , [email-masked], Jukka 
>> Manner MJ , tsvwg chair >> [email-masked]>, [email-masked], dime- 
>> Subject: Resolution of issue QoS Parameters encoding in >> parameters>, & 
>>
>> Hello,
>>
>> The Issue:
>> =======

---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 20 Feb 2008 17:43:35 +0100

Hello Jerry,

On 20 Feb 2008, at 16:58, Gerald Ash wrote:

> Francois,
>
> In your "Proposed Resolution" posting to NSIS on 3 December http:// 
> www.ietf.org/mail-archive/web/nsis/current/msg08155.html you say:
>
> > The Proposed Resolution
> > ===================
> I saw no discussion of this proposed resolution on the NSIS list.

which is why we've been assuming there was no issue with it.

> Who were the QSPEC co-authors who worked with you on the proposed  
> resolution?

Attila, Cornelia and Dave Oran (+ NSIS WG chairs).

> The above proposed paragraph is really unclear.  Which draft is  
> setting up IANA Registries to assign Admission Priority  
> parameters?  The way it reads it sounds like all three drafts are  
> setting up registries but that somehow (magically) all refer "to  
> the same Admission Priority".  How can that be if they assign  
> different values?  Right now emergency-rsvp and nsis-qspec set up  
> registries for Admission Priority and dime-qos-parameters is using  
> the nsis-qspec registry as I recall.
>
> Please clarify the proposal as to which draft is setting up a  
> registry for Admission Priority.

No registry is setup.
It is up to a network administrator to decide how many/which  
admission priority gets used for what. This is similar to how  
Preemption is used (ie each network administrator may decide to use  
it or not, may decide to use 2,3,4,...128,.. levels...).
The statement above only says that the the same value of admission  
priority should be used in the three protocols to refer to same level  
of admission priority.

Cheers

Francois

> Also, please provide clearer proposed text to include in the drafts.
>
> It would be good to see some discussion of the proposal on the  
> list, to confirm and validate agreement of the WG.
>
> Jerry
>
>
> >> Manner MJ , tsvwg chair
> >> Subject: Resolution of issue QoS Parameters encoding in
> >> parameters>, &
> >>
> >> Hello,
> >>
> >> The Issue:
> >> =======

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 21 Feb 2008 10:56:15 +0100

Hi,

This has been agreed some time back and needs to be fixed. 

Please go ahead with the change.

Thanks,

  Martin

> From: Gerald Ash [mailto:[email-masked]] 
> Sent: Wednesday, February 20, 2008 4:58 PM
> To: Francois Le Faucheur IMAP; Martin Stiemerling; nsis
> Cc: Gerald Ash; [email-masked]
> In your "Proposed Resolution" posting to NSIS on 3 December 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08155.htm
> l you say:
>  
> > The Proposed Resolution
> > ===================
> corresponding 
> > WGs converged on the following proposed resolution.
>  
> I saw no discussion of this proposed resolution on the NSIS 
> list.  Who were the QSPEC co-authors who worked with you on 
> the proposed resolution?
>  
> > RPH registry). See IANA Considerations section of 
> > tsvwg-emergency-rsvp.
> > * there is no attempt to define what specific values should be used 
> value in each 
> > of the three protocol spec. For example, in tsvwg-emergency-rsvp, 
> Admission Priority 
> > Admission Priority parameter defined in section 4.10 of 
> > [dime-qos-parameters].
> [emergency-rsvp] Admission 
> > parameter or the [dime-qos-parameters] Admission Priority 
> parameter, 
> The above proposed paragraph is really unclear.  Which draft 
> is setting up IANA Registries to assign Admission Priority 
> parameters?  The way it reads it sounds like all three drafts 
> are setting up registries but that somehow (magically) all 
> refer "to the same Admission Priority".  How can that be if 
> they assign different values?  Right now emergency-rsvp and 
> nsis-qspec set up registries for Admission Priority and 
> dime-qos-parameters is using the nsis-qspec registry as I recall.
>  
> registry for Admission Priority.  Also, please provide 
> clearer proposed text to include in the drafts.  
>  
> It would be good to see some discussion of the proposal on 
> the list, to confirm and validate agreement of the WG.
>  
> Jerry
> 
> 
> pointing to 
> should be 
> ________________________________
> 
> <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.c
> om/newsearch/category.php?category=shopping> 
>

---

From: Gerald Ash <[email-masked]>
Date: Thu, 21 Feb 2008 08:55:44 -0800 (PST)

Francois, Martin, John, All,

  >> are setting up registries but that somehow (magically) all refer
  >> "to the same Admission Priority".  How can that be if they
  >> assign different values?  Right now emergency-rsvp and

  > Preemption is used (ie each network administrator may decide 
  > to use it or not, may decide to use 2,3,4,...128,.. levels...).
  > The statement above only says that the the same value of 
  > admission priority should be used in the three protocols to refer 
  > to same level of admission priority.
   
  That's a fundamental change to NSIS/QSPEC and does away with standardized Admission Priority values.  QSPEC is following Y.1571 (now Y.2171 according to An Nguyen) in standardizing 3 priority levels to have end-to-end cross-domain significance.
   
  If we elimate this standardization, as is proposed, then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance.  For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission priority=2,  admission priority=4, admission priority=10 for the highest level priority, respectively.  Admin-domain 1 and Admin-domain 2 try to initiate end-to-end flows via Admin-domain 3 for a 'high priority' flow.  However, Admin-domain 3 has no idea how to treat the flow admission priority since all 3 domains are using different encodings of high priority.
     
  Admission priority is not the same as preemption priority and should not be based on that model.

  IMO we should retain the standardized admission priority levels based on Y.1571/Y.2171.  Otherwise, how do we achieve end-to-end, cross-domain standardization of admission priority?  In any case, we need to see some good justification for the change.

  > which is why we've been assuming there was no issue with it. 
   
  It isn't sufficient to declare 'silence is agreement' on making such a fundamental change.  People should weigh in *on the list* and give their technical justifications and confirm their agreement (or disagreement).
   
  >> Who were the QSPEC co-authors who worked with you on the
  >> proposed resolution?

  > Attila, Cornelia and Dave Oran (+ NSIS WG chairs).
   
  So far I've not been able to verify agreement from the QSPEC co-authors as yet.  We saw no discussion of the issue on the list, and there needs to be some explanation/justification for the change.  
   
  Perhaps Francois could summarize the technical discussion amonst the co-authors, and also state who explicitly agreed (as opposed to who had no comment or active participation in the discussion).  
   
  It would be good if the co-authors who participated in the discussion of the 'proposed agreement' could weigh in on the list with their technical view.
   
  Also, both NSIS chairs have said there is an agreement on the proposal, so perhaps they could weigh in on the list also with their technical view.
   
  Jerry

    Francois,

   

    Who were the QSPEC co-authors who worked with you on the proposed resolution?

     
   
  OK.

   
  Please clarify the proposal as to which draft is setting up a registry for Admission Priority. 

  No registry is setup.
  It is up to a network administrator to decide how many/which admission priority gets used for what. This is similar to how Preemption is used (ie each network administrator may decide to use it or not, may decide to use 2,3,4,...128,.. levels...).
  The statement above only says that the the same value of admission priority should be used in the three protocols to refer to same level of admission priority.

  Cheers

  Francois

   
  Jerry

Cheers

Francois

  

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

---

From: "TARAPORE, PERCY S, ATTLABS" <[email-masked]>
Date: Fri, 22 Feb 2008 12:05:36 -0600

The purpose and intent for Y.2171 was to standardize a set of admission control priority levels that can be recognized across multiple admin domains - and acted upon appropriately to provide the necessary CAC within each domain. Further, Priority Level 1 - the highest CAC priority - is exclusively reserved for emergency telecommunications in Y.2171. Thus retaining these in the NSIS-QSPEC is appropriate. They should not be changed or removed.
 
Percy S. Tarapore

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gerald Ash
Sent: Thursday, February 21, 2008 11:56 AM
To: Francois Le Faucheur IMAP; Martin Stiemerling; [email-masked]; nsis
Cc: [email-masked]
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

 

 

 

 

 

 
Jerry

	Hello Jerry, 

		Francois,

		 

		 
		 
		OK.

		 

	No registry is setup.

	Cheers

	Francois

		 
		Jerry

			Hello,

			
			Cheers
			
			Francois

			

		Looking for last minute shopping deals? Find them fast with Yahoo! Search. <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping> 

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>  
_______________________________________________
nsis mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nsis

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 22 Feb 2008 19:52:18 +0100

Hello Percy,

Some of the considerations that led to the decision to not re-specify  
in <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> the  
admission priority values that are already specified in Y.2171 specs  
included:
	* they are already defined in this ITU spec
	* if one wants to comply with the ITU way to do Admission Priority  
they can follow the ITU spec
	* it is not 100% obvious that absolutely every network administrator  
will ever want to implement admission priority exactly as specified  
by ITU and by that particular spec. Maybe one administrator will want  
to use less priorities, maybe one will want to use more...
	* the admission mechanism to be defined by IETF should be flexible  
and not tied to one single application of one single SDO.
	* the admission priority mechanism defined in IETF should allow  
support of a particular application of a particular SDO. This can be  
achieved by deliberate choice of a network administrator to use the  
values of that application/SDO (but we don't have to mandate that  
everybody using the admission priority mechanisms use it in the same  
way)
	* this is the approach already used for the "Preemption" mechanism  
supported by NSIS and RSVP (ie it is up to network administrator to  
decide which preemption priority value to use in their network and  
their semantic is not defined in the documents)
	* as a side practical considerations: it is undesirable to have an  
IETF spec tied to specifications of another body (eg what happens if  
ITU defines Y.2171bis with one more value? do we have to immediately  
reissue <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec>)?  
For example, if those documents would have mandated the ITU values  
and have been standardised in 2006, they would have referred to Y. 
1571 (as I think Qspec used to do before Y.1571 got superseded by Y. 
2171...)

Cheers

Francois

On 22 Feb 2008, at 19:05, TARAPORE, PERCY S, ATTLABS wrote:

> The purpose and intent for Y.2171 was to standardize a set of  
> admission control priority levels that can be recognized across  
> multiple admin domains - and acted upon appropriately to provide  
> the necessary CAC within each domain. Further, Priority Level 1 -  
> the highest CAC priority - is exclusively reserved for emergency  
> telecommunications in Y.2171. Thus retaining these in the NSIS- 
> QSPEC is appropriate. They should not be changed or removed.
>
> Percy S. Tarapore
>
> Behalf Of Gerald Ash
> That's a fundamental change to NSIS/QSPEC and does away with  
> standardized Admission Priority values.  QSPEC is following Y.1571  
> (now Y.2171 according to An Nguyen) in standardizing 3 priority  
> levels to have end-to-end cross-domain significance.
>
> If we elimate this standardization, as is proposed, then different  
> admission priority values can be assigned in different Admin  
> domains, and will have no end-to-end significance.  For example,  
> Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission  
> priority=2,  admission priority=4, admission priority=10 for the  
> highest level priority, respectively.  Admin-domain 1 and Admin- 
> domain 2 try to initiate end-to-end flows via Admin-domain 3 for a  
> 'high priority' flow.  However, Admin-domain 3 has no idea how to  
> treat the flow admission priority since all 3 domains are using  
> different encodings of high priority.
>
> IMO we should retain the standardized admission priority levels  
> based on Y.1571/Y.2171.  Otherwise, how do we achieve end-to-end,  
> cross-domain standardization of admission priority?  In any case,  
> we need to see some good justification for the change.
>
> It isn't sufficient to declare 'silence is agreement' on making  
> such a fundamental change.  People should weigh in *on the list*  
> and give their technical justifications and confirm their agreement  
> (or disagreement).
>
> So far I've not been able to verify agreement from the QSPEC co- 
> authors as yet.  We saw no discussion of the issue on the list, and  
> there needs to be some explanation/justification for the change.
>
> Perhaps Francois could summarize the technical discussion amonst  
> the co-authors, and also state who explicitly agreed (as opposed to  
> who had no comment or active participation in the discussion).
>
> It would be good if the co-authors who participated in the  
> discussion of the 'proposed agreement' could weigh in on the list  
> with their technical view.
>
> Also, both NSIS chairs have said there is an agreement on the  
> proposal, so perhaps they could weigh in on the list also with  
> their technical view.
>
> Jerry
>
>
> priority should be used in the three protocols to refer to same  
> level of admission priority.
>
> Cheers
>
> Francois
>
>

---

From: "TARAPORE, PERCY S, ATTLABS" <[email-masked]>
Date: Fri, 22 Feb 2008 15:04:30 -0600

Francois,
 
If it is undesirable to tie in to specs from another SDO, then should we completely abandon all other efforts that are related? For example, should we drop the tie-in to Y.1541-QSPEC that NSIS is also working on?
 
Can you demonstrate how domain-specific priority assignments could possibly work? See Jerry's statement from the e-mail thread:
 
"...If we eliminate this standardization, as is proposed, then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance.  For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission priority=2,  admission priority=4, admission priority=10 for the highest level priority, respectively.  Admin-domain 1 and Admin-domain 2 try to initiate end-to-end flows via Admin-domain 3 for a 'high priority' flow.  However, Admin-domain 3 has no idea how to treat the flow admission priority since all 3 domains are using different encodings of high priority...."
 
Can you please indicate how this situation could be resolved without an accepted standardized set of priority levels that can be exchanged across domains? 
 
It is also my understanding that there really is no major issue in changing an IETF spec that is tied to an ITU-T spec. If for example, Y.2171 is updated some time in the future to add a 4th priority level, then IANA can accommodate this by an appropriate change in NSIS-QSPEC. Jerry can you please confirm this?
 
I still do not see any merit in removing Y.2171 priority levels from NSIS-QSPEC.
 
Thanks
 
Percy

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 1:52 PM
To: TARAPORE, PERCY S, ATTLABS
Cc: Francois Le Faucheur IMAP; Gerald Ash; Martin Stiemerling; [email-masked]; nsis
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

Hello Percy, 

Some of the considerations that led to the decision to not re-specify in <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> the admission priority values that are already specified in Y.2171 specs included:
* they are already defined in this ITU spec
* if one wants to comply with the ITU way to do Admission Priority they can follow the ITU spec
* it is not 100% obvious that absolutely every network administrator will ever want to implement admission priority exactly as specified by ITU and by that particular spec. Maybe one administrator will want to use less priorities, maybe one will want to use more...
* the admission mechanism to be defined by IETF should be flexible and not tied to one single application of one single SDO.

* the admission priority mechanism defined in IETF should allow support of a particular application of a particular SDO. This can be achieved by deliberate choice of a network administrator to use the values of that application/SDO (but we don't have to mandate that everybody using the admission priority mechanisms use it in the same way) 

* this is the approach already used for the "Preemption" mechanism supported by NSIS and RSVP (ie it is up to network administrator to decide which preemption priority value to use in their network and their semantic is not defined in the documents)

* as a side practical considerations: it is undesirable to have an IETF spec tied to specifications of another body (eg what happens if ITU defines Y.2171bis with one more value? do we have to immediately reissue <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec>)? For example, if those documents would have mandated the ITU values and have been standardised in 2006, they would have referred to Y.1571 (as I think Qspec used to do before Y.1571 got superseded by Y.2171...)

Cheers

Francois

	 
	Percy S. Tarapore

	 

	 

	 

	 

	 
	 
	Jerry

		Hello Jerry, 

			Francois,

			 

			 
			 
			OK.

			 

		No registry is setup.

		Cheers

		Francois

			 
			Jerry

				Hello,

				
				Cheers
				
				Francois

---

From: Gerald Ash <[email-masked]>
Date: Sat, 23 Feb 2008 07:45:47 -0800 (PST)

Percy,
   
  > It is also my understanding that there really is no major issue in
  > changing an IETF spec that is tied to an ITU-T spec. If for example,
  > Y.2171 is updated some time in the future to add a 4th priority level,
  > then IANA can accommodate this by an appropriate change in
  > NSIS-QSPEC. Jerry can you please confirm this?
   
    Right, there is no issue in having an IETF spec tied to an ITU spec.  If ITU modifies their spec, IANA will make the corresponding changes in the IETF IANA assignments.  E.g., if ITU later standardizes more priority levels, say in "Y.2171.bis', IANA will change the admission priority registry accordingly.  I checked that out with IANA a while ago, IANA can tie into ITU specs in this way.
   
  In fact, many IETF standards incorporate ITU standards.  As you point out, NSIS/NSLP/QSPEC incorporates Y.1541, and there are lots of other examples.  I don't think we can reject this approach to admission priority because it is based on an ITU standard, in fact, IMO it strengthens the approach in this case.

  Thanks,
  Jerry

"TARAPORE, PERCY S, ATTLABS" <[email-masked]> wrote:
      Francois,

   

   
   
  Thanks
   
  Percy

  
Hello Percy,   

  Cheers

  Francois

   
  Percy S. Tarapore

  

   

   

   

   

   
  Jerry

    Francois,

   

     
   
  OK.

   

  No registry is setup.

  Cheers

  Francois

   
  Jerry

Cheers

Francois

---

From: Gerald Ash <[email-masked]>
Date: Sat, 23 Feb 2008 07:47:36 -0800 (PST)

Martin, John, All,
   
  We've not seen justification for a fundamental change to NSIS/QSPEC that does away with standardized Admission Priority values, as proposed in http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html.  QSPEC is following Y.2171 in standardizing 3 priority levels to have end-to-end cross-domain significance.  Having domain-specific assignments can't possibly work across domains if each network administrator decides a different set of priority levels and encodings.
   
  Adoption of the extension to the RPH Priority registry specified in [EMERGENCY-RSVP], as proposed in http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html, is fine.

    However, without justification there is no reason to change the NSIS/QSPEC approach to admission priority or eliminate the admission priority IANA registry at this point.  If valid arguments come forward later (*on the list*) to make a change, we can do it then of course.

  Jerry

Gerald Ash <[email-masked]> wrote:
    Francois, Martin, John, All,

   

   

   

   

   
  Jerry

    Francois,

   

     
   
  OK.

   

  No registry is setup.

  Cheers

  Francois

   
  Jerry

Cheers

Francois