RE: [Hubmib] Last Call: 'Managed Objects of EPON' to Proposed Sta ndard (draft-ietf-hubmib-efm-epon-mib)

Hi Dan and all,
I have done a another review according to the comments in this mail, the Gen-art comments and some additional comments received from a kind review of Bert.
The following changes are embedded in the new draft.

1) I have elaborated the security considerations sections to include the risks of malicious and accidental mis-configuration for each one of the objects.

The sections is now as follow:
7.  Security Considerations

"
   There are number of managed objects defined in this MIB module that
   have a MAX-ACCESS clause of read-write or read-create.  Writing to
   these objects can have potentially disruptive effects on network
   operation: Including:

   Changing dot3MpcpAdminState state can lead to disabling the Multi-
   point control protocol on the respective interface leading to the
   interruption of service of the users connected to the respective EPON
   interface.

   Changing dot3EponFecMode state can lead to disabling the Forward
   error correction on the respective interface which can lead to a
   degradation of the optical link and therefore may lead to an
   interruption of service of the users connected to the respective EPON
   interface.

   Changing dot3ExtPkgObjectReset state can lead to a reset of the
   respective interface leading to an interruption of service of the
   users connected to the respective EPON interface.

   Changing dot3ExtPkgObjectPowerDown state can lead to a power down of
   the respective interface leading to an interruption of service of the
   users connected to the respective EPON interface.

   Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the
   Forward error correction on the respective interface which can lead
   to a degradation of the optical link and therefore may lead to an
   interruption of service of the users connected to the respective EPON
   interface.

   Changing dot3ExtPkgObjectRegisterAction state can lead to a change in
   the registration state of the respective interface leading to a
   deregistration and an interruption of service of the users connected
   to the respective EPON interface.

   Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in
   the reporting of the ONU interface and therefore to a change in the
   bandwidth allocation of the respective interface.  This change may
   lead a degradation or an interruption of service of the users
   connected to the respective EPON interface.

   Changing dot3ExtPkgObjectReportThreshold can lead to a change in the
   reporting of the ONU interface and therefore to a change in the
   bandwidth allocation of the respective interface.  This change may
   lead a degradation or an interruption of service of the users
   connected to the respective EPON interface.

   Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   of the users connected to the respective EPON interface, depending on
   the system action on such an alert.

   Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   of the users connected to the respective EPON interface, depending on
   the system action on such an alert.

   Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   of the users connected to the respective EPON interface, depending on
   the system action on such an alert.

   Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   of the users connected to the respective EPON interface, depending on
   the system action on such an alert.

   Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in
   the optical transmission of the respective interface leading to an
   interruption of service of the users connected to the respective EPON
   interface.


   The user of this MIB module must therefore be aware that support for
   SET operations in a non-secure environment without proper protection
   can have a negative effect on network operations.

   The readable objects in this MIB module (i.e., those with MAX-ACCESS
   other than not-accessible) may be considered sensitive in some
   environments since, collectively, they provide information about the
   performance of network interfaces and can reveal some aspects of
   their configuration.  In such environments it is important to control
   even GET and NOTIFY access to these objects and possibly even to
   encrypt their values when sending them over the network via SNMP.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

"

2) I have done another syntax pass on the description clauses.

3) I Included the comments from the Gen-art review.

4) added an Acknowledgment section to the document.

5) running SMIC resulted in 5 errors:
  C:\bwijnen\smicng\work>smicng epon.inc
  E: f(epon.mi2), (237,17) Default value for "dot3MpcpMode" must be 
     a name and not a number
  E: f(epon.mi2), (1237,17) Default value for "dot3EponFecMode" must
     be a name and not a number
  E: f(epon.mi2), (1391,17) Default value for "dot3ExtPkgObjectReset"
     must be a name and not a number
  E: f(epon.mi2), (1496,17) Default value for "dot3ExtPkgObjectFecEnabled"
     must be a name and not a number
  E: f(epon.mi2), (1558,17) Default value for "dot3ExtPkgObjectRegisterAction"
     must be a name and not a number

  *** 5 errors and 0 warnings in parsing

The default value of these objects was changed to the name of the enumerator (for instance  DEFVAL {unknown} instead of DEFVAL {1} for dot3EponFecMode).

6) All "Copyright (C) The Internet Society (2006)" changed into "Copyright (C) The IETF Trust (2006)" according to the new copyright expected guidance.

7) Changed the WG chair details.

Appreciate all the effort of intensive review.


Thanks,
Best regards,
Lior



-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]] 
Sent: Thursday, November 02, 2006 14:52
To: [email protected]
Cc: Hubmib Mailing List (E-mail)
Subject: FW: [Hubmib] Last Call: 'Managed Objects of EPON' to Proposed Standard (draft-ietf-hubmib-efm-epon-mib) 

 1. I find the security considerations section to be incomplete. What is missing is a description of the security risks encountered by the malicious or accidental mis-configuration of the read-write objects that are listed. For example ' Changing dot3MpcpAdminState state can lead to disabling the Multi-point control protocol on the respective interface leading to the interruption of service of the users connected to the respective EPON interface'.

2. Parts of the document and especially the DESCRIPTION clauses of the MIB objects need to undergo a serious English syntax checking. Although we can assume that the RFC Editor will anyway perform its editorial duties it would be better to have a native English speaker go through this process in advance, rather than having too consistent changes made in final RFC Editor controlled phases.

Dan



 

-----Original Message-----
From: The IESG [mailto:[email protected]]
Sent: Thursday, October 19, 2006 11:02 PM
To: IETF-Announce
Cc: [email protected]
Subject: [Hubmib] Last Call: 'Managed Objects of EPON' to Proposed Standard (draft-ietf-hubmib-efm-epon-mib) 

The IESG has received a request from the Ethernet Interfaces and Hub MIB WG to consider the following document:

- 'Managed Objects of EPON '
   <draft-ietf-hubmib-efm-epon-mib-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.  Please send any comments to the [email protected] or [email protected] mailing lists by 2006-11-02.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon-mib-05.tx
t


_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib


_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib

_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf