Re: dsx1/dsx3CircuitIdentifier still deprecated? (fwd)

[Gary Hanson <[e-mail]>]

Fred (trunkmib WG chair) and other IESG members,

I am still concerned about inconsistencies between the DS1/DS3 MIB
drafts and the (recently-approved) IF-MIB draft which have not yet
been resolved.  I urge the IESG to reconsider whether we can allow
the dsx1CircuitIdentifier and dsx3CircuitIdentifier objects to
become deprecated based on the now-invalidated assumption that the
ifmib WG would change ifPhysAddress to read-write when the latter WG
decided to not make that particular change.

In addition, there is an internal inconsistency within the DS3 MIB
draft regarding the deprecation itself, as described below.

Speaking for ADC Kentrox, I see no reason to deprecate these objects,
especially given that the original reason for their deprecation is
no longer valid.  Support for them had been requested by many of our
customers, they have proven their value, and I think they should stay
in the MIBs.  At least one other vendor that supports the existing
DS1/DS3 MIBs also sees their value, as Dawn Xie relates below.

Please consider my request to make this change to these drafts prior
to their release as updated Proposed Standards.  Thank you for your
consideration.

Regards,
Gary

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


---------- Forwarded message ----------
Date: Fri, 1 Aug 1997 13:29:10 -0700 (PDT)
From: Gary Hanson <[e-mail]>
To: David Fowler <[e-mail]>
Cc: [e-mail]
Subject: Re: dsx1/dsx3CircuitIdentifier still deprecated?

Dave,

As far as I can remember, the two objects were planned to be deprecated
back at a time when it seemed possible to increase the MAX-ACCESS of
ifPhysAddress to be read-write, at which point the ifPhysAddress object
could be used instead of the dsx1/dsx3CircuitIdentifier objects.

However, the conclusion of the ifmib WG (from the August, 1996 minutes)
was that there was going to be no change of ifPhysAddress, and indeed
no change has been made to the draft-ietf-ifmib-mib-05.txt document.

So, at that point, the dsx1/dsx3CircuitIdentifier objects should have
been restored to current status.  What complicates thing for us now
is that dsx3CircuitIdentifier was never flagged in the ASN.1 of the
draft-ietf-trunkmib-ds3-mib-05.txt document as deprecated, even though
the list of changes and the discussions of the use of ifPhysAddress in
that document document SAYS it was.

Given that the DS3-MIB draft is thus inconsistent with itself at best,
and inconsistent with the ifmib draft at worst, I think it makes sense
to restore the objects's MAX-ACCESS back to current status, since the
users of these MIBs have to have SOME object where the values can be
written.  (Note that it could remain an implementation choice whether
or not to populate the ifPhysAddress with these values, once written.)

I apologize for not noticing the inconsistencies earlier, but I think
it needs to be fixed.

Regards,
Gary


On Fri, 1 Aug 1997, David Fowler wrote:

> Dawn Xie wrote> 
> > CircuitIdentifier object is useful to associate a port to a 
> > connection facility. So I agree with Gary that these objects better 
> > not be deprecated.
> > 
> 
> Gary Hanson wrote: 
> > I thought a conclusion had been reached a year ago about not 
> expanding
> > the MAX-ACCESS of ifPhysAddress, and the current IF-MIB 
> draft (which has
> > apparently expired since May!) still shows ifPhysAddress to be 
> read-only.
> 
> > > 
> > > Do you know which direction this discrepancy is going to be 
> > resolved?
> > > 
> 
> The last drafts I submitted are intended to be the final documents.
> This means that CircuitIdentifier was supposed to stay deprecated.
> 
> I, for one, can see the value of naming objects.  I guess the question
> is whether one truly needs to set these objects through SNMP or will they 
> be assigned on a local interface and then only read through SNMP?
> 
> Gary/Dawn:  Will you give me a bit more info on how you would like to
> use this object?
> 
> Thanks,
> David
> 
> P.S.  No promises here.  These drafts have been merely waiting for
> interoperability and I'm not planning on churning them again unless
> the chair asks me to do it!
>