Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 4 Apr 2005 18:36:59 +0200

Alan,

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Alan Clark
> Sent: 04 April, 2005 7:19 PM
> To: David R Oran
> Cc: Magnus Westerlund; Colin Perkins; Mark Baugher; Avt@Ietf. 
> Org; Amy Pendleton
> Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB
> 
> 
> Dave
> 
> 1. It complicates the situation - for example - I know of one 
> networking
> company that is implementing only the RTCP XR MIB history 
> table and not the
> individual call/session tables.  Hence there would be some 
> circumstances in
> which you would need to implement the RTP MIB and some where 
> you wouldn't?

The question is what we would like the standard to require for compliance. We need not accommodate all vendors implementation if we believe that the standards threshold needs to be hold higher. 

> 
> 2. The fact that both share the SSRC and "some" parameters is not a
> sufficient reason to implement ALL of the RTP MIB .. for example IP
> addresses and UDP ports are implemented independently by many 
> MIBS?  Is the
> right answer to update the RTP MIB to expose some of the 
> parameters (e.g. as
> TCs) ?

The compliance clauses of RTCP-XR can be defined so that they require only partial implementation of the RTP MIB. Of course, the respective implementation will not be able to claim compliance with the RTP MIB, if it did not implement all mandatory compliance clauses defined there. 

> 
> 3. The RTCP XR MIB is, in the same sense as the VoIP Metrics 
> block within
> RFC3611, targetted at VoIP management and not at more general 
> RTP session
> monitoring.  Maybe we need to think of it as the VoIP Metrics MIB?
> 
> Regards
> 
> Alan
> 
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 7 Apr 2005 19:01:50 +0300

I have no strong opinion for now, but is there not a 4th option? Update the RTP MIB with the necessary changes as described in Alan's mail and some more that may be required? This would imply recycling to Proposed, but we will have a document at the required level of quality, and in full synch with the RTCP XR MIB 

Regards,

Dan

