Subject: [NSIS] QSPEC Draft Review

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 Mar 2007 15:15:15 +0200

Hi all,

I reviewed the QSPEC draft (a little bit late but the WGLC ran during 
the draft submission deadline period).

In addition to the comments I made in past review comments already (and 
that were already mentioned by Robert in his recent review as well) I 
would like to point to the following issues:

* Am I allowed to register new QoS parameters without defining a new QoSM?

* Section 5.4:

This text block has to be removed:
"

   The set of QSPEC parameters defined herein is at this point in time
   considered complete.  Additional QSPEC parameters may be defined in
   the future.  However, since this requires an update of all QNEs, this
   should be considered carefully.  The definition of new QSPEC
   parameter requires standards action and an update of this document.
   Such an update also needs a new QSPEC version number.  Furthermore,
   all QOSM definitions must be updated to include how the new QSPEC
   parameter is to be interpreted in the respective QOSM.

"
since it is not correct anymore (I hope at least).

Regarding
"
   Additional QSPEC parameters MAY need to be defined in the future
   and are defined in separate informational documents specific to a
   given QOSM.  For example, QSPEC parameters are defined in
   [RMD-QOSM] and [Y.1541-QOSM].
"

  - I would not use RFC 2119 language here.
  - Additional QoS parameters do not need informational documents -> see 
IANA consideration section.

I would delete the entire section since it is meaningless.

* In the IANA consideration section you write:
"
Note that if additional QSPEC parameters are
   defined in the future, this requires a standards action equivalent to
   reissuing this document as a QSPEC-bis.
"

I suspect that this is a left-over from old days and has to be deleted.

* You have Y.1541 and Y.1571 in the normative references. What are the 
rules for dealing with non-IETF documents? Are these documents 
publically available?

* Are the references [3GPP-1],[3GPP-2] and [3GPP-3] really normative 
references? I thought that they were just mentioned informally.

* Acknowledgments and Contributors

Dave Oran is still listed in the acknowledgments section. There are many 
contributors listed even though, for most of them, I have not seen them 
discussing anything on the list while some of the listed persons in the 
acknowledgment list have spent a lot of time fixing the document over 
several years. There might be a misbalance. I must admit that I am in 
general not excited about the way how people are acknowledged in IETF 
drafts in general given that they are "allowed" to fix documents of 
draft authors but they get no reward.

* You write: "The excess treatment parameter is set by the QNI.  It 
cannot be overwritten."

  Why not? Why cannot the AAA server set a value that is different to 
the one set by the initiator?

* The IDNITS tool told me the following:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
    Nothing found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - No 'Intended status' indicated for this document; assuming Proposed
    Standard

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be 
changed.

  Miscellaneous warnings:
    Nothing found here.

  Checking references for intended status: Proposed Standard
  - Missing Reference: 'QOS-SIG' is mentioned on line 1312, but not defined
  - Possible downref: Undefined Non-RFC (?) reference : ref. 'QOS-SIG'
  - Missing Reference: 'S' is mentioned on line 1704, but not defined
  - Possible downref: Undefined Non-RFC (?) reference : ref. 'S'
  - Unused Reference: 'RFC4506' is defined on line 2323, but not referenced
  - Unused Reference: 'IEEE754' is defined on line 2335, but not referenced
  - Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2341, but not
    referenced
  - Unused Reference: 'RFC3564' is defined on line 2367, but not referenced
  - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1'
  - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2'
  - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3'
  - Possible downref: Non-RFC (?) normative reference: ref. 'GIST'
  - Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG'

    Summary: 1 error, 14 warnings

Ciao
Hannes

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

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Sun, 11 Mar 2007 08:37:00 -0500

Hannes, 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 8:15 AM
> To: [email-masked]
> Subject: [NSIS] QSPEC Draft Review
> 
> Hi all,
> 

Yes, as discussed on the list
http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html.
 
> since it is not correct anymore (I hope at least).

Yes, as discussed on the list
http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html.
 
> I would delete the entire section since it is meaningless.

It will be clarified as discussed on the list
http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html.

> I suspect that this is a left-over from old days and has to 

Yes, as discussed on the list
http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html.
 
> publicly available?

Yes.  Non-IETF documents are allowed as normative references.
 
> references? I thought that they were just mentioned informally.

Yes.  Non-IETF documents are allowed as normative references.

> the one set by the initiator?

Parameter is read-only, what would it mean to overwrite what the QNI has
already specified?
 
>   Checking nits according to 
> http://www.ietf.org/ietf/1id-guidelines.txt:

OK.  I always check idnits too.

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Mar 2007 20:36:48 +0200

Good to see that all these issues will be addressed with the next draft 
update.

> Parameter is read-only, what would it mean to overwrite what the QNI has
The authorization decision by a policy server may do whatever it wants 
regardless whether the QNI said it wants to have a certain treatment.

