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

Please see inline.
Now, considering how much WG was supportive of SNMP and actually very
consistent in this support over many meetings, these questions are at least
surprising.

Cheers.

--Gene

 

 


-----Original Message-----
From: Andy Bierman [mailto:[email protected]] 
Sent: Saturday, January 15, 2005 12: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.  

[Gene Golovinsky] I am not so sure I share "significant valid concerns"
statement. Most of the discussions that I can re-call were not in anyway
objecting to SNMP notification mechanism being implemented in RDS. We are
not talking about RDS running on cell phones only. There are PCs and laptops
that can run software that RAQMON in interested in and we have SNMP agents
on them already. So, adding RAQMON notification is trivial and inexpensive.


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.  

[Gene Golovinsky] I can not make any product commitments or announcements,
but we are management vendor. We have monitoring peaces of software running
on managed servers/nodes. If this node happened to run RAQMON related app
the easiest way for us to define management metrics is RAQMON and to report
them in that manner. It would complicate matters for us a lot if RDS would
not have SNMP

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