RE: Begin WG Last Call: draft-ietf-rmonmib-raqmon-pdu-09

At 06:12 AM 1/18/2005, Siddiqui, Anwar A \(Anwar\) wrote:
>SNMP transport is an OPTIONAL FEATURE to transport RAQMON PDU. The
>motivation of that came from the fact that IT Managers tend to manage
>Desk Top Applications environments today with SNMP and RAQMON needed to
>fit into that existing environment unlike embedded devices like IP
>Phones or PDAs.

I can't find any text in the specs that mentions this or any
other rationale for the SNMP transport.

This is not optional.  It is mandatory that an RRC support it.



>So it seemed for applications such as Softphones or Collaboration
>clients running Audio, Video, Data sharing on a PC a RDS MIB probably
>would be very useful.

Why? Why will it be used instead of TCP?


>Anwar

Andy



>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On
>Behalf Of Andy Bierman
>Sent: Saturday, January 15, 2005 1:05 PM
>To: [email protected]
>Subject: Re: [RMONMIB] Begin WG Last Call:
>draft-ietf-rmonmib-raqmon-pdu-09
>
>At 06:14 PM 1/8/2005, Andy Bierman wrote:
>>Hi,
>
>I want to get confirmation from at least 3 potential RAQMON 
>implementors that they plan to support the SNMP Notification 
>transport in their RDS implementation.
>
>There are significant valid concerns that have been raised
>regarding the use of SNMP, SNMP notification sender only (w/o 
>a command responder), and UDP, for RDS to RRC communication.
>
>It seems that the SNMP transport mapping is inferior to the 
>TCP transport mapping in every possible way:
>  - code size
>  - encoding size
>  - complexity
>  - congestion control
>  - proper use of the (transport) protocol
>
>If nobody plans to develop an SNMP-based RDS, then we don't
>need to standardize it.  If you want to keep the SNMP Notification
>transport, then speak up during this WG Last Call.  
>
>I have yet to hear of any plans to support this feature.  In fact,
>I have only heard objections to it.  So I am declaring the WG 
>consensus to be that the SNMP notification transport should be 
>removed from RAQMON.  
>
>Related (but perhaps soon-to-be irrelevant) issues:
>
>1) I am wondering why the raqmonPeerAddrType and raqmonPeerAddr 
>   need to be in the INDEX.  This is very inefficient.
>   Why doesn't the SNMP PDU follow the TCP PDU fields?  
>   It's not clear in the document which MIB objects correspond to 
>   which BASIC PDU parameter numbers.  Not every parameter is
>   source or dest related. How is the address in the INDEX clause
>   apply to session-related parameters?
>
>2) Why is raqmonAppName the required parameter in every notification?
>   This is inefficient.  Why not take raqmonRCN out of the INDEX and
>make
>   that the mandatory parameter?
>
>>The RMONMIB WG has completed work on the Real-time Application 
>>Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU).
>>
>>The WG proposes that the I-D 'draft-ietf-rmonmib-raqmon-pdu-09.txt' 
>>is the completed version of this document.  This document addresses
>>issues raised on the mailing list and also at the IETF #61 meeting.
>>
>>The WG members are strongly urged to review this document as 
>>soon as possible, and express any concerns, or identify any errors,
>>in an email to the RMONMIB WG mailing list.
>>
>>Unless there are strong objections, published on the RMONMIB WG mailing
>>list by January 23, 2005, this document will be forwarded to the OPS 
>>Area Directors for standards track consideration by the IESG.
>>
>>Please send all comments to the WG mailing list at [email protected].
>>
>>Andy
>
>Andy
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib