Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ifmib/ifmib-minutes-96jun.txt

Text File | 1996-10-07 | 12KB | 306 lines

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


Monday, June 24 1300-1500
Interfaces MIB
draft-ietf-ifmib-mib-03.txt
dated: 22 February 1996

Issues discussed and resolutions taken:

(1) IANA:assignments/smi-numbers: g703-2mb marked obsolete.

A message has been sent to IANA to properly edit the smi-assignments
documents available on their server. The working group chair will get
back to the WG as that is cleared up.

Suggestion that a URL for the SNMP MIB Module, IANAifType-MIB
stored at IANA be included in the RFC.
Problem that URL is not permanent.

Conclusion: a discription of how to reach IANA will be included in the
RFC as a pointer.


(2) downBecauseOfDependancy.

General support for this functionality on list and in the group. Question
of why is this not in an additional variable, since it is a sort of "hint"
or "probable cause". Pursuing the probable cause notion was deemed too
complex.

Why in the ifOperStatus? The answer is that the definition of down is
ifAdminStatus=up combined with ifOperStatus=down. Making a
change anywhere else leaves interface explicitly in down state.

Conclusion: Adopt the state.
The name of the state is up to the documents editor. This state sends
traps exactly as if it is the down state, so if ifLinkUpDownTrapEnable
is on, the if will generate traps on transition to down or downBecause.
This state is required.

(3) ifIndex consistancy requirements. columnar failures and renumbering.
what to do?

This was a highly contentious issue.

The working group felt that renumbering interfaces was an expensive
operation and wanted to avoid it whenever possible.

A common renumbering case was called out for attention: version (1) an
interface card holds the counter values onboard; it breaks and is hot-
swapped with another. version (2) a software interface module holds
counter values in itself; it dies and a new instance is spawned.
RFC 1573 states that when counter values are discontinuous the ifIndex
must be changed.
One observation is that modern interfaces are more complex than
previous interfaces. Hot-swapping and layered software interfaces are
especially difficult, since they can come and go.

The notion of an interface sysUpTime was discussed extensively. (The
name ifSysUpTime was used, though later, timeticks syntax was
rejected in favor of a timestamp syntax object. I have named it
ifCounterDisconTime here.)

The issue of current practice was considered. It was asserted that many
agents do not renumber interfaces when they are required, but simply
restart counters. The point was made that ifCounterDisconTime is a
"legalization" of this practice.

When can an interface ifCounterDisconTime be reset? Conflict between
managers if interface counters are reset at whim. Feeling in the group
that reseting counters should only be allowed in circumstances beyond
the agents control. Does this include reset by a human?

Opposing positions:
This use of ifCounterDisconTime does not eliminate interface
renumbering. It only avoids it in some situations.

The policy question was raised - what does the ifIndex value really
mean. Is it the slot? is it the card? is it the WAN link to Chicago? Only
ifAlias is constant and is operator supplied. So what is the point of
keeping ifIndex values?

What is the core of an interface?
What can change about an interface before the ifIndex changes? The
list was not fully determined.
ifType? no.
ifConnectorPresent? no.
ifAlias, ifName, ifSpeed, ifPhyAddress? yes?

The issue of obsoleting all interface mib counters was raised. Counters
timestamped with ifCounterDisconTime seem a redefinition.
Possibility of different base, with a timestamp syntax, for a counter is
explicitly allowed in RFC 1902, but existing mibs do not specify - rather
they assume sysUpTime.

The WG chair observed that a change of this sort could keep the
interfaces mib from progressing to draft and would force it to cycle at
proposed.

The NM Area director spoke about the delays which would be
experienced by other mibs dependent on the interfaces mib and which
are going to draft themselves. (Note: A draft mib cannot depend on a
mib a proposed.) She also stressed the need to keep from obsoleting
existing MIBs.

An explicit poll was taken of members of the working group whether
they support this change.

Agent implementers speaking in favor of ifCounterDisconTime: RAD,
Nexion, cisco, Shiva, Newbridge, DEC, IBM.

Snmp engine vendors speaking in favor of ifCounterDisconTime: Peer.

Network Management Station implementors spoke: IBM - the amount of
data kept would be the same per counter, its just that the counter is
assumed to be from sysUpTime. Cabletron - be sure there is a good
migration strategy.

Conclusion of the WG Chair up to this point: Because we explicitly
discussed this and decided not to do it one year ago when we had the
mib open for major surgery; Because this working group claimed it was
just going to wrap up details in this meeting and WG members may not
have attended, Because there was an RMON meeting running at the
same time as interfaces mib and WG members may have been split;
Because ifCounterDisconTime does not represent the consensus of the
WG members present, notably absent from consensus are the WG chair
and the document editor,
The WG Chair decided that the WG as a whole must be better drawn
into the discussion for this sort of change to move forward.


(4) ifPhysAddress with MAX-ACCESS r/w and MIN-ACCESS r/o?

Conclusion: No change. It was not felt that enough interfaces have
writable phyAddresses to warrent inclusion as a standard.

(5) ifSpeed and asymmetric interfaces (not one way). eg. ADSL, cable-
modems.

The ADSL interest group defined ifSpeed to be the outgoing speed of an
interface, and defined two objects for incoming and outgoing speed in
their proprietary interface.

Conclusion: Do not change mib. Have asymmetric interfaces follow
technique of ADSL.




Wednesday, June 26 1930-2200
============================


(3) ifIndex consistancy requirements. columnar failures and renumbering.
what to do?

Reconsidered. This was still a highly contentious issue.

The WG chair asserted that the WG must make a choice between
imperfect options:

Option a) simply relax the renumbering requirement, without doing
anything else.
(a) was never even considered. It didn't fix anything.

Option b) define ifCounterDisconTime, and put it in a separate
document
at proposed. Move the interfaces mib to draft. (b) was rejected as
bureaucratic subterfuge, and the timestamp effectively changes the
semantics of the existing counters.

Option c) reuse ifLastChange for the purpose of this timestamp. (c) was
rejected as overloading an existing object semantics.

Option d) put a timestamp in the Enity Mib for logical and physical
entities. (d) was considered. The feeling was that the mapping to the
entity mib objects was too complex, and that it unfortunately mandated
the implementation of the entity mib in order to use the interfaces mib.

Option e) No! we can't make this change! (e) was proposed by the WG
chair, but didn't catch on. The feeling emerged that if we were to design
the interfaces counters all over again, we would use a technique such as
this. This became an overwhelming arguement in favor of doing it now.
Otherwise, the feeling went, we would make this same change a year
from now, with far greater cost.

Option f) define ifCounterDisconTime, and cycle the interfaces mib
at proposed. Define all new counter OIDs. (f) was discussed at length,
but modified.

Are we "matching the specification to the implementation" by
recasting the scope of renumbering?
This was seen as pragmatic standards making. In contrast "codification
of practice" had less support. A question of implementation was raised:
several vendors said yes, they still have counters implemented that
reset yet keep the same ifIndex value: cisco, Ascom, Newbridge.

So the question became "is this really the best technical solution"? And
by extension "is this the solution we want cloned in other mibs"? There
were no dissenting opinions.

Next question: "is this really a counter problem rather than and
interfaces mib problem"?
The answer was yes, this is a general counter problem. The Data Link
Switching (DLSw) MIB was offered as an example where the circuits
are, in effect, timestamped. The Hub MIB was another example of
timestamping.

It turns out that a timestamp per counter with a optional clause in the
OBJECT-TYPE, was suggested during the SNMPV2 discussion. Called
"Reference Time" it was abandoned in RFC 1902, because of the
difficulty is specifying in ASN.1 which field of the indexing variables
identifies the timestamp.

Without such special clause, the only other place to identify the
timestamp is in the discription clause.

A poll of WG members present was taken. Who builds management
applications? What do you think about counters that rely on a per
interface timestamp? Expressing comfort with such a thing were: RAD,
Ascom Timeplex. Expressing some concern was: Ascom Nexion.

The WG Chair decided that it was necessary to poll the ifmib list for
other management application builders who may be affected, in order
to get their input.

The issue of new OIDs for the interfaces counters was discussed. It was
flatly held to be not acceptible. When asked if new OIDs are required
by MIB rules, if the semantics of counters are bent to this degree, the
working group effectively said
"No we don't think so. The `evolution' of the interface values in
RFC1573 did not require new OIDs, so this should not either."

Issue of draft status was discussed.
There is no interoperability experience with these sort of counters.
Several vendors did not think this would be difficult to arrange
however, since many counters reset now.

The NM Area Director enjoined the WG to
please be careful of the work of others. Several working groups will
modify their mibs to follow this example.

It should be noted that the document editor voiced several objections to
such a change, and has raised some questions about the nature of an
interface and a counter.
Thus there may be need for clarifications on the mailing list; it may not
be a simple matter of "understanding the edits."

Finally it was felt that a note to the whole snmp list was in order. A
warning should be sent to management applications builders about
interface counters depending on a timestamp.


(6) mechnism to assign ifIndex values. Clarify.

Not discussed due to lack of time.

(7) trap generation limits? what is wrong with 1573?

Not discussed due to lack of time.

(8) ifType of other, and ifSpecific? ifVendorType?

Not discussed due to lack of time.



Topic II:
Test Mib
<draft-ietf-ifmib-testmib-00.txt>

Maria Greene presented the testmib, and reviewed its status.


Possible New Topic:
Dedicated Token Ring Interfaces MIB (IEEE 802.5)

The WG chair was asked by Jim Carlo representing IEEE 802.5, and Dan
Romascanu if work on the DTR MIB could be taken up in the IETF.

Michelle Bitton of RAD made a presentation on the DTR MIB. The
working group appreciated the effort on the part of the IEEE to work
together, and thanked Michelle for a good job in presenting the MIB.

Wider discussion on the best path forward ensued.

The IEEE would like wider exposure of its MIB by publishing it as an
RFC. It could be published as an Informational RFC, which would not
require a working group to explicitly consider it. On the other hand, if
the IEEE feels it must go through the IETF standards process, then the
IETF reserves change control, and has been known to exercise it in
unpredictable ways. The complication of differing versions of the mib,
IEEE and IETF, was a concern.

The previous process of taking an IEEE MIB into a working group was
necessary because of the GDMO format. The DTR MIB is not in that
format, so the process is not necessary now.

The IEEE would like SNMP review of its MIB reviewed by the IETF
community. This can be accomplished. Several volunteers were named:
Matt Hecht at SNMP Research, and [e-mail]

A note to Fred Baker, IESG Chair, advising him of this IEEE / IETF
interaction would be appropriate.