> Sent: 06 April, 2005 11:01 PM
> To: Avt@Ietf. Org
> Cc: Magnus Westerlund; Colin Perkins; Amy Pendleton
> Based on a comparison of the RTP MIB with the RTCP XR MIB it 
> appears that
> the RTP MIB does require a significant update in the areas 
> that are common
> to both, hence the issue of RTP MIB vs RTCP XR MIB is not 
> just one of making
> the XR MIB point back to the RTP MIB.
> 
> RTP MIB session table changes needed are at least:-
> 
> - the table index needs to be changed to Unsigned32
> - the IP addresses and Ports need to be changed from the 
> TDomain/TAddress
> form to the Inet form used by the XR MIB
> - it makes sense (IMHO) to change the call state object in 
> the RTP MIB to
> the form used in the latest version of the XR MIB that allows 
> this to be
> used as a table index - this breaks the table into a 
> non-overlapping set of
> active sessions and completed sessions
> - the joins/ leaves/ Byes objects should be moved out of the 
> RTP MIB session
> table to a table specific to multicast
> - the RTP MIB does have a start time but not an end time
> 
> Basically if these changes are made then the basic session 
> table of the RTP
> MIB has been completely changed to be identical to the basic 
> session table
> of the RTCP XR MIB.
> 
> This suggests three potential courses of action:-
> 
> (1) Leave things as they are
> 
> (2) Update the RTCP XR MIB with an inverse session table and 
> then use this
> to obsolete the RTP MIB
> 
> (3) Leave the RTP MIB as-is, but provide a row pointer in the 
> XR MIB to
> point to the corresponding row of the RTP MIB
> 
> Does anyone have an opinion on the relative merits of these 
> three options -
> and any specific recommendations related to the 
> implementation thereof?
> 
> Regards
> 
> Alan Clark
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Alan Clark
> Sent: Wednesday, April 06, 2005 9:32 AM
> To: David R Oran; Mark Baugher
> Cc: Avt@Ietf. Org
> Subject: FW: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB
> 
> 
> 
> Dave, Mark
> 
> I am starting to analyze the differences between the RTP MIB
> and RTCP XR MIB.  As a first step I ran the RTP MIB through a 
> couple of MIB
> validation tools - reports below.
> 
> The RTP MIB uses the TDomain/ TAddress concept, which was 
> superceded by
> TransportAddress/ TransportDomain.  In the RTCP XR MIB we used the
> InetAddress approach (RFC2851) which I understand is the 
> preferred approach
> for representing layer addressing.  The TAddress approach 
> provides an Octet
> String that has to be interpreted according to the TDomain 
> type .. the Inet
> approach simply presents IP Address and Port as two separate 
> objects.  Can
> you explain why the TDomain approach has merit over the Inet 
> approach - or
> should we re-write the RTP MIB to use Inet?
> 
> Regards
> 
> Alan
> 
> >
> > 
> --------------------------------------------------------------
> ------------
> --
> > ----------------
> >
> > Validation report - SMILINT
> > File: RTPMIB.mib
> >
> > Line  Severity  Problem
> > 109 5 index of row `rtpSessionInverseEntry' can exceed OID 
> size limit by
> 525
> > subidentifier(s)
> > 202 6 index element `rtpSessionDomain' of row 
> `rtpSessionInverseEntry'
> > should but cannot have a size restriction
> > 6 index element `rtpSessionDomain' of row 
> `rtpSenderInverseEntry' should
> but
> > cannot have a size restriction
> > 6 index element `rtpSessionDomain' of row 
> `rtpRcvrInverseEntry' should but
> > cannot have a size restriction
> > 357 5 index of row `rtpSenderInverseEntry' can exceed OID 
> size limit by
> 270
> > subidentifier(s)
> > 448 5 `TAddress' object should have an accompanied `TDomain' object
> > 507 6 use Integer32 instead of INTEGER in SMIv2
> > 544 5 index of row `rtpRcvrInverseEntry' can exceed OID 
> size limit by 271
> > subidentifier(s)
> > 655 5 `TAddress' object should have an accompanied `TDomain' object
> > 731 6 use Integer32 instead of INTEGER in SMIv2
> >
> > -----------------------------------------------------
> > Validation report - MIB Smithy
> >
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : INDEX object
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128
> > subidentifier maximum. No refinements possible.
> >
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : INDEX object
> > 'rtpRcvrAddr' value may exceed maximum of 128 
> subidentifiers for OBJECT
> > IDENTIFIER length by 128 subidentifier(s).
> >
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : All 
> INDEX objects in
> > this table are auxiliary (i.e., from other tables).
> >
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : INDEX object
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128
> > subidentifier maximum. No refinements possible.
> >
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : INDEX object
> > 'rtpSenderAddr' value may exceed maximum of 128 
> subidentifiers for OBJECT
> > IDENTIFIER length by 128 subidentifier(s).
> >
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : All 
> INDEX objects
> in
> > this table are auxiliary (i.e., from other tables).
> >
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128
> > subidentifier maximum. No refinements possible.
> >
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object
> > 'rtpSessionRemAddr' value may exceed maximum of 128 
> subidentifiers for
> > OBJECT IDENTIFIER length by 128 subidentifier(s).
> >
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object
> > 'rtpSessionLocAddr' value may exceed maximum of 128 
> subidentifiers for
> > OBJECT IDENTIFIER length by 128 subidentifier(s).
> >
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : All 
> INDEX objects
> in
> > this table are auxiliary (i.e., from other tables).
> >
> > 0 error(s), 10 warning(s)
> >
> 
> 
>

---

From: "Amy Pendleton" <[email-masked]>
Date: Fri, 8 Apr 2005 14:39:20 -0400

I want to voice my opinion on the issue of relationship between these MIB's
and the requested reference to the RTP MIB from the new RTCP XR MIB.

The RTCP XR MIB is designed to fulfill real vendor and customer requirements
for an open standard mechanism that enables RTCP XR metric reporting to
their network management systems so the metrics can be used to diagnose
service quality and network problems.  As it stands today, a number of
vendor's products are supporting proprietary versions of this MIB ahead of
the open standard.  While offering implementations ahead of standards is
fairly typical, and necessary due to standards bodies politics, it is not
something customers and network management vendors like to do long term.  

