Subject: RE: [NSIS] QSPEC-T: Questions and minor bugs

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 22 Nov 2005 09:55:53 +0100

Hi Matthias,

Thanks a lot for your careful reading, and for your comments and
suggestions.

> I've got some questions about the QSPEC Template. Mostly they are due
> to minor issues in the spec that should probably be fixed.
> 
> * What will the version number for the finished standard be?

As stated in Section 9 (IANA Considerations) in
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt:

  "QSPEC Version (4 bits):
   The following value is allocated by this specification:
   0: assigned to Version 0 QSPEC"
   
> * There is nothing said about how the length field of QSPEC Objects
>   work.  I assume they are excluding the header. The length fields of
>   the pre-defined parameters indicate that it's without headers, but
>   it is never said explicitly.

Yes, the Object length excludes the header.  We'll clarify that in the
next revision.
 
> * I guess there is no use in empty QSPECs or empty QSPEC Objects.
>   Shouldn't the spec forbid them?

OK, we'll state that in the next revision.
 
> * What about duplicate objects or parameters? It seems like it was
>   intended to have unique object types and unique parameter IDs (per
>   object). This is nice and easy to implement because you can store
>   objects or parameters in arrays or hash tables.
>   However, this seems not to be true for the "Reservation Priority"
>   parameter. I'd suggest to make this parameter's length variable and
>   allow multiple (Admission Priority, RPH Namespace, RPH Priority)
>   triples in one parameter.

It is true that multiple occurrences of a parameter are not possible. We
clarify in the next version. 

Good point about Reservation Priority.  Other approaches to fix this:

1. Keep the parameter as is, with fixed length.  Require that if
Admission Priority = 0 (high), then MUST set RPH Namespace = 5 (not
populated) and RPH Priority = don't care (any)
2. Make Admission Priority and RPH Namespace/RPH Priority separate QSPEC
parameters with fixed lengths.

I like approach #1, it is already implicitly specified, just needs to be
explicit.
 
> * I'm not sure why parameter IDs have been reassigned. When they were
>   starting with 1, errors were easier to detect. Now 0x00000000 looks
>   like a very broken "Non QOSM Hop" parameter.
>   This is also true for objects. 0x00000000 is a perfectly legal
>   "Control Information" object (unless we prohibit empty objects).

We can start numbering parameters/objects with 1 if that prevents
errors. However we dont understand why starting with 0 is a problem?
 
>   In any case: Bandwidth and Slack Term shouldn't have the same ID and
>   the IDs in the Token Bucket section are inconsistent (text 
>   vs. diagram).

Right, we'll correct that.
 
> * Section 5.1 is outdated: The QSPEC Procedure Identifier is no longer
>   a parameter.

Right, we'll correct that.

Thanks again,
Regards,
Jerry, Cornelia, Attila 

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

---

From: Matthias Friedrich <[email-masked]>
Date: Tue, 22 Nov 2005 22:51:06 +0100

Hi,

On Tuesday, 2005-11-22, Kappler, Cornelia wrote:
[...]

>    0: assigned to Version 0 QSPEC"

So the finished standard will have 0, too, ok.

[...]

> I like approach #1, it is already implicitly specified, just needs to be

I don't mind, as long as parameter IDs inside objects are unique.

> errors. However we dont understand why starting with 0 is a problem?

It is no problem, it just made a bug in my code more difficult to find.
There's really no need to change things because of my mistakes, I was
just interested if there was a special reason :-)

The library I use works with fixed size zero-padded buffers. This
combined with the fact that QSPECs no longer have a length field and an
off-by-one bug in my code caused me some headache. I was very confused
about an empty "Control Information" object that seemed to be at the end
of the QSPEC.

Oh, one more thing: For consistency and flexibility it would be nice if
a few Object Types could be reserved for private use like this is done
for QOSM IDs and Parameter IDs.

Thanks,
	Matthias