Re: [Dime] AD Review of dime-qos-parameters-06.txt

Hi Dan, 

Thanks for your very detailed review! 

>Hi,
>
>This is the AD review of dime-qos-parameters-06.txt. I believe 
>that the document needs more work before it can be sent to 
>IETF Last Call. I am placing it in Revised ID Needed. 
>
>1. Although it is the work of the DIME Working Group, the 
>document includes in its scope according to the Introduction 
>section the
>definition of parameters    that can be reused for conveying QoS
>information within RADIUS and Diameter. I believe that there 
>is a need to add text that shows how specifically these 
>parameters will be used in each of the two protocols.

The description can be found in documents using this specification. 
For Diameter a description can be found in
http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/

> Is there 
>a need for any supplementary documents to describe protocol 
>specific mapping and IANA allocations? 
I guess you refer to the IANA consideration section and the ability to
specify new parameters. 
Right? 

>
>2. Was the document reviewed by the RADIUS WG?

We have sent the WGLC announcements to DIME, RADEXT, NSIS, and TSVWG
(and to other SDOs). 

>
>3. This document will trigger again the issue of exceeding the 
>AAA scope of DIAMETER as described by RFC 3588, raised in a 
>number of previous occasions, last by Brian Carpenter in his 
>GenART review for draft-sun-dime-itu-t-rw. I suggest to put 
>text in the Introduction section mentioning the issue of scope 
>and referring to rfc3588bis as an Informational Reference.
No, this document doesn't. When used as described in
http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/ then it is
totally in line with the scope of Diameter. 

However, when used in
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt then
there are again the same issues as previously raised already. 

>
>4. There are several places in the document where the authors 
>seem to write requirements about the behavior and mode of 
>provisioning of a QoS enabled network. I do not think that an 
>AAA parameters document is a good place for such requirements. 
>I would strongly prefer that the document focuses on 
>describing the QoS parameters carried by AAA protocols, and if 
>examples of usage are left, they be marked clearly as examples.  

This was indeed not the intention. I will search through the document to fix
these 
Cases. 

>
>5. Section 3.2 - Path PLR and Path PER are defined on packet 
>basis, so the claim that they describe the desired bit error 
>rate seems odd. 

Fixed. 

>
>6. Same -'where the PLR is defined to be the PLR added by each 
>such node' and 'the PER is defined to be the PER added by each 
>such node'
>seem to be broken as definitions - maybe that was intended to 
>be define is 'the Path PLR' and 'the Path PER' respectively. 

Fixed. 

>
>7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords 
>usage seems unjustified here.

Fixed. 

>
>8. Section 4.1 and following - it would be good to mention 
>that Length all over this document is expressed in 32-bit words. 
>

Fixed. 

>9. It is not clear why there is a need to defined both TMOD-1 
>and TMOD-2. I suggest to add an explanation. 

>
>10. Section 4.2 - I suggest to add a normative reference to 
>IEEE 754 when referring the first time to single-precision 
>IEEE floating point format. It's a good moment, as the IEEE 
>standard was updated in June 2008, after more than two decades 
>of usage of the precedent version (but this does not affect 
>the way it is used here as far as I can tell)

Do you have a reference to the new standard? 

>
>11. The first phrase in 4.3 should appear also in 4.2 as the 
>two TMOD parameters have similar semantics. 

>
>12. Section 4.5 - there is no reference for the semantic of 
>the Path Jitter parameter value - probably section 3.4 in RFC2215

>
>13. I do not understand what is the reason to include Path 
>Jitter STAT4 (Reserved).

The format was copied from NSIS specifications. I will ask on the NSIS
mailing list for reasons why these parameters got included. 

>
>14. Section 4.6 - I do not believe that a AAA document should 
>include statements like 'The total PLR added across all QoS 
>aware nodes can range as high as 10^-1.'

Fixed. 

>
>15. Section 4.7 - in the first phrase s/PLR/PER/
>
Fixed. 

>16. Section 4.7 - I do not believe that a AAA document should 
>include statements like 'The total PER added across all QoS 
>aware nodes can range as high as 10^-1.'

Fixed. 

>
>17. Section 4.8 - I see no reason to refer here to [RFC2212]

RFC 2212 defines the slack term. 

>
>18. Section 4.8 - s/Path PLR/Slack Term/

Fixed. 

>
>19. Section 4.11 - I am not sure that quoting RFC4412 as a 
>reference for the semantic of the parameter value is fully 
>accurate. It may be good at most to say that what is referred 
>here is the resource-priority policy element 

RFC 4412 creates the registry this document refers to. 
[I-D.ietf-tsvwg-emergency-rsvp] converts the values in that registry from a
textual representation (in the form of, for example, 'dsn.flash') to
numerical values. We had a long discussion between NSIS and TSVWG on who
should create that registry. I did not have an opinion about that issue. 

>
>20. Section 4.11 - This I-D defines similarly ALRP parameter 
>as draft-ietf-tswg-emergency-rsvp and the two documents quote 
>each other with the apparent intent to keep the definitions in 
>sync. However draft-ietf-tswg-emergency-rsvp defines a policy 
>object which is a list of ALRPs, while here there is only one 
>instance. Why the difference? 

We only reference the registry. When one wants to convey multiple values
within RADIUS or Diameter for an authorization request (as an example) then
two separate objects have to be used. 

>
>21. Section 4.11 - if the intent is to keep the definitions 
>here and in draft-ietf-tswg-emergency-rsvp as close as 
>possible what are the ALRP Priority and Reserved octets 
>positions inversed in the two definitions?

When we wrote our document that was the format used in the NSIS documents. 
At that time we referenced the NSIS documents and only later the format was
changed. 
It seems that we have to align it now as well. 
>
>22. Section 4.12 should have a reference to the IANA registry 
>required to be defined for this parameter in Section 6.3. 

Fixed. 

>
>23.  Section 4.12 - what is 'the QoS Desired' object defined here? 
>
>24. Section 4.12 includes text about the behavior of the 
>network that looks mis-placed in an AAA document. 

Your feedback about Section 4.12 is good. Based on what you said I wonder
whether it wouldn't have been cleaner to put the functionality of the Excess
Treatment Parameter into the QoS attribute draft instead. 

I will need to check this with the group. 

>
>25. Section 4.13 could use a reorganization of the 
>description. The 16-bits in the payload have different 
>structure according to the PHB class type - they would better 
>get one generic name and specific descriptions for the three 
>cases covered by the object. 

I re-organized the section to make it more readable.  

>
>26. Section 4.14 - the semantic described in this section is 
>not identical with the one in RFC 4124 which is provided as 
>reference. 4124 says 0 is a reserved value - what semantics 
>does it have here? It is also not clear why this parameter was 
>defined to have an 8-bit representation

I will have to check with the NSIS group on this issue as the parameter
encoding is taken from there. 

>
>27. Section 4.15 - I strongly advice against presenting the 
>usages of the QoS Class parameters here especially in such 
>firm terms as here.
>Actually ITU-T Y.1541 Tables 2 and 3 make clear that these 
>class usages are only guidance (classes 1 to 5) and 
>provisional (classes 6,7). This is completely lost here. I 
>would prefer to just provide a pointer to the ITU-T document 
>and take out all the classes descriptions, or move them in an 
>Appendix, with all necessary description of their guidance and 
>provisional status. 

Sounds good to me. 

>
>28. Section 5 should provide a reference to the IANA registry 
>for Enterprise Numbers

Done. 

>
>29. Section 6.4 - It is not clear why there is a need to 
>create a registry for DSTE Class Type Parameters. If IETF WGs 
>or individuals writing RFCs and running them through the IETF 
>process will be allowed to add or modify values by Standards 
>Actions, this would modify the semantics defined in Section 
>4.14, which does not include any mention of extensibility for 
>these parameters. 

You are entirely correct. 

>
>30. Section 6.5 -  It is not clear why there is a need to 
>create a registry for Y.1541 Class Parameters. Who would take 
>the responsibility of running the Standard Action to modify or 
>add Object class values? In what conditions? When Y.1541 
>changes? In any case, this would modify the semantics defined 
>in Section 4.14, which does not include any mention of 
>extensibility for these parameters. 

Correct as well. 

>
>31. Section 7 - I disagree that this document does not raise 
>any security concerns. Actually the modification or 
>mis-configuration of the QoS parameters carries security 
>threats similar with the configuration operations that would 
>be performed for example in case the objects would be 
>configured by using a protocol like SNMP. QoS degradation may 
>lead to degradation of service that can make access to the 
>network resources difficult or impossible, or running 
>real-time applications impossible.
>We need text that explains what are the sensitive parameters, 
>and the recommended operational and deployment measures to 
>protect against security threats. 

We were planning to have that text in the QoS attribute draft rather than in
this draft. 

>
>32. The description of the [Y.1541] and [Y/1571] references 
>are incomplete. 
I messed it up in the XML2RFC description of the reference. 

Ciao
Hannes

>
>Thanks and Regards,
>
>Dan
>
>
> 
>_______________________________________________
>DiME mailing list
>DiME@ietf.org
>https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime