Draft:  draft-ietf-rmonmib-raqmon-framework-14.txt
Reviewer: Joel M. Halpern [joel@stevecrocker.com]
Review Date:  Saturday 2/4/2006 6:56 PM CST
IETF LC Date:  2/13/2006

Summary: This document is nearly ready for publication as a proposed standard.
(If I am confused about the congestion section, then it is ready for 
publication.)

Moderate:  Congestion...
Has the congestion safety section been reviewed by a transport area 
congestion expert?
It seems to me that the description in section 3, bullet 1, of the 
use of a constant Transmission rate ought to indicate that the rate 
needs to be related to the expected peak number of devices.  (After 
all, the earlier text did talk about the fan in problem.)  Based on 
routing protocol experience, it may also want to indicate that the 
timer for the constant rate needs to be randomly jittered.
The title of section 3, bullet 2 (retransmission timers with back 
offs) seems misleading.  If I am reading the text right, the actual 
technique is to send one message, and wait for a response before 
sending another.  What one might call "single outstanding 
request."  There is nothing in the text about retransmissions and 
back-offs.  (Although, such a technique does require retransmissions, 
and such retransmissions must be backed off.  That is secondary to 
the core of the technique, but ought to be mentioned.)
Section 3, bullet 3 is about avoiding fragmentation.  While that is a 
useful technique, it does not seem to me that it is a congestion 
avoidance technique.

Minor: In section 2.1.3, in describing how configuration parameters 
can be accessed, it lists several ideas as if they were implementable 
approaches.  If we are going to call out DHCP usage, don't we need to 
identify the DHCP option and structure to use?  If we are going to 
suggest using DNS, don't we need to indicate how such configuration 
information would appear in DNS?  For LDAP, we would need a schema...
     Having said that, I believe that the right answer is to reword 
this list to indicate that Manual config is the only defined method, 
a state that the remaining items are ideas for future exploration. 
(Unless you have a file format, a schema, a DHCP option, and a DNS 
record structure up your sleeves already.)
     And shouldn't the list include the MIB, which has the right properties?

Minor: DA, section 5.1.  One line says that this parameter MUST be 
sent in all RAQMON PDUs.  The next lines say that since it will 
remain constant, RDSs should avoid sending this information too 
often.  Which is it?  Should it be in every report, or should it be 
sent in only some reports, in order to confirm that the state hasn't 
changed?  (The same oddity occurs with the RA.)

Minor: Some of the "fraction" reporting items in section 5 state that 
they are reported as a fixed point value with the binary point at the 
left edge of the field (5.21).  Most of the items do not state the 
representation.  I can understand deferring the representation to the 
protocol / MIB.  I can understand including it here.  But we ought to 
be consistent. Given that the MIB uses "percent", and the PDU 
document gives explicit encoding, probably this document should have 
no format definition.

Nit: The receiver of the report is not a source. Why does 5.2 insist 
on calling it the "Receiver Source"?

Nit: In section 2.1.3, when describing ways of getting configuration, 
the LDAP client method appears to be part of the DNS method, rather 
than a separate method of its own.