Subject: RE: aMACControlFunctionsSupported

From: Andrew Smith <[email-masked]>
Date: Mon, 16 Nov 1998 18:49:42 -0800

1. I vote for (b) - options are bad.
2. OK
3. Any other opinions?

Andrew

> -----Original Message-----
> From: John Flick [mailto:[email-masked]]
> Sent: Monday, November 16, 1998 6:50 PM
> To: Andrew Smith
> Cc: 'John Flick'; [email-masked]
> Subject: RE: aMACControlFunctionsSupported
> 
> 
> Andrew Smith writes:
>  > 
>  > Feedback: 
>  > 
>  > 1. It may be quite dangerous to change the value of
>  > dot3PauseLinkDelayAllowance. Does anyone really believe 
> that this needs to
>  > be writable? (yes, that means we'll call you on it later 
> if we find you've
>  > only done it read-only :-)).
> 
> I made it read-write, because that is the way it is defined in the
> IEEE document.  I don't particularly like it either.  Are you
> suggesting that we (a) nuke it, (b) make it read-only, or (c) leave
> the definition as is and add a MIN-ACCESS read-only in the
> MODULE-COMPLIANCE?
> 
> (I think (c) is probably the path of least resistance.  From past
> e-mail, I think the chair would object to (a) or (b)).
> 
>  > 2. Can we make it more clear in the DESCRIPTION that the value of
>  > dot3DuplexStatus is also reflected in the relevant ifMauType OID?
> 
> Is the following acceptable?
> 
>     dot3DuplexStatus OBJECT-TYPE
>         SYNTAX      INTEGER {
>                         unknown(1),
>                         halfDuplex(2),
>                         fullDuplex(3)
>                     }
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION "The current mode of operation of the MAC
>                     entity.  'unknown' indicates that the current
>                     duplex mode could not be determined.
> 
>                     Management control of the duplex mode is
>                     accomplished through the MAU MIB.  When
>                     an interface does not support autonegotiation,
>                     or when autonegotiation is not enabled, the
>                     duplex mode is controlled using
>                     ifMauDefaultType.  When autonegotiation is
>                     supported and enabled, duplex mode is controlled
>                     using ifMauAutoNegAdvertisedBits.  In either
>                     case, the currently operating duplex mode is
>                     reflected both in this object and in ifMauType."
>         REFERENCE   "[IEEE 802.3 Std.], 30.3.1.1.32,
>                     aDuplexStatus."
>         ::= { dot3StatsEntry 19 }
> 
>  > 3. Do we really need dot3ControlTable? There's only a 
> single capability and
>  > the counter will be zero in nearly all implementations for 
> a while yet. We
>  > could add this at a later date when more control functions 
> get defined
>  > couldn't we?
> 
> One concern I would have is what is a current implementation to do
> when it receives an unknown control opcode.  I would expect that
> current implementations could still be in use in networks after a new
> control function is defined.  This counter would at least give an
> indication that it saw the control packet and dropped it.  If it is
> not defined now, when a new control function is deployed, "old"
> implementations could be dropping control frames with no indication
> that they are doing so.  I guess I see the dot3ControlTable as fairly
> cheap "future-proofing", but I could be talked out of it.
> 
> What do others think?
> 
> Reminder: Keep in mind that I need to submit this document by Tuesday
> (as in tomorrow) evening, so we need to reach consensus quickly.  The
> alternative is waiting until mid-December for the next draft.
> 
> John
>