EditorÕs note:  These minutes have not been edited.


SUMMARY OF ACTION ITEMS:
------------------------------------------------------------------ Jeff Johnson -
- write up the proposed changes to RFC 1650 for 100BASE-T 

------------------------------------------------------------------ Monday 
3/4/96 7:30-10:00pm
------------------------------------------------------------------ 

Meeting agenda (from Dan R's slide):

--implementors' survey
--topology proposal
--open issues in Hub MIB draft
--open issues in MAU MIB draft
--RFC1650 changes


IMPLEMENTORS' SURVEY (Dave Perkins)
------------------------------------------------------------------ Dave 
presented slides of the conclusions from his implementor' survey, and 
noted that hardcopies of the complete results would be available later. 

The conclusions he reached included the following: 

Hub MIB: 8 agent reports returned,
4 app reports returned (2 device vendors, 2 independents) 

Summary--keep: rptrReset, rptrOperStatus, rptrGroupObjectID, 
rptrGroupOperStatus (or remove because of Entity MIB?),
rptrGroupPortCapacity, rptrPortAdminStatus,
rptrPortAutoPartitionState, rptrPortOperStatus,
rptrMonTxCollisions, (all port counters),
(addrTrack objects)
--remove: rptrNonDisruptTest, totalPartitionedPorts, 
rptrGroupDescr, rptrGroupCapacity, rptrHealthText,
rptrGroupLastOperStatusChange, rptrMonitorGroupTotalxxx

[Editor's note:
These conclusions do not entirely agree with the results of our work so 
far. In the latest draft, we had deprecated all of the objects in Dave's 
suggested "remove" list, except for rptrGroupDescr and 
rptrGroupLastOperStatusChange, which are still listed at "current" 
status.] 

SourceAddrChanges is not implemented correctly in 2 out of 8 agents. 
Dave concluded that we should loosen up the description. Others 
present indicated that those implementations are not compliant with 
802.3. [Conclusion: we will discuss this on the mailing list.] 

Traps -- According to Dave's survey, the applications only display 
traps; 
they don't base decisions on them, therefore traps should be removed 
from the MIB. Others had doubts about this approach. Chuck Black 
(HP) indicated that upcoming applications may depend more on traps.

The issue of the usefulness of this MIB in general was revisited. 

Dan listed 3 reasons why RMON has taken off and the Hub MIB hasn't: 
1) lack of support for multiple repeaters; 2) competition between 
vendors kept people from testing interoperability; 3) RMON had new 
technology (alarms, topN). Dan believes there is still value in doing 
this MIB at this time. 

Bob Stewart: RMON is a MIB for a high-level app; this MIB is for low-
level devices. The two MIBs are aimed at different levels of the 
network. 


TOPOLOGY PROPOSAL
(slides from John Flick and Chuck Black, Hewlett-Packard) ------------
------------------------------------------------------ (This proposal was 
first sent to the mailing list before the December IETF, and John had 
made a presentation on it in Dallas. At this meeting, the subject was 
revisited, with the discussion being fueled by a presentation by Chuck 
Black of HP, who works on applications which use this MIB.)

The proposal includes a per-repeater table, by which a manager tells 
the device to watch for a given source address (on all ports). It is useful 
for deducing repeater topology. Chuck presented slides describing, in 
fairly specific terms, the algorithm that could be followed by an 
application using this MIB to do topology mapping. 

A manager uses the MIB to configure the device to "listen" for a 
particular address. The manager then causes several packets to be sent 
from the desired MAC address to/through the target device. Finally, 
the manager queries the device through this MIB to find out what port 
the packets with that source address came in on. 

The agent does NOT need to have a MAC address per repeater (it works 
for multiple repeaters managed by the same agent--i.e., our current 
draft). Chuck didn't know of any configurations where this approach 
doesn't work. It works for subnets (stops at routers). 

Dan questioned whether this presents a problem with customers since it 
requires traffic generation on the network. He noted that the RMON 
WG had an issue with traffic generation. However, that was a replay 
issue. In addition, this MIB is not specifying any traffic generation; the 
manager itself must still cause the traffic to be generated.
Kathy noted that this approach requires write access to the hubs in 
order to map the topology (it's not a passive approach). 

Agent requirements for implementation of this MIB: John F. explained 
that HP had first implemented this entirely in firmware, so it is 
possible to do. He knows of at least two chipsets that have a search 
address register already.
Anybody who has the address table implemented very precisely 
should be able to do this; also some chipsets have a 
sourceAddressChange interrupt. Worst case would be that the NMS 
must poll the lastSourceAddress object. With 100BASE-T, topology 
mapping may not be as involved, since the two-repeater-hop limit 
means not much cascading anyway. 

This MIB is applicable to VG as well; it's already part of the 802.12 
standard. John would like to put this in the VG MIB by having the VG 
MIB reference the table in the repeater MIB. 

Patent issues: HP is to put together an informational RFC. John has 
already submitted a document to Deirdre Kostick, the NM Area 
Director, with this info; the IESG lawyers are currently reviewing it. 
Currently there is no word on the expected timeframe for approval. 

Dan asked if those present had any issues with putting this proposal 
into the next draft, and there were none. [Conclusion: put it into next 
draft -- 1 month from now -- and see how the legal issues shape up. We 
are hoping to have the next draft be the one to go forward as an RFC, 
but if there are any legal issues with this then we'll take it out and 
forward the rest of the MIB as an RFC. Double-check with Deirdre 
about putting it into the draft (Dan?).] 


OPEN ISSUES
---------------------------------

-- rollover time for portTopN counters (there is currently no text in the 
draft; this is the same approach as RMON takes) [Consensus: continue 
to be silent; the draft is ok as is, in this respect.] 

-- use of AUGMENTS in 100BASE-T tables, ifMauAutoNegTable (not 1-
1?) [Kathy understands the edits, and will fix this.] 

-- remove rptrInfoNonDisruptTest?
The input from Dave's survey is that agents don't really implement it. 
[Consensus: remove it]

-- MAU MIB Compliance problems? (both MIBs need 100BT objects in 
separate group)
[Kathy understands the edits, and will fix this.] 

-- auto negotiation/jack MIB? No outstanding issues from those present; 
the current draft appears to be ok. Kathy mentioned that we still need 
to enumerate the jack types; suggestions should be sent to the list ASAP. 

-- Counter64? The group is satisfied with the current state of the draft 
(Counter32/Counter32 pair PLUS Counter64 in a separate compliance 
statement.) 

-- Should we add rptrMonitorPortSymbolErrors into the 
rptrMonitorPortTotalErrors counter? Bob S: add it to description of 
totalErrors, but it's not necessary to deprecate the old total. It's not an 
interoperability issue to add it to the total that is already defined.
[Consensus: use the old total, and change the description] 

-- general issue with deprecated objects: the description field should be 
updated when the status changes. Also, use big letters in the 
descriptions to make the change obvious readers. (Put it first in the 
description)
[Kathy to fix this in the next draft.]

Our expected schedule is: we'll allow 2-3 weeks to discuss our new 
(short?) list of open issues, then issue a new draft. 


RFC 1650 changes
--------------------------------
Dan had sent a request to Deirdre to allow changes to 1650. He received 
her approval for this; however, she would like to know about any 
implementation experience, for the proposed new object(s). This may 
become an issue when the Ethernet-like MIB is considered for promotion 
to draft status. 

The changes we need to make are as follows: -- Add 1 new object: 
dot3StatsSymbolErrors. -- Change wording for sqeTestErrors.
-- Add compliances for 100BASE-T
-- Add chipset definitions for 100BASE-T. 

[Jeff Johnson will draft the changes.]

It was determined that this group did not need another working session 
at this IETF, and the meeting adjourned, with all other business to be 
finished on the mailing list (no sessions planned for Montreal).