RFI v2 MIB Draft 08
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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
update to RFI Mib v2 with two changes:
1- ifAdminStatus requirements for UpChannels should read.
3.2.5.2. ifEntry for Upstream interfaces
ifAdminStatus The administrative status of this interface.
2- Re-define the requirement for docsIfUpChannelUpdate as below
- All the associated objects for the Clone Mechanism are no longer
referencing exclusively to SCDMA. The intention now is normalize this
requirements for all type of profiles.
- change GEN-ERROR for genError and COMMIT_FAILED_ERROR for
commitFailed
docsIfUpChannelUpdate OBJECT-TYPE
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 }
to:
docsIfUpChannelUpdate OBJECT-TYPE
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
not compatible with each other.
Reading this object always return 'false'."
::= { docsIfUpstreamChannelEntry 17 }
--------------------------------
IfAdminStatus Jasson email
-----Original Message-----
From: [email protected] [mailto:[email protected]]
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.
[email protected]
+353-21-7305826