Subject: RE: [NSIS] [QSPEC-T] Bugs and open issues

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 28 Sep 2005 07:18:41 -0500

Hi Matthias,

Many thanks for your review and comments on the QSPEC Template I-D.

Please see responses below.

Thanks,
Regards,
Jerry 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Matthias Friedrich
> Sent: Saturday, September 24, 2005 5:38 AM
> To: [email-masked]
> Subject: [NSIS] [QSPEC-T] Bugs and open issues
> 
> Hi,
> 
> as part of my study thesis I'm going to implement QSPEC Template.

That's great, this will be a good test of the QSPEC Template!

> While reading version 5 of the draft I noticed some minor problems:
>
>  * Endianness: Only specified once in section 6.6, but it should be
>    specified for all 16 and 32 bit integers. Apparently 32bit floats
>    also have different representations on big endian and little endian
>    machines. Perhaps it would be the easiest solution to simply
>    reference RFC 1832 (XDR: External Data Representation).

We'll add the specification of network byte order and references (RFC
1832, IEEE 754, and http://en.wikipedia.org/wiki/Network_byte_order), up
front in the parameter section (Section 6), as you suggest.

>  * Versioning: The QSPEC has no version number, perhaps a few bits
>    from the QOSM-Id could be used. There won't be 2^16 QOSMs
>    anyway.

Having a QSPEC version number encoded in the QSPEC would be a good idea
IMO.  However, I don't see how this is related to the number of QOSMs.
A new QOSM appearing on the scene doesn't cause a new QSPEC version
number (that would be unworkable IMO).
 
>  * Wrong reference: section 6.7.1 references RFC 3170 (IP Multicast),
>    RFC 3140 is probably the intended one.

You're right.  We should also put RFC 3140 in the normative references.
 
>  * Encoding: section 6.8.2 is a bit confusing. There are three
>    parameter Ids assigned but the length is specified as 4 bytes.

Right, these parameters should be broken out as separately encoded
parameters IMO.  Further, these parameters should not be encoded as a
'container', as they are now, since the parameters are used
independently.  In any case, a separate parameter ID => a separate
encoding.
 
>  * Inconsistencies: draft-ietf-nsis-rmd-03.txt assigns parameter ids
>    that are already used in QSPEC-T. Additionally, the PHB parameter
>    there is only 1 byte.

The inconsistencies will be fixed in the next update to the RMD-QOSM
I-D, according to the RMD authors.

> There's also the following note (see section 5.2.4):
> 
> | Future versions of this document will describe how <Minimum QoS> can
> | be used by the QNI to send a discrete set of desired parameters.
> 
> If it's not too late in the game I'd suggest a different solution. How
> about reassigning object IDs to allow more than one <QoS 
> Desired> object?
> 
>    Object ID:
>         0: control information
>       1-9: QoS Desired
>        10: QoS Available
>        11: QoS Reserved
>        12: Minimum QoS
> 
> QSPECs containing just one <QoS Desired> (oid=1) or both <QoS Desired>
> and <Minimum QoS> (oid=1,12) would be treated like specified 
> in version 5 of the draft.
> 
> If the QNI wants to send a set of parameters, up to n (n=8 here)
> <QoS Desired> objects may be listed, in order of preference. In this
> case, the use of <QoS Minimum> would be prohibited.

Maybe this is a good approach to the encoding of a set of discrete
parameters.  However, we've agreed on the NSIS list that the 'discrete
parameter' functionality is deferred to a future version of the QSPEC.
You have reminded us, however, to remove that sentence from the -06 I-D.

Thanks again.

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

---

From: Matthias Friedrich <[email-masked]>
Date: Thu, 29 Sep 2005 09:52:08 +0200

On Wednesday, 2005-09-28, Ash, Gerald R (Jerry), ALABS wrote:
[...]

> number (that would be unworkable IMO).

Sorry, I should have explained this better. What I had in mind was to
change the QSPEC header a bit to make room for a version field:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Vers.  |      QOSM ID          |       Length (bytes)          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, there are 4 bits for Version and still 12 bits left for
the QOSM ID (with 2^12=4096 possible QOSMs).

An alternative option would be to encode version information on the
layer below (QoS NSLP).

Oh, another question: Where should I report bugs in the draft in case
I find some more? I doubt this is interesting for the majority of
people on this list.

Matthias