Subject: Re: Protocol Action: The Interfaces Group MIB to Proposed Standard

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Fri, 21 Nov 1997 12:21:40 -0800

Robert-

> Would it be possible to publish a quarterly RFC and continue with
> the IANA based mechanism.  Letting the quarterly document just cement in
> stone all the IANA asignments and the pending requests.

That would be possible of course.  Sort of a hybrid solution which
tries to have it both ways.  Given that we are used to RFC updates
there would seem to be some "ease of use" to be gained.
But then someone would have to actually publish this RFC.

> Or does the IANA assigns the actual numbers at this point?
> If they assign the actual numbers, that would make it hard to document
> the pending requests if they are being slow.

IANA does assign the actual numbers.  We cannot anticipate the
names, their numbers and their ordering.  Furthermore, I for one,
don't even see the requests that go to IANA.  Unheard-of ifTypes,
at least unheard-of by me, are regularly allocated numbers.
But I don't have to see them, and this process is fine as long as it
keeps going.

And generally it does keep going.  Its just that monthly or quarterly
is more like the pace of assignments.  And I don't always get replys
to my requests for some sort of change or other.

> Seems like if this bookkeeping requires Postel's attention to succeed,
> then it is flawed.

Hmm...  Well thats not a happy conclusion given the scope of the
numbering assignments he oversees at IANA.

Ted Brunner			Video and Networking Division
				Tektronix
				MS 50-490
[email-masked]		14150 SW Karl Braun
503.627.1317			Beaverton OR 97005

---

From: Robert Snyder <[email-masked]>
Date: Fri, 21 Nov 1997 12:45:59 -0800

> numbering assignments he oversees at IANA.

I'll assume then that he has minions at his disposal that do the actual
assignments.

---

From: Gary Hanson <[email-masked]>
Date: Fri, 21 Nov 1997 13:01:27 -0800 (PST)

> numbering assignments he oversees at IANA.

Ted,

Given the dynamic nature of the IANAifType-MIB, would it be wise
to keep the if-mib WG as an ongoing entity that is responsible
for the maintenance of the IANAifType-MIB?  If (A) an editor were
assigned to the task, and (B) solicitation requests were sent out
to the if-mib WG, we might over time accumulate a set of detailed
information that could turn the IANAifType-MIB into a more useful
and more up-to-date cross-reference to the various specs and MIBs
that govern the various ifTypes.

For example, right now there is little way to quickly determine
where to find out about ipOverAtm(114), which the IANAifType-MIB
mysteriously documents as "IBM ipOverAtm".  Now, of course, it
turns out that that was merely a typo, and was never intended to
be an IBM interface, but was recorded as such because it was
submitted at the same time as the surrounding values by the same
IBM employee.  If the MIB told me to refer to the IPOA-MIB, from
RFCxxxx, I would know where to look.  Or, in the case of an IBM
ifType, if it were to give me some sort of document reference
that defined the interface and the use of the ifTable (or even
a contact name of somebody within IBM that in 1997 I could ask,
but who might not be there any more in 2007), I would then know
how and when it was appropriate to use the value.

Would the if-mib WG be interested in taking on this additional
mission into a renewed charter, given its apparent interest in
the IF-MIB being a central reference point of all the various
interfaces we keep dreaming up?  I can't think of a more
appropriate body of interested people to do the job....

Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: Sandra Durham <[email-masked]>
Date: Fri, 21 Nov 1997 13:49:44 -0800 (PST)

> that govern the various ifTypes.

Right now, how does the IANA determine that a request for a new
ifType is "valid"?  Esp. if the ifmib WG chair isn't part of
this loop?  Or are all requests to IANA accepted, so long as
they state in a sentence or two how this ifType is different?
Is there a requirement to document the necessary compliance
groups that this new ifType supports, at the time the request
is made to IANA?

> RFCxxxx, I would know where to look.  

just a pet peeve of mine - i recall checking out that very mib,
and it has very little documenting how this ipOverAtm layer is
to be supported.  As in what do the counters count? which counters
are necessary? etc etc.  Maybe it was floating in the document somewhere,
but i didn't see any handy-dandy table like rfc1695 etc has.  I would
like to add to Gary's suggestion, that not only should we have better
insight/control into the ifType assignment (and adding info on
where to find this new ifType documented), but put a requirement for
any new ifType to fill in a table (in the media mib rfc)
of how this new media is to be supported.

> appropriate body of interested people to do the job....

definitely. And i'd be willing to step up, and help out with
the publishing of the new foo-ifType-MIB doc on a regular basis.

Sandra Durham
cisco

---

From: Michael Thatcher <[email-masked]>
Date: Mon, 24 Nov 1997 08:37:10 -0800

To add my $.02 worth to the discussion about IANAIfTypes-MIB, I think it
would be beneficial if the fields "LAST UPDATED" and
REVISION/DESCRIPTION were used when IANA updates the ifTypes.  In
particular the DESCRIPTION should identify the added enumerations and
verbage about the usage or pointers to documents on their usage.

After all isn't this why these fields where add to the SMI?

Mike Thatcher