Subject: [NSIS] QSPEC Comment: IANA Consideration Section

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

Hi QSPEC authors,

let me comment on the IANA consideration section.

    This specification allocates the following codepoints in existing
    registries:

    PHB Class Parameter [RFC3140] (Section 7.2.6.1)

    The registries needed to use RFC 3140 already exist [DSCP-REGISTRY,
    PHBID-CODES-REGISTRY].

[hannes] Delete it from the IANA consideration section since you don't 
request IANA todo anything.

    This specification creates the following registries with the
    structures as defined below:

    Object Types (12 bits):
    The following values are allocated by this specification:
    0-4: assigned as specified in Section 7.
    The allocation policies for further values are as follows:
    5-63: Standards Action
    64-127: Private/Experimental Use
    128-4095: Reserved

[hannes] Don't let IANA search through the document. Provide them the 
values:

   Object Type = 0: control information
                = 1: QoS Desired
                = 2: QoS Available
                = 3: QoS Reserved
                = 4: Minimum QoS

[hannes] What does 'reserved' mean? The Object Type has 12 bits and 
according to Section 7 all of them are used.

    QSPEC Version (4 bits):
    The following value is allocated by this specification:
    0: assigned to Version 0 QSPEC
    The allocation policies for further values are as follows:
    1-15: Standards Action

[hannes] You might want to say something about the allocation registry:

* Is it allow to depreciate versions?
* Is it allowed to delete versions?
* Is it allowed to modify versions?

    QOSM ID (12 bits):
    The allocation policies are as follows:
    0-63: Specification Required

    64-127: Private/Experimental Use
    128-4095: Reserved

[hannes] What does 'reserved' mean?

    Note that QOSM ID assignments are normally requested in QOSM
    specification documents.

[hannes] Delete this sentence.

* Is it allow to depreciate QOSM IDs?
* Is it allowed to delete QOSM IDs?
* Is it allowed to modify QOSM IDs?

    QSPEC Procedure (8 bits):
    Broken down into
    Message Sequence (4 bits):
    The following values are allocated by this specification:
    0-2: assigned as specified in Section 7.1
    The allocation policies for further values are as follows:
    3-15: Standards Action
    Object Combination:
    The following values are allocated by this specification:
    0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3

    The allocation policies for further values are as follows:
    3-15: Standards Action

[hannes] I suspect that this be a bit confusing for IANA.

You want to create a registry and fill it with values according to:

                 0: Sender-Initiated Reservations, as defined in Section
                    6.1.1
                 1: Receiver-Initiated Reservations, as defined in
                    Section 6.1.2
                 2: Resource Queries, as defined in Section 6.1.3

[hannes] and then a second registry that should be contained in Section 
6.1.1 and 6.1.3. These sections do not exist.

    Error Code (16 bits)
    The following values are allocated by this specification:
    1-3: assigned as specified in Section 4.5.1

[hannes] Section 4.5.1 does not define error codes!

    The allocation policies for further values are as follows:
    4-127: Specification Required (e.g., QOSM specification document)

[hannes] Delete the example.

    128-255: Private/Experimental Use
    255-65535: Reserved

    Parameter ID (12 bits):
    The following values are allocated by this specification:
    0-18: assigned as specified in Sections 7.2.1 --> 7.2.12.

[hannes] List the values here.

    The allocation policies for further values are as follows:
    19-63: Standards Action (for mandatory parameters)
    64-127: Specification Required (for optional parameters)
    128-255: Private/Experimental Use
    255-4095: Reserved

[hannes] Again, what does 'reserved' mean?

    Note that if additional mandatory parameters are defined in the
    future, this requires a standards action equivalent to reissuing
    this document as a QSPEC-bis.

    Excess Treatment Parameter (8 bits):
    The following values are allocated by this specification:
    0-3: assigned as specified in Section 7.2.2
    The allocation policies for further values are as follows:
    4-63: Standards Action
    64-255: Reserved

    Y.1541 QoS Class Parameter (12 bits):
    The following values are allocated by this specification:
    0-7: assigned as specified in Section 7.2.6.2
    The allocation policies for further values are as follows:
    8-63: Standards Action
    64-4095: Reserved

    DSTE Class Type Parameter (12 bits):
    The following values are allocated by this specification:
    0-7: assigned as specified in Section 7.2.6.3
    The allocation policies for further values are as follows:
    8-63: Standards Action
    64-4095: Reserved

    Admission Priority Parameter (8 bits):
    The following values are allocated by this specification:
    0-2: assigned as specified in Section 7.2.6.2

