Subject: [Hubmib] Open issues in EtherLike-MIB

From: John Flick <[email-masked]>
Date: Tue, 04 Dec 2001 21:34:37 -0800

Hi,

The following is my list of open issues for the current EtherLike-MIB
draft, draft-ietf-hubmib-etherif-mib-v3-00.txt.  These issues will be
discussed at the WG session in SLC, with the hopes of driving them to
resolution, so come prepared.  Of course, mailing list discussion
before the meeting is very welcome and encouraged.

1. Need a way of initiating a loopback test.  This used to use the
   ifTestTable in IF-MIB which was deprecated.  Efforts between
   atommib and ifmib working groups to define a replacement appear
   to have died.  We currently have test and result OBJECT-IDENTITY
   values defined in the EtherLike-MIB, but no mechanism defined to
   use them.

2. In London, there was a request to clarify the definition of ifMtu
   to indicate that it was the MTU as seen by the network layer.  The
   current text says:

      "This value should reflect the value seen by the MAC client
      interface."

   I believe this is pretty clear, but there was a request for
   clarifying this in the document at the London meeting.  If anyone
   has any suggested text, please post it.

3. There was a request on the bridgemib mailing list by Mike
   MacFaden that the update to this MIB should clarify what it means
   on an Ethernet interface to set ifAdminStatus to down, and backing
   up this request with some test results from 4 different vendors
   that all behaved differently.  My assumption is that this should
   be the equivalent of setting aMACEnableStatus to false.
   Should this also affect the MAU?
   What effect does this have on ifMauStatus?
   Should the other end of the link see the link as physically down?

4. Question from Dave Harrington: What is the story with RFC 1643.
   Is it confusing to have this document, which only supports 10Mbit,
   half-duplex ethernet sitting at Standard, while the more
   up-to-date specification continues to cycle at Proposed?
   Should we move 1643 to Historic?

If there are any other issues that are not on my open issues list or
my list of edits that I sent out earlier this evening, please submit
them now.  We would like to spin this document soon after SLC and
go to WG last call shortly thereafter, so if you have issues, please
raise them now.

John

_______________________________________________
Hubmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Dec 2001 02:56:01 +0200

>    Should we move 1643 to Historic?

I think that this is a valid question to discuss, but it extends beyond
the strict scope of the Ether-like MIB I-D. 

It might extend even beyond the scope of this WG. Do 'update' standards
lead to the need to move their predecessors to Historic, even if they
still have a valid application space and keep at least some of the broad
deployment that led to their advancement to Full?

Also, RFC 1643 was not developed originally in this WG, thus we might
need not have 'full jurisdiction' about what happens to it.

For these reasons I would be very happy to have our A-D participating in
the discussions.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Dec 2001 02:55:59 +0200

>    has any suggested text, please post it.

I also believe that this is pretty clear, but I also encountered the
question. Maybe it is the 'MAC client' concept that is obscure, and we
might want to look for an appropriate IEEE reference, plus explain that
in many cases this is synonym with the 'MTU as seen from the network
layer'.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Dec 2001 02:56:01 +0200

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Dec 2001 02:55:59 +0200

Regards,

Dan