Re: 802.12 Rptr MIB Draft-- issues

[John Flick <[e-mail]>]

>	I have never supported _just_ "network" or _just_ "port."
>
>	BOTH words are required for the description to be correct. I have
>always requested that both words be used. I still think it's important for
>explaining how to _fix_ a failure to pass training.

I want our document to be as clear and correct as possible.  If these
comments had come back in August or September, I would have made the
changes withoug quibbling.  I just don't see them as the kind of
showstoppers that would warrant another roll now.  I am willing to roll
in this (and other) clarifications at a time that makes sense and doesn't
slow things down even more.  I would like to batch in these changes with
the comments from the AD review.

What do others think?


.aMediaType:

>	If we don't intend to support this object AT ALL in this MIB, can 
>the wording show that? Right now, it looks as if we're waiting for a shoe to
>drop.

I think the shoe(s) are:

  - 802.12d approval
  - extension of this WG's charter to produce a Tranceiver MIB (if we
    still want to take this on)

Saying "Tranceiver MIB issue" (given the terminology in 802.12d, "Link
MIB" would probably be the correct name) to me says this is being moved
to another document.  It is not that the object isn't important (in fact,
I know our applications use our private MIB version of it), it is that we
are following the 802.3 MIB structure (with a separate "MAU" MIB), and
waiting for a stable redundant link spec (since that will affect the
Tranceiver MIB).  I didn't want to put a big paragraph stating this in
the middle of a table.


vgRptrGroupCablesBundled:

>> However, the first paragraph is already pretty exlicit about this.
>
>	The first paragraph still doesn't seem quite "correct" to me.

The wording is taken directly from the 802.12 standard.

>	It is not crucial, but the current wording seems ambiguous.

We are not trying to fully document the 802.12 protocol here.
We are trying to write a document which allows agent implementers
and management application implementers who already understand
how 802.12 works to build agents and applications that interoperate.

Even if the statement is ambiguous, I can't see how this would lead to
non-interoperable MIB implementations.


vgRptrDetectedDupAddress:

>	The object is intended as an aid to help the user fix problems.
>I think fully and correctly explaining the cause of the problem (rather
>than just _a_ cause which might not be _the_ cause) is important for
>that.

Again, we are not trying to document 802.12.  I'm not saying I am
against being clear in our document, or that we can't add a
clarifying statement.  I am just saying this isn't a critical bug
that should halt our submitting this to the AD next week.

>	I guess we could ask why we have descriptions of MIB fields anyway.
>It seems as if helpfulness to network managers is our general intent, though.

Clarity for implementers of agents and management software.  If a
network manager is having to read the raw MIB, the management software
isn't doing its job.

(I know, I'm being an optimist here.  The unfortunate state of the art
is that network managers often are just being presented with raw MIB
info and forced to interpret it on their own.  But that is a separate
problem we are not going to solve here.)


>	Is a full cycle required (Jeff? Kaj?)? 

We would have to issue a new draft (which can't happen until after
the IETF - realistically I probably won't have time until after the
holidays).  We have to have an I-D to hand to the AD to review.
Therefore, the AD review would be delayed until at least January, rather
than next week.

>	If others have no objections, could changes be incorporated and
>approved at the IETF meeting itself? It seems that some standards processes
>allow this and others don't. Is it an option here?

We are not even meeting in San Jose.  The issue is not getting changes
"approved", it is the time involved in cycling the document.  I think
Jeff's poll coming just before the IETF meeting has more to do with
the fact that he will have to see the Area Director next week and
tell her that we are STILL not done.  We are 15 months behind schedule.
The mailing list has been silent for 4 months.  Marshall would have
terminated the working group completely by now.

We can't use our dependency on the 802.3 Repeater MIB structure as an
excuse anymore, since they are done.  I want to be done, too.

John