I agree that the RTP MIB has problems and needs to be cleaned up, but I do
not wish to continue delaying a very important draft just to prevent a small
amount of overlap in field content. I fail to see the value in providing
references between the two MIBs.

My choice would be to leave things as they are: separate MIBS. 

Thanks,
Amy Pendleton

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, April 07, 2005 11:02 AM
To: Alan Clark; Avt@Ietf. Org
Cc: Magnus Westerlund; Colin Perkins; [email-masked]
Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

I have no strong opinion for now, but is there not a 4th option? Update the
RTP MIB with the necessary changes as described in Alan's mail and some more
that may be required? This would imply recycling to Proposed, but we will
have a document at the required level of quality, and in full synch with the
RTCP XR MIB 

Regards,

Dan

> Based on a comparison of the RTP MIB with the RTCP XR MIB it appears
> that the RTP MIB does require a significant update in the areas
> that are common
> TDomain/TAddress form to the Inet form used by the XR MIB
> Basically if these changes are made then the basic session table of
> the RTP MIB has been completely changed to be identical to the basic
> session table
> of the RTCP XR MIB.
> 
> (2) Update the RTCP XR MIB with an inverse session table and then use
> this to obsolete the RTP MIB
> 
> (3) Leave the RTP MIB as-is, but provide a row pointer in the XR MIB
> to point to the corresponding row of the RTP MIB
> 
> Does anyone have an opinion on the relative merits of these three
> options - and any specific recommendations related to the
> implementation thereof?
> 
> Regards
> 
> Alan Clark
> 
> 
> I am starting to analyze the differences between the RTP MIB and RTCP 
> XR MIB.  As a first step I ran the RTP MIB through a couple of MIB 
> The RTP MIB uses the TDomain/ TAddress concept, which was superceded
> by TransportAddress/ TransportDomain.  In the RTCP XR MIB we used the
> > 507 6 use Integer32 instead of INTEGER in SMIv2 544 5 index of row 
> > `rtpRcvrInverseEntry' can exceed OID
> size limit by 271
> > subidentifier(s)

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 10 Apr 2005 17:28:46 +0300

Amy,
 
I cannot agree with your choice for several reasons:
 
1. RTP is the principal protocol developped by this WG, while RTCP XR is an extension. For this reason it is mandatory that the RTCP XR MIB document refers to the relation to the RTP MIB. Now this reference could say in theory 'There is no relation between the RTCP XR MIB and the RTP MIB', but ...
> the XR MIB point back to the RTP MIB. 
3. Beyond the structure relation there is another relation derived from the fact that the RTP MIB and the RTCP XR MIB may be deployed in the same network. Having a pre RFC 3550 RTP MIB, while the RTCP XR MIB is post RFC 3550 is inconsistent. This aspect was discussed and agreed by the WG as soon as the first RTCP XR submission was presented to the WG. 
4. Last but not least this WG has chartered the RTP MIB revision and the RTCP XR MIB to be completed together. Instead of wasting our energy with this long discussion I would advice that we work on the RTP MIB update and finish it in time, so that the RTCP XR MIB is not further delayed.  

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Amy Pendleton
Sent: 08 April, 2005 9:39 PM
To: Avt@Ietf. Org
Cc: Magnus Westerlund; [email-masked]; Romascanu, Dan (Dan)
Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

I want to voice my opinion on the issue of relationship between these MIB's and the requested reference to the RTP MIB from the new RTCP XR MIB.

The RTCP XR MIB is designed to fulfill real vendor and customer requirements for an open standard mechanism that enables RTCP XR metric reporting to their network management systems so the metrics can be used to diagnose service quality and network problems.  As it stands today, a number of vendor's products are supporting proprietary versions of this MIB ahead of the open standard.  While offering implementations ahead of standards is fairly typical, and necessary due to standards bodies politics, it is not something customers and network management vendors like to do long term.  

I agree that the RTP MIB has problems and needs to be cleaned up, but I do not wish to continue delaying a very important draft just to prevent a small amount of overlap in field content. I fail to see the value in providing references between the two MIBs.

Thanks, 
Amy Pendleton