RFI v2 MIB Draft 08
2003-11-04 15:58:01 GMT
Hi dear IPCD folks and OSSI reflector
Few updates of the last posted Draft -08
I am planning to do a quick update to the MIB draft after the IETF meeting to correct the below minor issues, Just a quick note, I will wait until the resolutions of the IETF IPCDN meeting to take actions on that.
Jason Tessier, identified a description in the idAdminStatus in the draft that is not needed and does not reflect the needs for interface Stack based on
RFC 2863 to propagate ifAdminStatus top to bottom of the stack for and up/down transition. Only ifOperStatus is propagated because of ifAdminStatus changes or inherent interface changes.
Also for docsIfUpChannelUpdate related to the clone mechanism, all the related objects were updated to not being SCMA specific. One objects left out of the updates docsIfUpChannelUpdate. The proposed change will align that object description.
See at the end of the email the Jasson arguments for the ifAdminStatus change
Below are the proposed changes, let us know any changes.
Thanks
Eduardo
ifAdminStatus The
administrative status of this interface.
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used to
perform the transfer of adjusted SCDMA parameters
from the temporary upstream row to the active upstream row
indicated by the docsIfUpChannelCloneFrom object. The
transfer is initiated through an SNMP SET of TRUE to this
object. The SNMP SET will fail with a GEN_ERROR (snmpv1)
or
COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted
SCDMA parameter values are not compatible with each other.
Although this object was created to facilitate SCDMA
parameter adjustment, it may also be used at the vendor's
discretion for non-SCDMA parameter adjustment.
An
SNMP GET of this object always returns FALSE."
::= { docsIfUpstreamChannelEntry
17 }
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used to
perform the transfer of adjusted parameters
from the temporary upstream row to the physical upstream row
indicated by the docsIfUpChannelCloneFrom object. The
transfer is initiated through an SNMP SET to 'true' of this
object. The SNMP SET failure returns an error genError (snmpv1)
or
commitFailed (snmpv2c/v3) if the adjusted parameter values are
Reading this object always return 'false'."
::= { docsIfUpstreamChannelEntry
17 }
From: Jason.Tessier <at> arrisi.com
[mailto:Jason.Tessier <at> arrisi.com]
Sent: Wednesday, October 22, 2003
10:20 AM
To: DOCSIS OSS Majordomo List
Subject:
ifAdminStatus sets to docsCableUpstream (129)
Hello,
In the
DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a docsCableUpstream
interface also be applied to the docsCableUpstreamChannel interfaces under
it.
3.2.5.2.1. ifEntry for Upstream
interfaces in Cable Modem Termination
Systems
ifTable Comments
==============
===========================================
<SNIP>
ifType
The IANA value of docsCableUpstream (129).
<SNIP>
ifAdminStatus The administrative status of this interface.
This reflect the total status of all the channels
under this interface. So if at least one channel
has a
physical connection this interface has
connection. Any SNMP SET
on this interface will
cause a SET to all the channels under
this
interface.
So in the case where
there are multiple logical channels under one upstream interface, if you want to
enable/disable the docsCableUpstream interface all of the logical channels
associated with it are also set to up/down.
I think that this makes it difficult for the operator to set the
ifAdminStatus of the docsCableUpstream interface without affecting several
logical channels, some of which may not even have been enabled in the first
place. If an operator sets the ifAdminStatus of the docsCableUpstream to
down, the set will already be reflected in the ifOperStatus of the
docsCableUpstreamChannels under it. The OperStatus of the
docsCableUpstreamChannels will reflect their own state, taking into account the
upper layer and modulation profiles, etc. I don't see a need for this
requirement.
An example:
interface
ifAdminStatus
docsCableUpstream US 1
down
docsCableUpstreamChannel 1
up
docsCableUpstreamChannel 2 down (not in
use)
docsCableUpstreamChannel 2
down (not in use)
docsCableUpstreamChannel 2 down (not in
use)
Setting ifAdminStatus of
US 1 to up results in this:
interface
ifAdminStatus
docsCableUpstream US 1
up
docsCableUpstreamChannel 1 up
docsCableUpstreamChannel 2
up
docsCableUpstreamChannel 3 up
docsCableUpstreamChannel 4
up
The effect is that
with one set 4 ifAdminStatus are affected, and 3 channels are put into use that
may not be desired. I'm thinking of proposing an ECR to remove this requirement
from the MIB.
Thanks,
Jason Tessier
QA Engineer
ARRIS
Communications Ireland
Ltd.
Jason.Tessier <at> arrisi.com
+353-21-7305826
RSS Feed