Re: 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