Subject: [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 28 Aug 2008 15:00:29 +0200

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. Is there a need for any supplementary
documents to describe protocol specific mapping and IANA allocations? 

2. Was the document reviewed by the RADIUS WG? 

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.

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.  

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. 

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. 

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

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

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)

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

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

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

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

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

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

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 

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? 

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?

22. Section 4.12 should have a reference to the IANA registry required
to be defined for this parameter in Section 6.3. 

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. 

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. 

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

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. 

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

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. 

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. 

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. 

32. The description of the [Y.1541] and [Y/1571] references are
incomplete. 

Thanks and Regards,

Dan

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors