Subject: [NSIS] QSPEC Comment: Mandatory Attribute List

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Jul 2006 12:25:23 +0200

Hi QSPEC authors,

Section 7.2 of the QSPEC template draft lists a number of mandatory 
attributes:

* NON QOSM Hop
* Excess Treatment
* Bandwidth
* Token Bucket
* PHB Class
* Y.1541 QoS Class
* DSTE Class Type
* <Preemption Priority> & <Defending Priority>
* Admission Priority
* RPH Priority

A few comments:

- The DSTE Class Type' parameter points to a requirements document with 
respect to its functional specification (see RFC3564). Maybe you placed 
the wrong reference in here.

- I would be more relaxed to see a review of the RFC 4412 authors (James 
Polk and Henning Schulzrinne) when it comes to the usage of the RPH 
Priority parameters (defined for SIP) in the QSPEC template draft.

- I am not sure why the Y.1541 QoS Class parameter is a mandatory object.

- The Admission Priority parameter points to a non-IETF in the 
informative reference section.

- The NON QOSM Hop parameter does not seem to be a QoS parameter at all 
that belongs to this category. I would rather see it as an error message.

Ciao
Hannes

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sun, 2 Jul 2006 19:05:46 -0500

Hi Hannes,

See below. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Sunday, July 02, 2006 6:25 AM
> To: NSIS
> Subject: [NSIS] QSPEC Comment: Mandatory Attribute List
> 
> Hi QSPEC authors,
> 

OK.  A better reference would be RFC 4124 http://www.ietf.org/rfc/rfc4124.txt?number=4124, the DSTE protocol extensions specification.
 
> Priority parameters (defined for SIP) in the QSPEC template draft.

As GIST co-author, Henning at least probably monitors this list.  In addition, there was a suggested that we might want to send the last call on QoS-NSLP and QSPEC to TSVWG as well.

> - I am not sure why the Y.1541 QoS Class parameter is a 

Actually the mandatory parameter is <QoS Class>.  As discussed in Section 7.2.6, <QoS Class> consists of the <PHB Class>, <Y.1541 QoS Class>, or <DSTE Class Type> parameter.  These are 3 different ways to specify <QoS Class>, and it is expected that at most one is populated.  This can be clarified.
 
> informative reference section.

It should be in the Normative References section, per your previous comment.  Also, it is OK that this is not an RFC, if that is your point.  I checked this out with IANA, normative references that are not RFCs (e.g., Standards from other SDO's) are certainly permissible as normative references.

> that belongs to this category. I would rather see it as an 

I think it should be a flag, along with the E-Flag for QSPEC objects specified in Section 7.1, as I suggested in a previous response to one of your comments.

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 10:05:25 +0200

Hi Jerry,

please find my comments below:

Ash, Gerald R (Jerry), ALABS wrote:
> Hi Hannes,
> 
> See below.
> 
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[email-masked]] Sent: Sunday, July 02, 2006 6:25
>> AM To: NSIS Subject: [NSIS] QSPEC Comment: Mandatory Attribute List
>> 
>> 
>> Hi QSPEC authors,
>> 
>> * NON QOSM Hop * Excess Treatment * Bandwidth * Token Bucket * PHB
>> Class * Y.1541 QoS Class * DSTE Class Type * <Preemption Priority>
>> & <Defending Priority> * Admission Priority * RPH Priority
>> 
>> A few comments:
>> 
>> - The DSTE Class Type' parameter points to a requirements document
>> with respect to its functional specification (see RFC3564). Maybe 
>> you placed the wrong reference in here.
> 
> 
> OK. A better reference would be RFC 4124
http://www.ietf.org/rfc/rfc4124.txt?number=4124, the DSTE protocol
extensions specification.
> 
> 
>> - I would be more relaxed to see a review of the RFC 4412 authors
>> (James Polk and Henning Schulzrinne) when it comes to the usage of
>> the RPH Priority parameters (defined for SIP) in the QSPEC template
>> draft.
> 
> 
> As GIST co-author, Henning at least probably monitors this list.  In
> addition, there was a suggested that we might want to send the last
> call on QoS-NSLP and QSPEC to TSVWG as well.
> 

