Subject: RE: [Sipping] WGLC on RTCP Summary Draft

From: "Amy Pendleton" <[email-masked]>
Date: Thu, 17 Mar 2005 12:24:34 -0500

There were are few comments sent to me as well that I believe will need to
be addressed for the draft.  These comments include:
 
- need to add an quality algorithm type parameter to align with related
standards
- need to permit token extensions to the basic event definition
- need to clean up some minor issues with ABNF definitions
 
I recommend another draft cleanup but I don't believe it should require a
new last call but I am looking for the advice from the WG chairs.
 
I do want to highlight, to respond to Jean Francois and Dan's comments about
the generalization of the service reporting package versus restricting to
RTCP XR for voice only.  This was discussed on the list previously and the
conclusion was that it was not a good idea to restrict the package to voice
only--it will force us to later create an entirely new package, or packages,
for other media types.  The modification of the codec parameters definition
to use SDP lines was meant to address that problem.  I don't see a reason to
change the event definition back to "rtcp xr" just for the purpose of
aligning with related efforts.  We are simply creating more work for the
future.
 
Thanks,
Amy

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, March 14, 2005 2:34 PM
To: [email-masked]; Alan Johnston; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sipping] WGLC on RTCP Summary Draft

> This should have happened about two months ago. I'm sorry.

> Your friendly but only marginally performant working group chairs were  

> just reminded of the fact that the working group agreed in DC to adopt  

> draft-johnston-sipping-rtcp-summary-06.txt as a working group document  

> and proceed to WGLC. I believe we agreed that this would be an  

> informational track document.

> So, I'd like to announce a working group last call, starting  

> immediately, and closing March 16, 2005.

> The draft under discussion is available at:

> http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-
<http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp->  

> summary-06.txt

> As usual, please copy your comments to both the list and the authors.

> And if we've forgotten anything else that you have the good fortune to  

> be able to remember, please have pity and remind us gently.

> -- 

> Dean

Jean-Francois made a set of comments on this draft that I almost integrally
agree with and will try not to repeat. Here are a few more.

1. Even if the document is informative, its technical content is strongly
dependent on RTCP-XR, so I believe that RFC 3611 is a normative reference. 

2. The scope section should mention that the focus of the initial package as
of the RTCP-XR bucket it is based upon is media monitoring specific. 

3. There is a REQ-5 missing in Section 2

4. Section 4 ('Why SNMP is not appropriate) should be taken out. It's simply
wrong technically and politically :-) On the technical side it's wrong
because as Jean Francois pointed, all requirements in Section 2 can actually
be met by SNMPv3 with the proper security model in place. On the 'political'
side - we need to work towards a comprehensive framework for VoIP
performance monitoring, and there is room in this framework for SNMP in some
management applications as RTCP-XR shows, there is a need for svcqual as
this draft demonstrates. 

5. If you want an extra argument in favor of svcqual you should add
scalability (maybe in the requirements list). By avoiding a centralized pull
model, the SIP PUBLISH method allows for a broader scale deployment. 

6. Why do we need a re-definition of most if not all metrics in Section 7.7,
rather than referring RFC 3611, Section 4.7?'  

Regards,

Dan

_______________________________________________
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: "Amy Pendleton" <[email-masked]>
Date: Mon, 21 Mar 2005 13:23:16 -0500

Hi Dan,
 
I was not intending to respond only to your comments on the draft although
it was a response to your email.  My apologies for the confusion.  I am
happy that you agree we should not restrict the draft content to only focus
on voice.
 
I agree that you made some good points and I will now address your comments
and questions now as you suggested:

Amy> I agree.  The reference should be changed in the SIP draft.

Amy> I am not clear on what you are requesting.

Amy> Agreed, should be removed.

Amy> I agree that SNMP is appropriate for some endpoint types but not all.
The point of this section initially was to address the question, "why not
just use SNMP."  I think this section should be editted.  By the way, I
would be interested in helping to work on a performance monitoring framework
both for VoIP and MMoIP.

Amy>  Good point.  Thanks for the input.

Amy> I agree.  Originally this section contained some formatting
descriptions but it is now only focused on definition.  For all of the
metrics which are defined by RFC3611, the defintions should just refer to
that document.  For the metrics that are not defined elsewhere, the draft
should define them. 
 
My question now is what to do to move forward?
 
Regards,
Amy

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2005 11:43 AM
To: Pendleton, Amy [NGC:B601:EXCH]; [email-masked]; Alan Johnston;
[email-masked]; [email-masked]; [email-masked]; Dean
Willis; Rohan Mahy; Gonzalo Camarillo
Subject: RE: [Sipping] WGLC on RTCP Summary Draft

Amy,
 
I did not ask in my comments restricting the RTCP XR package for voice only.
I am OK with the approach that you are taking, but I believe that it is not
documented well enough, since my comments 1, 2, and to a certain extent 6. 
 
As the comments I submitted are WGLC comments submitted within the WGLC
period, I believe that you should answer them one by one, and provide a
suggestion for resolution before stepping ahead in editing a revised version
of the Internet-Draft. This especially as you suggest to skip another WG
draft, which implies consensus in resolving all WGLC comments. 

Regards,

Dan

-----Original Message-----
From: Amy Pendleton [mailto:[email-masked]]
Sent: 17 March, 2005 7:25 PM
To: Romascanu, Dan (Dan); [email-masked]; Alan Johnston;
[email-masked]; [email-masked]; [email-masked]; Dean
Willis; Rohan Mahy; Gonzalo Camarillo
Subject: RE: [Sipping] WGLC on RTCP Summary Draft

 

Thanks,
Amy

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, March 14, 2005 2:34 PM

Regards,

Dan

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 13 Apr 2005 16:23:36 -0600

You wrote:
> I do want to highlight, to respond to Jean Francois and Dan's comments
> about the generalization of the service reporting package versus
> restricting to RTCP XR for voice only.  This was discussed on the list
> previously and the conclusion was that it was not a good idea to
> restrict the package to voice only--it will force us to later create

I need pointers to that discussion, anyone? (then I will continue to argue about it given the ID content :)

> an entirely new package, or packages, for other media types.
I maintain that as defined today, if I were to create metrics to report real-time fax service quality over SIP, I would still need to refine -or- redefine some requirements.

To be specific, based on draft06:
| 7.5  NOTIFY Bodies
|  There are two notify bodies:  a general report and a threshold
|  report.  The general report is used for periodic, mid-call reporting
                                                     ^^^^^^^^
This term is voice specific.

|  and end of call reporting.  The metrics provided by this event are
|  intended to be generically defined to allow both cumulative based and
|  short interval based reporting.
I admit fax is a poor example. But, for fax reporting, I may want to send a report after each fax page or multiple times during a call, each time a page has to be retransmitted.

|  The threshold report is used when call quality degrades.
That again is a pure voice example.
What does "when call quality degrades" mean for a session with a couple of video & audio streams being mixed at the endpoint to degrade? If you loose 1 audio, does that mean a threshold report should be sent? May be, may be not.
My point is: whoever defines such new metrics or additional sub-packages will have to revisit section 7.5 and provide guidance. So I fail to see the argument in favor of genericity in the current text. Then section 7.7 and 7.8 just keep getting into more rtcp xr specifics.
 
| The general
| report is also included in the alert report to provide all of the
| necessary diagnostic information.

| This specification defines a new MIME type application/svcqual which
| is a text encoding of the RTCP-XR statistics, with the addition of a
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These last 2 sentences do not make any sense to me. You choose a new, more generic mime type but kept your focus on RTCP-XR stats... I'd say keep the later focus and just make the language consistent in the doc.

> The
> modification of the codec parameters definition to use SDP lines was
> meant to address that problem.  I don't see a reason to change the
> event definition back to "rtcp xr" just for the purpose of aligning
> with related efforts.  We are simply creating more work for the
> future.
Future will tell, but I personally fail to see this.
Jean-François

> 	Jean-Francois made a set of comments on this draft that I almost
> integrally agree with and will try not to repeat. Here are a few more.
> 
> 	1. Even if the document is informative, its technical content is
> strongly dependent on RTCP-XR, so I believe that RFC 3611 is a
> normative reference.
> 
> 	2. The scope section should mention that the focus of the
> initial package as of the RTCP-XR bucket it is based upon is media
> monitoring specific.
> 
> 	4. Section 4 ('Why SNMP is not appropriate) should be taken out.
> It's simply wrong technically and politically :-) On the technical
> side it's wrong because as Jean Francois pointed, all requirements in
> Section 2 can actually be met by SNMPv3 with the proper security model
> in place. On the 'political' side - we need to work towards a
> comprehensive framework for VoIP performance monitoring, and there is
> room in this framework for SNMP in some management applications as
> RTCP-XR shows, there is a need for svcqual as this draft demonstrates.
> 
> 	5. If you want an extra argument in favor of svcqual you should
> add scalability (maybe in the requirements list). By avoiding a
> centralized pull model, the SIP PUBLISH method allows for a broader
> scale deployment.
> 
> 	6. Why do we need a re-definition of most if not all metrics in
> Section 7.7, rather than referring RFC 3611, Section 4.7?'
> 
> 
> 	Regards,
> 
> 	Dan