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

Andy,

See in line. 

Regards,

Dan



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

Are not we setting the threshold too high? Why require confirmation from three potential implementers? Even in order to advance a standard from Proposed to Draft only two interoperable implementations are required. 

I also doubt that the people following this list can make firm commitments about implementation plans. Even speaking for myself I have good reasons to believe that my employer intents to implement all the options in the RAQMON standard, but I am not authorized to make firm product plans commitments.
 
> 
> 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. 


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

The SNMP notifications mapping was the result of the discussions at IETF56, including the bar-BOF in San Francisco (hard to forget, we were watching the start of the Iraq war on the TV). The intent was to avoid RDSs that already have SNMP on them to use SNMP, instead of supporting the new RAQMON protocol. That's how we got eventually to the current proposal, where a RDS MUST support either the TCP or SNMP transport, while the collectors MUST support both.

Defining the objects as a table rather than group of scalars was chosen because the indices of the table define the reporting session, and possible extensions to RAQMON can be defined easily as extensions of the table. 

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

I am respectfully declaring myself out of this consensus proposal, but as editor will gracefully obey to the decision of the WG. I want to wrap-up this work, it took too long time already. 

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

I am not sure that I understand your question. The address in the index reflects the Receiver Address (RA) field in the PDU. Every MIB object corresponds to a RAQMON PDU field, the MIB being the mapping of the PDU. Can you be more specific on what you see as not being correctly and clearly mapped? 

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

Yes, we can do this and it would be more efficient indeed. The potential problem is that when somebody will define an extension in the future, the indexation may not be unique in the case of multiple sub-sessions running in parallel. By keeping the current indexation it is clear by examining a notification to what session / sub-session the reporting information relates.  

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