Subject: [Sipping] RAQMON I-Ds Last Call

From: Henry Sinnreich <[email-masked]>
Date: Mon, 08 Nov 2004 21:54:16 -0600

Three excellent I-Ds for RAQMON are on last call in the RMONMIB WG: 

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqmon-
framework-07.txt

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqmon-
pdu-07.txt

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqmon-
mib-05.txt

This is very thorough work and should be made available to the Internet
community as INFORMATIVE RFCs IMHO. The reason why informative ONLY is
recommended is that application specific reporting, such as for VoIP, IM or
SMS messaging, etc. may be application targeted and service providers or IT
managers should not be mandated to use this SNMP based approach, where other
techniques are preferable. The specific approach should be the choice of the
service provider, IT group and the application vendor, for example a desktop
office suite enabled with real time communications or IM and presence SLA
may not need SNMP. 

An example of a VoIP targeted approach is

http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-04.t
xt

This proposal is based on the experience of deploying and monitoring large
numbers of personal IP telephony devices, such as SIP phones and PC soft
phones. Other approaches may emerge as well. How do we monitor all the
communication enabled applications on the PC for example, now that every
application, for example in Microsoft Office (Word, PowerPoint, Outlook,
Access are SIP/SIMPLE enabled, besides the Windows Messenger and
Conferencing/Collaboration, etc.)?

In summary, the RAQMON I-Ds are ready for last call, but should NOT be the
only mandated approach. I suggest some additional wording to be added to
make this point clear.

I have copied here the co-authors of the proposal for the RTCP Summary in
case the issue of normative vs. informative RAQMON RFCs needs to be
discussed on the list.

Thanks, Henry

Henry Sinnreich
MCI
1201 E. Arapaho Rd./Office 1020
Richardson, Texas 75081
USA

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 9 Nov 2004 15:38:55 +0200

Henry,

Thank you for your message, and for reading and commenting on the RAQMON drafts. 

I am not sure what you mean when you say that RAQMON is 'SNMP-based'. Do you refer to the transport of the RAQMON PDUs? I agree with you that one single transport method for the performance monitoring information should not be mandate in complex multi-application environments. Exactly for this reason RAQMON does not mandate SNMP as a transport, but offers another choice that is mapping RAQMON PDUs over TCP. 

If you refer to the RAQMON MIB, RAQMON indeed provides an SNMP MIB interface for the collectors, which are entities that aggregate information from many data sources (endpoints for example). SNMP MIBs are developed for all the RMON family of protocols, and RAQMON is part of the RMON performance monitoring. Same RTP, SIP, etc. have standard track MIB modules. 

The RMON MIB WG has RAQMON in its charter as a standard track item. At the end of the day, it is the IESG who decides what status the documents will receive. SNMP MIBs are the approach recommended by the Operation and Management Area to retrieve management information, especially when it comes to performance monitoring. As I said I agree with you that multiple methods are required, but my opinion is that RAQMON should be standards track. 

I would invite you and the other interested parties to attend the RMON WG meeting on Thursday. RAQMON is the main item on the agenda, and the WG would like to wrap up this work 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Henry Sinnreich
> Sent: 09 November, 2004 5:54 AM
> To: [email-masked]; [email-masked]
> Cc: 'Johnston, Alan'; 'Alan Clark'; 'Amy Pendleton'
> Subject: [Sipping] RAQMON I-Ds Last Call
> 
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 09 Nov 2004 08:59:04 -0600

Thanks to all for your patience with this last minute discussion! The main
points I wanted to make:

- This is good work,

- There is more than one single approach for monitoring QoS for services and
applications, and we should offer the market some choices.

Thanks again, Henry

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, November 09, 2004 7:39 AM
To: Henry Sinnreich; [email-masked]; [email-masked]
Cc: Johnston, Alan; Alan Clark; Amy Pendleton; Bert Wijnen (E-mail)
Subject: RE: [Sipping] RAQMON I-Ds Last Call

Henry,

Thank you for your message, and for reading and commenting on the RAQMON
drafts. 

I am not sure what you mean when you say that RAQMON is 'SNMP-based'. Do you
refer to the transport of the RAQMON PDUs? I agree with you that one single
transport method for the performance monitoring information should not be
mandate in complex multi-application environments. Exactly for this reason
RAQMON does not mandate SNMP as a transport, but offers another choice that
is mapping RAQMON PDUs over TCP. 

If you refer to the RAQMON MIB, RAQMON indeed provides an SNMP MIB interface
for the collectors, which are entities that aggregate information from many
data sources (endpoints for example). SNMP MIBs are developed for all the
RMON family of protocols, and RAQMON is part of the RMON performance
monitoring. Same RTP, SIP, etc. have standard track MIB modules. 

The RMON MIB WG has RAQMON in its charter as a standard track item. At the
end of the day, it is the IESG who decides what status the documents will
receive. SNMP MIBs are the approach recommended by the Operation and
Management Area to retrieve management information, especially when it comes
to performance monitoring. As I said I agree with you that multiple methods
are required, but my opinion is that RAQMON should be standards track. 

I would invite you and the other interested parties to attend the RMON WG
meeting on Thursday. RAQMON is the main item on the agenda, and the WG would
like to wrap up this work 

Regards,

Dan

> This is very thorough work and should be made available to the 
> Internet community as INFORMATIVE RFCs IMHO. The reason why 
> informative ONLY is recommended is that application specific 
> reporting, such as for VoIP, IM or SMS messaging, etc. may be 
> application targeted and service providers or IT managers should not 
> be mandated to use this SNMP based approach, where other techniques 
> are preferable. The specific approach should be the choice of the 
> service provider, IT group and the application vendor, for example a 
> desktop office suite enabled with real time communications or IM and 
> presence SLA may not need SNMP.
> 
> This proposal is based on the experience of deploying and monitoring 
> large numbers of personal IP telephony devices, such as SIP phones and 
> PC soft phones. Other approaches may emerge as well. How do we monitor 
> all the communication enabled applications on the PC for example, now 
> that every application, for example in Microsoft Office (Word, 
> PowerPoint, Outlook, Access are SIP/SIMPLE enabled, besides the 
> Windows Messenger and Conferencing/Collaboration, etc.)?
> 
> In summary, the RAQMON I-Ds are ready for last call, but should NOT be 
> the only mandated approach. I suggest some additional wording to be 
> added to make this point clear.
> 
> I have copied here the co-authors of the proposal for the RTCP Summary 
> in case the issue of normative vs. informative RAQMON RFCs needs to be 
> discussed on the list.
> 
> Thanks, Henry
> 
> Henry Sinnreich
> MCI
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>