Subject: [IETFMIBS] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB

From: Kristine Adamson <[email-masked]>
Date: Fri, 12 Jan 2007 06:07:43 -0700

I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended 
Statistics MIB because I work on an IBM product's SNMP support.  As far as 
I am aware, you may have more than one "augmenting" table which augments a 
base table.  But an augmenting table can not itself be a base table.  I am 
copying the MIB mailing list for any additional feedback. 

So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and 
the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the 
tcpConnectionTable in the TCP-MIB. 

That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's 
tcpConnectionInfoTable, could be moved to one of the tables in the 
TCP-ESTATS-MIB.  We will be looking into implementing the TCP-ESTATS-MIB 
in the future in order to support additional information for TCP 
connections.  Since the TCP-ESTATS-MIB is in the final approval stages, 
maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's 
table in the future, as an updated version of the MIB module.   Or, maybe 
they should be added to the TCP-MIB's  tcpConnectionTable? 

Unfortunately, I don't think any IETF group is working on an extended 
statistics MIB module for UDP endpoints.  If we create a MIB table with a 
general name like, udpEndpointInfoTable, then you would expect that any 
other additional management data for UDP endpoints would be added to this 
table.  Instead, maybe it would be better to either add the UDP Creation 
MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the 
udpEndpointInfoTable to something more specific, like 
udpEndpointCreationTable.
 
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked]

<[email-masked]> wrote on 01/12/2007 02:39:58 AM:

> > Does this conflict with
> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-e
> xtension-14.txt
> > (currently between states in IESG review).
> > 
> > The TCP Extended Statistics MIB also AUGMENTS both the 
> > tcpConnectionEntry and
> > tcpListenerEntry.    I am not enough of a mib person to understand how
> > multiple AUGMENTS clauses might interact.
> 
> I'm not enough of a MIB person either, but I really wish the existence
> of a related v6ops draft had been brought up during WG or at the latest
> IETF Last Call.
> 
> Lars
> -- 
> NEW EMAIL: [email-masked]
> NEW MOBILE: +358 50 48 24461
> NEW JABBER: [email-masked] 

_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietfmibs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2007 14:13:50 +0100

> udpEndpointCreationTable.

It would help people like me who did not follow any of this work if
you can provide us the names of the documents in question.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Kristine Adamson <[email-masked]>
Date: Fri, 12 Jan 2007 06:32:10 -0700

Juergen,
   Sorry for the confusion.  The current draft of the TCP-ESTATS-MIB is 
at:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt

The TCP/UDP Process MIB draft is at:
http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt 

Kristine Adamson

Juergen Schoenwaelder <[email-masked]> wrote on 01/12/2007

---

From: Matt Mathis <[email-masked]>
Date: Fri, 12 Jan 2007 10:57:48 -0500 (EST)

If there is not a technical problem with two tables that AUGMENT the same base
table, I strongly advocate advancing the documents separately.   ESTATS mib is
almost ready for the RFC editor queue.  -mib-issue- is not even a WG item yet,
and may or may not converge quickly.   I really don't want to reopen ESTATS
mib for lots of new revisions at this time.

That said, the issues raised in -mib-issue- are real.  We were aware of them
but (mistakenly?) believed that there did not exist a standardizable OS
independent solution.  I would like to see this work proceed, but not at the
cost of stalling ESTATS.

Thanks,
--MM--

---

From: Anders Persson <[email-masked]>
Date: Fri, 12 Jan 2007 10:22:18 -0800

> independent solution.  I would like to see this work proceed, but not at the
I agree that advancing the documents separately is best way moving 
forward. However, maintaining two separate documents might also lead to 
some objects being duplicated (i.e., creation time).

Anders 
>>>> Statistics MIB because I work on an IBM product's SNMP support.  As
>>>>         
>> far as
>>     
>>>> I am aware, you may have more than one "augmenting" table which
>>>>         
>> augments a
>>     
>>>> base table.  But an augmenting table can not itself be a base table. I
>>>>         
>> am
>>     
>>>> So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB)
>>>>         
>> and
>>     
>>>> the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment
>>>>         
>> the
>>     
>>>> TCP-ESTATS-MIB.  We will be looking into implementing the
>>>>         
>> TCP-ESTATS-MIB
>>     
>>>> connections.  Since the TCP-ESTATS-MIB is in the final approval
>>>>         
>> stages,
>>     
>>>> table in the future, as an updated version of the MIB module.   Or,
>>>>         
>> maybe
>>     
>>>> statistics MIB module for UDP endpoints.  If we create a MIB table
>>>>         
>> with a
>>     
>>>> general name like, udpEndpointInfoTable, then you would expect that
>>>>         
>> any
>>     
>>>> other additional management data for UDP endpoints would be added to
>>>>         
>> this
>>     
>>>> table.  Instead, maybe it would be better to either add the UDP
>>>>         
>> Creation
>>     
>>>> MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename
>>>>         
>> the
>>     
>>> <http://www.eecs.iu-bremen.de/>    P.O. Box 750 561, 28725 Bremen,
>>>       
>> Germany
>>
>>     
>
>