Ciao
Hannes

---

From: Andrew McDonald <[email-masked]>
Date: Tue, 13 Mar 2007 18:43:38 +0000

Hi,

On a related point to the following, some comments below:

> http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html.

Reading through the current -15 draft (and intended changes outlined 
above), I'm unclear how the version field 'works'.

The main text about the version field is in 4.2 and 5.4. The 2nd 
paragraph of section 4.2 defines the behaviour when a version n+1 device 
receives a version n message (just carry on, since you have to be 
backwards compatible). However, the text doesn't say what a version n 
device does when it receives an n+1 message. (NB: Under the current 
processing, a message with an unsupported parameter with 'M' set would 
be rejected the same way regardless of version). So, the version field 
currently seems to be ignored when processing a QSpec.

The consequence of the e-mails you referenced above would seem to be 
that the version number does not need to be increased if you add a new 
parameter. This sounds like the correct behaviour to me (given the 
existence of the 'M' flag). I could possibly imagine a version number 
being used for more substantive changes in the QSpec. This would 
probably require a simple 'reject if version is higher than that 
supported' response, allowing the QNE that sent the RESERVE (or other 
NSLP message) to retry with a lower QSpec version.

On a related topic, I don't know what other people who have been 
implementing the QSpec think, but the alignment of the fields in the 
common header seems a bit strange to me. It is currently:
   Version: 4 bits
   QSPEC Type: 8 bits
   QSpec Proc: 8 bits
   Reserved: 12 bits
So, the second and third fields aren't aligned on octet boundaries, 
although they are 8 bit fields. This is likely to make processing more 
difficult or inefficient (it always requires a mask/shift). A nicer 
format, if 'version' is kept as being 4 bits long, might be:
   Version: 4 bits
   Reserved: 4 bits
   QSPEC Type: 8 bits
   QSpec Proc: 8 bits
   Reserved: 8 bits
Alternatively, version could be expanded to 8 bits. (The GIST version 
number is 8 bits).

regards,

Andrew

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Tue, 13 Mar 2007 17:58:51 -0500

Hi Andrew, 

Thanks for the comments.  Please see below.

> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 2:44 PM
> To: ASH, GERALD R, ATTLABS
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [NSIS] QSPEC Draft Review
> 
> Hi,
> 

> NSLP message) to retry with a lower QSpec version.

I agree with your suggestion here.  Some of the current text had to do
with QSPEC-1 parameters, now removed, so the text needs to be updated.

Based on your suggestion, I propose the following replacement text for
the second paragraph in Section 4.2:

"The QSPEC consists of a QSPEC version number and QSPEC objects.  IANA
assigns a new QSPEC version number when substantive changes are made to
the QSPEC and this document is reissued.  Note that a new QSPEC version
number is not needed when new QSPEC parameters are specified in other
specification documents, as prescribed in the IANA Considerations
section.  Later QSPEC versions MUST be backward compatible with earlier
QSPEC versions.  That is, a version n+1 device must support QSPEC
version n (or earlier).  On the other hand, if a QSPEC version n (or
earlier) device receives an NSLP message specifying QSPEC version n+1,
then the version n device responds with a  'Malformed QSPEC' error code
(0x03) response, as discussed in Section 5.2.3, allowing the QNE that
sent the NSLP message to retry with a lower QSPEC version."

Would we need to define another error code besides 0x03 for this case?

Note that the first paragraph in Section 5.4 is eliminated based on
earlier discussion on the list, so that no reference to QSPEC version
number will be made in Section 5.4 after this is done.

> Alternatively, version could be expanded to 8 bits. (The GIST version 

Would this order be any better (?):

    QSPEC Type: 8 bits
    QSpec Proc: 8 bits
    Version: 4 bits
    Reserved: 12 bits

Several of the QSPEC parameters may not be aligned on octet boundaries
either.  Would it be more problematic for the common header to not
align? 

Thanks,
Regards,
Jerry

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 14 Mar 2007 13:59:49 +0000

Hi Jerry,

> sent the NSLP message to retry with a lower QSPEC version."

I don't understand the distinction between adding new parameters outside 
the QSPEC base document and reissuing the QSPEC base document with the 
addition of some parameters as the only change. Do you need to increase 
the version number in either case? Won't the 'M' bits be enough to 
handle this?

I may be missing something, but I think a change that increases the 
version number is likely to be more radical than simply adding a new 
parameter. Probably adding a new QSPEC object would be one case (since 
there is no equivalent of the 'M' bit or NSLP/GIST 'A/B' flags there).

The version number field is fairly small (4 bits), so small changes 
which require only a new parameter seem to be a waste of version 
numbers, given that there are other compatibility/extension mechanisms 
in place.

> Would we need to define another error code besides 0x03 for this case?

It would probably be a good idea. If you've got a bad version number you 
can probably retry with a lower one. In the general 'malformed' case 
there isn't necessarily anything you can do to automatically retry.

> number will be made in Section 5.4 after this is done.

OK

> either.  Would it be more problematic for the common header to not

Keeping the version as the first field is probably a good idea. If we 
move to a version 2, will it still have QSpec Type and QSpec Proc fields?

The other parameters looked ok to me. Where fields are not a multiple of 
8 bits they only need masking to extract the relevant data. They don't 
require glueing together nibbles from consecutive bytes.

regards,
Andrew

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 14 Mar 2007 10:52:01 -0500

Hi Andrew,

I guess I confused you with my previous post, please see below. 

> Sent: Wednesday, March 14, 2007 10:00 AM
> Cc: [email-masked]

> the version number in either case? Won't the 'M' bits be enough to 

The QSPEC version number does *not* need to be increased with a new
parameter specified outside the base document.  I thought this sentence
in the proposed replacement text took care of that: 'Note that a new
QSPEC version number is not needed when new QSPEC parameters are
specified in other specification documents, as prescribed in the IANA
Considerations section'.  Is that sentence confusing perhaps?  If so,
please suggest alternative text.

Furthermore, I don't see that the base QSPEC document ever needs to be
reissued 'with the addition of some parameters as the only change'.  I
think addition of new parameters can/should be done in separate
documents (not reissue the QSPEC document).  

However, if the QSPEC document is reissued to make 'substantive
changes', then IMO a new version number is required, as stated in my
proposed replacement text (and as I think you also proposed): 'IANA
assigns a new QSPEC version number when substantive changes are made to
the QSPEC and this document is reissued.'

It seems that my proposed text is not clear, so please suggest
clarifications.
 
> there is no equivalent of the 'M' bit or NSLP/GIST 'A/B' flags there).

Yes I agree, see above comments.
 
> numbers, given that there are other compatibility/extension 
> mechanisms in place.

Yes I agree, see above comments.

> there isn't necessarily anything you can do to automatically retry.

OK, can you suggest an error code to be specified in the QoS NSLP
document so that we can reference that code in the QSPEC document.
 
> >> Alternatively, version could be expanded to 8 bits. (The 
> >> GIST version number is 8 bits).
> > 

So I suggest we make the Version Number 8 bits (like GIST and as you
suggest), and keep the same order, as follows:

    Version: 8 bits
    QSPEC Type: 8 bits
    QSpec Proc: 8 bits
    Reserved: 8 bits

Thanks,
Regards,
Jerry

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 14 Mar 2007 16:29:39 +0000

Hi Jerry,

> please suggest alternative text.

It's the second half of that sentence that I had difficulty with. I read 
that as saying "The QSPEC version number does *not* need to be increased 
with a new parameter specified /outside/ the base document. The QSPEC 
version number *does* need to be increased with a new parameter 
specified /inside/ the base document."

How about just cutting that sentence down to:
"Note that a new QSPEC version number is not needed when new QSPEC 
parameters are specified."

> documents (not reissue the QSPEC document).  

OK. Your previous text suggested to me that there would be circumstances 
in which new parameters would be defined in other documents, and 
circumstances in which they'd need to be defined in a new QSPEC 
document, with the latter requiring the version number to be increased.

> the QSPEC and this document is reissued.'

Looks OK. Possibly "incompatible changes" or "changes which are not 
backwards compatible" would be a bit more precise than just "substantive 
changes" (where people may want to argue over what 'substantive' means).

> It seems that my proposed text is not clear, so please suggest

Hopefully the suggestions above help.

> document so that we can reference that code in the QSPEC document.

At the QoS NSLP level I think we want to avoid too much knowledge of the 
internal structure of a QSpec. So, I guess we want to make this fairly 
generic, e.g. "Incompatible QSpec".

BTW, "Malformed QSPEC" seems to be 0x0c rather than 0x03.

>>>> common header seems a bit strange to me. It is currently:
[snip discussion]
> suggest), and keep the same order, as follows:

I'm happy with that.

Andrew

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 14 Mar 2007 11:50:51 -0500

Hi Andrew,

I agree with all your suggestions, many thanks.  One further
comment/question below.

Thanks,
Regards,
Jerry 

> Sent: Wednesday, March 14, 2007 12:30 PM

OK, so what will be the error code for "Incompatible QSPEC", perhaps:

     o  Protocol Error:
     ...
     *  0x0f - Incompatible QSPEC

in Section 5.1.3.6. (Information Object (INFO_SPEC) and Error Codes) of
the QoS NSLP document (?)

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 14 Mar 2007 16:59:22 +0000

Hi Jerry,

> the QoS NSLP document (?)

I'll hand this one over at Jukka, as keeper-of-the-nroff.

Andrew

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 14 Mar 2007 20:04:45 +0200 (EET)

Works for me. Will add to the next version. Thanks.

Jukka