From mailman-admin@ietf.org Wed Jan 1 12:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10082 for ; Wed, 1 Jan 2003 12:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01HE7J29096 for ; Wed, 1 Jan 2003 12:14:07 -0500 Date: Wed, 01 Jan 2003 12:14:07 -0500 Message-ID: <20030101171407.32165.28924.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: hubmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hubmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for hubmib-archive@lists.ietf.org: List Password // URL ---- -------- hubmib@ietf.org XUKx https://www1.ietf.org/mailman/options/hubmib/hubmib-archive%40lists.ietf.org From mailnull@www1.ietf.org Sat Jan 4 01:49:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26938 for ; Sat, 4 Jan 2003 01:49:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h046wW522520 for hubmib-archive@odin.ietf.org; Sat, 4 Jan 2003 01:58:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h046wTJ22515; Sat, 4 Jan 2003 01:58:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h046v7J22472 for ; Sat, 4 Jan 2003 01:57:07 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26927 for ; Sat, 4 Jan 2003 01:47:26 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id WAA11622; Fri, 3 Jan 2003 22:50:38 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 3 Jan 2003 22:50:37 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hubmib cc: Avi Berger , "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" Subject: Re: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, 23 Dec 2002, Romascanu, Dan (Dan) wrote: > >This is the official announcement for the Working Group Last Call for >the Power Ethernet MIB. The Internet-Draft is available at > >http://www.ietf.org/internet-drafts/draft-ietf-hubmib-power-ethernet-mib-04.txt > >Please send your comments until the latest January 15, 2003, to >hubmib@ietf.org. In an effort to help the WG produce the cleanest possible document I've attempted to do a fairly detailed "MIB Doctor" on this draft. Please note that I've not been able to check the document for editorial and technical consistency with the 802.3af draft, since I have not been participating in the Power Ethernet work and do not have access to the specification. Someone else should do that check. The following list of comments goes through the sections of the document in the order that they appear. 1.) I-D Boilerplate -- OK (required stuff is present, and there are no references or section numbers). 2.) Abstract -- references are not allowed in the abstract; please change "Ethernet-like Interfaces MIB [RFC2665]" to "Ethernet-like Interfaces MIB". 3.) Introduction (Section 1) -- in the first paragraph the acronyms MDI and arguably DTE are not common terms and therefore need to be expanded on first use, or else removed. My suggestion would be to change "Power Ethernet (DTE Power via MDI)" to "Power Ethernet [IEEE-802.3af]" which will circumvent the need to define those terms here. In the second paragraph please change the reference from [RFC2863] to [RFC2119]. 4.) MIB Boilerplate (Section 2) -- the official MIB boilerplate has been changed owing to the publication of the full-standard SNMPv3 RFCs. So, please change the section heading to "Internet-Standard Management Framework" and use the boilerplate text from the OPS area web site (http://www.ops.ietf.org/mib-boilerplate.html). Note that the new boilerplate uses [RFC3410] instead of [RFC2570] and does not refer to the SNMP protocol documents themselves. 5.) Overview (Section 3) -- OK 6.) MIB Structure (Section 4) -- in the first sentence please change "and the fourth scalar objects" to "and the fourth contains scalar objects." 7.) Evolution of the Document, Limitations and Future Work (Section 5) -- in its present form this section would not be appropriate in the final published RFC. It should either be reworded, eliminated from the draft, or moved to the back of the draft with a prominent note telling the RFC Editor that it is to be removed prior to publication. 8.) Changes Log (Section 6) -- this section would not be appropriate in the final published RFC. It should be moved to the back of the draft with a prominent telling the RFC Editor that it is to be removed prior to publication. In addition, please change "[PWR-MIB]" to "draft-romascanu-hubmib-power-ethernet-mib-00.txt"; this reference needs to be removed (see below) since it points to an expired draft. 9.) Definitions (Section 7) -- there are two MIB compiler warnings related to unreferenced notification groups plus several other things that either need correction or that could (in the opinion of this reviewer) be improved. I'll go through them in the order in which they appear in the MIB module. (a) Our AD has requested that working group mailing list information appear in the CONTACT-INFO clause of the MODULE-IDENTITY invocation. You may therefore want to add the following lines at the top: WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address and change the indentation of the rest of the stuff to match (you should not go beyond column 72, see http://www.ietf.org/ID-nits.html). (b) IESG policy now requires that a copyright notice appear in the DESCRIPTION clause of the MODULE-IDENTITY invocation (see http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt for details). Here is a suitable template: DESCRIPTION "[ ... ] Copyright (C) The Internet Society (date). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice Prior to submission '(date)' must be replaced with the current year, i.e., '(2003)'. (c) The "box in the stack, module in a rack" language that appears in the DESCRIPTION clauses for pethPsePortGroupIndex, pethMainPseGroupIndex, and pethNotificationControlGroupIndex suggests that the same value will be used in all three of these indices to refer to a given physical entity. If that is true, it would be best to say so explicitly, and in that case I would recommend modifying the DESCRIPTION clause for pethPsePortGroupIndex to something along the following lines: "This variable uniquely identifies the group containing the port to which a power Ethernet PSE is connected. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethMainPseGroupIndex, and pethNotificationControlGroupIndex to refer to a given (box in the stack, module in a rack)." In any case, the sentence "pethPseMidSpanGroupCapacity is the number of Mid-Span PSE groups that can be contained within the Mid-Span PSE" needs to be removed because there no such object (indeed, there is no mention of pethPseMidSpanGroupCapacity anywhere else in the document). (d) In the DESCRIPTION clause for pethPsePortIndex please change "pethPseGroupIndex" to "pethPsePortGroupIndex". (e) In the following object definition pethPsePortAdminEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables power supply on this port. Setting this object at a value enable(1) enables power and detection mechanism for this port. Setting this object at a value disable(2) disables power for this port." ::= { pethPsePortEntry 3 } use of the name "pethPsePortAdminEnable" rather than "pethPsePortAdminStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to match by changing "the value enable(1)" to "the value true(1)" and by changing "the value disable(2)" to "the value false(2)". [It would also be nice to have the object name appear a few columns to the left of the SYNTAX, MAX-ACCESS, STATUS, and DESCRIPTION clauses as it does in most other object definitions; maybe indent all the other clauses three spaces, as was done in the definitions of the index objects?] (f) In the following object definition pethPsePortDetectionStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), searching(2), deliveringPower(4), fault(5), test(7), denyLowPriority(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the operational status of the port PD detection. A value of disabled(1)- indicates that the PSE State diagram is in the state IDLE A value of searching(2)- indicates that the PSE State diagram is in the state DETECTION, CLASSIFICATION, SIGNATURE_INVALID or BACKOFF. A value of deliveringPower(4) - indicates that the PSE State diagram is in the state POWER_UP, POWER_ON or POWER_OFF. A value of fault(5) - indicates that the PSE State diagram is in the state TEST_ERROR or the state IDLE due to the variable error condition. Faults detected are vendor specific. A value of test(7) - indicates that the PSE State diagram is in the state TEST_MODE. A value of denyLowPriority(8) indicates that the port was disabled by the power management system, in order to keep active higher priority ports. " ::= { pethPsePortEntry 7 } the enumerations are not contiguous, which is allowed but contrary to the recommendations in RFC 2578 Section 7.1.1. Is there a reason for this? If there isn't, please change to conform to the recommendations. If there is, it would be a good idea to document it (e.g., if you are aligning with the numbering of states in the IEEE specification then say so, and maybe even add a REFERENCE clause). (g) In the following object definition pethPsePortPowerMaintenanceStatus OBJECT-TYPE SYNTAX INTEGER { ok(1), underCurrent(2), mPSAbsent(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value ok(1) indicates the Power Maintenance Signature is present and the overcurrent condition has not been detected. The value overCurrent (2) indicates an overcurrent condition has been detected. The value mPSAbsent(3) indicates that the Power Maintenance Signature is absent." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, 30.9.1.1.8 aPSEPowerMaintenanceStatus]" ::= { pethPsePortEntry 10 } the enumeration labels and the DESCRIPTION clauses don't match. This needs to be fixed; it appears that "underCurrent" should be "overCurrent". [ Scott Mains has also pointed this out in a message posted 19 Dec 2002.] (h) In the DESCRIPTION clause for this object pethPsePortOverCurrentCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counts the number of times that the aPSEPowerCurrentStatus attribute changes from any value to the value overCurrent(2)." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, object 30.9.1.1.1 aPSEOverCurrentCounter]" ::= { pethPsePortEntry 12 } please change "aPSEPowerCurrentStatus" to "pethPsePortPowerMaintenanceStatus". [ Scott Mains has also pointed this out in a message posted 19 Dec 2002.] (i) In the following object pethPsePortPowerClassifications OBJECT-TYPE SYNTAX INTEGER { class0(1), class1(2), class2(3), class3(4), class4(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Classification is a way to tag different terminals on the Power over LAN network according to their power consumption. Devices such as IP telephones, WLAN access points and others, will be classified according to their power requirements. The value is only valid while a valid PD is being detected as indicated by the attribute pethPsePortDetectionStatus reporting the value or deliveringPower(4)." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, object 30.9.1.1.7 aPSEPowerClassification]" ::= { pethPsePortEntry 14 } are the classification labels 'class0' and so on defined in the IEEE specification? If so, please add a sentence along the lines of The meaning of the classification labels is defined in the IEEE specification. at the end of the first paragraph of the DESCRIPTION clause. (Also, if the IEEE document uses numeric values 0 through 4 for class0 through class 4 you _might_ want to do the same thing -- this would fall under the "valid reason" exemption to the "start at 1" recommendation.) (j) You may want to add the following REFERENCE clause to the definition of pethPdPortIndex: REFERENCE "RFC 2863, ifIndex" (k) In the following object pethPdPortAdminEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This value identifies the operational state of the PD functions. An interface which can provide the PD functions will be enabled to do so when this attribute has the value enable. When this attribute has the value disable the interface will act as it would if it had no PD function." ::= { pethPdPortEntry 2 } the name and semantics (in particular the fact that it is writeable) suggests that it is an administrative state while the DESCRIPTION says that it is an operational state. If it is indeed an admin state, please change the words "operational state" to "administrative state" in the DESCRIPTION. Also, use of the name "pethPdPortAdminEnable" rather than "pethPdPortAdminStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to match by changing "the value enable" to "the value true(1)" and by changing "the value disable" to "the value false(2)". (l) The "box in the stack, module in a rack" language that appears in the DESCRIPTION clauses for pethPsePortGroupIndex, pethMainPseGroupIndex, and pethNotificationControlGroupIndex suggests that the same value will be used in all three of these indices to refer to a given physical entity. If that is true, it would be best to say so explicitly, and in that case I would recommend modifying the DESCRIPTION clause for pethMainPseGroupIndex to something along the following lines: "This variable uniquely identifies the group to which a power Ethernet PSE is connected. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethNotificationControlGroupIndex to refer to a given (box in the stack, module in a rack)." (m) Making the same assumptions as above, the equivalent modification for pethNotificationControlGroupIndex would be: "This variable uniquely identifies the group. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethMainPseGroupIndex to refer to a given (box in the stack, module in a rack)." In any case, the current language "it is RECOMENDED that the value 1 be used for non-modular devices" is not consistent with that in the DESCRIPTION clauses for pethPsePortGroupIndex and pethMainPseGroupIndex; the same imperative should be used in all three places. I think that the MUST wording is the right way to go, since it does not cost the agent anything and makes life easier for the manager. (n) In the following object pethNotificationControlEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enable Notification from Agent" use of the name "pethNotificationControlEnable" rather than "pethNotificationControlStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to read "This object controls, on a per-group basis, whether or not notifications from the agent are enabled. The value true(1) means that notifications are enabled; the value false(2) means that they are not." (o) Regarding the notification definitions: it was recently noted on the mibs@ops.ietf.org mailing list that MIB doctors should make sure that notifications defined in IETF MIB modules cannot "flood" the communication network in case of a high rate of occurrence of the events that trigger them. Hence, it is recommended that the notification definitions in this MIB module include a rate limiting mechanism, e.g., a statement in the DESCRIPTION clause that at least x milliseconds must elapse between successive notifications triggered by any one object instance (this works for the notifications defined in this MIB module because they are triggered by changes in the values of MIB objects). One could either choose a fixed value for x (e.g., 500 msec) or allow it to be configured (another object would need to be defined for that purpose, and it would need to be mentioned in the Security Considerations section). (p) The following warnings are generated from the command smilint -l 9 -s -i namelength-32 ./POWER-ETHERNET-MIB ./POWER-ETHERNET-MIB:667: [6] current group `pethPsePortNotificationGroup' is not referenced in this module ./POWER-ETHERNET-MIB:674: [6] current group `pethMainPowerNotificationGroup' is not referenced in this module These warnings are issued because it it not uncommon for an object group or notification group to be omitted from the conformance statements by mistake. The module is still well-formed, because an object group or notification group that is not mentioned in any MANDATORY-GROUPS clause or in any GROUP clause is unconditionally optional; but it's not altogether clear whether this was the MIB designer's intent or just an oversight. For this reason, it is RECOMMENDED that object groups and notification groups be mentioned in a GROUP clause even when they are unconditionally optional. Appropriate GROUP clauses might be: GROUP pethPsePortNotificationGroup DESCRIPTION "Implementation of the pethPsePortNotificationGroup is RECOMMENDED for systems which implement PSE ports." GROUP pethMainPowerNotificationGroup DESCRIPTION "Implementation of the pethMainPowerNotificationGroup is RECOMMENDED for systems which implement main power supply within a PSE Device." If "RECOMMENDED" is too strong, then "encouraged" or "optional" could be used instead. These GROUP clauses should be added to the end of pethCompliance. [Note: if it was intended that notifications be mandatory, then the language from the other GROUP clauses in the pethCompliance statement should be adapted instead.] (q) If it is indeed the case that the notifications are intended to be optional, then the GROUP clause (in pethCompliance) for pethNotificationControlGroup has an erroneous DESCRIPTION clause. It says "The pethNotificationControlGroup is mandatory for systems which implement PSE ports." It should say "The pethNotificationControlGroup is mandatory for systems which implement notifications." (r) The compliance statements in this MIB module are redundant. It defines pethPseCompliance, which applies to PSEs, and pethPdCompliance, which applies to PDs. But it also defines pethCompliance, which applies to any device, and which is a superset of the other two (it does this by making all groups conditionally mandatory depending on what functions are implemented). This redundancy is not necessary. My recommendation is to remove pethPseCompliance and pethPdCompliance. (s) General comment on REFERENCE clauses: I notice that some of the object definitions have REFERENCE clauses that point to the IEEE specification while others do not. It would indeed be desirable to add reference clauses for all objects that have equivalent GDMO objects in 802.3af clause 30.9; and for those that do not but which require hardware support, it would be good to refer to the clauses in the IEEE specification that mandate the necessary hardware support, as was done in the ETHER-WIS MIB module for the objects in etherWisDeviceGroupBasic and etherWisDeviceGroupExtra (see draft-ietf-hubmib-wis-mib-05.txt or its successor). One word of caution, though: the REFERENCE clauses will need to point to the final published IEEE STD 802.3af and not to IEEE Draft P802.3af/D4.0, and you will need to re-check the clause numbers each time a new version appears. 10.) References (Sections 8 and 9) -- the references need to be updated owing mainly to the publication of the new SNMPv2 RFCs but also to a few errors/oversights. Here are the details: Remove normative reference [RFC2570]. RFC 2570 has been replaced by RFC 3410, which is supposed to be an informative reference. Remove normative references [RFC2571], [RFC2572], [RFC2573], [RFC2574], and [RFC2575] since they are no longer required by the boilerplate and are not used elsewhere. Add a normative reference [RFC2863] to RFC 2863, since InterfaceIndex is imported from the IF-MIB. Remove informative references [RFC1155], [RFC1212], [RFC1215], [RFC1157], [RFC1901], [RFC1905], and [RFC1906] since they are no longer required by the boilerplate and are not used elsewhere. Remove the informative reference [PWR-MIB], since it points to an expired draft that defined a predecessor to this MIB module. Add an informative reference [RFC3410] to RFC 3410 since it is required by the boilerplate and security sections (see http://www.ops.ietf.org/mib-boilerplate.html and comment 11 below). Please revise the style of the references to match that of recently published RFCs (see RFC 3418 or the MIB boilerplate http://www.ops.ietf.org/mib-boilerplate.html for an example). The authors need to be aware that this document can go through the IETF approval process but cannot be published as an RFC as long as [IEEE-802.3af] points to IEEE Draft P802.3af/D4.0 (or any other version of the draft) rather than IEEE STD 802.3af. That reference, however, should _not_ be updated until the final standard is actually approved, and then there should be a final review of this document to ensure that it is editorially and technically consistent with the final IEEE standard ... things like clause numbers (which are used in the REFERENCE clauses) are subject to change even very late in the process. 10.) IPR Notices (Section 10) -- probably OK: the draft contains verbatim copies of the IPR notices specified in bullets (A) and (B) of Section 10.4 of RFC 2026 as required, but the AUTHORS NEED TO CONFIRM that the notice in bullet (D) is not needed. 11.) Security Considerations Section -- the MIB security guidelines are in the process of being updated, so the text on the OPS area web site (http://www.ops.ietf.org/security.html) is out of date. However, based on the latest wisdom to appear on the mibs@ops.ietf.org mailing list, I would recommend a rewrite along the following lines: There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. These are: pethPsePortAdminEnable pethPsePortPowerPairs pethPsePortPowerDetectionControl pethPsePortPowerPriority pethPsePortType pethPdPortAdminEnable pethMainPseUsageThreshold pethNotificationControlEnable Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) contain information that may be considered sensitive in some network environments. These are: pethPsePortPowerPairsControlAbility pethPsePortPowerPriority pethPsePortPowerClassifications It is thus important to control even GET and NOTIFY access to these objects and possibly 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. 12.) IANA Considerations section (none present) -- NEED TO CHECK WITH OUR AD. An IANA Considerations section probably should not be needed since this document does not define a name space. However, the current version of http://www.ietf.org/ID-nits.html states that there is supposed to be an IANA considerations section whenever IANA is reequired to make an assignment in a registry prior to RFC publication. I have raised objections about this policy, and an answer from our AD is pending. For the time being I think that the notation powerEthernetMIB MODULE-IDENTITY [ ... ] ::= { mib-2 XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice that is already present will suffice; but if an IANA Considerations section has to be written, I would suggest something along the lines of The POWER-ETHERNET-MIB module defined in this document is registered under an IANA-assigned node in the mib-2 OBJECT IDENTIFIER subtree [RFC2578]. That node is defined as "powerEthernetMIB" in the POWER-ETHERNET-MIB MODULE-IDENTITY invocation. Subordinate assignments under powerEthernetMIB will be managed by the IETF working group responsible for maintaining the ETHER-WIS MIB module; no further IANA action is required. ******************************************************* * EDITOR'S NOTE (to be removed prior to publication): * * before this draft is published as an RFC, a subid * * under the mib-2 OBJECT IDENTIFIER subtree needs to * * be assigned by IANA for powerEthernetMIB, and this * * subid needs to be inserted by the RFC Editor into * * the POWER-ETHERNET-MIB -WIS MODULE-IDENTITY value. * ******************************************************* 13.) Copyrights -- the full copyright notice should start with the line Copyright (C) The Internet Society (date). All Rights Reserved. The absence of a copyright notice in the DESCRIPTION clause of the MODULE-IDENTITY invocation was noted in 9(b) bove. Note: when the draft is resubmitted, please be sure to change the year to 2003 in all three places (on the front page, in the DESCRIPTON clause of the MODULE-IDENTITY invocation, and in the full copyright statement). 14.) General comments on formatting -- the layout of the MIB module is not uniform, as noted in a couple of places in (9) above, and it would be nice to have that fixed. Also, the draft does not fully adhere to the document formatting guidelines in Instructions to RFC Authors, . That can be fixed during the final editing process, but it would speed up the process (and reduce the chances for error) if the next version of the draft would attempt to comply more closely with those guidelines. //cmh _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sat Jan 4 01:49:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26951 for ; Sat, 4 Jan 2003 01:49:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h046wTJ22515; Sat, 4 Jan 2003 01:58:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h046v7J22472 for ; Sat, 4 Jan 2003 01:57:07 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26927 for ; Sat, 4 Jan 2003 01:47:26 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id WAA11622; Fri, 3 Jan 2003 22:50:38 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 3 Jan 2003 22:50:37 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hubmib cc: Avi Berger , "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" Subject: Re: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, 23 Dec 2002, Romascanu, Dan (Dan) wrote: > >This is the official announcement for the Working Group Last Call for >the Power Ethernet MIB. The Internet-Draft is available at > >http://www.ietf.org/internet-drafts/draft-ietf-hubmib-power-ethernet-mib-04.txt > >Please send your comments until the latest January 15, 2003, to >hubmib@ietf.org. In an effort to help the WG produce the cleanest possible document I've attempted to do a fairly detailed "MIB Doctor" on this draft. Please note that I've not been able to check the document for editorial and technical consistency with the 802.3af draft, since I have not been participating in the Power Ethernet work and do not have access to the specification. Someone else should do that check. The following list of comments goes through the sections of the document in the order that they appear. 1.) I-D Boilerplate -- OK (required stuff is present, and there are no references or section numbers). 2.) Abstract -- references are not allowed in the abstract; please change "Ethernet-like Interfaces MIB [RFC2665]" to "Ethernet-like Interfaces MIB". 3.) Introduction (Section 1) -- in the first paragraph the acronyms MDI and arguably DTE are not common terms and therefore need to be expanded on first use, or else removed. My suggestion would be to change "Power Ethernet (DTE Power via MDI)" to "Power Ethernet [IEEE-802.3af]" which will circumvent the need to define those terms here. In the second paragraph please change the reference from [RFC2863] to [RFC2119]. 4.) MIB Boilerplate (Section 2) -- the official MIB boilerplate has been changed owing to the publication of the full-standard SNMPv3 RFCs. So, please change the section heading to "Internet-Standard Management Framework" and use the boilerplate text from the OPS area web site (http://www.ops.ietf.org/mib-boilerplate.html). Note that the new boilerplate uses [RFC3410] instead of [RFC2570] and does not refer to the SNMP protocol documents themselves. 5.) Overview (Section 3) -- OK 6.) MIB Structure (Section 4) -- in the first sentence please change "and the fourth scalar objects" to "and the fourth contains scalar objects." 7.) Evolution of the Document, Limitations and Future Work (Section 5) -- in its present form this section would not be appropriate in the final published RFC. It should either be reworded, eliminated from the draft, or moved to the back of the draft with a prominent note telling the RFC Editor that it is to be removed prior to publication. 8.) Changes Log (Section 6) -- this section would not be appropriate in the final published RFC. It should be moved to the back of the draft with a prominent telling the RFC Editor that it is to be removed prior to publication. In addition, please change "[PWR-MIB]" to "draft-romascanu-hubmib-power-ethernet-mib-00.txt"; this reference needs to be removed (see below) since it points to an expired draft. 9.) Definitions (Section 7) -- there are two MIB compiler warnings related to unreferenced notification groups plus several other things that either need correction or that could (in the opinion of this reviewer) be improved. I'll go through them in the order in which they appear in the MIB module. (a) Our AD has requested that working group mailing list information appear in the CONTACT-INFO clause of the MODULE-IDENTITY invocation. You may therefore want to add the following lines at the top: WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address and change the indentation of the rest of the stuff to match (you should not go beyond column 72, see http://www.ietf.org/ID-nits.html). (b) IESG policy now requires that a copyright notice appear in the DESCRIPTION clause of the MODULE-IDENTITY invocation (see http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt for details). Here is a suitable template: DESCRIPTION "[ ... ] Copyright (C) The Internet Society (date). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice Prior to submission '(date)' must be replaced with the current year, i.e., '(2003)'. (c) The "box in the stack, module in a rack" language that appears in the DESCRIPTION clauses for pethPsePortGroupIndex, pethMainPseGroupIndex, and pethNotificationControlGroupIndex suggests that the same value will be used in all three of these indices to refer to a given physical entity. If that is true, it would be best to say so explicitly, and in that case I would recommend modifying the DESCRIPTION clause for pethPsePortGroupIndex to something along the following lines: "This variable uniquely identifies the group containing the port to which a power Ethernet PSE is connected. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethMainPseGroupIndex, and pethNotificationControlGroupIndex to refer to a given (box in the stack, module in a rack)." In any case, the sentence "pethPseMidSpanGroupCapacity is the number of Mid-Span PSE groups that can be contained within the Mid-Span PSE" needs to be removed because there no such object (indeed, there is no mention of pethPseMidSpanGroupCapacity anywhere else in the document). (d) In the DESCRIPTION clause for pethPsePortIndex please change "pethPseGroupIndex" to "pethPsePortGroupIndex". (e) In the following object definition pethPsePortAdminEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables power supply on this port. Setting this object at a value enable(1) enables power and detection mechanism for this port. Setting this object at a value disable(2) disables power for this port." ::= { pethPsePortEntry 3 } use of the name "pethPsePortAdminEnable" rather than "pethPsePortAdminStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to match by changing "the value enable(1)" to "the value true(1)" and by changing "the value disable(2)" to "the value false(2)". [It would also be nice to have the object name appear a few columns to the left of the SYNTAX, MAX-ACCESS, STATUS, and DESCRIPTION clauses as it does in most other object definitions; maybe indent all the other clauses three spaces, as was done in the definitions of the index objects?] (f) In the following object definition pethPsePortDetectionStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), searching(2), deliveringPower(4), fault(5), test(7), denyLowPriority(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the operational status of the port PD detection. A value of disabled(1)- indicates that the PSE State diagram is in the state IDLE A value of searching(2)- indicates that the PSE State diagram is in the state DETECTION, CLASSIFICATION, SIGNATURE_INVALID or BACKOFF. A value of deliveringPower(4) - indicates that the PSE State diagram is in the state POWER_UP, POWER_ON or POWER_OFF. A value of fault(5) - indicates that the PSE State diagram is in the state TEST_ERROR or the state IDLE due to the variable error condition. Faults detected are vendor specific. A value of test(7) - indicates that the PSE State diagram is in the state TEST_MODE. A value of denyLowPriority(8) indicates that the port was disabled by the power management system, in order to keep active higher priority ports. " ::= { pethPsePortEntry 7 } the enumerations are not contiguous, which is allowed but contrary to the recommendations in RFC 2578 Section 7.1.1. Is there a reason for this? If there isn't, please change to conform to the recommendations. If there is, it would be a good idea to document it (e.g., if you are aligning with the numbering of states in the IEEE specification then say so, and maybe even add a REFERENCE clause). (g) In the following object definition pethPsePortPowerMaintenanceStatus OBJECT-TYPE SYNTAX INTEGER { ok(1), underCurrent(2), mPSAbsent(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value ok(1) indicates the Power Maintenance Signature is present and the overcurrent condition has not been detected. The value overCurrent (2) indicates an overcurrent condition has been detected. The value mPSAbsent(3) indicates that the Power Maintenance Signature is absent." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, 30.9.1.1.8 aPSEPowerMaintenanceStatus]" ::= { pethPsePortEntry 10 } the enumeration labels and the DESCRIPTION clauses don't match. This needs to be fixed; it appears that "underCurrent" should be "overCurrent". [ Scott Mains has also pointed this out in a message posted 19 Dec 2002.] (h) In the DESCRIPTION clause for this object pethPsePortOverCurrentCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counts the number of times that the aPSEPowerCurrentStatus attribute changes from any value to the value overCurrent(2)." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, object 30.9.1.1.1 aPSEOverCurrentCounter]" ::= { pethPsePortEntry 12 } please change "aPSEPowerCurrentStatus" to "pethPsePortPowerMaintenanceStatus". [ Scott Mains has also pointed this out in a message posted 19 Dec 2002.] (i) In the following object pethPsePortPowerClassifications OBJECT-TYPE SYNTAX INTEGER { class0(1), class1(2), class2(3), class3(4), class4(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Classification is a way to tag different terminals on the Power over LAN network according to their power consumption. Devices such as IP telephones, WLAN access points and others, will be classified according to their power requirements. The value is only valid while a valid PD is being detected as indicated by the attribute pethPsePortDetectionStatus reporting the value or deliveringPower(4)." REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, object 30.9.1.1.7 aPSEPowerClassification]" ::= { pethPsePortEntry 14 } are the classification labels 'class0' and so on defined in the IEEE specification? If so, please add a sentence along the lines of The meaning of the classification labels is defined in the IEEE specification. at the end of the first paragraph of the DESCRIPTION clause. (Also, if the IEEE document uses numeric values 0 through 4 for class0 through class 4 you _might_ want to do the same thing -- this would fall under the "valid reason" exemption to the "start at 1" recommendation.) (j) You may want to add the following REFERENCE clause to the definition of pethPdPortIndex: REFERENCE "RFC 2863, ifIndex" (k) In the following object pethPdPortAdminEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This value identifies the operational state of the PD functions. An interface which can provide the PD functions will be enabled to do so when this attribute has the value enable. When this attribute has the value disable the interface will act as it would if it had no PD function." ::= { pethPdPortEntry 2 } the name and semantics (in particular the fact that it is writeable) suggests that it is an administrative state while the DESCRIPTION says that it is an operational state. If it is indeed an admin state, please change the words "operational state" to "administrative state" in the DESCRIPTION. Also, use of the name "pethPdPortAdminEnable" rather than "pethPdPortAdminStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to match by changing "the value enable" to "the value true(1)" and by changing "the value disable" to "the value false(2)". (l) The "box in the stack, module in a rack" language that appears in the DESCRIPTION clauses for pethPsePortGroupIndex, pethMainPseGroupIndex, and pethNotificationControlGroupIndex suggests that the same value will be used in all three of these indices to refer to a given physical entity. If that is true, it would be best to say so explicitly, and in that case I would recommend modifying the DESCRIPTION clause for pethMainPseGroupIndex to something along the following lines: "This variable uniquely identifies the group to which a power Ethernet PSE is connected. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethNotificationControlGroupIndex to refer to a given (box in the stack, module in a rack)." (m) Making the same assumptions as above, the equivalent modification for pethNotificationControlGroupIndex would be: "This variable uniquely identifies the group. 'Group' means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethMainPseGroupIndex to refer to a given (box in the stack, module in a rack)." In any case, the current language "it is RECOMENDED that the value 1 be used for non-modular devices" is not consistent with that in the DESCRIPTION clauses for pethPsePortGroupIndex and pethMainPseGroupIndex; the same imperative should be used in all three places. I think that the MUST wording is the right way to go, since it does not cost the agent anything and makes life easier for the manager. (n) In the following object pethNotificationControlEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enable Notification from Agent" use of the name "pethNotificationControlEnable" rather than "pethNotificationControlStatus" suggests that a more appropriate SYNTAX would be TruthValue. Thus, it is recommended that the SYNTAX be changed to TruthValue (both in the object definition and in the SEQUENCE) and that the DESCRIPTION clause be updated to read "This object controls, on a per-group basis, whether or not notifications from the agent are enabled. The value true(1) means that notifications are enabled; the value false(2) means that they are not." (o) Regarding the notification definitions: it was recently noted on the mibs@ops.ietf.org mailing list that MIB doctors should make sure that notifications defined in IETF MIB modules cannot "flood" the communication network in case of a high rate of occurrence of the events that trigger them. Hence, it is recommended that the notification definitions in this MIB module include a rate limiting mechanism, e.g., a statement in the DESCRIPTION clause that at least x milliseconds must elapse between successive notifications triggered by any one object instance (this works for the notifications defined in this MIB module because they are triggered by changes in the values of MIB objects). One could either choose a fixed value for x (e.g., 500 msec) or allow it to be configured (another object would need to be defined for that purpose, and it would need to be mentioned in the Security Considerations section). (p) The following warnings are generated from the command smilint -l 9 -s -i namelength-32 ./POWER-ETHERNET-MIB ./POWER-ETHERNET-MIB:667: [6] current group `pethPsePortNotificationGroup' is not referenced in this module ./POWER-ETHERNET-MIB:674: [6] current group `pethMainPowerNotificationGroup' is not referenced in this module These warnings are issued because it it not uncommon for an object group or notification group to be omitted from the conformance statements by mistake. The module is still well-formed, because an object group or notification group that is not mentioned in any MANDATORY-GROUPS clause or in any GROUP clause is unconditionally optional; but it's not altogether clear whether this was the MIB designer's intent or just an oversight. For this reason, it is RECOMMENDED that object groups and notification groups be mentioned in a GROUP clause even when they are unconditionally optional. Appropriate GROUP clauses might be: GROUP pethPsePortNotificationGroup DESCRIPTION "Implementation of the pethPsePortNotificationGroup is RECOMMENDED for systems which implement PSE ports." GROUP pethMainPowerNotificationGroup DESCRIPTION "Implementation of the pethMainPowerNotificationGroup is RECOMMENDED for systems which implement main power supply within a PSE Device." If "RECOMMENDED" is too strong, then "encouraged" or "optional" could be used instead. These GROUP clauses should be added to the end of pethCompliance. [Note: if it was intended that notifications be mandatory, then the language from the other GROUP clauses in the pethCompliance statement should be adapted instead.] (q) If it is indeed the case that the notifications are intended to be optional, then the GROUP clause (in pethCompliance) for pethNotificationControlGroup has an erroneous DESCRIPTION clause. It says "The pethNotificationControlGroup is mandatory for systems which implement PSE ports." It should say "The pethNotificationControlGroup is mandatory for systems which implement notifications." (r) The compliance statements in this MIB module are redundant. It defines pethPseCompliance, which applies to PSEs, and pethPdCompliance, which applies to PDs. But it also defines pethCompliance, which applies to any device, and which is a superset of the other two (it does this by making all groups conditionally mandatory depending on what functions are implemented). This redundancy is not necessary. My recommendation is to remove pethPseCompliance and pethPdCompliance. (s) General comment on REFERENCE clauses: I notice that some of the object definitions have REFERENCE clauses that point to the IEEE specification while others do not. It would indeed be desirable to add reference clauses for all objects that have equivalent GDMO objects in 802.3af clause 30.9; and for those that do not but which require hardware support, it would be good to refer to the clauses in the IEEE specification that mandate the necessary hardware support, as was done in the ETHER-WIS MIB module for the objects in etherWisDeviceGroupBasic and etherWisDeviceGroupExtra (see draft-ietf-hubmib-wis-mib-05.txt or its successor). One word of caution, though: the REFERENCE clauses will need to point to the final published IEEE STD 802.3af and not to IEEE Draft P802.3af/D4.0, and you will need to re-check the clause numbers each time a new version appears. 10.) References (Sections 8 and 9) -- the references need to be updated owing mainly to the publication of the new SNMPv2 RFCs but also to a few errors/oversights. Here are the details: Remove normative reference [RFC2570]. RFC 2570 has been replaced by RFC 3410, which is supposed to be an informative reference. Remove normative references [RFC2571], [RFC2572], [RFC2573], [RFC2574], and [RFC2575] since they are no longer required by the boilerplate and are not used elsewhere. Add a normative reference [RFC2863] to RFC 2863, since InterfaceIndex is imported from the IF-MIB. Remove informative references [RFC1155], [RFC1212], [RFC1215], [RFC1157], [RFC1901], [RFC1905], and [RFC1906] since they are no longer required by the boilerplate and are not used elsewhere. Remove the informative reference [PWR-MIB], since it points to an expired draft that defined a predecessor to this MIB module. Add an informative reference [RFC3410] to RFC 3410 since it is required by the boilerplate and security sections (see http://www.ops.ietf.org/mib-boilerplate.html and comment 11 below). Please revise the style of the references to match that of recently published RFCs (see RFC 3418 or the MIB boilerplate http://www.ops.ietf.org/mib-boilerplate.html for an example). The authors need to be aware that this document can go through the IETF approval process but cannot be published as an RFC as long as [IEEE-802.3af] points to IEEE Draft P802.3af/D4.0 (or any other version of the draft) rather than IEEE STD 802.3af. That reference, however, should _not_ be updated until the final standard is actually approved, and then there should be a final review of this document to ensure that it is editorially and technically consistent with the final IEEE standard ... things like clause numbers (which are used in the REFERENCE clauses) are subject to change even very late in the process. 10.) IPR Notices (Section 10) -- probably OK: the draft contains verbatim copies of the IPR notices specified in bullets (A) and (B) of Section 10.4 of RFC 2026 as required, but the AUTHORS NEED TO CONFIRM that the notice in bullet (D) is not needed. 11.) Security Considerations Section -- the MIB security guidelines are in the process of being updated, so the text on the OPS area web site (http://www.ops.ietf.org/security.html) is out of date. However, based on the latest wisdom to appear on the mibs@ops.ietf.org mailing list, I would recommend a rewrite along the following lines: There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. These are: pethPsePortAdminEnable pethPsePortPowerPairs pethPsePortPowerDetectionControl pethPsePortPowerPriority pethPsePortType pethPdPortAdminEnable pethMainPseUsageThreshold pethNotificationControlEnable Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) contain information that may be considered sensitive in some network environments. These are: pethPsePortPowerPairsControlAbility pethPsePortPowerPriority pethPsePortPowerClassifications It is thus important to control even GET and NOTIFY access to these objects and possibly 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. 12.) IANA Considerations section (none present) -- NEED TO CHECK WITH OUR AD. An IANA Considerations section probably should not be needed since this document does not define a name space. However, the current version of http://www.ietf.org/ID-nits.html states that there is supposed to be an IANA considerations section whenever IANA is reequired to make an assignment in a registry prior to RFC publication. I have raised objections about this policy, and an answer from our AD is pending. For the time being I think that the notation powerEthernetMIB MODULE-IDENTITY [ ... ] ::= { mib-2 XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice that is already present will suffice; but if an IANA Considerations section has to be written, I would suggest something along the lines of The POWER-ETHERNET-MIB module defined in this document is registered under an IANA-assigned node in the mib-2 OBJECT IDENTIFIER subtree [RFC2578]. That node is defined as "powerEthernetMIB" in the POWER-ETHERNET-MIB MODULE-IDENTITY invocation. Subordinate assignments under powerEthernetMIB will be managed by the IETF working group responsible for maintaining the ETHER-WIS MIB module; no further IANA action is required. ******************************************************* * EDITOR'S NOTE (to be removed prior to publication): * * before this draft is published as an RFC, a subid * * under the mib-2 OBJECT IDENTIFIER subtree needs to * * be assigned by IANA for powerEthernetMIB, and this * * subid needs to be inserted by the RFC Editor into * * the POWER-ETHERNET-MIB -WIS MODULE-IDENTITY value. * ******************************************************* 13.) Copyrights -- the full copyright notice should start with the line Copyright (C) The Internet Society (date). All Rights Reserved. The absence of a copyright notice in the DESCRIPTION clause of the MODULE-IDENTITY invocation was noted in 9(b) bove. Note: when the draft is resubmitted, please be sure to change the year to 2003 in all three places (on the front page, in the DESCRIPTON clause of the MODULE-IDENTITY invocation, and in the full copyright statement). 14.) General comments on formatting -- the layout of the MIB module is not uniform, as noted in a couple of places in (9) above, and it would be nice to have that fixed. Also, the draft does not fully adhere to the document formatting guidelines in Instructions to RFC Authors, . That can be fixed during the final editing process, but it would speed up the process (and reduce the chances for error) if the next version of the draft would attempt to comply more closely with those guidelines. //cmh _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Sat Jan 4 08:04:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10304 for ; Sat, 4 Jan 2003 08:04:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04DE9J17810 for hubmib-archive@odin.ietf.org; Sat, 4 Jan 2003 08:14:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04DE8J17805; Sat, 4 Jan 2003 08:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04DDuJ17786 for ; Sat, 4 Jan 2003 08:13:56 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10298 for ; Sat, 4 Jan 2003 08:04:08 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h04D7Ih04140 for ; Sat, 4 Jan 2003 08:07:18 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Jan 2003 14:07:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DBF5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , Hubmib Cc: Avi Berger , "Romascanu, Dan (Dan)" Subject: RE: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib- 04.txt Date: Sat, 4 Jan 2003 14:07:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mike, first thanks for an excellent and very detailed review. This will help improve the document quite a bit. There is one issue that I would like to add: The tables (I believe all of them) contain read-write objects. What is not clear to me is what happens in case of a reboot or restart. Do the values that have been SET by an NMS survive a restart/reboot? I think it would be good to add that behaviour to the DESCRIPTION clauses, either of each of the Table definitions (if all writable objects in the table are supposed to behave the same in this respect) or in each writable object (if they have different behaviour within the same table). My current understanding is that we do not need an IANA Considerations section and that the notation ::= { mib-2 XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice will do. Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: zaterdag 4 januari 2003 7:51 > To: Hubmib > Cc: Avi Berger; Romascanu, Dan (Dan); Wijnen, Bert (Bert) > Subject: Re: [Hubmib] WG Last Call - > draft-ietf-hubmib-power-ethernet-mib-04.txt > > > On Mon, 23 Dec 2002, Romascanu, Dan (Dan) wrote: > > > >This is the official announcement for the Working Group Last Call for > >the Power Ethernet MIB. The Internet-Draft is available at > > > >http://www.ietf.org/internet-drafts/draft-ietf-hubmib-power-e > thernet-mib-04.txt > > > >Please send your comments until the latest January 15, 2003, to > >hubmib@ietf.org. > > In an effort to help the WG produce the cleanest possible document > I've attempted to do a fairly detailed "MIB Doctor" on this draft. > Please note that I've not been able to check the document for > editorial and technical consistency with the 802.3af draft, since > I have not been participating in the Power Ethernet work and do not > have access to the specification. Someone else should do that check. > > The following list of comments goes through the sections of > the document in the order that they appear. > > 1.) I-D Boilerplate -- OK (required stuff is present, and there > are no references or section numbers). > > 2.) Abstract -- references are not allowed in the abstract; > please change "Ethernet-like Interfaces MIB [RFC2665]" to > "Ethernet-like Interfaces MIB". > > 3.) Introduction (Section 1) -- in the first paragraph the acronyms > MDI and arguably DTE are not common terms and therefore need to be > expanded on first use, or else removed. My suggestion would be > to change "Power Ethernet (DTE Power via MDI)" to "Power > Ethernet [IEEE-802.3af]" which will circumvent the need to > define those terms here. In the second paragraph please change > the reference from [RFC2863] to [RFC2119]. > > 4.) MIB Boilerplate (Section 2) -- the official MIB boilerplate has > been changed owing to the publication of the full-standard SNMPv3 > RFCs. So, please change the section heading to "Internet-Standard > Management Framework" and use the boilerplate text from the OPS area > web site (http://www.ops.ietf.org/mib-boilerplate.html). Note that > the new boilerplate uses [RFC3410] instead of [RFC2570] and does not > refer to the SNMP protocol documents themselves. > > 5.) Overview (Section 3) -- OK > > 6.) MIB Structure (Section 4) -- in the first sentence please change > "and the fourth scalar objects" to "and the fourth contains scalar > objects." > > 7.) Evolution of the Document, Limitations and Future Work > (Section 5) -- > in its present form this section would not be appropriate in the final > published RFC. It should either be reworded, eliminated from > the draft, > or moved to the back of the draft with a prominent note > telling the RFC > Editor that it is to be removed prior to publication. > > 8.) Changes Log (Section 6) -- this section would not be > appropriate in > the final published RFC. It should be moved to the back of the draft > with a prominent telling the RFC Editor that it is to be removed prior > to publication. In addition, please change "[PWR-MIB]" to > "draft-romascanu-hubmib-power-ethernet-mib-00.txt"; this reference > needs to be removed (see below) since it points to an expired draft. > > 9.) Definitions (Section 7) -- there are two MIB compiler warnings > related to unreferenced notification groups plus several other things > that either need correction or that could (in the opinion of this > reviewer) be improved. I'll go through them in the order in which > they appear in the MIB module. > > (a) Our AD has requested that working group mailing list information > appear in the CONTACT-INFO clause of the MODULE-IDENTITY invocation. > You may therefore want to add the following lines at the top: > > WG charter: > http://www.ietf.org/html.charters/hubmib-charter.html > > Mailing Lists: > General Discussion: hubmib@ietf.org > To Subscribe: hubmib-request@ietf.org > In Body: subscribe your_email_address > > and change the indentation of the rest of the stuff to match (you > should not go beyond column 72, see http://www.ietf.org/ID-nits.html). > > (b) IESG policy now requires that a copyright notice appear in > the DESCRIPTION clause of the MODULE-IDENTITY invocation (see > http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt for > details). Here is a suitable template: > > DESCRIPTION > "[ ... ] > > Copyright (C) The Internet Society (date). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > Prior to submission '(date)' must be replaced with the current year, > i.e., '(2003)'. > > (c) The "box in the stack, module in a rack" language that > appears in the DESCRIPTION clauses for pethPsePortGroupIndex, > pethMainPseGroupIndex, and pethNotificationControlGroupIndex > suggests that the same value will be used in all three of > these indices to refer to a given physical entity. If that > is true, it would be best to say so explicitly, and in that > case I would recommend modifying the DESCRIPTION clause for > pethPsePortGroupIndex to something along the following lines: > > "This variable uniquely identifies the group containing > the port to which a power Ethernet PSE is connected. > 'Group' means (box in the stack, module in a rack) > and the value 1 MUST be used for non-modular devices. > Furthermore, the same value MUST be used in this > variable, pethMainPseGroupIndex, and > pethNotificationControlGroupIndex to refer to a > given (box in the stack, module in a rack)." > > In any case, the sentence "pethPseMidSpanGroupCapacity is the number > of Mid-Span PSE groups that can be contained within the Mid-Span PSE" > needs to be removed because there no such object (indeed, there is no > mention of pethPseMidSpanGroupCapacity anywhere else in the document). > > (d) In the DESCRIPTION clause for pethPsePortIndex please change > "pethPseGroupIndex" to "pethPsePortGroupIndex". > > (e) In the following object definition > > pethPsePortAdminEnable OBJECT-TYPE > SYNTAX INTEGER { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Enables power supply on this port. > Setting this object at a value enable(1) enables power > and detection mechanism for this port. > Setting this object at a value disable(2) disables power > for this port." > ::= { pethPsePortEntry 3 } > > use of the name "pethPsePortAdminEnable" rather than > "pethPsePortAdminStatus" > suggests that a more appropriate SYNTAX would be TruthValue. > Thus, it is > recommended that the SYNTAX be changed to TruthValue (both in > the object > definition and in the SEQUENCE) and that the DESCRIPTION > clause be updated > to match by changing "the value enable(1)" to "the value > true(1)" and by > changing "the value disable(2)" to "the value false(2)". [It > would also > be nice to have the object name appear a few columns to the > left of the > SYNTAX, MAX-ACCESS, STATUS, and DESCRIPTION clauses as it does in most > other object definitions; maybe indent all the other clauses three > spaces, as was done in the definitions of the index objects?] > > (f) In the following object definition > > pethPsePortDetectionStatus OBJECT-TYPE > SYNTAX INTEGER { > disabled(1), > searching(2), > deliveringPower(4), > fault(5), > test(7), > denyLowPriority(8) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Describes the operational status of the port PD detection. > A value of disabled(1)- indicates that the PSE > State diagram is in > the state IDLE > A value of searching(2)- indicates that the PSE > State diagram is in > the state DETECTION, CLASSIFICATION, > SIGNATURE_INVALID or BACKOFF. > A value of deliveringPower(4) - indicates that > the PSE State diagram > is in the state POWER_UP, POWER_ON or POWER_OFF. > A value of fault(5) - indicates that the PSE > State diagram is in the > state TEST_ERROR or the state IDLE due to the > variable error > condition. > Faults detected are vendor specific. > A value of test(7) - indicates that the PSE State > diagram is in the > state TEST_MODE. > A value of denyLowPriority(8) indicates that the port was > disabled by the power management system, in order to keep > active higher priority ports. > " > ::= { pethPsePortEntry 7 } > > the enumerations are not contiguous, which is allowed but > contrary to the > recommendations in RFC 2578 Section 7.1.1. Is there a reason > for this? > If there isn't, please change to conform to the > recommendations. If there > is, it would be a good idea to document it (e.g., if you are aligning > with the numbering of states in the IEEE specification then > say so, and > maybe even add a REFERENCE clause). > > (g) In the following object definition > > pethPsePortPowerMaintenanceStatus OBJECT-TYPE > SYNTAX INTEGER { > ok(1), > underCurrent(2), > mPSAbsent(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value ok(1) indicates the Power Maintenance > Signature is present and the overcurrent > condition has not been > detected. > The value overCurrent (2) indicates an > overcurrent condition > has been detected. > The value mPSAbsent(3) indicates that the Power > Maintenance > Signature is absent." > > > REFERENCE "[IEEE Draft P802.3af/D4.0, November, > 2002, 30.9.1.1.8 > aPSEPowerMaintenanceStatus]" > ::= { pethPsePortEntry 10 } > > the enumeration labels and the DESCRIPTION clauses don't match. This > needs to be fixed; it appears that "underCurrent" should be > "overCurrent". > > [ Scott Mains has also pointed this out in a message posted > 19 Dec 2002.] > > (h) In the DESCRIPTION clause for this object > > pethPsePortOverCurrentCounter OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Counts the number of times that the > aPSEPowerCurrentStatus > attribute changes from any value to the > value overCurrent(2)." > REFERENCE "[IEEE Draft P802.3af/D4.0, November, > 2002, object 30.9.1.1.1 > aPSEOverCurrentCounter]" > ::= { pethPsePortEntry 12 } > > please change "aPSEPowerCurrentStatus" to > "pethPsePortPowerMaintenanceStatus". > > [ Scott Mains has also pointed this out in a message posted > 19 Dec 2002.] > > (i) In the following object > > pethPsePortPowerClassifications OBJECT-TYPE > SYNTAX INTEGER { > class0(1), > class1(2), > class2(3), > class3(4), > class4(5) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Classification is a way to tag different terminals on the > Power over LAN network according to their power > consumption. > Devices such as IP telephones, WLAN access points > and others, > will be classified according to their power requirements. > > The value is only valid while a valid PD is being > detected as > indicated by the attribute > pethPsePortDetectionStatus reporting > the value or deliveringPower(4)." > REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, > object 30.9.1.1.7 aPSEPowerClassification]" > ::= { pethPsePortEntry 14 } > > are the classification labels 'class0' and so on defined in the IEEE > specification? If so, please add a sentence along the lines of > > The meaning of the classification labels is defined in the > IEEE specification. > > at the end of the first paragraph of the DESCRIPTION clause. (Also, > if the IEEE document uses numeric values 0 through 4 for > class0 through > class 4 you _might_ want to do the same thing -- this would fall under > the "valid reason" exemption to the "start at 1" recommendation.) > > (j) You may want to add the following REFERENCE clause to the > definition of pethPdPortIndex: > > REFERENCE "RFC 2863, ifIndex" > > (k) In the following object > > pethPdPortAdminEnable OBJECT-TYPE > SYNTAX INTEGER { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This value identifies the operational state of > the PD functions. > An interface which can provide the PD > functions will be enabled > to do so when this attribute has the value > enable. When this > attribute has the value disable the > interface will act > as it would if it had no PD function." > ::= { pethPdPortEntry 2 } > > the name and semantics (in particular the fact that it is > writeable) suggests > that it is an administrative state while the DESCRIPTION says > that it is an > operational state. If it is indeed an admin state, please > change the words > "operational state" to "administrative state" in the > DESCRIPTION. Also, > use of the name "pethPdPortAdminEnable" rather than > "pethPdPortAdminStatus" > suggests that a more appropriate SYNTAX would be TruthValue. > Thus, it is > recommended that the SYNTAX be changed to TruthValue (both in > the object > definition and in the SEQUENCE) and that the DESCRIPTION > clause be updated > to match by changing "the value enable" to "the value true(1)" and by > changing "the value disable" to "the value false(2)". > > (l) The "box in the stack, module in a rack" language that > appears in the DESCRIPTION clauses for pethPsePortGroupIndex, > pethMainPseGroupIndex, and pethNotificationControlGroupIndex > suggests that the same value will be used in all three of > these indices to refer to a given physical entity. If that > is true, it would be best to say so explicitly, and in that > case I would recommend modifying the DESCRIPTION clause for > pethMainPseGroupIndex to something along the following lines: > > "This variable uniquely identifies the group to > which a power Ethernet PSE is connected. 'Group' > means (box in the stack, module in a rack) and > the value 1 MUST be used for non-modular devices. > Furthermore, the same value MUST be used in this > variable, pethPsePortGroupIndex, and > pethNotificationControlGroupIndex to refer to > a given (box in the stack, module in a rack)." > > (m) Making the same assumptions as above, the equivalent > modification for > pethNotificationControlGroupIndex would be: > > "This variable uniquely identifies the group. > 'Group' means (box in the stack, module in a rack) > and the value 1 MUST be used for non-modular > devices. Furthermore, the same value MUST be > used in this variable, pethPsePortGroupIndex, > and pethMainPseGroupIndex to refer to a > given (box in the stack, module in a rack)." > > In any case, the current language "it is RECOMENDED that the value 1 > be used for non-modular devices" is not consistent with that in the > DESCRIPTION clauses for pethPsePortGroupIndex and > pethMainPseGroupIndex; > the same imperative should be used in all three places. I think that > the MUST wording is the right way to go, since it does not cost the > agent anything and makes life easier for the manager. > > (n) In the following object > > pethNotificationControlEnable OBJECT-TYPE > SYNTAX INTEGER > { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Enable Notification from Agent" > > use of the name "pethNotificationControlEnable" rather than > "pethNotificationControlStatus" suggests that a more > appropriate SYNTAX > would be TruthValue. Thus, it is recommended that the SYNTAX > be changed > to TruthValue (both in the object definition and in the SEQUENCE) and > that the DESCRIPTION clause be updated to read > > "This object controls, on a per-group basis, whether > or not notifications from the agent are enabled. The > value true(1) means that notifications are enabled; the > value false(2) means that they are not." > > (o) Regarding the notification definitions: it was recently noted > on the mibs@ops.ietf.org mailing list that MIB doctors should make > sure that notifications defined in IETF MIB modules cannot "flood" > the communication network in case of a high rate of occurrence of > the events that trigger them. Hence, it is recommended that the > notification definitions in this MIB module include a rate limiting > mechanism, e.g., a statement in the DESCRIPTION clause that at least > x milliseconds must elapse between successive notifications triggered > by any one object instance (this works for the notifications defined > in this MIB module because they are triggered by changes in the > values of MIB objects). One could either choose a fixed value for x > (e.g., 500 msec) or allow it to be configured (another object would > need to be defined for that purpose, and it would need to be > mentioned in the Security Considerations section). > > (p) The following warnings are generated from the command > smilint -l 9 -s -i namelength-32 ./POWER-ETHERNET-MIB > > ./POWER-ETHERNET-MIB:667: [6] current group > `pethPsePortNotificationGroup' > is not referenced in this module > ./POWER-ETHERNET-MIB:674: [6] current group > `pethMainPowerNotificationGroup' > is not referenced in this module > > These warnings are issued because it it not uncommon for an > object group > or notification group to be omitted from the conformance statements by > mistake. The module is still well-formed, because an object group or > notification group that is not mentioned in any > MANDATORY-GROUPS clause > or in any GROUP clause is unconditionally optional; but it's not > altogether clear whether this was the MIB designer's intent or just an > oversight. For this reason, it is RECOMMENDED that object groups and > notification groups be mentioned in a GROUP clause even when they are > unconditionally optional. Appropriate GROUP clauses might be: > > GROUP pethPsePortNotificationGroup > DESCRIPTION > "Implementation of the pethPsePortNotificationGroup is > RECOMMENDED for systems which implement PSE ports." > GROUP pethMainPowerNotificationGroup > DESCRIPTION > "Implementation of the > pethMainPowerNotificationGroup is > RECOMMENDED for systems which implement main > power supply > within a PSE Device." > > If "RECOMMENDED" is too strong, then "encouraged" or "optional" could > be used instead. These GROUP clauses should be added to the end of > pethCompliance. [Note: if it was intended that notifications be > mandatory, then the language from the other GROUP clauses in the > pethCompliance statement should be adapted instead.] > > (q) If it is indeed the case that the notifications are intended to > be optional, then the GROUP clause (in pethCompliance) for > pethNotificationControlGroup has an erroneous DESCRIPTION clause. It > says "The pethNotificationControlGroup is mandatory for systems which > implement PSE ports." It should say "The pethNotificationControlGroup > is mandatory for systems which implement notifications." > > (r) The compliance statements in this MIB module are redundant. It > defines pethPseCompliance, which applies to PSEs, and > pethPdCompliance, > which applies to PDs. But it also defines pethCompliance, which > applies to any device, and which is a superset of the other two (it > does this by making all groups conditionally mandatory depending on > what functions are implemented). This redundancy is not necessary. > My recommendation is to remove pethPseCompliance and pethPdCompliance. > > (s) General comment on REFERENCE clauses: I notice that some of the > object definitions have REFERENCE clauses that point to the IEEE > specification while others do not. It would indeed be desirable to > add reference clauses for all objects that have equivalent GDMO > objects in 802.3af clause 30.9; and for those that do not but which > require hardware support, it would be good to refer to the clauses > in the IEEE specification that mandate the necessary hardware support, > as was done in the ETHER-WIS MIB module for the objects in > etherWisDeviceGroupBasic and etherWisDeviceGroupExtra (see > draft-ietf-hubmib-wis-mib-05.txt or its successor). One word of > caution, though: the REFERENCE clauses will need to point to the > final published IEEE STD 802.3af and not to IEEE Draft P802.3af/D4.0, > and you will need to re-check the clause numbers each time a new > version appears. > > 10.) References (Sections 8 and 9) -- the references need to be > updated owing mainly to the publication of the new SNMPv2 RFCs > but also to a few errors/oversights. Here are the details: > > Remove normative reference [RFC2570]. RFC 2570 has been replaced > by RFC 3410, which is supposed to be an informative reference. > > Remove normative references [RFC2571], [RFC2572], [RFC2573], > [RFC2574], and [RFC2575] since they are no longer required > by the boilerplate and are not used elsewhere. > > Add a normative reference [RFC2863] to RFC 2863, since > InterfaceIndex is imported from the IF-MIB. > > Remove informative references [RFC1155], [RFC1212], [RFC1215], > [RFC1157], [RFC1901], [RFC1905], and [RFC1906] since they are > no longer required by the boilerplate and are not used elsewhere. > > Remove the informative reference [PWR-MIB], since it points to > an expired draft that defined a predecessor to this MIB module. > > Add an informative reference [RFC3410] to RFC 3410 since > it is required by the boilerplate and security sections > (see http://www.ops.ietf.org/mib-boilerplate.html and > comment 11 below). > > Please revise the style of the references to match that of > recently published RFCs (see RFC 3418 or the MIB boilerplate > http://www.ops.ietf.org/mib-boilerplate.html for an example). > > The authors need to be aware that this document can go through > the IETF approval process but cannot be published as an RFC as > long as [IEEE-802.3af] points to IEEE Draft P802.3af/D4.0 (or > any other version of the draft) rather than IEEE STD 802.3af. > That reference, however, should _not_ be updated until the final > standard is actually approved, and then there should be a final > review of this document to ensure that it is editorially and > technically consistent with the final IEEE standard ... things > like clause numbers (which are used in the REFERENCE clauses) > are subject to change even very late in the process. > > 10.) IPR Notices (Section 10) -- probably OK: the draft contains > verbatim copies of the IPR notices specified in bullets (A) and (B) > of Section 10.4 of RFC 2026 as required, but the AUTHORS NEED TO > CONFIRM that the notice in bullet (D) is not needed. > > 11.) Security Considerations Section -- the MIB security guidelines > are in the process of being updated, so the text on the OPS area web > site (http://www.ops.ietf.org/security.html) is out of date. However, > based on the latest wisdom to appear on the mibs@ops.ietf.org mailing > list, I would recommend a rewrite along the following lines: > > There are a number of management objects defined in this MIB module > with a MAX-ACCESS clause of read-write. These are: > > pethPsePortAdminEnable > pethPsePortPowerPairs > pethPsePortPowerDetectionControl > pethPsePortPowerPriority > pethPsePortType > pethPdPortAdminEnable > pethMainPseUsageThreshold > pethNotificationControlEnable > > Such objects may be considered sensitive or vulnerable in some > network environments. The support for SET operations in a > non-secure > environment without proper protection can have a negative effect on > network operations. > > Some of the readable objects in this MIB module (i.e., > objects with a > MAX-ACCESS other than not-accessible) contain information > that may be > considered sensitive in some network environments. These are: > > pethPsePortPowerPairsControlAbility > pethPsePortPowerPriority > pethPsePortPowerClassifications > > It is thus important to control even GET and NOTIFY access to these > objects and possibly 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. > > 12.) IANA Considerations section (none present) -- NEED TO CHECK > WITH OUR AD. An IANA Considerations section probably should not > be needed since this document does not define a name space. However, > the current version of http://www.ietf.org/ID-nits.html states that > there is supposed to be an IANA considerations section whenever > IANA is reequired to make an assignment in a registry prior to RFC > publication. I have raised objections about this policy, and an > answer from our AD is pending. For the time being I think that > the notation > > powerEthernetMIB MODULE-IDENTITY > > [ ... ] > > ::= { mib-2 XXX } > -- RFC Ed.: replace XXX with IANA-assigned number & remove > this notice > > that is already present will suffice; but if an IANA Considerations > section has to be written, I would suggest something along > the lines of > > The POWER-ETHERNET-MIB module defined in this document is > registered > under an IANA-assigned node in the mib-2 OBJECT IDENTIFIER subtree > [RFC2578]. That node is defined as "powerEthernetMIB" in the > POWER-ETHERNET-MIB MODULE-IDENTITY invocation. Subordinate > assignments under powerEthernetMIB will be managed by the IETF > working group responsible for maintaining the ETHER-WIS MIB module; > no further IANA action is required. > > ******************************************************* > * EDITOR'S NOTE (to be removed prior to publication): * > * before this draft is published as an RFC, a subid * > * under the mib-2 OBJECT IDENTIFIER subtree needs to * > * be assigned by IANA for powerEthernetMIB, and this * > * subid needs to be inserted by the RFC Editor into * > * the POWER-ETHERNET-MIB -WIS MODULE-IDENTITY value. * > ******************************************************* > > 13.) Copyrights -- the full copyright notice should start > with the line > > Copyright (C) The Internet Society (date). All Rights Reserved. > > The absence of a copyright notice in the DESCRIPTION clause of the > MODULE-IDENTITY invocation was noted in 9(b) bove. > > Note: when the draft is resubmitted, please be sure to > change the year > to 2003 in all three places (on the front page, in the > DESCRIPTON clause > of the MODULE-IDENTITY invocation, and in the full copyright > statement). > > 14.) General comments on formatting -- the layout of the MIB module > is not uniform, as noted in a couple of places in (9) above, and it > would be nice to have that fixed. Also, the draft does not fully > adhere to the document formatting guidelines in Instructions to RFC > Authors, . That can be > fixed during > the final editing process, but it would speed up the process > (and reduce > the chances for error) if the next version of the draft would attempt > to comply more closely with those guidelines. > > //cmh > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sat Jan 4 08:05:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10319 for ; Sat, 4 Jan 2003 08:05:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04DE8J17805; Sat, 4 Jan 2003 08:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04DDuJ17786 for ; Sat, 4 Jan 2003 08:13:56 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10298 for ; Sat, 4 Jan 2003 08:04:08 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h04D7Ih04140 for ; Sat, 4 Jan 2003 08:07:18 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Jan 2003 14:07:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DBF5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , Hubmib Cc: Avi Berger , "Romascanu, Dan (Dan)" Subject: RE: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib- 04.txt Date: Sat, 4 Jan 2003 14:07:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mike, first thanks for an excellent and very detailed review. This will help improve the document quite a bit. There is one issue that I would like to add: The tables (I believe all of them) contain read-write objects. What is not clear to me is what happens in case of a reboot or restart. Do the values that have been SET by an NMS survive a restart/reboot? I think it would be good to add that behaviour to the DESCRIPTION clauses, either of each of the Table definitions (if all writable objects in the table are supposed to behave the same in this respect) or in each writable object (if they have different behaviour within the same table). My current understanding is that we do not need an IANA Considerations section and that the notation ::= { mib-2 XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice will do. Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: zaterdag 4 januari 2003 7:51 > To: Hubmib > Cc: Avi Berger; Romascanu, Dan (Dan); Wijnen, Bert (Bert) > Subject: Re: [Hubmib] WG Last Call - > draft-ietf-hubmib-power-ethernet-mib-04.txt > > > On Mon, 23 Dec 2002, Romascanu, Dan (Dan) wrote: > > > >This is the official announcement for the Working Group Last Call for > >the Power Ethernet MIB. The Internet-Draft is available at > > > >http://www.ietf.org/internet-drafts/draft-ietf-hubmib-power-e > thernet-mib-04.txt > > > >Please send your comments until the latest January 15, 2003, to > >hubmib@ietf.org. > > In an effort to help the WG produce the cleanest possible document > I've attempted to do a fairly detailed "MIB Doctor" on this draft. > Please note that I've not been able to check the document for > editorial and technical consistency with the 802.3af draft, since > I have not been participating in the Power Ethernet work and do not > have access to the specification. Someone else should do that check. > > The following list of comments goes through the sections of > the document in the order that they appear. > > 1.) I-D Boilerplate -- OK (required stuff is present, and there > are no references or section numbers). > > 2.) Abstract -- references are not allowed in the abstract; > please change "Ethernet-like Interfaces MIB [RFC2665]" to > "Ethernet-like Interfaces MIB". > > 3.) Introduction (Section 1) -- in the first paragraph the acronyms > MDI and arguably DTE are not common terms and therefore need to be > expanded on first use, or else removed. My suggestion would be > to change "Power Ethernet (DTE Power via MDI)" to "Power > Ethernet [IEEE-802.3af]" which will circumvent the need to > define those terms here. In the second paragraph please change > the reference from [RFC2863] to [RFC2119]. > > 4.) MIB Boilerplate (Section 2) -- the official MIB boilerplate has > been changed owing to the publication of the full-standard SNMPv3 > RFCs. So, please change the section heading to "Internet-Standard > Management Framework" and use the boilerplate text from the OPS area > web site (http://www.ops.ietf.org/mib-boilerplate.html). Note that > the new boilerplate uses [RFC3410] instead of [RFC2570] and does not > refer to the SNMP protocol documents themselves. > > 5.) Overview (Section 3) -- OK > > 6.) MIB Structure (Section 4) -- in the first sentence please change > "and the fourth scalar objects" to "and the fourth contains scalar > objects." > > 7.) Evolution of the Document, Limitations and Future Work > (Section 5) -- > in its present form this section would not be appropriate in the final > published RFC. It should either be reworded, eliminated from > the draft, > or moved to the back of the draft with a prominent note > telling the RFC > Editor that it is to be removed prior to publication. > > 8.) Changes Log (Section 6) -- this section would not be > appropriate in > the final published RFC. It should be moved to the back of the draft > with a prominent telling the RFC Editor that it is to be removed prior > to publication. In addition, please change "[PWR-MIB]" to > "draft-romascanu-hubmib-power-ethernet-mib-00.txt"; this reference > needs to be removed (see below) since it points to an expired draft. > > 9.) Definitions (Section 7) -- there are two MIB compiler warnings > related to unreferenced notification groups plus several other things > that either need correction or that could (in the opinion of this > reviewer) be improved. I'll go through them in the order in which > they appear in the MIB module. > > (a) Our AD has requested that working group mailing list information > appear in the CONTACT-INFO clause of the MODULE-IDENTITY invocation. > You may therefore want to add the following lines at the top: > > WG charter: > http://www.ietf.org/html.charters/hubmib-charter.html > > Mailing Lists: > General Discussion: hubmib@ietf.org > To Subscribe: hubmib-request@ietf.org > In Body: subscribe your_email_address > > and change the indentation of the rest of the stuff to match (you > should not go beyond column 72, see http://www.ietf.org/ID-nits.html). > > (b) IESG policy now requires that a copyright notice appear in > the DESCRIPTION clause of the MODULE-IDENTITY invocation (see > http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt for > details). Here is a suitable template: > > DESCRIPTION > "[ ... ] > > Copyright (C) The Internet Society (date). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > Prior to submission '(date)' must be replaced with the current year, > i.e., '(2003)'. > > (c) The "box in the stack, module in a rack" language that > appears in the DESCRIPTION clauses for pethPsePortGroupIndex, > pethMainPseGroupIndex, and pethNotificationControlGroupIndex > suggests that the same value will be used in all three of > these indices to refer to a given physical entity. If that > is true, it would be best to say so explicitly, and in that > case I would recommend modifying the DESCRIPTION clause for > pethPsePortGroupIndex to something along the following lines: > > "This variable uniquely identifies the group containing > the port to which a power Ethernet PSE is connected. > 'Group' means (box in the stack, module in a rack) > and the value 1 MUST be used for non-modular devices. > Furthermore, the same value MUST be used in this > variable, pethMainPseGroupIndex, and > pethNotificationControlGroupIndex to refer to a > given (box in the stack, module in a rack)." > > In any case, the sentence "pethPseMidSpanGroupCapacity is the number > of Mid-Span PSE groups that can be contained within the Mid-Span PSE" > needs to be removed because there no such object (indeed, there is no > mention of pethPseMidSpanGroupCapacity anywhere else in the document). > > (d) In the DESCRIPTION clause for pethPsePortIndex please change > "pethPseGroupIndex" to "pethPsePortGroupIndex". > > (e) In the following object definition > > pethPsePortAdminEnable OBJECT-TYPE > SYNTAX INTEGER { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Enables power supply on this port. > Setting this object at a value enable(1) enables power > and detection mechanism for this port. > Setting this object at a value disable(2) disables power > for this port." > ::= { pethPsePortEntry 3 } > > use of the name "pethPsePortAdminEnable" rather than > "pethPsePortAdminStatus" > suggests that a more appropriate SYNTAX would be TruthValue. > Thus, it is > recommended that the SYNTAX be changed to TruthValue (both in > the object > definition and in the SEQUENCE) and that the DESCRIPTION > clause be updated > to match by changing "the value enable(1)" to "the value > true(1)" and by > changing "the value disable(2)" to "the value false(2)". [It > would also > be nice to have the object name appear a few columns to the > left of the > SYNTAX, MAX-ACCESS, STATUS, and DESCRIPTION clauses as it does in most > other object definitions; maybe indent all the other clauses three > spaces, as was done in the definitions of the index objects?] > > (f) In the following object definition > > pethPsePortDetectionStatus OBJECT-TYPE > SYNTAX INTEGER { > disabled(1), > searching(2), > deliveringPower(4), > fault(5), > test(7), > denyLowPriority(8) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Describes the operational status of the port PD detection. > A value of disabled(1)- indicates that the PSE > State diagram is in > the state IDLE > A value of searching(2)- indicates that the PSE > State diagram is in > the state DETECTION, CLASSIFICATION, > SIGNATURE_INVALID or BACKOFF. > A value of deliveringPower(4) - indicates that > the PSE State diagram > is in the state POWER_UP, POWER_ON or POWER_OFF. > A value of fault(5) - indicates that the PSE > State diagram is in the > state TEST_ERROR or the state IDLE due to the > variable error > condition. > Faults detected are vendor specific. > A value of test(7) - indicates that the PSE State > diagram is in the > state TEST_MODE. > A value of denyLowPriority(8) indicates that the port was > disabled by the power management system, in order to keep > active higher priority ports. > " > ::= { pethPsePortEntry 7 } > > the enumerations are not contiguous, which is allowed but > contrary to the > recommendations in RFC 2578 Section 7.1.1. Is there a reason > for this? > If there isn't, please change to conform to the > recommendations. If there > is, it would be a good idea to document it (e.g., if you are aligning > with the numbering of states in the IEEE specification then > say so, and > maybe even add a REFERENCE clause). > > (g) In the following object definition > > pethPsePortPowerMaintenanceStatus OBJECT-TYPE > SYNTAX INTEGER { > ok(1), > underCurrent(2), > mPSAbsent(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value ok(1) indicates the Power Maintenance > Signature is present and the overcurrent > condition has not been > detected. > The value overCurrent (2) indicates an > overcurrent condition > has been detected. > The value mPSAbsent(3) indicates that the Power > Maintenance > Signature is absent." > > > REFERENCE "[IEEE Draft P802.3af/D4.0, November, > 2002, 30.9.1.1.8 > aPSEPowerMaintenanceStatus]" > ::= { pethPsePortEntry 10 } > > the enumeration labels and the DESCRIPTION clauses don't match. This > needs to be fixed; it appears that "underCurrent" should be > "overCurrent". > > [ Scott Mains has also pointed this out in a message posted > 19 Dec 2002.] > > (h) In the DESCRIPTION clause for this object > > pethPsePortOverCurrentCounter OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Counts the number of times that the > aPSEPowerCurrentStatus > attribute changes from any value to the > value overCurrent(2)." > REFERENCE "[IEEE Draft P802.3af/D4.0, November, > 2002, object 30.9.1.1.1 > aPSEOverCurrentCounter]" > ::= { pethPsePortEntry 12 } > > please change "aPSEPowerCurrentStatus" to > "pethPsePortPowerMaintenanceStatus". > > [ Scott Mains has also pointed this out in a message posted > 19 Dec 2002.] > > (i) In the following object > > pethPsePortPowerClassifications OBJECT-TYPE > SYNTAX INTEGER { > class0(1), > class1(2), > class2(3), > class3(4), > class4(5) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Classification is a way to tag different terminals on the > Power over LAN network according to their power > consumption. > Devices such as IP telephones, WLAN access points > and others, > will be classified according to their power requirements. > > The value is only valid while a valid PD is being > detected as > indicated by the attribute > pethPsePortDetectionStatus reporting > the value or deliveringPower(4)." > REFERENCE "[IEEE Draft P802.3af/D4.0, November, 2002, > object 30.9.1.1.7 aPSEPowerClassification]" > ::= { pethPsePortEntry 14 } > > are the classification labels 'class0' and so on defined in the IEEE > specification? If so, please add a sentence along the lines of > > The meaning of the classification labels is defined in the > IEEE specification. > > at the end of the first paragraph of the DESCRIPTION clause. (Also, > if the IEEE document uses numeric values 0 through 4 for > class0 through > class 4 you _might_ want to do the same thing -- this would fall under > the "valid reason" exemption to the "start at 1" recommendation.) > > (j) You may want to add the following REFERENCE clause to the > definition of pethPdPortIndex: > > REFERENCE "RFC 2863, ifIndex" > > (k) In the following object > > pethPdPortAdminEnable OBJECT-TYPE > SYNTAX INTEGER { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This value identifies the operational state of > the PD functions. > An interface which can provide the PD > functions will be enabled > to do so when this attribute has the value > enable. When this > attribute has the value disable the > interface will act > as it would if it had no PD function." > ::= { pethPdPortEntry 2 } > > the name and semantics (in particular the fact that it is > writeable) suggests > that it is an administrative state while the DESCRIPTION says > that it is an > operational state. If it is indeed an admin state, please > change the words > "operational state" to "administrative state" in the > DESCRIPTION. Also, > use of the name "pethPdPortAdminEnable" rather than > "pethPdPortAdminStatus" > suggests that a more appropriate SYNTAX would be TruthValue. > Thus, it is > recommended that the SYNTAX be changed to TruthValue (both in > the object > definition and in the SEQUENCE) and that the DESCRIPTION > clause be updated > to match by changing "the value enable" to "the value true(1)" and by > changing "the value disable" to "the value false(2)". > > (l) The "box in the stack, module in a rack" language that > appears in the DESCRIPTION clauses for pethPsePortGroupIndex, > pethMainPseGroupIndex, and pethNotificationControlGroupIndex > suggests that the same value will be used in all three of > these indices to refer to a given physical entity. If that > is true, it would be best to say so explicitly, and in that > case I would recommend modifying the DESCRIPTION clause for > pethMainPseGroupIndex to something along the following lines: > > "This variable uniquely identifies the group to > which a power Ethernet PSE is connected. 'Group' > means (box in the stack, module in a rack) and > the value 1 MUST be used for non-modular devices. > Furthermore, the same value MUST be used in this > variable, pethPsePortGroupIndex, and > pethNotificationControlGroupIndex to refer to > a given (box in the stack, module in a rack)." > > (m) Making the same assumptions as above, the equivalent > modification for > pethNotificationControlGroupIndex would be: > > "This variable uniquely identifies the group. > 'Group' means (box in the stack, module in a rack) > and the value 1 MUST be used for non-modular > devices. Furthermore, the same value MUST be > used in this variable, pethPsePortGroupIndex, > and pethMainPseGroupIndex to refer to a > given (box in the stack, module in a rack)." > > In any case, the current language "it is RECOMENDED that the value 1 > be used for non-modular devices" is not consistent with that in the > DESCRIPTION clauses for pethPsePortGroupIndex and > pethMainPseGroupIndex; > the same imperative should be used in all three places. I think that > the MUST wording is the right way to go, since it does not cost the > agent anything and makes life easier for the manager. > > (n) In the following object > > pethNotificationControlEnable OBJECT-TYPE > SYNTAX INTEGER > { > enable(1), > disable(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Enable Notification from Agent" > > use of the name "pethNotificationControlEnable" rather than > "pethNotificationControlStatus" suggests that a more > appropriate SYNTAX > would be TruthValue. Thus, it is recommended that the SYNTAX > be changed > to TruthValue (both in the object definition and in the SEQUENCE) and > that the DESCRIPTION clause be updated to read > > "This object controls, on a per-group basis, whether > or not notifications from the agent are enabled. The > value true(1) means that notifications are enabled; the > value false(2) means that they are not." > > (o) Regarding the notification definitions: it was recently noted > on the mibs@ops.ietf.org mailing list that MIB doctors should make > sure that notifications defined in IETF MIB modules cannot "flood" > the communication network in case of a high rate of occurrence of > the events that trigger them. Hence, it is recommended that the > notification definitions in this MIB module include a rate limiting > mechanism, e.g., a statement in the DESCRIPTION clause that at least > x milliseconds must elapse between successive notifications triggered > by any one object instance (this works for the notifications defined > in this MIB module because they are triggered by changes in the > values of MIB objects). One could either choose a fixed value for x > (e.g., 500 msec) or allow it to be configured (another object would > need to be defined for that purpose, and it would need to be > mentioned in the Security Considerations section). > > (p) The following warnings are generated from the command > smilint -l 9 -s -i namelength-32 ./POWER-ETHERNET-MIB > > ./POWER-ETHERNET-MIB:667: [6] current group > `pethPsePortNotificationGroup' > is not referenced in this module > ./POWER-ETHERNET-MIB:674: [6] current group > `pethMainPowerNotificationGroup' > is not referenced in this module > > These warnings are issued because it it not uncommon for an > object group > or notification group to be omitted from the conformance statements by > mistake. The module is still well-formed, because an object group or > notification group that is not mentioned in any > MANDATORY-GROUPS clause > or in any GROUP clause is unconditionally optional; but it's not > altogether clear whether this was the MIB designer's intent or just an > oversight. For this reason, it is RECOMMENDED that object groups and > notification groups be mentioned in a GROUP clause even when they are > unconditionally optional. Appropriate GROUP clauses might be: > > GROUP pethPsePortNotificationGroup > DESCRIPTION > "Implementation of the pethPsePortNotificationGroup is > RECOMMENDED for systems which implement PSE ports." > GROUP pethMainPowerNotificationGroup > DESCRIPTION > "Implementation of the > pethMainPowerNotificationGroup is > RECOMMENDED for systems which implement main > power supply > within a PSE Device." > > If "RECOMMENDED" is too strong, then "encouraged" or "optional" could > be used instead. These GROUP clauses should be added to the end of > pethCompliance. [Note: if it was intended that notifications be > mandatory, then the language from the other GROUP clauses in the > pethCompliance statement should be adapted instead.] > > (q) If it is indeed the case that the notifications are intended to > be optional, then the GROUP clause (in pethCompliance) for > pethNotificationControlGroup has an erroneous DESCRIPTION clause. It > says "The pethNotificationControlGroup is mandatory for systems which > implement PSE ports." It should say "The pethNotificationControlGroup > is mandatory for systems which implement notifications." > > (r) The compliance statements in this MIB module are redundant. It > defines pethPseCompliance, which applies to PSEs, and > pethPdCompliance, > which applies to PDs. But it also defines pethCompliance, which > applies to any device, and which is a superset of the other two (it > does this by making all groups conditionally mandatory depending on > what functions are implemented). This redundancy is not necessary. > My recommendation is to remove pethPseCompliance and pethPdCompliance. > > (s) General comment on REFERENCE clauses: I notice that some of the > object definitions have REFERENCE clauses that point to the IEEE > specification while others do not. It would indeed be desirable to > add reference clauses for all objects that have equivalent GDMO > objects in 802.3af clause 30.9; and for those that do not but which > require hardware support, it would be good to refer to the clauses > in the IEEE specification that mandate the necessary hardware support, > as was done in the ETHER-WIS MIB module for the objects in > etherWisDeviceGroupBasic and etherWisDeviceGroupExtra (see > draft-ietf-hubmib-wis-mib-05.txt or its successor). One word of > caution, though: the REFERENCE clauses will need to point to the > final published IEEE STD 802.3af and not to IEEE Draft P802.3af/D4.0, > and you will need to re-check the clause numbers each time a new > version appears. > > 10.) References (Sections 8 and 9) -- the references need to be > updated owing mainly to the publication of the new SNMPv2 RFCs > but also to a few errors/oversights. Here are the details: > > Remove normative reference [RFC2570]. RFC 2570 has been replaced > by RFC 3410, which is supposed to be an informative reference. > > Remove normative references [RFC2571], [RFC2572], [RFC2573], > [RFC2574], and [RFC2575] since they are no longer required > by the boilerplate and are not used elsewhere. > > Add a normative reference [RFC2863] to RFC 2863, since > InterfaceIndex is imported from the IF-MIB. > > Remove informative references [RFC1155], [RFC1212], [RFC1215], > [RFC1157], [RFC1901], [RFC1905], and [RFC1906] since they are > no longer required by the boilerplate and are not used elsewhere. > > Remove the informative reference [PWR-MIB], since it points to > an expired draft that defined a predecessor to this MIB module. > > Add an informative reference [RFC3410] to RFC 3410 since > it is required by the boilerplate and security sections > (see http://www.ops.ietf.org/mib-boilerplate.html and > comment 11 below). > > Please revise the style of the references to match that of > recently published RFCs (see RFC 3418 or the MIB boilerplate > http://www.ops.ietf.org/mib-boilerplate.html for an example). > > The authors need to be aware that this document can go through > the IETF approval process but cannot be published as an RFC as > long as [IEEE-802.3af] points to IEEE Draft P802.3af/D4.0 (or > any other version of the draft) rather than IEEE STD 802.3af. > That reference, however, should _not_ be updated until the final > standard is actually approved, and then there should be a final > review of this document to ensure that it is editorially and > technically consistent with the final IEEE standard ... things > like clause numbers (which are used in the REFERENCE clauses) > are subject to change even very late in the process. > > 10.) IPR Notices (Section 10) -- probably OK: the draft contains > verbatim copies of the IPR notices specified in bullets (A) and (B) > of Section 10.4 of RFC 2026 as required, but the AUTHORS NEED TO > CONFIRM that the notice in bullet (D) is not needed. > > 11.) Security Considerations Section -- the MIB security guidelines > are in the process of being updated, so the text on the OPS area web > site (http://www.ops.ietf.org/security.html) is out of date. However, > based on the latest wisdom to appear on the mibs@ops.ietf.org mailing > list, I would recommend a rewrite along the following lines: > > There are a number of management objects defined in this MIB module > with a MAX-ACCESS clause of read-write. These are: > > pethPsePortAdminEnable > pethPsePortPowerPairs > pethPsePortPowerDetectionControl > pethPsePortPowerPriority > pethPsePortType > pethPdPortAdminEnable > pethMainPseUsageThreshold > pethNotificationControlEnable > > Such objects may be considered sensitive or vulnerable in some > network environments. The support for SET operations in a > non-secure > environment without proper protection can have a negative effect on > network operations. > > Some of the readable objects in this MIB module (i.e., > objects with a > MAX-ACCESS other than not-accessible) contain information > that may be > considered sensitive in some network environments. These are: > > pethPsePortPowerPairsControlAbility > pethPsePortPowerPriority > pethPsePortPowerClassifications > > It is thus important to control even GET and NOTIFY access to these > objects and possibly 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. > > 12.) IANA Considerations section (none present) -- NEED TO CHECK > WITH OUR AD. An IANA Considerations section probably should not > be needed since this document does not define a name space. However, > the current version of http://www.ietf.org/ID-nits.html states that > there is supposed to be an IANA considerations section whenever > IANA is reequired to make an assignment in a registry prior to RFC > publication. I have raised objections about this policy, and an > answer from our AD is pending. For the time being I think that > the notation > > powerEthernetMIB MODULE-IDENTITY > > [ ... ] > > ::= { mib-2 XXX } > -- RFC Ed.: replace XXX with IANA-assigned number & remove > this notice > > that is already present will suffice; but if an IANA Considerations > section has to be written, I would suggest something along > the lines of > > The POWER-ETHERNET-MIB module defined in this document is > registered > under an IANA-assigned node in the mib-2 OBJECT IDENTIFIER subtree > [RFC2578]. That node is defined as "powerEthernetMIB" in the > POWER-ETHERNET-MIB MODULE-IDENTITY invocation. Subordinate > assignments under powerEthernetMIB will be managed by the IETF > working group responsible for maintaining the ETHER-WIS MIB module; > no further IANA action is required. > > ******************************************************* > * EDITOR'S NOTE (to be removed prior to publication): * > * before this draft is published as an RFC, a subid * > * under the mib-2 OBJECT IDENTIFIER subtree needs to * > * be assigned by IANA for powerEthernetMIB, and this * > * subid needs to be inserted by the RFC Editor into * > * the POWER-ETHERNET-MIB -WIS MODULE-IDENTITY value. * > ******************************************************* > > 13.) Copyrights -- the full copyright notice should start > with the line > > Copyright (C) The Internet Society (date). All Rights Reserved. > > The absence of a copyright notice in the DESCRIPTION clause of the > MODULE-IDENTITY invocation was noted in 9(b) bove. > > Note: when the draft is resubmitted, please be sure to > change the year > to 2003 in all three places (on the front page, in the > DESCRIPTON clause > of the MODULE-IDENTITY invocation, and in the full copyright > statement). > > 14.) General comments on formatting -- the layout of the MIB module > is not uniform, as noted in a couple of places in (9) above, and it > would be nice to have that fixed. Also, the draft does not fully > adhere to the document formatting guidelines in Instructions to RFC > Authors, . That can be > fixed during > the final editing process, but it would speed up the process > (and reduce > the chances for error) if the next version of the draft would attempt > to comply more closely with those guidelines. > > //cmh > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Sat Jan 11 16:08:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18320 for ; Sat, 11 Jan 2003 16:08:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BLLIH11954 for hubmib-archive@odin.ietf.org; Sat, 11 Jan 2003 16:21:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BLLHJ11949; Sat, 11 Jan 2003 16:21:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BLK8J11916 for ; Sat, 11 Jan 2003 16:20:08 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18264 for ; Sat, 11 Jan 2003 16:06:47 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA07501; Sat, 11 Jan 2003 13:10:04 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 11 Jan 2003 13:10:04 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Mailing List cc: AToM MIB Mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] New WIS MIB draft now available Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hub MIB and AToM MIB WG members, The latest WIS MIB draft, which was submitted yesterday, is now available at http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-06.txt The I-D actually made its appearance in the repository before the official announcement, which can be expected to arrive shortly. Here is what has changed since the previous version: 1.) Names of WIS MIB design team members other than the editor now appear in a Contributors section with (updated) contact information, rather than on the front page. 2.) References to RFC 2570bis were updated to point to RFC 3410, which was published in late December. 3.) Working group mailing list information was added to the CONTACT-INFO clause of the MODULE-IDENTITY invocation, as requested by Bert Wijnen. 4.) The dates in the LAST-UPDATED and REVISION clauses of the MODULE-IDENTITY invocation were updated. 5.) The Intellectual Property section was relocated. 6.) The working group names in the Acknowlegments section were corrected. 7.) The part of the Security Considerations section dealing with read-only objects was wordsmithed to align with the latest agreed-on Security guidelines, and some typos in the last part were fixed. 8.) References [SONETng], [ETHERIF], and [MAU-MIB] were updated to point to , , and , respectively. 9.) All references to multi-author RFCs were updated to conform to the style used in recently published RFCs. 10.) The "To-Do List" was replaced with a "NOTES TO RFC Editor" section. I've checked the document against http://www.ietf.org/ID-nits.html and believe that conforms to those guidelines, modulo forthcoming updates to the effect that no IANA considerations is needed just to request an OID for a MIB module and that warnings from smilint -9 about names > 32 characters can be ignored. As far as I'm aware there are no outstanding issues left, and I believe that the document is ready for the next step in the process. WG editors and chairs please note that the following three normative references need to be progressed to Proposed Standard or higher prior to or simultaneously with the WIS MIB document in order for it to be published as an RFC: [SONETng] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", , work in progress. [ETHERIF] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", , work in progress. [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", , work in progress. As subscribers to the AToM MIB list are aware, updated versions of [SONETng] (and the PerfHistTC-MIB document on which it depends) appeared in the I-D repository earlier this week: http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2558bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2493bis-01.txt These drafts addressed Bert Wijnen's review comments and to the best of my knowledge closed all the open issues with the documents (corrections are welcome if that's not the case). In addition, the implementation reports required for advancement to Draft Standard have been submitted to the IESG secretary and responsible ADs and are available on the IETF web site. So, as long there are no unexpected delays in the process these documents should create no delays in publishing the WIS MIB. Updates to [ETHERIF] and [MAU-MIB] to address A-D review comments have not yet appeared but presumably are forthcoming. These updates will be needed before the WIS MIB can be published. Thanks and regards, Mike -- C. M. Heard heard@pobox.com _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sat Jan 11 16:08:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18324 for ; Sat, 11 Jan 2003 16:08:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BLLHJ11949; Sat, 11 Jan 2003 16:21:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BLK8J11916 for ; Sat, 11 Jan 2003 16:20:08 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18264 for ; Sat, 11 Jan 2003 16:06:47 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA07501; Sat, 11 Jan 2003 13:10:04 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 11 Jan 2003 13:10:04 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Mailing List cc: AToM MIB Mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] New WIS MIB draft now available Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hub MIB and AToM MIB WG members, The latest WIS MIB draft, which was submitted yesterday, is now available at http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-06.txt The I-D actually made its appearance in the repository before the official announcement, which can be expected to arrive shortly. Here is what has changed since the previous version: 1.) Names of WIS MIB design team members other than the editor now appear in a Contributors section with (updated) contact information, rather than on the front page. 2.) References to RFC 2570bis were updated to point to RFC 3410, which was published in late December. 3.) Working group mailing list information was added to the CONTACT-INFO clause of the MODULE-IDENTITY invocation, as requested by Bert Wijnen. 4.) The dates in the LAST-UPDATED and REVISION clauses of the MODULE-IDENTITY invocation were updated. 5.) The Intellectual Property section was relocated. 6.) The working group names in the Acknowlegments section were corrected. 7.) The part of the Security Considerations section dealing with read-only objects was wordsmithed to align with the latest agreed-on Security guidelines, and some typos in the last part were fixed. 8.) References [SONETng], [ETHERIF], and [MAU-MIB] were updated to point to , , and , respectively. 9.) All references to multi-author RFCs were updated to conform to the style used in recently published RFCs. 10.) The "To-Do List" was replaced with a "NOTES TO RFC Editor" section. I've checked the document against http://www.ietf.org/ID-nits.html and believe that conforms to those guidelines, modulo forthcoming updates to the effect that no IANA considerations is needed just to request an OID for a MIB module and that warnings from smilint -9 about names > 32 characters can be ignored. As far as I'm aware there are no outstanding issues left, and I believe that the document is ready for the next step in the process. WG editors and chairs please note that the following three normative references need to be progressed to Proposed Standard or higher prior to or simultaneously with the WIS MIB document in order for it to be published as an RFC: [SONETng] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", , work in progress. [ETHERIF] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", , work in progress. [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", , work in progress. As subscribers to the AToM MIB list are aware, updated versions of [SONETng] (and the PerfHistTC-MIB document on which it depends) appeared in the I-D repository earlier this week: http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2558bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2493bis-01.txt These drafts addressed Bert Wijnen's review comments and to the best of my knowledge closed all the open issues with the documents (corrections are welcome if that's not the case). In addition, the implementation reports required for advancement to Draft Standard have been submitted to the IESG secretary and responsible ADs and are available on the IETF web site. So, as long there are no unexpected delays in the process these documents should create no delays in publishing the WIS MIB. Updates to [ETHERIF] and [MAU-MIB] to address A-D review comments have not yet appeared but presumably are forthcoming. These updates will be needed before the WIS MIB can be published. Thanks and regards, Mike -- C. M. Heard heard@pobox.com _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Mon Jan 13 07:51:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09870 for ; Mon, 13 Jan 2003 07:51:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DD5Aw22080 for hubmib-archive@odin.ietf.org; Mon, 13 Jan 2003 08:05:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD59J22075; Mon, 13 Jan 2003 08:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD3VJ22015 for ; Mon, 13 Jan 2003 08:03:31 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09835 for ; Mon, 13 Jan 2003 07:49:20 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23031 for ; Mon, 13 Jan 2003 07:50:10 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23027 for ; Mon, 13 Jan 2003 07:50:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BB02.A6ECDDFA" Date: Mon, 13 Jan 2003 14:52:38 +0200 Message-ID: Thread-Topic: IEEE Interim Meeting - WG Last Call for Power Ethernet MIB Thread-Index: AcK7Aqb2f4YlZp/hQjiFor+4ZeAY9g== From: "Romascanu, Dan (Dan)" To: Cc: "DTE Power" Subject: [Hubmib] IEEE Interim Meeting - WG Last Call for Power Ethernet MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BB02.A6ECDDFA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I attended last week one of the sessions of the IEEE 802.3af (Power = Ethernet) interim meeting. I gave a short presentation focused on a = outline of the last Power Ethernet MIB, which is now in WG Last Call. I = received several comments which I would like to bring to the attention = of the WG, and be considered as comments to the last call. At the same = time I would like to re-iterate the invitation made to the IEEE 802.3af = participants to have another read of the document = (http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-powe= r-ethernet-mib-04.txt) and send their comments to hubmib@ietf.org. The = Last Call expires in two days. Here are the IEEE folks comments: 1. Align the enumerated names for pethPsePortPowerPairs with the = terminology used in the IEEE draft - alternativeA, alternativeB instead = of spare, signal. 2. The capability to performed control of detection has been removed of = the mandatory clauses of the IEEE standard, thus the object = pethPsePortPowerDetectionControl should be removed. 3. The state test(7) in pethPsePortDetectionStatus needs to be removed 4. Typo in the enumerated of pethPsePortPowerMaintenanceStatus - it is = meant to be overCurrent, and not underCurrent 5. Recommend a separate conformance clause for pethMainPseTable, which = is a 'high-end' feature 6. For power management, it was suggested that the usage threshold = comparison be made not with the measured, but rather with the = consumption-based estimated usage, as devices may have a temporary usage = below the power allowed by their class.=20 After the meeting I learnt about another important change, which will = impact the MIB: 7. The PD group is no longer mandatory - this actually means that the = pethPfPortTable can be taken out of the MIB Regards, Dan =20 =20 ------_=_NextPart_001_01C2BB02.A6ECDDFA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IEEE Interim Meeting - WG Last Call for Power Ethernet = MIB

