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

Andy,

See in-line. 

Regards, 

Dan


> I'm not asking for firm commitments.
...
> I want to avoid a scenario where people dismiss RAQMON (in favor
> of proprietary or other approaches) because it has so much extra 
> baggage they don't need and don't want to implement.  Do you
> really think vendors are going to implement SNMP-transport in
> their collector if none of their own (or foreseeable) products
> plan to use it? What RDSs are they even going to test against?

My company is doing both RDSs and collectors. I believe that we will implement the full RAQMON specification, whatever it ends being. 

> 
> > 
> >> 
> >> 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.
> >> 
> >
> >We do not propose to implement an SNMP notification sender 
> only. We are talking about a full SNMP implementation 
> ('agent'), we just propose that the reporting objects are 
> only 'accessible-for-notify' in order to allow keeping the 
> state in the RDSs beyond the emission of the notifications. 
> 
> This is a notification sender.  It is not a full agent.
> See the thread on event driven polling as well. 

No, it is a full agent. It may have whatever number of objects with read-only and/or read-write MAX-ACCESS. Only the RDS-MIB objects in this table would be accessible-for-notify.  

> 
> 
> 
> 
> >> 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.  
> >
> >Are we bending because of a CLR over CLR discussion? Even 
> this discussion seems to converge towards relaxing the text 
> in the MIB Review Guidelines by replacing the famous 'i.e.' 
> by a 'e.g.' - this being where this whole thread started. 
> 
> No.  See Juergen's objections to this transport.  
> I have heard several times from at least one RAQMON author
> that nobody will implement the SNMP-transport in the RDS and we
> were only doing it to make the "SNMP people" feel happy.
> Look at the list above.  Are you dismissing these technical 
> arguments?  
> Do you believe the SNMP transport is viable and will be used instead 
> of the TCP transport?  If so, why?

All the arguments above are valid arguments for any implementation and deployment of SNMP agents. But if a RDS device has already implemented the SNMP agent, and if it is deployed in an environment where the level of loss because of the UDP transport is acceptable, why should we impose another transport? 

> I know the history.  The SNMP transport was an optimization
> to get around the development of a new protocol, under the assumption
> that it will be easier and faster to get to RFC publication this way.
> Well, now we have a bloated, inefficient, sub-optimal standard
> because of it.  We didn't save any time either, so let's just
> decide on the technical merits.  
> 

I am certainly with you on deciding based on technical merits, but I do not believe that the SNMP solution was just an opportunistic proposal but a rather a realistic one. To me the arguments being brought in this discussion are too much on the line of defending the purity of the SNMP framework, and accepting them would prevent because of 'academic' reasons a very simple and straight-forward application of SNMP for devices that already have implemented SNMP. However, as I already said, I will accept the consensus of the WG. 

> 
> The TCP PDU parameters and SNMP Notification parameters are not the
> same and it is not explained well how they exactly correlate.
> 

I wish you were more specific. Both TCP PDU fields and the objects in the SNMP Notifications refer the framework document. The MIB module definition uses the REFERENCE clauses. Where are the differences? 

>