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

From: "Alan Clark" <[email-masked]>
Date: Wed, 6 Apr 2005 09:32:11 -0400

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

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

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 6 Apr 2005 16:00:30 -0400

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

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

Regards

Alan

--
525
but
270
in
in

---

From: Mark Baugher <[email-masked]>
Date: Thu, 7 Apr 2005 06:04:25 -0700

Alan
    The RTP MIB was in the RFC editor's queue at the same time as RFC  
2851.  Inet, therefore, was not the preferred approach during the time  
that the RTP MIB was written and underwent review.  Regarding the MIB  
compiler errors, the RTP MIB was compiled using SMIC with each revision  
from 1998-2000.  The IETF requires that a MIB to compile without errors  
or warnings before it is published as an Internet standard.  I believe  
SMIC was used, but all of this was done about five years ago.  Please  
refer to the AVT archives if you have questions regarding the RTP MIB  
process.

   The Proposed Standard RTP MIB was reviewed by groups from two  
standards bodies (the IETF and ITU), referenced in the H-MIB standard,  
and implemented in a publicly-available reference implementation.  I  
have been asked to do an industry survey of who has implemented the MIB  
but I don't have time to do that.  I think it's well documented that  
the RTP MIB met the standards of the IETF MIB process at the time, in  
2000.  I have to say that your process of evaluating the RTP MIB  
_after_ completing work on another RTP-related MIB seems quite  
backwards to me.

    At this point, I think AVT should not be be discussing MIB compiler  
errors.  I think we should be deciding what the RTP systems management  
strategy should be - we don't seem to have one anymore.  Should we  
instrument the protocol in its entirety or just the parts needed by  
specific applications?  I had taken the former approach years ago, but  
my question isn't rhetorical.  There But no one has made the case for  
such a strategy.  It's how product teams often work, particularly if  
they are organized around selling an application solution to customers.  
  I can't fault them for that.  But some body has to look after the  
entire protocol.  That's AVT.

   I hear that customers have a great need for this solution - right  
now.  But the "code first and think later" method to development  
usually takes a lot longer than starting with a well thought out design  
and following it consistently.

Mark

---

From: "Alan Clark" <[email-masked]>
Date: Thu, 7 Apr 2005 10:13:18 -0400

Mark

Whatever happened to "rough consensus and running code" ;-)

I'm not criticizing what was done on the RTP MIB but just pointing out that
the revisions needed are both fairly extensive and would also result in the
rtpSession table turning into the RTCP XR MIB session table.

I'm also hoping to get opinions from other parties than you and I on the way
forward.

Regards

Alan

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 9:04 AM
To: Alan Clark
Cc: Avt@Ietf. Org
Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

Alan

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 7 Apr 2005 08:08:05 -0700

Alan,

> Whatever happened to "rough consensus and running code" ;-)

It has become "running code and rough consensus."  I should clarify  

> and following it consistently.

This is an AVT issue and not an Alan & RTCP XR team issue IMHO.  We  
should have resolved the relationship between the two MIBs before RTCP  
XR MIB became an AVT work item.  Personally, I watched this parade go  
by without saying anything until the question was asked.  Now we have  
an additional complication:  What needs to be changed in RTCP XR  
implementations?  We should have resolved the relationship question  
before this point.

> rtpSession table turning into the RTCP XR MIB session table.

A MIB will need to be updated when it moves from Proposed to Draft  
Standard if for no other reason than the fact SNMP is changing over  
time.  Before spending a lot of time delving into these details, I  
think we need rough consensus on RTP management direction.  If AVT  
decides to instrument RTP on an application-by-application basis rather  
than as a system, then the issues you raise are moot.  There might be  
very good reasons, by the way, to do things on an application basis.   
I'm not the one to make that case.  Saying that a lot of changes need  
to be made to the RTCP XR MIB to make it compatible with the RTP MIB,  
or vice versa, does not make the case.

> I'm also hoping to get opinions from other parties than you and I on  

I'm hoping to hear why we should instrument RTP on an application basis  
rather than as a system.

Mark
>>> --------------------------------------------------------------------- 
>>> -
>>> ----
>> --
>>> ----------------
>>>

---

From: "Alan Clark" <[email-masked]>
Date: Thu, 7 Apr 2005 11:22:46 -0400

Mark

The issue of the relationship between the RTP MIB and the XR MIB has been
discussed from time to time both on the list and in AVT meetings.  I also
posted a request on the AVT mailing list on 10th November asking for
specific comments on what needed to be updated in the RTP MIB and did not
get a response from anyone, including you.

I must admit to being somewhat puzzled at your admission that "I watched
this parade go by without saying anything until the question was asked" -
this does not seem to be particularly helpful.  Does this mean that you were
waiting until the XR draft was approaching last call before you elected to
raise comments?

Regards

Alan

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 11:08 AM
To: Alan Clark
Cc: Avt@Ietf. Org
Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

Alan,

Mark

---

From: Colin Perkins <[email-masked]>
Date: Thu, 7 Apr 2005 16:30:09 +0100

Mark, Alan,

On 7 Apr 2005, at 16:22, Alan Clark wrote:
> this does not seem to be particularly helpful.  Does this mean that 
> you were waiting until the XR draft was approaching last call before 
> you elected to raise comments?

Arguing about who did what when doesn't seem productive. Can we please 
focus on how to move forward, without arguing over history?

Colin

---

From: "Alan Clark" <[email-masked]>
Date: Thu, 7 Apr 2005 11:39:07 -0400

Colin

Point taken .. and I would welcome responses to my posting of yesterday
which outlined the situation and the potential solutions.

Regards

Alan

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 11:30 AM
To: Alan Clark
Cc: Mark Baugher; Avt@Ietf. Org
Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

Mark, Alan,

Colin