I attended last week one of = the sessions of the IEEE 802.3af (Power Ethernet) interim meeting. I = gave a short presentation focused on a outline of the last Power = Ethernet MIB, which is now in WG Last Call. I received several comments = which I would like to bring to the attention of the WG, and be = considered as comments to the last call. At the same time I would like = to re-iterate the invitation made to the IEEE 802.3af participants to = have another read of the document (http://www.ietf.cnri.reston.va.us/internet-= drafts/draft-ietf-hubmib-power-ethernet-mib-04.txt) and send their = comments to hubmib@ietf.org. The Last Call expires in two = days.

Here are the IEEE folks = comments:

1. Align the enumerated names = for pethPsePortPowerPairs with the terminology = used in the IEEE draft - alternativeA, alternativeB instead of spare, = signal.

2. The = capability to performed control of detection has been removed of the = mandatory clauses of the IEEE standard, thus the object = pethPsePortPowerDetectionControl should be removed.

3. The = state test(7) in pethPsePortDetectionStatus needs to be = removed

4. Typo = in the enumerated of pethPsePortPowerMaintenanceStatus - it is meant to = be overCurrent, and not underCurrent

5. = Recommend a separate conformance clause for pethMainPseTable, which is a = 'high-end' feature

6. For = power management, it was suggested that the usage threshold comparison = be made not with the measured, but rather with the consumption-based = estimated usage, as devices may have a temporary usage below the power = allowed by their class.

After = the meeting I learnt about another important change, which will impact = the MIB:

7. The = PD group is no longer mandatory - this actually means that the = pethPfPortTable can be taken out of the MIB

Regards,

Dan




 

 

------_=_NextPart_001_01C2BB02.A6ECDDFA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Jan 13 07:51:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09883 for ; Mon, 13 Jan 2003 07:51:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD59J22075; Mon, 13 Jan 2003 08:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DD3VJ22015 for ; Mon, 13 Jan 2003 08:03:31 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09835 for ; Mon, 13 Jan 2003 07:49:20 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23031 for ; Mon, 13 Jan 2003 07:50:10 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23027 for ; Mon, 13 Jan 2003 07:50:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BB02.A6ECDDFA" Date: Mon, 13 Jan 2003 14:52:38 +0200 Message-ID: Thread-Topic: IEEE Interim Meeting - WG Last Call for Power Ethernet MIB Thread-Index: AcK7Aqb2f4YlZp/hQjiFor+4ZeAY9g== From: "Romascanu, Dan (Dan)" To: Cc: "DTE Power" Subject: [Hubmib] IEEE Interim Meeting - WG Last Call for Power Ethernet MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BB02.A6ECDDFA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I attended last week one of the sessions of the IEEE 802.3af (Power = Ethernet) interim meeting. I gave a short presentation focused on a = outline of the last Power Ethernet MIB, which is now in WG Last Call. I = received several comments which I would like to bring to the attention = of the WG, and be considered as comments to the last call. At the same = time I would like to re-iterate the invitation made to the IEEE 802.3af = participants to have another read of the document = (http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-powe= r-ethernet-mib-04.txt) and send their comments to hubmib@ietf.org. The = Last Call expires in two days. Here are the IEEE folks comments: 1. Align the enumerated names for pethPsePortPowerPairs with the = terminology used in the IEEE draft - alternativeA, alternativeB instead = of spare, signal. 2. The capability to performed control of detection has been removed of = the mandatory clauses of the IEEE standard, thus the object = pethPsePortPowerDetectionControl should be removed. 3. The state test(7) in pethPsePortDetectionStatus needs to be removed 4. Typo in the enumerated of pethPsePortPowerMaintenanceStatus - it is = meant to be overCurrent, and not underCurrent 5. Recommend a separate conformance clause for pethMainPseTable, which = is a 'high-end' feature 6. For power management, it was suggested that the usage threshold = comparison be made not with the measured, but rather with the = consumption-based estimated usage, as devices may have a temporary usage = below the power allowed by their class.=20 After the meeting I learnt about another important change, which will = impact the MIB: 7. The PD group is no longer mandatory - this actually means that the = pethPfPortTable can be taken out of the MIB Regards, Dan =20 =20 ------_=_NextPart_001_01C2BB02.A6ECDDFA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IEEE Interim Meeting - WG Last Call for Power Ethernet = MIB

I attended last week one of = the sessions of the IEEE 802.3af (Power Ethernet) interim meeting. I = gave a short presentation focused on a outline of the last Power = Ethernet MIB, which is now in WG Last Call. I received several comments = which I would like to bring to the attention of the WG, and be = considered as comments to the last call. At the same time I would like = to re-iterate the invitation made to the IEEE 802.3af participants to = have another read of the document (http://www.ietf.cnri.reston.va.us/internet-= drafts/draft-ietf-hubmib-power-ethernet-mib-04.txt) and send their = comments to hubmib@ietf.org. The Last Call expires in two = days.

Here are the IEEE folks = comments:

1. Align the enumerated names = for pethPsePortPowerPairs with the terminology = used in the IEEE draft - alternativeA, alternativeB instead of spare, = signal.

2. The = capability to performed control of detection has been removed of the = mandatory clauses of the IEEE standard, thus the object = pethPsePortPowerDetectionControl should be removed.

3. The = state test(7) in pethPsePortDetectionStatus needs to be = removed

4. Typo = in the enumerated of pethPsePortPowerMaintenanceStatus - it is meant to = be overCurrent, and not underCurrent

5. = Recommend a separate conformance clause for pethMainPseTable, which is a = 'high-end' feature

6. For = power management, it was suggested that the usage threshold comparison = be made not with the measured, but rather with the consumption-based = estimated usage, as devices may have a temporary usage below the power = allowed by their class.

After = the meeting I learnt about another important change, which will impact = the MIB:

7. The = PD group is no longer mandatory - this actually means that the = pethPfPortTable can be taken out of the MIB

Regards,

Dan




 

 

------_=_NextPart_001_01C2BB02.A6ECDDFA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Mon Jan 13 09:24:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11690 for ; Mon, 13 Jan 2003 09:24:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DEc7N28670 for hubmib-archive@odin.ietf.org; Mon, 13 Jan 2003 09:38:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEc7J28665; Mon, 13 Jan 2003 09:38:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEVXJ27682 for ; Mon, 13 Jan 2003 09:31:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11489; Mon, 13 Jan 2003 09:17:22 -0500 (EST) Message-Id: <200301131417.JAA11489@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 13 Jan 2003 09:17:22 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-wis-mib-06.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF. Title : Definition of Managed Objects for the Ethernet WAN Interface Sublayer Author(s) : C. Heard Filename : draft-ietf-hubmib-wis-mib-06.txt Pages : 43 Date : 2003-1-10 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the SONET/SDH Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-wis-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-wis-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10144050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-wis-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-wis-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10144050.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Jan 13 09:24:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11703 for ; Mon, 13 Jan 2003 09:24:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEc7J28665; Mon, 13 Jan 2003 09:38:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEVXJ27682 for ; Mon, 13 Jan 2003 09:31:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11489; Mon, 13 Jan 2003 09:17:22 -0500 (EST) Message-Id: <200301131417.JAA11489@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 13 Jan 2003 09:17:22 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-wis-mib-06.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF. Title : Definition of Managed Objects for the Ethernet WAN Interface Sublayer Author(s) : C. Heard Filename : draft-ietf-hubmib-wis-mib-06.txt Pages : 43 Date : 2003-1-10 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the SONET/SDH Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-wis-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-wis-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10144050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-wis-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-wis-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10144050.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Mon Jan 13 17:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27374 for ; Mon, 13 Jan 2003 17:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DND8O30929 for hubmib-archive@odin.ietf.org; Mon, 13 Jan 2003 18:13:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DND7J30918; Mon, 13 Jan 2003 18:13:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNCKJ30875 for ; Mon, 13 Jan 2003 18:12:20 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27297 for ; Mon, 13 Jan 2003 17:57:58 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id PAA30826; Mon, 13 Jan 2003 15:01:18 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 13 Jan 2003 15:01:17 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB cc: DTE Power Subject: Re: [Hubmib] IEEE Interim Meeting - WG Last Call for Power Ethernet MIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, 13 Jan 2003, Romascanu, Dan (Dan) wrote: > I attended last week one of the sessions of the IEEE 802.3af (Power > Ethernet) interim meeting. I gave a short presentation focused on a > outline of the last Power Ethernet MIB, which is now in WG Last Call. > I received several comments which I would like to bring to the > attention of the WG, and be considered as comments to the last call. It is good to get these comments. > Here are the IEEE folks comments: [ ... ] > 5. Recommend a separate conformance clause for pethMainPseTable, which > is a 'high-end' feature Note that pethCompliance already does this by making pethMainPseGroup conditionally required: GROUP pethMainPseGroup DESCRIPTION "The pethMainPseGroup is mandatory for systems which implement main power supply within a PSE Device." since pethMainPseGroup includes all the accessible columns in the pethMainPseTable. Thus, if my previous suggestion to eliminate pethPseCompliance and pethPdCompliance in favor of pethPseCompliance is accepted, then this comment will be addressed, too. (The alternative is to eliminate pethCompliance and make more specific compliance statements; that's not as simple, but it's OK. There shouldn't be any redundant compliance statements, however.) > After the meeting I learnt about another important change, which will > impact the MIB: > > 7. The PD group is no longer mandatory - this actually means that the > pethPfPortTable can be taken out of the MIB Comment: there is one accessible column in pethPdPortTable, namely pethPdPortAdminEnable, and if this goes then pethPdPortGroup goes with it. That would eliminate the corresponding GROUP clause of pethCompliance (and would completely eliminate pethPdCompliance). Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Jan 13 17:59:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27416 for ; Mon, 13 Jan 2003 17:59:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DND7J30918; Mon, 13 Jan 2003 18:13:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNCKJ30875 for ; Mon, 13 Jan 2003 18:12:20 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27297 for ; Mon, 13 Jan 2003 17:57:58 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id PAA30826; Mon, 13 Jan 2003 15:01:18 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 13 Jan 2003 15:01:17 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB cc: DTE Power Subject: Re: [Hubmib] IEEE Interim Meeting - WG Last Call for Power Ethernet MIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, 13 Jan 2003, Romascanu, Dan (Dan) wrote: > I attended last week one of the sessions of the IEEE 802.3af (Power > Ethernet) interim meeting. I gave a short presentation focused on a > outline of the last Power Ethernet MIB, which is now in WG Last Call. > I received several comments which I would like to bring to the > attention of the WG, and be considered as comments to the last call. It is good to get these comments. > Here are the IEEE folks comments: [ ... ] > 5. Recommend a separate conformance clause for pethMainPseTable, which > is a 'high-end' feature Note that pethCompliance already does this by making pethMainPseGroup conditionally required: GROUP pethMainPseGroup DESCRIPTION "The pethMainPseGroup is mandatory for systems which implement main power supply within a PSE Device." since pethMainPseGroup includes all the accessible columns in the pethMainPseTable. Thus, if my previous suggestion to eliminate pethPseCompliance and pethPdCompliance in favor of pethPseCompliance is accepted, then this comment will be addressed, too. (The alternative is to eliminate pethCompliance and make more specific compliance statements; that's not as simple, but it's OK. There shouldn't be any redundant compliance statements, however.) > After the meeting I learnt about another important change, which will > impact the MIB: > > 7. The PD group is no longer mandatory - this actually means that the > pethPfPortTable can be taken out of the MIB Comment: there is one accessible column in pethPdPortTable, namely pethPdPortAdminEnable, and if this goes then pethPdPortGroup goes with it. That would eliminate the corresponding GROUP clause of pethCompliance (and would completely eliminate pethPdCompliance). Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Tue Jan 14 15:02:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09755 for ; Tue, 14 Jan 2003 15:02:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKGHm28063 for hubmib-archive@odin.ietf.org; Tue, 14 Jan 2003 15:16:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKGHJ28058; Tue, 14 Jan 2003 15:16:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKFBJ27982 for ; Tue, 14 Jan 2003 15:15:11 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09690 for ; Tue, 14 Jan 2003 15:00:22 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA17746; Tue, 14 Jan 2003 12:03:42 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 14 Jan 2003 12:03:41 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] 10GBASE-CX4 and 10GBASE-T Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hub MIB folks, For those who aren't already aware, I'd like to bring your attention to the fact that there are two IEEE study groups at work on new PMDs for 10 Gb/s Ethernet. The 10GBASE-CX4 group is working on a 15 m shielded copper solution that will use the same PCS as does 10GBASE-LX4. The 10GBASE-T group is working on a 100 m UTP solution. Those who are interested can find more information on the 802.3 web site http://grouper.ieee.org/groups/802/3/ The 10GBASE-CX4 effort has, I believe, the much shorter timeline, and it appears that the impact on our documents will be minimal. In fact as far as I can tell, the only document that will be affected is the MAU-MIB document, and the changes to it will be confined to the following additions: [ ... ] dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over copper (per 802.3 section 54)" ::= { dot3MauType XX } -- NOTE: next unassigned value is 41 [ ... ] ifMauTypeListBits OBJECT-TYPE SYNTAX BITS { [ ... ] b10GbaseCX4(XX), -- 10GBASE-CX4 (see NOTE above) [ ... ] } [ ... ] These would mirror the proposed changes to Clause 30, which you can find here: http://grouper.ieee.org/groups/802/3/10GBCX4/public/jan03/WP2p0_cls30_annex30B.pdf While it is probably not be appropriate to include this stuff in the next MAU-MIB draft that includes the 802.3ae stuff, the changes are small enough that they should be able to go into a maintenance update without affecting time-in-grade, or else when then the document advances Draft Standard. The impact of 10GBASE-T is harder to gauge. Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Jan 14 15:02:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09795 for ; Tue, 14 Jan 2003 15:02:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKGHJ28058; Tue, 14 Jan 2003 15:16:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKFBJ27982 for ; Tue, 14 Jan 2003 15:15:11 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09690 for ; Tue, 14 Jan 2003 15:00:22 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA17746; Tue, 14 Jan 2003 12:03:42 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 14 Jan 2003 12:03:41 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] 10GBASE-CX4 and 10GBASE-T Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hub MIB folks, For those who aren't already aware, I'd like to bring your attention to the fact that there are two IEEE study groups at work on new PMDs for 10 Gb/s Ethernet. The 10GBASE-CX4 group is working on a 15 m shielded copper solution that will use the same PCS as does 10GBASE-LX4. The 10GBASE-T group is working on a 100 m UTP solution. Those who are interested can find more information on the 802.3 web site http://grouper.ieee.org/groups/802/3/ The 10GBASE-CX4 effort has, I believe, the much shorter timeline, and it appears that the impact on our documents will be minimal. In fact as far as I can tell, the only document that will be affected is the MAU-MIB document, and the changes to it will be confined to the following additions: [ ... ] dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over copper (per 802.3 section 54)" ::= { dot3MauType XX } -- NOTE: next unassigned value is 41 [ ... ] ifMauTypeListBits OBJECT-TYPE SYNTAX BITS { [ ... ] b10GbaseCX4(XX), -- 10GBASE-CX4 (see NOTE above) [ ... ] } [ ... ] These would mirror the proposed changes to Clause 30, which you can find here: http://grouper.ieee.org/groups/802/3/10GBCX4/public/jan03/WP2p0_cls30_annex30B.pdf While it is probably not be appropriate to include this stuff in the next MAU-MIB draft that includes the 802.3ae stuff, the changes are small enough that they should be able to go into a maintenance update without affecting time-in-grade, or else when then the document advances Draft Standard. The impact of 10GBASE-T is harder to gauge. Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Wed Jan 15 04:14:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20700 for ; Wed, 15 Jan 2003 04:14:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F9T9p25858 for hubmib-archive@odin.ietf.org; Wed, 15 Jan 2003 04:29:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9T8J25853; Wed, 15 Jan 2003 04:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9SMJ25802 for ; Wed, 15 Jan 2003 04:28:22 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20682 for ; Wed, 15 Jan 2003 04:13:17 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0F9DwT11951 for ; Wed, 15 Jan 2003 04:13:58 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0F9DvQ11945 for ; Wed, 15 Jan 2003 04:13:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Hubmib] 10GBASE-CX4 and 10GBASE-T Date: Wed, 15 Jan 2003 11:16:32 +0200 Message-ID: Thread-Topic: [Hubmib] 10GBASE-CX4 and 10GBASE-T Thread-Index: AcK8CJfQAmaiIrApRX2P4p6z/ASQ7AAbVlMQ From: "Romascanu, Dan (Dan)" To: "C. M. Heard" , "Hub MIB" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F9SMJ25803 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike, It is still too early to gauge the impact of technologies that are in Study Group phase in the IEEE on our WG work. We need first see these two subjects adopted as standards work by the IEEE and the specifications reaching a relatively stable phase. At this point, if there is interest and there are volunteers to work, we can require to be chartered in order to make the needed additions to the Ethernet MIBs. Also, let us not forget that we also have IEEE 802.3ah - Ethernet First Mile as a possible work item, even before the copper 10GBE technologies. Are people interested in starting to look at possible MIB work for EFM? Thanks, Dan > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Tuesday, January 14, 2003 10:04 PM > To: Hub MIB > Subject: [Hubmib] 10GBASE-CX4 and 10GBASE-T > > > Hub MIB folks, > > For those who aren't already aware, I'd like to bring your > attention to the fact that there are two IEEE study groups > at work on new PMDs for 10 Gb/s Ethernet. The 10GBASE-CX4 > group is working on a 15 m shielded copper solution that > will use the same PCS as does 10GBASE-LX4. The 10GBASE-T > group is working on a 100 m UTP solution. Those who are > interested can find more information on the 802.3 web site > http://grouper.ieee.org/groups/802/3/ > > The 10GBASE-CX4 effort has, I believe, the much shorter > timeline, and it appears that the impact on our documents > will be minimal. In fact as far as I can tell, the only > document that will be affected is the MAU-MIB document, > and the changes to it will be confined to the following > additions: > > [ ... ] > > dot3MauType10GigBaseCX4 OBJECT-IDENTITY > STATUS current > DESCRIPTION "X fiber over copper (per 802.3 section > 54)" > ::= { dot3MauType XX } -- NOTE: next unassigned value is 41 > > [ ... ] > > ifMauTypeListBits OBJECT-TYPE > SYNTAX BITS { > [ ... ] > b10GbaseCX4(XX), -- 10GBASE-CX4 (see NOTE above) > [ ... ] > } > [ ... ] > > These would mirror the proposed changes to Clause 30, which you can > find here: > > http://grouper.ieee.org/groups/802/3/10GBCX4/public/jan03/WP2p > 0_cls30_annex30B.pdf > > While it is probably not be appropriate to include this stuff in the > next MAU-MIB draft that includes the 802.3ae stuff, the changes are > small enough that they should be able to go into a maintenance update > without affecting time-in-grade, or else when then the document > advances Draft Standard. > > The impact of 10GBASE-T is harder to gauge. > > Mike Heard > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Jan 15 04:14:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20715 for ; Wed, 15 Jan 2003 04:14:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9T8J25853; Wed, 15 Jan 2003 04:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9SMJ25802 for ; Wed, 15 Jan 2003 04:28:22 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20682 for ; Wed, 15 Jan 2003 04:13:17 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0F9DwT11951 for ; Wed, 15 Jan 2003 04:13:58 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0F9DvQ11945 for ; Wed, 15 Jan 2003 04:13:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Hubmib] 10GBASE-CX4 and 10GBASE-T Date: Wed, 15 Jan 2003 11:16:32 +0200 Message-ID: Thread-Topic: [Hubmib] 10GBASE-CX4 and 10GBASE-T Thread-Index: AcK8CJfQAmaiIrApRX2P4p6z/ASQ7AAbVlMQ From: "Romascanu, Dan (Dan)" To: "C. M. Heard" , "Hub MIB" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F9SMJ25803 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike, It is still too early to gauge the impact of technologies that are in Study Group phase in the IEEE on our WG work. We need first see these two subjects adopted as standards work by the IEEE and the specifications reaching a relatively stable phase. At this point, if there is interest and there are volunteers to work, we can require to be chartered in order to make the needed additions to the Ethernet MIBs. Also, let us not forget that we also have IEEE 802.3ah - Ethernet First Mile as a possible work item, even before the copper 10GBE technologies. Are people interested in starting to look at possible MIB work for EFM? Thanks, Dan > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Tuesday, January 14, 2003 10:04 PM > To: Hub MIB > Subject: [Hubmib] 10GBASE-CX4 and 10GBASE-T > > > Hub MIB folks, > > For those who aren't already aware, I'd like to bring your > attention to the fact that there are two IEEE study groups > at work on new PMDs for 10 Gb/s Ethernet. The 10GBASE-CX4 > group is working on a 15 m shielded copper solution that > will use the same PCS as does 10GBASE-LX4. The 10GBASE-T > group is working on a 100 m UTP solution. Those who are > interested can find more information on the 802.3 web site > http://grouper.ieee.org/groups/802/3/ > > The 10GBASE-CX4 effort has, I believe, the much shorter > timeline, and it appears that the impact on our documents > will be minimal. In fact as far as I can tell, the only > document that will be affected is the MAU-MIB document, > and the changes to it will be confined to the following > additions: > > [ ... ] > > dot3MauType10GigBaseCX4 OBJECT-IDENTITY > STATUS current > DESCRIPTION "X fiber over copper (per 802.3 section > 54)" > ::= { dot3MauType XX } -- NOTE: next unassigned value is 41 > > [ ... ] > > ifMauTypeListBits OBJECT-TYPE > SYNTAX BITS { > [ ... ] > b10GbaseCX4(XX), -- 10GBASE-CX4 (see NOTE above) > [ ... ] > } > [ ... ] > > These would mirror the proposed changes to Clause 30, which you can > find here: > > http://grouper.ieee.org/groups/802/3/10GBCX4/public/jan03/WP2p > 0_cls30_annex30B.pdf > > While it is probably not be appropriate to include this stuff in the > next MAU-MIB draft that includes the 802.3ae stuff, the changes are > small enough that they should be able to go into a maintenance update > without affecting time-in-grade, or else when then the document > advances Draft Standard. > > The impact of 10GBASE-T is harder to gauge. > > Mike Heard > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Wed Jan 15 14:20:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07051 for ; Wed, 15 Jan 2003 14:20:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FJZL703187 for hubmib-archive@odin.ietf.org; Wed, 15 Jan 2003 14:35:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJZLJ03181; Wed, 15 Jan 2003 14:35:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJYZJ03143 for ; Wed, 15 Jan 2003 14:34:35 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07033 for ; Wed, 15 Jan 2003 14:19:19 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0FJK4U21376 for ; Wed, 15 Jan 2003 14:20:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0FJK3J21357 for ; Wed, 15 Jan 2003 14:20:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCCB.772AA20B" Date: Wed, 15 Jan 2003 21:22:38 +0200 Message-ID: Thread-Topic: Power Ethernet MIB Last Call - Late Comments Thread-Index: AcK8y3cwxaqcpu6XTZCLwefYIZ62/g== From: "Romascanu, Dan (Dan)" To: Subject: [Hubmib] Power Ethernet MIB Last Call - Late Comments Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BCCB.772AA20B Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The WG Last Call for the Power Ethernet MIB is ending today. In the last = couple of days I got calls for two contributors about late comments = being prepared. One of them is our colleague David Law from 3Com, who is = the chief editor of the IEEE management clauses, and will be making some = comments related to later changes in the IEEE 802.3af Draft. The other = comments are coming from one of the companies implementing the IEEE = Draft. These comments might get to the list later than the Last Call = deadline, but I suggest that we admit and include them as Last Call = inputs.=20 Please let me know if there are any objections. Thanks, Dan ------_=_NextPart_001_01C2BCCB.772AA20B Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Power Ethernet MIB Last Call - Late Comments

The WG Last Call for the = Power Ethernet MIB is ending today. In the last couple of days I got = calls for two contributors about late comments being prepared. One of = them is our colleague David Law from 3Com, who is the chief editor of = the IEEE management clauses, and will be making some comments related to = later changes in the IEEE 802.3af Draft. The other comments are coming = from one of the companies implementing the IEEE Draft. These comments = might get to the list later than the Last Call deadline, but I suggest = that we admit and include them as Last Call inputs.

Please let me know if there = are any objections.

Thanks,

Dan

------_=_NextPart_001_01C2BCCB.772AA20B-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Jan 15 14:20:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07064 for ; Wed, 15 Jan 2003 14:20:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJZLJ03181; Wed, 15 Jan 2003 14:35:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJYZJ03143 for ; Wed, 15 Jan 2003 14:34:35 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07033 for ; Wed, 15 Jan 2003 14:19:19 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0FJK4U21376 for ; Wed, 15 Jan 2003 14:20:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0FJK3J21357 for ; Wed, 15 Jan 2003 14:20:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCCB.772AA20B" Date: Wed, 15 Jan 2003 21:22:38 +0200 Message-ID: Thread-Topic: Power Ethernet MIB Last Call - Late Comments Thread-Index: AcK8y3cwxaqcpu6XTZCLwefYIZ62/g== From: "Romascanu, Dan (Dan)" To: Subject: [Hubmib] Power Ethernet MIB Last Call - Late Comments Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BCCB.772AA20B Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The WG Last Call for the Power Ethernet MIB is ending today. In the last = couple of days I got calls for two contributors about late comments = being prepared. One of them is our colleague David Law from 3Com, who is = the chief editor of the IEEE management clauses, and will be making some = comments related to later changes in the IEEE 802.3af Draft. The other = comments are coming from one of the companies implementing the IEEE = Draft. These comments might get to the list later than the Last Call = deadline, but I suggest that we admit and include them as Last Call = inputs.=20 Please let me know if there are any objections. Thanks, Dan ------_=_NextPart_001_01C2BCCB.772AA20B Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Power Ethernet MIB Last Call - Late Comments

The WG Last Call for the = Power Ethernet MIB is ending today. In the last couple of days I got = calls for two contributors about late comments being prepared. One of = them is our colleague David Law from 3Com, who is the chief editor of = the IEEE management clauses, and will be making some comments related to = later changes in the IEEE 802.3af Draft. The other comments are coming = from one of the companies implementing the IEEE Draft. These comments = might get to the list later than the Last Call deadline, but I suggest = that we admit and include them as Last Call inputs.

Please let me know if there = are any objections.

Thanks,

Dan

------_=_NextPart_001_01C2BCCB.772AA20B-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Wed Jan 15 20:48:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17611 for ; Wed, 15 Jan 2003 20:48:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G23C031520 for hubmib-archive@odin.ietf.org; Wed, 15 Jan 2003 21:03:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G23CJ31512; Wed, 15 Jan 2003 21:03:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G1UvJ29502 for ; Wed, 15 Jan 2003 20:30:57 -0500 Received: from columba.www.eur.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17078 for ; Wed, 15 Jan 2003 20:15:33 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id h0G1KVNS024289 for ; Thu, 16 Jan 2003 01:20:32 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h0G1KJQ00045 for ; Thu, 16 Jan 2003 01:20:19 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CB0.000741EA ; Thu, 16 Jan 2003 01:19:16 +0000 X-Lotus-FromDomain: 3COM From: "David Law" To: hubmib@ietf.org Message-ID: <80256CB0.000741A7.00@notesmta.eur.3com.com> Date: Thu, 16 Jan 2003 01:34:46 +0000 Subject: Re: [Hubmib] Power Ethernet MIB Last Call - Late Comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , All, As Dan mentions below I'm concerned that there may be some changes that are about to occur in the IEEE P802.3af DTE Power via MDI Draft that may impact the Power Ethernet MIB. To update you all on the status of this work, the Sponsor ballot for IEEE P802.3af DTE Power via MDI Draft D4.0 closed on the 1st January. The Sponsor ballot is the second ballot of the IEEE P802.3 two stage balloting process. The IEEE P802.3af Task Force met last week to perform comment resolution and while good progress was made, the Task Force didn't complete this work by the end of this meeting as originally expected. The Task Force is therefore meeting again in a couple of weeks time to complete comment resolution. A new draft is then expect to be submitted for Sponsor Ballot re-circulation in early February. One area where there was a large number of comments was the PSE State Diagram, for example to align it better to the behavior described in the related text and to the register bits (Clause 22). Another area I have a concern with was that of PD management. The register bits to support this have now been removed and there is currently an accepted comment that would result in PD management object being removed from the Management clause (Clause 30) altogether. My concern is that these changes may therefore also impact the Power Ethernet MIB in a couple of ways. Firstly, that the Power Ethernet MIB references states in the PSE State Diagram that may be removed of whose behavior may be changed in a way that will now longer provided the desired behavior in the Power Ethernet MIB. Secondly, changes to the register bits in the Clause 22 registers may result in implementations no longer providing the hardware support for the Power Ethernet MIB, a undesirable situation in my opinion. Now while it may be possible to list the individual updates required to the current Power Ethernet MIB draft to align to the comments resolved so far, it is entirely possible that additional changes could occur at the next comment resolution meeting. Since I believe it is in the interest of the users of our respective documents to assure that our two document align, and alignment between similar documents in the past is something we have successfully achieved, it would be great if we could assure that happens again in this case despite any change that may occur to the IEEE P802.3af draft in the next couple of weeks. Best regards, David Law "Romascanu, Dan (Dan)" @ietf.org on 15/01/2003 19:22:38 Sent by: hubmib-admin@ietf.org To: cc: Subject: [Hubmib] Power Ethernet MIB Last Call - Late Comments The WG Last Call for the Power Ethernet MIB is ending today. In the last couple of days I got calls for two contributors about late comments being prepared. One of them is our colleague David Law from 3Com, who is the chief editor of the IEEE management clauses, and will be making some comments related to later changes in the IEEE 802.3af Draft. The other comments are coming from one of the companies implementing the IEEE Draft. These comments might get to the list later than the Last Call deadline, but I suggest that we admit and include them as Last Call inputs. Please let me know if there are any objections. Thanks, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Jan 15 20:48:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17625 for ; Wed, 15 Jan 2003 20:48:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G23CJ31512; Wed, 15 Jan 2003 21:03:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G1UvJ29502 for ; Wed, 15 Jan 2003 20:30:57 -0500 Received: from columba.www.eur.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17078 for ; Wed, 15 Jan 2003 20:15:33 -0500 (EST) Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id h0G1KVNS024289 for ; Thu, 16 Jan 2003 01:20:32 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h0G1KJQ00045 for ; Thu, 16 Jan 2003 01:20:19 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CB0.000741EA ; Thu, 16 Jan 2003 01:19:16 +0000 X-Lotus-FromDomain: 3COM From: "David Law" To: hubmib@ietf.org Message-ID: <80256CB0.000741A7.00@notesmta.eur.3com.com> Date: Thu, 16 Jan 2003 01:34:46 +0000 Subject: Re: [Hubmib] Power Ethernet MIB Last Call - Late Comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , All, As Dan mentions below I'm concerned that there may be some changes that are about to occur in the IEEE P802.3af DTE Power via MDI Draft that may impact the Power Ethernet MIB. To update you all on the status of this work, the Sponsor ballot for IEEE P802.3af DTE Power via MDI Draft D4.0 closed on the 1st January. The Sponsor ballot is the second ballot of the IEEE P802.3 two stage balloting process. The IEEE P802.3af Task Force met last week to perform comment resolution and while good progress was made, the Task Force didn't complete this work by the end of this meeting as originally expected. The Task Force is therefore meeting again in a couple of weeks time to complete comment resolution. A new draft is then expect to be submitted for Sponsor Ballot re-circulation in early February. One area where there was a large number of comments was the PSE State Diagram, for example to align it better to the behavior described in the related text and to the register bits (Clause 22). Another area I have a concern with was that of PD management. The register bits to support this have now been removed and there is currently an accepted comment that would result in PD management object being removed from the Management clause (Clause 30) altogether. My concern is that these changes may therefore also impact the Power Ethernet MIB in a couple of ways. Firstly, that the Power Ethernet MIB references states in the PSE State Diagram that may be removed of whose behavior may be changed in a way that will now longer provided the desired behavior in the Power Ethernet MIB. Secondly, changes to the register bits in the Clause 22 registers may result in implementations no longer providing the hardware support for the Power Ethernet MIB, a undesirable situation in my opinion. Now while it may be possible to list the individual updates required to the current Power Ethernet MIB draft to align to the comments resolved so far, it is entirely possible that additional changes could occur at the next comment resolution meeting. Since I believe it is in the interest of the users of our respective documents to assure that our two document align, and alignment between similar documents in the past is something we have successfully achieved, it would be great if we could assure that happens again in this case despite any change that may occur to the IEEE P802.3af draft in the next couple of weeks. Best regards, David Law "Romascanu, Dan (Dan)" @ietf.org on 15/01/2003 19:22:38 Sent by: hubmib-admin@ietf.org To: cc: Subject: [Hubmib] Power Ethernet MIB Last Call - Late Comments The WG Last Call for the Power Ethernet MIB is ending today. In the last couple of days I got calls for two contributors about late comments being prepared. One of them is our colleague David Law from 3Com, who is the chief editor of the IEEE management clauses, and will be making some comments related to later changes in the IEEE 802.3af Draft. The other comments are coming from one of the companies implementing the IEEE Draft. These comments might get to the list later than the Last Call deadline, but I suggest that we admit and include them as Last Call inputs. Please let me know if there are any objections. Thanks, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Thu Jan 16 01:26:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22626 for ; Thu, 16 Jan 2003 01:26:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G6f5t14914 for hubmib-archive@odin.ietf.org; Thu, 16 Jan 2003 01:41:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6f5J14908; Thu, 16 Jan 2003 01:41:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6ecJ14886 for ; Thu, 16 Jan 2003 01:40:39 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22605 for ; Thu, 16 Jan 2003 01:25:09 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id WAA30355 for ; Wed, 15 Jan 2003 22:28:30 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 15 Jan 2003 22:28:29 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub Mib Subject: Re: [Hubmib] Power Ethernet MIB Last Call - Late Comments In-Reply-To: <80256CB0.000741A7.00@notesmta.eur.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 16 Jan 2003, David Law wrote: > As Dan mentions below I'm concerned that there may be some > changes that are about to occur in the IEEE P802.3af DTE > Power via MDI Draft that may impact the Power Ethernet MIB. > [ .... ] these changes may [ ... ] impact the Power Ethernet > MIB in a couple of ways. Firstly, that the Power Ethernet > MIB references states in the PSE State Diagram that may be > removed of whose behavior may be changed in a way that will > now longer provided the desired behavior in the Power Ethernet > MIB. Secondly, changes to the register bits in the Clause 22 > registers may result in implementations no longer providing the > hardware support for the Power Ethernet MIB, a undesirable > situation in my opinion. That's putting it mildly. It would be intolerable if the Power Ethernet MIB were not aligned with the behaviour or hardware resources of standards-conforming devices. > Now while it may be possible to list the individual > updates required to the current Power Ethernet MIB > draft to align to the comments resolved so far, it is > entirely possible that additional changes could occur > at the next comment resolution meeting. > > Since I believe it is in the interest of the users of our > respective documents to assure that our two document align, and > alignment between similar documents in the past is something we > have successfully achieved, it would be great if we could assure > that happens again in this case despite any change that may > occur to the IEEE P802.3af draft in the next couple of weeks. I agree. I think that the WG should wait until the IEEE P802.3af draft is considered to be stable, and then update the Power Ethernet MIB to align with it before submitting the document to the the IESG for consideration as a Proposed Standard. That's not to say that all work on the Power Ethernet MIB should necessarily stop. There are a number of MIB doctor and "ID nit" type things that need to be addressed, as I noted in previous comments. If the authors want to spin an updated draft to address those issues, I'll be happy to give it another review, and then to do it again when the final technical changes from the stable IEEE draft are rolled in. A certain amount of churn is just part of the process. Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Jan 16 01:26:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22643 for ; Thu, 16 Jan 2003 01:26:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6f5J14908; Thu, 16 Jan 2003 01:41:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6ecJ14886 for ; Thu, 16 Jan 2003 01:40:39 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22605 for ; Thu, 16 Jan 2003 01:25:09 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id WAA30355 for ; Wed, 15 Jan 2003 22:28:30 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 15 Jan 2003 22:28:29 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub Mib Subject: Re: [Hubmib] Power Ethernet MIB Last Call - Late Comments In-Reply-To: <80256CB0.000741A7.00@notesmta.eur.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 16 Jan 2003, David Law wrote: > As Dan mentions below I'm concerned that there may be some > changes that are about to occur in the IEEE P802.3af DTE > Power via MDI Draft that may impact the Power Ethernet MIB. > [ .... ] these changes may [ ... ] impact the Power Ethernet > MIB in a couple of ways. Firstly, that the Power Ethernet > MIB references states in the PSE State Diagram that may be > removed of whose behavior may be changed in a way that will > now longer provided the desired behavior in the Power Ethernet > MIB. Secondly, changes to the register bits in the Clause 22 > registers may result in implementations no longer providing the > hardware support for the Power Ethernet MIB, a undesirable > situation in my opinion. That's putting it mildly. It would be intolerable if the Power Ethernet MIB were not aligned with the behaviour or hardware resources of standards-conforming devices. > Now while it may be possible to list the individual > updates required to the current Power Ethernet MIB > draft to align to the comments resolved so far, it is > entirely possible that additional changes could occur > at the next comment resolution meeting. > > Since I believe it is in the interest of the users of our > respective documents to assure that our two document align, and > alignment between similar documents in the past is something we > have successfully achieved, it would be great if we could assure > that happens again in this case despite any change that may > occur to the IEEE P802.3af draft in the next couple of weeks. I agree. I think that the WG should wait until the IEEE P802.3af draft is considered to be stable, and then update the Power Ethernet MIB to align with it before submitting the document to the the IESG for consideration as a Proposed Standard. That's not to say that all work on the Power Ethernet MIB should necessarily stop. There are a number of MIB doctor and "ID nit" type things that need to be addressed, as I noted in previous comments. If the authors want to spin an updated draft to address those issues, I'll be happy to give it another review, and then to do it again when the final technical changes from the stable IEEE draft are rolled in. A certain amount of churn is just part of the process. Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Thu Jan 16 09:34:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12275 for ; Thu, 16 Jan 2003 09:34:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEn9V26981 for hubmib-archive@odin.ietf.org; Thu, 16 Jan 2003 09:49:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEn9J26976; Thu, 16 Jan 2003 09:49:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3BAJ03161 for ; Wed, 15 Jan 2003 22:11:10 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18968 for ; Wed, 15 Jan 2003 21:55:44 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0G2uUd22082 for ; Thu, 16 Jan 2003 02:56:30 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0G317I26833 for ; Thu, 16 Jan 2003 03:01:07 GMT Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011518592718986 for ; Wed, 15 Jan 2003 18:59:27 -0800 Received: from fmsmsx408.amr.corp.intel.com ([132.233.42.219]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 18:59:05 -0800 content-class: urn:content-classes:message Date: Wed, 15 Jan 2003 18:59:05 -0800 Message-ID: <3BF285C347DD274FB835A67133811D4F23CC6A@fmsmsx408.fm.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Thread-Topic: WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Thread-Index: AcK9CjNZl5nYRuMuQvqKEve63UAZxA== From: "Grow, Bob" To: X-OriginalArrivalTime: 16 Jan 2003 02:59:05.0830 (UTC) FILETIME=[3B610860:01C2BD0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0G3BAJ03162 Subject: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I personally believe the timing for closing of the last call is too early. The comments submitted on P802.3af/D4.0 Sponsor Ballot are producing changes to the management structure. A number of commenters have discovered inconsistencies between the state machine description, and the MDIO register bit definitions. These changes are fundamental to the hubmib, because capabilities described in the state diagrams and registers represent the hardware capabilities on which any MIB is built. Our MIB specified in Clause 30 will be modified to agree with the state diagrams and register bit definitions. While some changes were communicated to Dan Romascanu, a number of contemplated changes have not yet been decided by the 802.3af Task Force. The 802.3af Task Force will be meeting to continue comment resolution at the end of January. The decisions made at that meeting and the resulting D4.1 will provide a more stable base of functionality for construction of the IETF hubmib for power Ethernet. Bob Grow Chair, IEEE 802.3 Working Group bob.grow@ieee.org _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Jan 16 09:37:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12359 for ; Thu, 16 Jan 2003 09:37:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEn9J26976; Thu, 16 Jan 2003 09:49:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3BAJ03161 for ; Wed, 15 Jan 2003 22:11:10 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18968 for ; Wed, 15 Jan 2003 21:55:44 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0G2uUd22082 for ; Thu, 16 Jan 2003 02:56:30 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0G317I26833 for ; Thu, 16 Jan 2003 03:01:07 GMT Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011518592718986 for ; Wed, 15 Jan 2003 18:59:27 -0800 Received: from fmsmsx408.amr.corp.intel.com ([132.233.42.219]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 18:59:05 -0800 content-class: urn:content-classes:message Date: Wed, 15 Jan 2003 18:59:05 -0800 Message-ID: <3BF285C347DD274FB835A67133811D4F23CC6A@fmsmsx408.fm.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Thread-Topic: WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Thread-Index: AcK9CjNZl5nYRuMuQvqKEve63UAZxA== From: "Grow, Bob" To: X-OriginalArrivalTime: 16 Jan 2003 02:59:05.0830 (UTC) FILETIME=[3B610860:01C2BD0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0G3BAJ03162 Subject: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I personally believe the timing for closing of the last call is too early. The comments submitted on P802.3af/D4.0 Sponsor Ballot are producing changes to the management structure. A number of commenters have discovered inconsistencies between the state machine description, and the MDIO register bit definitions. These changes are fundamental to the hubmib, because capabilities described in the state diagrams and registers represent the hardware capabilities on which any MIB is built. Our MIB specified in Clause 30 will be modified to agree with the state diagrams and register bit definitions. While some changes were communicated to Dan Romascanu, a number of contemplated changes have not yet been decided by the 802.3af Task Force. The 802.3af Task Force will be meeting to continue comment resolution at the end of January. The decisions made at that meeting and the resulting D4.1 will provide a more stable base of functionality for construction of the IETF hubmib for power Ethernet. Bob Grow Chair, IEEE 802.3 Working Group bob.grow@ieee.org _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Thu Jan 16 09:45:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12590 for ; Thu, 16 Jan 2003 09:45:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GF12R27562 for hubmib-archive@odin.ietf.org; Thu, 16 Jan 2003 10:01:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF12J27557; Thu, 16 Jan 2003 10:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEv0J27327 for ; Thu, 16 Jan 2003 09:57:00 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12441 for ; Thu, 16 Jan 2003 09:41:20 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09377 for ; Thu, 16 Jan 2003 09:42:11 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09361 for ; Thu, 16 Jan 2003 09:42:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Date: Thu, 16 Jan 2003 16:44:39 +0200 Message-ID: Thread-Topic: WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Thread-Index: AcK9CjNZl5nYRuMuQvqKEve63UAZxAAYuqVQ From: "Romascanu, Dan (Dan)" To: "Grow, Bob" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GEv0J27328 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks for the update, Bob. My proposal is to defer issuing a new version of the Internet Draft for after the publication of the 802.3af/D4.1 in February. This version would include the comments received during the Last Call period, and possible changes resulted from the changes in D4.1 relative to D4.0. If there are no strong objections in the next 48 hours, I will submit the request for the change in schedules to the O&M Area Directors. Dan > -----Original Message----- > From: Grow, Bob [mailto:bob.grow@intel.com] > Sent: Thursday, January 16, 2003 4:59 AM > To: hubmib@ietf.org > Subject: [Hubmib] WG Last Call - > draft-ietf-hubmib-power-ethernet-mib-04.txt > > > I personally believe the timing for closing of the last call > is too early. The comments submitted on P802.3af/D4.0 > Sponsor Ballot are producing changes to the management > structure. A number of commenters have discovered > inconsistencies between the state machine description, and > the MDIO register bit definitions. These changes are > fundamental to the hubmib, because capabilities described in > the state diagrams and registers represent the hardware > capabilities on which any MIB is built. Our MIB specified in > Clause 30 will be modified to agree with the state diagrams > and register bit definitions. While some changes were > communicated to Dan Romascanu, a number of contemplated > changes have not yet been decided by the 802.3af Task Force. > > The 802.3af Task Force will be meeting to continue comment > resolution at the end of January. The decisions made at that > meeting and the resulting D4.1 will provide a more stable > base of functionality for construction of the IETF hubmib for > power Ethernet. > > Bob Grow > Chair, IEEE 802.3 Working Group > bob.grow@ieee.org > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Jan 16 09:49:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12666 for ; Thu, 16 Jan 2003 09:49:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF12J27557; Thu, 16 Jan 2003 10:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEv0J27327 for ; Thu, 16 Jan 2003 09:57:00 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12441 for ; Thu, 16 Jan 2003 09:41:20 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09377 for ; Thu, 16 Jan 2003 09:42:11 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09361 for ; Thu, 16 Jan 2003 09:42:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Hubmib] WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Date: Thu, 16 Jan 2003 16:44:39 +0200 Message-ID: Thread-Topic: WG Last Call - draft-ietf-hubmib-power-ethernet-mib-04.txt Thread-Index: AcK9CjNZl5nYRuMuQvqKEve63UAZxAAYuqVQ From: "Romascanu, Dan (Dan)" To: "Grow, Bob" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GEv0J27328 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks for the update, Bob. My proposal is to defer issuing a new version of the Internet Draft for after the publication of the 802.3af/D4.1 in February. This version would include the comments received during the Last Call period, and possible changes resulted from the changes in D4.1 relative to D4.0. If there are no strong objections in the next 48 hours, I will submit the request for the change in schedules to the O&M Area Directors. Dan > -----Original Message----- > From: Grow, Bob [mailto:bob.grow@intel.com] > Sent: Thursday, January 16, 2003 4:59 AM > To: hubmib@ietf.org > Subject: [Hubmib] WG Last Call - > draft-ietf-hubmib-power-ethernet-mib-04.txt > > > I personally believe the timing for closing of the last call > is too early. The comments submitted on P802.3af/D4.0 > Sponsor Ballot are producing changes to the management > structure. A number of commenters have discovered > inconsistencies between the state machine description, and > the MDIO register bit definitions. These changes are > fundamental to the hubmib, because capabilities described in > the state diagrams and registers represent the hardware > capabilities on which any MIB is built. Our MIB specified in > Clause 30 will be modified to agree with the state diagrams > and register bit definitions. While some changes were > communicated to Dan Romascanu, a number of contemplated > changes have not yet been decided by the 802.3af Task Force. > > The 802.3af Task Force will be meeting to continue comment > resolution at the end of January. The decisions made at that > meeting and the resulting D4.1 will provide a more stable > base of functionality for construction of the IETF hubmib for > power Ethernet. > > Bob Grow > Chair, IEEE 802.3 Working Group > bob.grow@ieee.org > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Mon Jan 20 13:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26877 for ; Mon, 20 Jan 2003 13:45:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJ2K006462 for hubmib-archive@odin.ietf.org; Mon, 20 Jan 2003 14:02:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ2GJ06457; Mon, 20 Jan 2003 14:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ1gJ06426 for ; Mon, 20 Jan 2003 14:01:42 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26860 for ; Mon, 20 Jan 2003 13:44:00 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0KIilP10406 for ; Mon, 20 Jan 2003 13:44:47 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0KIik610382 for ; Mon, 20 Jan 2003 13:44:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C0B4.5EC08439" Date: Mon, 20 Jan 2003 20:47:23 +0200 Message-ID: Thread-Topic: Meeting in San Francisco? Thread-Index: AcLAtF7NdppKAS/5Q4acFg8QwtesIg== From: "Romascanu, Dan (Dan)" To: Subject: [Hubmib] Meeting in San Francisco? Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C0B4.5EC08439 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable WG Scheduling for the San Francisco IETF is open. At this point in time = I do not see compelling reasons for the Ethernet Interfaces and Hub MIB = WG to have a meeting in San Francisco. If there are any different = opinions, and proposals please post a message to the list.=20 Dan ------_=_NextPart_001_01C2C0B4.5EC08439 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Meeting in San Francisco?

WG Scheduling for the San = Francisco IETF is open. At this point in time I do not see compelling = reasons for the Ethernet Interfaces and Hub MIB WG to have a meeting in = San Francisco. If there are any different opinions, and proposals please = post a message to the list.

Dan

------_=_NextPart_001_01C2C0B4.5EC08439-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Jan 20 13:45:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26925 for ; Mon, 20 Jan 2003 13:45:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ2GJ06457; Mon, 20 Jan 2003 14:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ1gJ06426 for ; Mon, 20 Jan 2003 14:01:42 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26860 for ; Mon, 20 Jan 2003 13:44:00 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0KIilP10406 for ; Mon, 20 Jan 2003 13:44:47 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h0KIik610382 for ; Mon, 20 Jan 2003 13:44:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C0B4.5EC08439" Date: Mon, 20 Jan 2003 20:47:23 +0200 Message-ID: Thread-Topic: Meeting in San Francisco? Thread-Index: AcLAtF7NdppKAS/5Q4acFg8QwtesIg== From: "Romascanu, Dan (Dan)" To: Subject: [Hubmib] Meeting in San Francisco? Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C0B4.5EC08439 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable WG Scheduling for the San Francisco IETF is open. At this point in time = I do not see compelling reasons for the Ethernet Interfaces and Hub MIB = WG to have a meeting in San Francisco. If there are any different = opinions, and proposals please post a message to the list.=20 Dan ------_=_NextPart_001_01C2C0B4.5EC08439 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Meeting in San Francisco?

WG Scheduling for the San = Francisco IETF is open. At this point in time I do not see compelling = reasons for the Ethernet Interfaces and Hub MIB WG to have a meeting in = San Francisco. If there are any different opinions, and proposals please = post a message to the list.

Dan

------_=_NextPart_001_01C2C0B4.5EC08439-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib