[Gen-art] Re: LC Review Assignment: RAQMON
"Joel M. Halpern" <joel@stevecrocker.com> Sun, 05 February 2006 00:57 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5YDh-0002vi-Lc; Sat, 04 Feb 2006 19:57:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5YDC-0002pK-Mv; Sat, 04 Feb 2006 19:57:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22188; Sat, 4 Feb 2006 19:55:16 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5YOv-0006WL-HF; Sat, 04 Feb 2006 20:09:14 -0500
Received: from [71.240.232.61] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12972909; Sat, 04 Feb 2006 17:52:59 -0700
Message-Id: <7.0.1.0.0.20060204195611.0363dd88@stevecrocker.com>
Message-Id: <7.0.1.0.0.20060204182157.03618c70@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sat, 04 Feb 2006 19:56:19 -0500
To: gen-art@ietf.org
From: "Joel M. Halpern" <joel@stevecrocker.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: dromasca@avaya.com, ybkim@broadcom.com, anwars@avaya.com, eugene_golovinsky@bmc.com, rmonmib@ietf.org, bwijnen@lucent.com, Andy Bierman <ietf@andybierman.com>, mahfuz@research.panasonic.com
Subject: [Gen-art] Re: LC Review Assignment: RAQMON
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Framework: http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-14.txt 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. PDU http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-12.txt This document is ready for publication as a Proposed Standard. The few minor items should be considered if there is a need to revise the document. Minor: In describing the T bits, it says "A value of zero is considered to be valid..." If I am reading this right, a value of 0 would be common, since many times there is no application specific information to add to the basic information. If it was intended that this count include the basic application information, then "that trail the BASIC Part" would need to become "including the BASIC part." (And if it does not include the basic part, can we change "trail" to "follow"?) Minor: The Packet Discard in Fraction field occurs in the packet before the Packet Loss in Fraction field. But discard is bit 31 and loss is bit 30 in the bits. And the field descriptions after the bit table are in yet a different order. Is there a need for this variation? Minor: The WG probably considered it obvious, but I think there ought to be a short section that says roughly ~to use TCP to transport RAQMON PDUs, it is sufficient to send the PDUs as the TCP data. As each PDU carries its length, the receiver can determine the PDU boundaries." Nit: "...both functional parts trail a field carrying ..." I am sure that there is a better word than "trail". Contain? MIB http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-11.txt This document is ready for publication as a Proposed Standard Minor: The framework makes a point of distinguishing between discarded packets and lost packets. The raqmonQos table does not make such a distinction. Is there a reason for this? Probably this would be dealt with by an extra sentence or two in section 4 indicating the rationale for the particular selection of fields in the table. Nit: Was there no way to squeeze "priority" / "DSCP" (or at least "pri") in the names of the raqmonParticipantSrcLayer2 (DestLayer2, SrcLayer3, and DestLayer3) fields? The bits definition and the description clause makes it clear what these are. But the naming threw me for a bit. At 05:26 PM 2/1/2006, Mary Barnes wrote: >--------------------------- >Reviewer: Joel Halpern > >- 'Real-time Application Quality of Service Monitoring (RAQMON) MIB ' > <draft-ietf-rmonmib-raqmon-mib-11.txt> as a Proposed Standard >- 'Real-time Application Quality of Service Monitoring (RAQMON) >Framework ' > <draft-ietf-rmonmib-raqmon-framework-14.txt> as a Proposed Standard >- 'Transport Mappings for Real-time Application Quality of Service >Monitoring > (RAQMON) Protocol Data Unit (PDU) ' > <draft-ietf-rmonmib-raqmon-pdu-12.txt> as a Proposed Standard > > There is a potential overlap between the RAQMON protocol and > the IPFIX and/or RTCP-XR work, but there are enough differences > in applicability and complexity that this should not be > a significant issue. RAQMON is an extensible, distributed, > SNMP-based monitoring system, integrated with the RMON > family of MIB modules. As such, it is intended to be applicable > to many different types of protocols, that may run concurrently. > If a specialized protocol for VoIP monitoring is desired, then > RTCP-XR should probably be used instead. If SNMP and/or > RMON integration are not desired, then IPFIX would be a > suitable choice. > >IETF LC ends on 2006-02-13. > >The files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-11.txt >http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-14.txt >http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-12.txt _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Re: LC Review Assignment: RAQMON Joel M. Halpern
- [Gen-art] RE: [RMONMIB] Re: LC Review Assignment:… Romascanu, Dan (Dan)
- [Gen-art] RE: [RMONMIB] Re: LC Review Assignment:… Joel M. Halpern
- [Gen-art] Re: [RMONMIB] Re: LC Review Assignment:… Andy Bierman