Subject: new ethermib draft

From: John Flick <[email-masked]>
Date: Thu, 19 Nov 1998 18:25:04 -0800 (PST)

Hi,

As you probably already noticed, I did manage to (barely) get a new
draft of the Ethernet Interface MIB in before the I-D cutoff for
Orlando.  This draft has some new text that should be reviewed to make 
sure the WG agrees with it.  In addition, there were some issues still 
being discussed, that we need to come to consensus on.  I just took a
"best guess" as to a possible resolution, but having some discussion
(with input from more than just me and Andy) and a final consensus
(gauged by the WG chair) is important.

Significant new/changed text:

1. Section on relationship to the MAU MIB was updated.  Old text was
   out of date because of the addition of dot3StatsDuplexStatus.

2. New section on dot3StatsEtherChipSet added.  I don't know if the
   IESG is going to allow us to get away with text this vague,  but I
   couldn't write anything more definite without resolution of the
   issue of what to do with this object (see open issues).  Also, we
   need to actually create the Informational document with the
   historic chip assignments.  These documents should probably go to
   the IESG as a set.

3. I added text on why some of the IEEE managed objects were not
   included.  Please review this and see if you agree with me.

4. Compliance section was considerably reorganized.  Please review.

Open issues:

1. dot3StatsEtherChipSet.  I think we agree that the existing OID
   assignments should be moved to a separate, informational RFC.  The
   question still open is how to deal with new assignments.  I think
   we have three choices:

      a. IANA maintained assignments under dot3 tree
      b. vendor assignment under enterprise tree
      c. deprecate the object

   I have been arguing for b, but could easily be talked into c.
   Andy was arguing for b.
   I think Dan was arguing for a (and that seemed to be where those
   present in Chicago were heading).

2. dot3PauseLinkDelayAllowance.  Andrew points out that this is a
   rather dangerous value to modify.  I agree.  However, when I
   originally argued for leaving this object out of the MIB, Dan
   argued that he felt it was a valuable thing to be able to manage.
   I think there are four choices:

      a. delete the object
      b. make the object read-only
      c. make the object MAX-ACCESS read-write, MIN-ACCESS read-only
      d. make the object mandatory read-write

   Andrew is arguing for b.  The current draft does c.

3. dot3ControlTable.  Andrew argues that this is unnecessary.  I argue 
   that it seems like pretty cheap future-proofing, and the objects
   are in the IEEE standard.  I'm not really attached to this table,
   but I don't want to remove it without hearing from others in the
   WG.  The choices are:

      a. remove dot3ControlTable
      b. leave it in

PLEASE comment on the above open issues and review the above mentioned 
sections in the document.  It is really difficult to gauge consensus
on a silent mailing list.  We cannot submit any new drafts until after 
the Orlando IETF, but I would like to have the above issues resolved,
and have finished WG last call on the Ethernet MIB, MAU MIB, and a
proposed informational chipset document by then.  That way, we can be
ready to submit updated documents on December 14 that would be ready
to be immediately handed to the Area Directors.  But we can't do this
without YOUR input.

Thanks,
John