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

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.

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.

Anwar


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