[hannes] Wrong reference: You have to point to Section 7.2.7.2

    The allocation policies for further values are as follows:
    3-63: Standards Action
    64-255: Reserved

    RPH Namespace Parameter (16 bits):
    The following values are allocated by this specification:
    0-5: assigned as specified in Section 7.2.7.2

[hannes] Wrong reference: You have to point to Section 7.2.7.3
See, however, my comment regarding the entire section below:

    The allocation policies for further values are as follows:
    6-63: Standards Action
    64-65535: Reserved

    RPH Priority Parameter (8 bits):
    dsn namespace:
    The following values are allocated by this specification:
    0-4: assigned as specified in Section 7.2.7.2
    The allocation policies for further values are as follows:
    5-63: Standards Action
    64-255: Reserved
    drsn namespace:
    The following values are allocated by this specification:
    0-5: assigned as specified in Section 7.2.7.2
    The allocation policies for further values are as follows:
    6-63: Standards Action
    64-255: Reserved
    Q735 namespace:
    The following values are allocated by this specification:
    0-4: assigned as specified in Section 7.2.7.2
    The allocation policies for further values are as follows:
    5-63: Standards Action
    64-255: Reserved
    ets namespace:
    The following values are allocated by this specification:
    0-4: assigned as specified in Section 7.2.7.2
    The allocation policies for further values are as follows:
    5-63: Standards Action
    64-255: Reserved
    wts namespace:
    The following values are allocated by this specification:
    0-4: assigned as specified in Section 7.2.7.2
    The allocation policies for further values are as follows:
    5-63: Standards Action
    64-255: Reserved

[hannes] The reference in the draft to [SIP-PRIORITY]. [SIP-PRIORITY] is 
an RFC in the meanwhile:
http://www.rfc-editor.org/rfc/rfc4412.txt

RFC 4412 creates a registry for these values already. See Section 12.6 
of RFC 4412. Why do you need to create another one with the same values?

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:04:08 -0500

Hi Hannes,

See below.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Sunday, July 02, 2006 6:01 AM
> To: NSIS
> Subject: [NSIS] QSPEC Comment: IANA Consideration Section
> 
> Hi QSPEC authors,
> 

OK.
 
>    Object Type = 0: control information

OK.
 
> according to Section 7 all of them are used.

I'm not sure of your question, Section 9 says:

   Object Types (12 bits): 

This is how the 12 bits are used in the registry.  Perhaps your question pertains to the "Reserved" above?  Here the specified range designated as 'reserved' is a normal use of allocated space in a registry that is reserved for future definition by a specification.  Future specifications can redefine the registry allocations, and allocate more space to various designations, as necessary (e.g., more space allocated to "Standards Action" or to "Private/Experimental Use", etc.).

> * Is it allowed to modify versions?

No, no, and no, not without another specification doing that.
 
> [hannes] What does 'reserved' mean?

See above for explanation of use of 'reserved' fields in registries.

> [hannes] Delete this sentence.

Why?  I think it just explains why there are no QOSM ID assignments in this document, and where QOSM ID requests will be found in the future.
 
> * Is it allowed to modify QOSM IDs?

No, no, and no.  Not without a specification that does that.

> 6.1.1 and 6.1.3. These sections do not exist.

OK, will fix.

> [hannes] Section 4.5.1 does not define error codes!

Yes, you're right.  This didn't get updated after all the discussion on error codes.  Will do.
 
> [hannes] Delete the example.

Why, it's just an example?  
 
> [hannes] List the values here.

OK.
 
> [hannes] Again, what does 'reserved' mean?

Again, see above explanation of 'reserved'.
 
> [hannes] Wrong reference: You have to point to Section 7.2.7.2

OK.
 
> [hannes] Wrong reference: You have to point to Section 7.2.7.3

OK.

> http://www.rfc-editor.org/rfc/rfc4412.txt

OK.
 
> of RFC 4412. Why do you need to create another one with the 

Good point.  I think this is necessary because the assigned values are being mapped to QSPEC parameter values.  However, I think that this aspect needs to be pointed out to IANA.

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 09:56:54 +0200

Hi Jerry,

thanks for your quick feedback.
Please find my comment 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:01
>> AM To: NSIS Subject: [NSIS] QSPEC Comment: IANA Consideration
>> Section
>> 
>> Hi QSPEC authors,
>> 
>> [hannes] Delete it from the IANA consideration section since you
>> don't request IANA todo anything.
> 
> 
> OK.
> 
> 
>> Object Types (12 bits): The following values are allocated by this
>> specification: 0-4: assigned as specified in Section 7. The
>> allocation policies for further values are as follows: 5-63:
>> Standards Action 64-127: Private/Experimental Use 128-4095:
>> Reserved
>> 
>> [hannes] Don't let IANA search through the document. Provide them
>> the values:
>> 
>> Object Type = 0: control information = 1: QoS Desired = 2: QoS
>> Available = 3: QoS Reserved = 4: Minimum QoS
> 
> 
> OK.
> 
> 
> Object Types (12 bits): The following values are allocated by this
> specification: 0-4: assigned as specified in Section 7. The
> allocation policies for further values are as follows: 5-63:
> Standards Action 64-127: Private/Experimental Use 128-4095: Reserved
> 
> This is how the 12 bits are used in the registry.  Perhaps your
> question pertains to the "Reserved" above?

The packet format looks as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|E|r|r|       Object Type     |r|r|r|r|         Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Object Type has 12 bytes but in the IANA consideration section you 
define more bytes as reserved. This means: A few bytes are reserved in 
the Object Type and then followed by a few bytes that are reserved.

The meaning of the two reserved is different: The 'r's from the above 
figure indicate padding and the other reserved mean for undefined future 
use. Then, there are the 'r's at the beginning of the object that mean 
'will be specified if you add something to the registry'.

Sounds confusing to me.

   Here the specified range
> designated as 'reserved' is a normal use of allocated space in a
> registry that is reserved for future definition by a specification.
> Future specifications can redefine the registry allocations, and
> allocate more space to various designations, as necessary (e.g., more
> space allocated to "Standards Action" or to "Private/Experimental
> Use", etc.).

I am not so sure that this is common and useful practice.
The IANA consideration section already indicates that a fraction of the 
namespace requires standards track actions.

> 
> 
>> QSPEC Version (4 bits): The following value is allocated by this
>> specification: 0: assigned to Version 0 QSPEC The allocation
>> policies for further values are as follows: 1-15: Standards Action
>> 
>> * Is it allow to depreciate versions? * Is it allowed to delete
>> versions? * Is it allowed to modify versions?
> 
> 

You need to tell IANA this fact. IANA is not going to read through your 
draft. They look at the IANA consideration section and create a registry 
with a specific policy.

> 
> 
>> QOSM ID (12 bits): The allocation policies are as follows: 0-63:
>> Specification Required 64-127: Private/Experimental Use 128-4095:
>> Reserved
>> 

Again, I think that this is not a particularly good use. IANA wouldn't 
know what todo with it.

> Why?  I think it just explains why there are no QOSM ID assignments
> in this document, and where QOSM ID requests will be found in the
> future.

IANA does not need these types of notes.

> 
> 
>> * Is it allow to depreciate QOSM IDs? * Is it allowed to delete
>> QOSM IDs? * Is it allowed to modify QOSM IDs?
> 
> 

But are specifications allowed todo it.
YOU need to specify the policy. How should IANA know it?

> 
> 
>> QSPEC Procedure (8 bits): Broken down into Message Sequence (4
>> bits): The following values are allocated by this specification: 
>> 0-2: assigned as specified in Section 7.1 The allocation policies
>> for further values are as follows: 3-15: Standards Action Object
>> Combination: The following values are allocated by this
>> specification: 0-2: assigned as specified in tables in Section
>> 6.1.1 --> 6.1.3
>> 
>> The allocation policies for further values are as follows: 3-15:
>> Standards Action
>> 
>> 0: Sender-Initiated Reservations, as defined in Section 6.1.1 1:
>> Receiver-Initiated Reservations, as defined in Section 6.1.2 2:
>> Resource Queries, as defined in Section 6.1.3

What about telling IANA the following:

You need a Value, a token and the semantic associated with it for this 
registry. This document creates three values, namely:

Value: (0)
Token: Sender-Initiated Reservations
Semantic: See Section 6.1.1 1:

Value: (1)
Token: Receiver-Initiated Reservations
Semantic: See Section 6.1.2

Value: (2)
Token: Resource Queries
Semantic: See Section 6.1.3

Then, you tell IANA that the policies for defining new values in the 
namespace....

Then, you tell them that new entires need to define a token and a 
semantic for the token.

Maybe you want to let them know whether it is possible to replace or 
delete entries in the registry (with a specification, obviously).

>> 
>> [hannes] and then a second registry that should be contained in
>> Section 6.1.1 and 6.1.3. These sections do not exist.
> 
> 
> OK, will fix.
> 
> 
>> Error Code (16 bits) The following values are allocated by this
>> specification: 1-3: assigned as specified in Section 4.5.1
>> 
>> The allocation policies for further values are as follows: 4-127:
>> Specification Required (e.g., QOSM specification document)
>> 

Think as an IANA person. They just want to know their info and not any 
examples. It does not tell them anything.

> 
> 
>> 128-255: Private/Experimental Use 255-65535: Reserved Parameter ID
>> (12 bits): The following values are allocated by this
>> specification: 0-18: assigned as specified in Sections 7.2.1 -->
>> 7.2.12.
>> 
>> The allocation policies for further values are as follows: 19-63:
>> Standards Action (for mandatory parameters) 64-127: Specification
>> Required (for optional parameters) 128-255: Private/Experimental
>> Use 255-4095: Reserved
>> 
>> Excess Treatment Parameter (8 bits): The following values are
>> allocated by this specification: 0-3: assigned as specified in
>> Section 7.2.2 The allocation policies for further values are as
>> follows: 4-63: Standards Action 64-255: Reserved
>> 
>> Y.1541 QoS Class Parameter (12 bits): The following values are
>> allocated by this specification: 0-7: assigned as specified in
>> Section 7.2.6.2 The allocation policies for further values are as
>> follows: 8-63: Standards Action 64-4095: Reserved
>> 
>> DSTE Class Type Parameter (12 bits): The following values are
>> allocated by this specification: 0-7: assigned as specified in
>> Section 7.2.6.3 The allocation policies for further values are as
>> follows: 8-63: Standards Action 64-4095: Reserved
>> 
>> Admission Priority Parameter (8 bits): The following values are
>> allocated by this specification: 0-2: assigned as specified in
>> Section 7.2.6.2
>> 
>> The allocation policies for further values are as follows: 3-63:
>> Standards Action 64-255: Reserved
>> 
>> RPH Namespace Parameter (16 bits): The following values are
>> allocated by this specification: 0-5: assigned as specified in
>> Section 7.2.7.2
>> 
>> The allocation policies for further values are as follows: 6-63:
>> Standards Action 64-65535: Reserved
>> 
>> RPH Priority Parameter (8 bits): dsn namespace: The following
>> values are allocated by this specification: 0-4: assigned as
>> specified in Section 7.2.7.2 The allocation policies for further
>> values are as follows: 5-63: Standards Action 64-255: Reserved drsn
>> namespace: The following values are allocated by this
>> specification: 0-5: assigned as specified in Section 7.2.7.2 The
>> allocation policies for further values are as follows: 6-63:
>> Standards Action 64-255: Reserved Q735 namespace: The following
>> values are allocated by this specification: 0-4: assigned as
>> specified in Section 7.2.7.2 The allocation policies for further
>> values are as follows: 5-63: Standards Action 64-255: Reserved ets
>> namespace: The following values are allocated by this
>> specification: 0-4: assigned as specified in Section 7.2.7.2 The
>> allocation policies for further values are as follows: 5-63:
>> Standards Action 64-255: Reserved wts namespace: The following
>> values are allocated by this specification: 0-4: assigned as
>> specified in Section 7.2.7.2 The allocation policies for further
>> values are as follows: 5-63: Standards Action 64-255: Reserved
>> 
>> [hannes] The reference in the draft to [SIP-PRIORITY]. 
>> [SIP-PRIORITY] is an RFC in the meanwhile: 
>> RFC 4412 creates a registry for these values already. See Section
>> 12.6 of RFC 4412. Why do you need to create another one with the 
>> same values?
> 
> 
> Good point.  I think this is necessary because the assigned values
> are being mapped to QSPEC parameter values.  However, I think that
> this aspect needs to be pointed out to IANA.

Why cannot you use the values directly?

Ciao
Hannes

> Thanks, Jerry
>> Ciao Hannes