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

From: Matthias Friedrich <[email-masked]>
Date: Sat, 24 Sep 2005 11:38:21 +0200

Hi,

as part of my study thesis I'm going to implement 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).

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

 * Wrong reference: section 6.7.1 references RFC 3170 (IP Multicast),
   RFC 3140 is probably the intended one.

 * Encoding: section 6.8.2 is a bit confusing. There are three parameter
   Ids assigned but the length is specified as 4 bytes.

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

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.

Thanks for reading,
	Matthias Friedrich

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 29 Sep 2005 07:35:10 -0500

Hi Matthias,

> >>  * 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).

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

OK, I see now.  The format you suggest looks good to me.
 
> 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.

Well, I think it should be done on the list, then anyone interested can
comment if they wish.  Anyone not interested can ignore and delete :-)

Thanks,
Jerry