Maybe you want to point the respective person explicitly to this aspect.
Henning and the TSVWG list is busy with many other things....

> Actually the mandatory parameter is <QoS Class>.  As discussed in
> Section 7.2.6, <QoS Class> consists of the <PHB Class>, <Y.1541 QoS
> Class>, or <DSTE Class Type> parameter.  These are 3 different ways
> to specify <QoS Class>, and it is expected that at most one is
> populated.  This can be clarified.

Hmmm. How should this work. QoS Class is just a container. Is it 
necessary for a QNE to understand the <PHB Class>, the <Y.1541 QoS 
Class>, and the <DSTE Class Type> parameter to realize the concept of a 
mandatory attribute?

I don't see how it could work if you indicate that the QoS class 
parameter is a mandatory attribute but the individual child elements are 
  not all mandatory...

> It should be in the Normative References section, per your previous
> comment.  Also, it is OK that this is not an RFC, if that is your
> point.  I checked this out with IANA, normative references that are
> not RFCs (e.g., Standards from other SDO's) are certainly permissible
> as normative references.

I know that it does not necessarily needs to be an RFC but it might 
raise some eyebrows particularly if everyone has to implement it.
I recall the difficult discussions in the context of MLPP with the 
different priority levels....

Then, there is also the IPR question. Are you aware of any IPR related 
to this document (and hence to the documents referenced by it)?

> 
> 
>> - The NON QOSM Hop parameter does not seem to be a QoS parameter at
>> all that belongs to this category. I would rather see it as an 
>> error message.
> 
> 
> I think it should be a flag, along with the E-Flag for QSPEC objects
> specified in Section 7.1, as I suggested in a previous response to
> one of your comments.

Fine.

Ciao
Hannes

> Thanks, Jerry
>> Ciao Hannes

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 3 Jul 2006 10:14:15 -0400

Nits with regard to RPH.

References should be updated to include RFC4412 (instead of just the ID)

In section 7.2.7.3 you show a mapping between the text values and numeric
values for RPH priority. (The mappings for ets and wps are fine)

For dsn and drsn you show

  4 - dsn.routine
   3 - dsn.priority
   2 - dsn.immediate
   1 - dsn.flash
   0 - dsn.flash-override

   5 - drsn.routine
   4 - drsn.priority
   3 - drsn.immediate
   2 - drsn.flash
   1 - drsn.flash-override
   0 - drsn.flash-override-override

You might want to check with the intended users of those namesapces, as I
understand (see recent email on the IEPREP mailing list) that DISA intends
to use a quite different numerical mapping, with "0" for routine in all
cases.

"The current DISA specification for MLPP on VoIP networks specifies RPH
r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of priority (e.g.
0 = Routine and 9 = F-O-O)."

It will be very confusing if one numeric mapping is used  in SIP and a
different, opposing, mapping is used in QSPEC.

Thanks

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 3 Jul 2006 19:07:11 -0500

Hi Janet,

See below. 

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: Monday, July 03, 2006 10:14 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila Báder (IJ/ETH)
> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List
> 
> Nits with regard to RPH.
> 

Agreed.  We'll check the referenced specification and align the mapping in the QSPEC.  

Thanks a lot for pointing this out.

Jerry

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Wed, 5 Jul 2006 15:52:39 -0400

Classification:  UNCLASSIFIED 
Caveats: NONE

Janet,

Just a question: Is the DISA specification publicly available? 

An

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
Sent: Monday, July 03, 2006 8:07 PM
To: Janet P Gunn
Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader
(IJ/ETH); NSIS; John Rosenberg
Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List

Hi Janet,

See below. 

Jerry

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

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Wed, 5 Jul 2006 16:27:21 -0400

My next question is: how can you reference it in the ID if it is not publicly available? This leads to my next question: for security, is DISA comfortable with having its MLPP spec being discussed here?

An

-----Original Message-----
From: John Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 05, 2006 4:04 PM
To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P Gunn
Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS
Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List
(UNCLASSIFIED)

No, not yet.

---

From: ken carlberg <[email-masked]>
Date: Wed, 5 Jul 2006 17:00:16 -0400

Another thought is to just remove the example DISA-related values  
from the QSPEC and simply have them registered later through IANA by  
the interested party.  The critical thing for the QSPEC is to have  
the structure/container that can hold the values and not the values  
themselves.

-ken

On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote:

> My next question is: how can you reference it in the ID if it is  
> not publicly available? This leads to my next question: for  
> security, is DISA comfortable with having its MLPP spec being  
> discussed here?
>
> An
>
>> Agreed.  We'll check the referenced specification and align the  
>> mapping in
>> the QSPEC.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Jul 2006 16:42:29 -0500

At 05:00 PM 7/5/2006 -0400, ken carlberg wrote:
>the interested party.

>The critical thing for the QSPEC is to have

This is an interesting idea.  Design the container and the semantics, but 
leave the values for later assignment.

  I like it.

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 5 Jul 2006 21:27:17 -0400

An,

I don't know if it is publicly available or not, which is why I was careful
to quote from what had been posted on the IEPREP mailing list, instead of
from the spec itself.

Janet

"Nguyen, An P CIV NCS NC2" <[email-masked]> wrote on 07/05/2006
03:52:39 PM:

> mapping in the QSPEC.

---

From: John Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 15:31:52 -0500

DISA's current (mostly TDM) MLPP spec is publicly available, and I believe 
that their SIP-based spec will be too, whenever they get done with it.

Having said that, I don't know what the best way, or even a good way, is to 
reference their current rather closely-held draft.

John

At 03:27 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote:
 >My next question is: how can you reference it in the ID if it is not
 >publicly available? This leads to my next question: for security, is DISA
 >comfortable with having its MLPP spec being discussed here?
 >
 >An
 >

---

From: John Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 15:03:42 -0500

No, not yet.

---

From: John Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 15:31:52 -0500

John

---

From: John Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 15:03:42 -0500

No, not yet.

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Thu, 6 Jul 2006 08:59:39 -0400

Ken,

I like your suggestion.

An

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 5:00 PM
To: Nguyen, An P CIV NCS NC2
Cc: John Rosenberg; Ash, Gerald R (Jerry), ALABS; Janet P Gunn; Attila Bader (IJ/ETH); NSIS; Kappler Cornelia
Subject: Re: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED)

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 6 Jul 2006 09:43:54 -0400

I do to,

Janet

"Nguyen, An P CIV NCS NC2" <[email-masked]> wrote on 07/06/2006
08:59:39 AM:

> Cc: John Rosenberg; Ash, Gerald R (Jerry), ALABS; Janet P Gunn;
> Attila Bader (IJ/ETH); NSIS; Kappler Cornelia

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 16:28:36 +0300

James,

>>The critical thing for the QSPEC is to have the structure/container 
>>that can hold the values and not the values themselves.
>
>This is an interesting idea.  Design the container and the 
>semantics, but leave the values for later assignment.

This is the general idea for the QoS NSLP - we can define the 
semantics, the QSPEC template defines the container and QoS models
define specific QoS deployments.

John

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 16:28:58 +0300

Ken,

>Another thought is to just remove the example DISA-related 
>values from the QSPEC and simply have them registered later 
>through IANA by the interested party.  The critical thing for 
>the QSPEC is to have the structure/container that can hold the 
>values and not the values themselves.

I think that is a good suggestion.

John

>> publicly available? This leads to my next question: for security, is 
>> DISA comfortable with having its MLPP spec being discussed here?
>>
>> An
>>