From moulchan@cisco.com Tue Jan 8 02:00:12 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D65621F88CA for ; Tue, 8 Jan 2013 02:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FfrutqFXQTW for ; Tue, 8 Jan 2013 02:00:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A321F88C8 for ; Tue, 8 Jan 2013 02:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=177; q=dns/txt; s=iport; t=1357639211; x=1358848811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5vjWC6Xc6eBvDz9ZpcfUFR6SYpi+EocA0O7wVifriH0=; b=SnU91YuBCO7fwn4+R1PwQ1/67qaX65IJv8+bchWEVRfO5KzUYoXgPHGw Sbdcd9O/Enc26NHT8tucfuJaveHjiYQNRTiePh+mPLwB50vS++2/8aCik OVN2dnA/tGHeB0h/OWS6zeNM6T5sCCmznt+KraM+j+/N+uw68yreeZC4r g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAJXs61CtJXHB/2dsb2JhbABEFoVct2MWc4IfAQECAjo/EAIBKhQQMiUCBA4NiA8Mqg+NOYxXF4NGYQOXJ48tgnSCJg X-IronPort-AV: E=Sophos;i="4.84,430,1355097600"; d="scan'208";a="159756457" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2013 10:00:11 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r08A0AIm003798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 10:00:10 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 04:00:10 -0600 From: "Mouli Chandramouli (moulchan)" To: Rolf Winter Thread-Topic: Using Batteries to Reduce the Power Costs of Internet-Scale Distributed Systems Thread-Index: AQHN7YbxO4oEj39XRkuK/3iUi7DTSQ== Date: Tue, 8 Jan 2013 10:00:10 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42866FF43@xmb-rcd-x08.cisco.com> References: <20121022202601.24058.73317.idtracker@ietfa.amsl.com> In-Reply-To: <20121022202601.24058.73317.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B0mU Cnf2 EQJE Exjq FJUk Ip6J KTas K5Be K6ZR NM8J OtEP PZ9y P2Fs RPoS S5SX UpN0; 2; ZQBtAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AHIAbwBsAGYALgB3AGkAbgB0AGUAcgBAAG4AZQBjAGwAYQBiAC4AZQB1AA==; Sosha1_v1; 7; {41A84410-E235-43C1-93A7-B41C92B3A777}; bQBvAHUAbABjAGgAYQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 08 Jan 2013 10:00:04 GMT; VQBzAGkAbgBnACAAQgBhAHQAdABlAHIAaQBlAHMAIAB0AG8AIABSAGUAZAB1AGMAZQAgAHQAaABlACAAUABvAHcAZQByACAAQwBvAHMAdABzACAAbwBmACAASQBuAHQAZQByAG4AZQB0AC0AUwBjAGEAbABlACAARABpAHMAdAByAGkAYgB1AHQAZQBkACAAUwB5AHMAdABlAG0AcwA= x-cr-puzzleid: {41A84410-E235-43C1-93A7-B41C92B3A777} x-originating-ip: [10.65.76.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: [eman] Using Batteries to Reduce the Power Costs of Internet-Scale Distributed Systems X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:00:12 -0000 Using Batteries to Reduce the Power Costs of Internet-Scale Distributed Sys= tems=20 http://people.cs.umass.edu/~ramesh/Site/HOME_files/batteriespaper.pdf Thanks Mouli From bclaise@cisco.com Fri Jan 11 07:52:16 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE3721F858E for ; Fri, 11 Jan 2013 07:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl-C-Oez95r4 for ; Fri, 11 Jan 2013 07:52:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E02FE21F8432 for ; Fri, 11 Jan 2013 07:52:11 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BFbGIJ018315; Fri, 11 Jan 2013 16:37:16 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BFbFjq022367; Fri, 11 Jan 2013 16:37:16 +0100 (CET) Message-ID: <50F031AB.9070908@cisco.com> Date: Fri, 11 Jan 2013 16:37:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-eman-rfc4133bis@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040203060801000000090304" Cc: eman mailing list Subject: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:52:16 -0000 This is a multi-part message in MIME format. --------------040203060801000000090304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy, Dan, Juergen, Mouli, Here is my review. I'm sending this draft to IETF LC now. Please insert this feedback part of it _TECHNICAL_ entity3Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement _version 3 and 4 (full compliance)_ of the Entity MIB." MODULE -- this module MANDATORY-GROUPS { entityPhysicalGroup, entityPhysical2Group, entityGeneralGroup, entityNotificationsGroup } GROUP entityLogical2Group DESCRIPTION "Implementation of this group is not mandatory for agents that model all MIB object instances within a single naming scope." Is this correct to say "version 3 and version 4"? Version 3 is now obsolete: how could we compliant? I believe it only be "version 4 (full compliance)" Should the name be changed from entity3Compliance to entity4Compliance? I believe it makes sense since you have entity4CRCompliance later in the doc. _EDITORIAL_ 1. OLD 2.16.2. Modification to some of the MIB objects Addition of a new MIB object to the entPhysicalTable - entPhysicalUUID. In comparison to entPhysicalUris the new object is read-only and restricted to a fixed size to allow only for RFC 4122 [RFC4122 ] compliant values. NEW 2.16.2. Modification to some of the MIB objects Addition of a new MIB object to the entPhysicalTable - entPhysicalUUID, which contains a Universal Unique Identifier (UUID) In comparison to entPhysicalUris the new object is read-only and restricted to a fixed size to allow only for RFC 4122 [RFC4122 ] compliant values. 2. Section 2.16.2 Add an extra "." at the end of the paragraph Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for devices with constrained resources like batteries, which might require a limited number of objects to be supported (entPhysicalClass, entPhysicalName, entPhysicalUUID) 3. remove (UUID) below 2.16.3. New TC for Universal Unique Identifier Two new Textual Conventions (TC) UUID and UUIDorZero were created to represent a Universal Unique Identifier (UUID), 4. entPhysicalUUID OBJECT-TYPE SYNTAX UUIDorZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. A zero length octet string is returned if no UUID information is known." Either remove "additional", or mention compared to what Regards, Benoit (OPS AD) --------------040203060801000000090304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andy, Dan, Juergen, Mouli,

Here is my review.
I'm sending this draft to IETF LC now.  Please insert this feedback part of it


TECHNICAL
entity3Compliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "The compliance statement for SNMP entities that implement
            version 3 and 4 (full compliance) of the Entity MIB."
    MODULE  -- this module
        MANDATORY-GROUPS {
                           entityPhysicalGroup,
                           entityPhysical2Group,
                           entityGeneralGroup,
                           entityNotificationsGroup
        }
        GROUP entityLogical2Group
        DESCRIPTION
            "Implementation of this group is not mandatory for agents
            that model all MIB object instances within a single naming
            scope."
Is this correct to say "version 3 and version 4"? Version 3 is now obsolete: how could we compliant?
I believe it only be "version 4 (full compliance)"
Should the name be changed from entity3Compliance to entity4Compliance?
I believe it makes sense since you have entity4CRCompliance later in the doc.


EDITORIAL

1.
OLD

2.16.2. Modification to some of the MIB objects

 Addition of a new MIB object to the entPhysicalTable - entPhysicalUUID. In comparison to entPhysicalUris the new object is read-only and restricted to a fixed size to allow only for RFC 4122 [RFC4122] compliant values.

NEW

2.16.2. Modification to some of the MIB objects

 Addition of a new MIB object to the entPhysicalTable - entPhysicalUUID, which contains a  Universal Unique Identifier (UUID)
In comparison to entPhysicalUris the new object is read-only and restricted to a fixed size to allow only for RFC 4122 [RFC4122] compliant values.

2.
Section 2.16.2
Add an extra "." at the end of the paragraph
   Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for
   devices with constrained resources like batteries, which might
   require a limited number of objects to be supported
   (entPhysicalClass, entPhysicalName, entPhysicalUUID)

3.
remove (UUID) below
2.16.3.  New TC for Universal Unique Identifier

   Two new Textual Conventions (TC) UUID and UUIDorZero were created to
   represent a Universal Unique Identifier (UUID),

4.
entPhysicalUUID OBJECT-TYPE
    SYNTAX      UUIDorZero
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "This object contains additional identification information
            about the physical entity.  The object contains a Universal
            Unique Identifier, the syntax of this object must conform 
            to RFC 4122, section 4.1.

            A zero length octet string is returned if no UUID 
             information is known."
Either remove "additional", or mention compared to what


Regards, Benoit (OPS AD)
--------------040203060801000000090304-- From iesg-secretary@ietf.org Fri Jan 11 07:58:25 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F3221F88BD; Fri, 11 Jan 2013 07:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yChNVRi5lSnv; Fri, 11 Jan 2013 07:58:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF521F8793; Fri, 11 Jan 2013 07:58:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111155823.23604.94235.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 07:58:23 -0800 Cc: eman@ietf.org Subject: [eman] Last Call: (Entity MIB (Version 4)) to Proposed Standard X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:58:25 -0000 The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Entity MIB (Version 4)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ballot/ No IPR declarations have been submitted directly on this I-D. From j.schoenwaelder@jacobs-university.de Fri Jan 11 08:20:45 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2984B21F8937 for ; Fri, 11 Jan 2013 08:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuIV5rUOvtXm for ; Fri, 11 Jan 2013 08:20:43 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9593F21F8942 for ; Fri, 11 Jan 2013 08:20:37 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB2C320BE0; Fri, 11 Jan 2013 17:20:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0wKW-Homz9Sn; Fri, 11 Jan 2013 17:20:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4778120BDE; Fri, 11 Jan 2013 17:20:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B3F2E23E8D65; Fri, 11 Jan 2013 17:20:37 +0100 (CET) Date: Fri, 11 Jan 2013 17:20:37 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130111162037.GB5052@elstar.local> Mail-Followup-To: Benoit Claise , draft-ietf-eman-rfc4133bis@tools.ietf.org, eman mailing list References: <50F031AB.9070908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F031AB.9070908@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-eman-rfc4133bis@tools.ietf.org, eman mailing list Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:20:45 -0000 On Fri, Jan 11, 2013 at 04:37:15PM +0100, Benoit Claise wrote: > Andy, Dan, Juergen, Mouli, > > Here is my review. > I'm sending this draft to IETF LC now. Please insert this feedback > part of it > > > _TECHNICAL_ > > entity3Compliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities that implement > _version 3 and 4 (full compliance)_ of the Entity MIB." > MODULE -- this module > MANDATORY-GROUPS { > entityPhysicalGroup, > entityPhysical2Group, > entityGeneralGroup, > entityNotificationsGroup > } > GROUP entityLogical2Group > DESCRIPTION > "Implementation of this group is not mandatory for agents > that model all MIB object instances within a single naming > scope." > > Is this correct to say "version 3 and version 4"? Version 3 is now > obsolete: how could we compliant? > I believe it only be "version 4 (full compliance)" > Should the name be changed from entity3Compliance to entity4Compliance? > I believe it makes sense since you have entity4CRCompliance later in > the doc. Even worse, it seems the definition of already existing compliance groups have changed and with that the number of mandatory groups. This is not allowed per RFC 2580 section 7. > _EDITORIAL_ > > 1. > OLD > > > 2.16.2. Modification to some of the MIB objects > > Addition of a new MIB object to the entPhysicalTable - > entPhysicalUUID. In comparison to entPhysicalUris the new object is > read-only and restricted to a fixed size to allow only for RFC 4122 > [RFC4122 > ] compliant values. > > NEW > > > 2.16.2. Modification to some of the MIB objects > > Addition of a new MIB object to the entPhysicalTable - > entPhysicalUUID, which contains a Universal Unique Identifier > (UUID) > In comparison to entPhysicalUris the new object is read-only and > restricted to a fixed size to allow only for RFC 4122 > [RFC4122 > ] compliant values. > > 2. > Section 2.16.2 > Add an extra "." at the end of the paragraph > > Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for > devices with constrained resources like batteries, which might > require a limited number of objects to be supported > (entPhysicalClass, entPhysicalName, entPhysicalUUID) > > > 3. > remove (UUID) below > > > 2.16.3. New TC for Universal Unique Identifier > > > Two new Textual Conventions (TC) UUID and UUIDorZero were created to > represent a Universal Unique Identifier (UUID), > > > 4. > > entPhysicalUUID OBJECT-TYPE > SYNTAX UUIDorZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform > to RFC 4122, section 4.1. > > A zero length octet string is returned if no UUID > information is known." > > Either remove "additional", or mention compared to what Ideally, there would also be some guidance whether systems also implementing entPhysicalUris are expected to report the UUID value also as part of entPhysicalUris or not. Note also that RFC 4122 is twice in the references, once normative and once informative. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From iesg-secretary@ietf.org Fri Jan 11 13:03:02 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D021321F8A54; Fri, 11 Jan 2013 13:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQRW5b1vfUMS; Fri, 11 Jan 2013 13:03:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD221F8443; Fri, 11 Jan 2013 13:03:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111210301.17796.56390.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 13:03:01 -0800 Cc: eman@ietf.org Subject: [eman] Last Call: (Requirements for Energy Management) to Informational RFC X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:03:02 -0000 The IESG has received a request from the Energy Management WG (eman) to consider the following document: - 'Requirements for Energy Management' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions: Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From dromasca@avaya.com Sun Jan 13 00:40:57 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EB321F84CA for ; Sun, 13 Jan 2013 00:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcZRpwpAmZGM for ; Sun, 13 Jan 2013 00:40:56 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1D21F84C8 for ; Sun, 13 Jan 2013 00:40:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIbQt1CHCzI1/2dsb2JhbABBA4F/bb0ZFnOCHgEBAQECARIoNAsFBwICAgEIDQECAQQBAQEKFAkHGxcUCQgCBAENBQgah2gGAQuhe50MBIxBEIEAgkthA5cdhHGKN4JygWM+ X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="384230340" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Jan 2013 03:31:14 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2013 03:15:35 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Sun, 13 Jan 2013 03:41:04 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Benoit Claise" Thread-Topic: [eman] AD review of draft-ietf-eman-rfc4133bis-05 Thread-Index: AQHN8BGbswUFkV+tXUKzN4tBQfWwx5hEotyAgAJLC5A= Date: Sun, 13 Jan 2013 08:41:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA05F18B@AZ-FFEXMB04.global.avaya.com> References: <50F031AB.9070908@cisco.com> <20130111162037.GB5052@elstar.local> In-Reply-To: <20130111162037.GB5052@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , eman mailing list Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 08:40:57 -0000 Hi, Juergen comments are accurate. As this document is now under AD control, we= should wait for instructions from Benoit about when to make the required c= hanges.=20 See more in-line.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, January 11, 2013 6:21 PM > To: Benoit Claise > Cc: draft-ietf-eman-rfc4133bis@tools.ietf.org; eman mailing list > Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 >=20 > On Fri, Jan 11, 2013 at 04:37:15PM +0100, Benoit Claise wrote: > > Andy, Dan, Juergen, Mouli, > > > > Here is my review. > > I'm sending this draft to IETF LC now. Please insert this feedback > > part of it > > > > > > _TECHNICAL_ > > > > entity3Compliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP entities that implement > > _version 3 and 4 (full compliance)_ of the Entity MIB." > > MODULE -- this module > > MANDATORY-GROUPS { > > entityPhysicalGroup, > > entityPhysical2Group, > > entityGeneralGroup, > > entityNotificationsGroup > > } > > GROUP entityLogical2Group > > DESCRIPTION > > "Implementation of this group is not mandatory for agents > > that model all MIB object instances within a single naming > > scope." > > > > Is this correct to say "version 3 and version 4"? Version 3 is now > > obsolete: how could we compliant? > > I believe it only be "version 4 (full compliance)" > > Should the name be changed from entity3Compliance to > entity4Compliance? > > I believe it makes sense since you have entity4CRCompliance later in > > the doc. >=20 > Even worse, it seems the definition of already existing compliance > groups have changed and with that the number of mandatory groups. This > is not allowed per RFC 2580 section 7. >=20 [[DR]] Right. We need to re-establish entity3Compliance exactly to what it = was in RFC4133 and to create an entity4FullCompliance. > > _EDITORIAL_ > > > > 1. > > OLD > > > > > > 2.16.2. Modification to some of the MIB objects > > > > Addition of a new MIB object to the entPhysicalTable - > > entPhysicalUUID. In comparison to entPhysicalUris the new object is > > read-only and restricted to a fixed size to allow only for RFC 4122 > > [RFC4122 > > ] compliant values. > > > > NEW > > > > > > 2.16.2. Modification to some of the MIB objects > > > > Addition of a new MIB object to the entPhysicalTable - > > entPhysicalUUID, which contains a Universal Unique Identifier > > (UUID) > > In comparison to entPhysicalUris the new object is read-only and > > restricted to a fixed size to allow only for RFC 4122 > > [RFC4122 > > ] compliant values. > > > > 2. > > Section 2.16.2 > > Add an extra "." at the end of the paragraph > > > > Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for > > devices with constrained resources like batteries, which might > > require a limited number of objects to be supported > > (entPhysicalClass, entPhysicalName, entPhysicalUUID) > > > > > > 3. > > remove (UUID) below > > > > > > 2.16.3. New TC for Universal Unique Identifier > > > > > > Two new Textual Conventions (TC) UUID and UUIDorZero were created > to > > represent a Universal Unique Identifier (UUID), > > > > > > 4. > > > > entPhysicalUUID OBJECT-TYPE > > SYNTAX UUIDorZero > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object contains additional identification > information > > about the physical entity. The object contains a > Universal > > Unique Identifier, the syntax of this object must conform > > to RFC 4122, section 4.1. > > > > A zero length octet string is returned if no UUID > > information is known." > > > > Either remove "additional", or mention compared to what >=20 [[DR]] Removing seems fine to me.=20 > Ideally, there would also be some guidance whether systems also > implementing entPhysicalUris are expected to report the UUID value also > as part of entPhysicalUris or not.=20 [[DR]] Mouli - can you answer this? My take is that some agents may already= report this information, and we do not want to change their implementation= s.=20 > Note also that RFC 4122 is twice in > the references, once normative and once informative. >=20 [[DR]] Normative seems the right place. > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From bclaise@cisco.com Sun Jan 13 01:29:43 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC0A21F865B for ; Sun, 13 Jan 2013 01:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b4z9Yhgh0Ub for ; Sun, 13 Jan 2013 01:29:42 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C143A21F8654 for ; Sun, 13 Jan 2013 01:29:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0D9Tble022800; Sun, 13 Jan 2013 10:29:37 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0D9Sgeq022771; Sun, 13 Jan 2013 10:28:57 +0100 (CET) Message-ID: <50F27E4B.4010200@cisco.com> Date: Sun, 13 Jan 2013 10:28:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <50F031AB.9070908@cisco.com> <20130111162037.GB5052@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA05F18B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA05F18B@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , eman mailing list Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 09:29:43 -0000 Hi Dan, > Hi, > > Juergen comments are accurate. As this document is now under AD control, we should wait for instructions from Benoit about when to make the required changes. If you can make a new revision quickly, then do it. And I'll reply to the IETF LC email, mentioning the new version. Otherwise, collect all the feedback and produce a new version after the LC. Regards, Benoit > > See more in-line. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >> university.de] >> Sent: Friday, January 11, 2013 6:21 PM >> To: Benoit Claise >> Cc: draft-ietf-eman-rfc4133bis@tools.ietf.org; eman mailing list >> Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 >> >> On Fri, Jan 11, 2013 at 04:37:15PM +0100, Benoit Claise wrote: >>> Andy, Dan, Juergen, Mouli, >>> >>> Here is my review. >>> I'm sending this draft to IETF LC now. Please insert this feedback >>> part of it >>> >>> >>> _TECHNICAL_ >>> >>> entity3Compliance MODULE-COMPLIANCE >>> STATUS current >>> DESCRIPTION >>> "The compliance statement for SNMP entities that implement >>> _version 3 and 4 (full compliance)_ of the Entity MIB." >>> MODULE -- this module >>> MANDATORY-GROUPS { >>> entityPhysicalGroup, >>> entityPhysical2Group, >>> entityGeneralGroup, >>> entityNotificationsGroup >>> } >>> GROUP entityLogical2Group >>> DESCRIPTION >>> "Implementation of this group is not mandatory for agents >>> that model all MIB object instances within a single naming >>> scope." >>> >>> Is this correct to say "version 3 and version 4"? Version 3 is now >>> obsolete: how could we compliant? >>> I believe it only be "version 4 (full compliance)" >>> Should the name be changed from entity3Compliance to >> entity4Compliance? >>> I believe it makes sense since you have entity4CRCompliance later in >>> the doc. >> Even worse, it seems the definition of already existing compliance >> groups have changed and with that the number of mandatory groups. This >> is not allowed per RFC 2580 section 7. >> > > [[DR]] Right. We need to re-establish entity3Compliance exactly to what it was in RFC4133 and to create an entity4FullCompliance. > > >>> _EDITORIAL_ >>> >>> 1. >>> OLD >>> >>> >>> 2.16.2. Modification to some of the MIB objects >>> >>> Addition of a new MIB object to the entPhysicalTable - >>> entPhysicalUUID. In comparison to entPhysicalUris the new object is >>> read-only and restricted to a fixed size to allow only for RFC 4122 >>> [RFC4122 >>> ] compliant values. >>> >>> NEW >>> >>> >>> 2.16.2. Modification to some of the MIB objects >>> >>> Addition of a new MIB object to the entPhysicalTable - >>> entPhysicalUUID, which contains a Universal Unique Identifier >>> (UUID) >>> In comparison to entPhysicalUris the new object is read-only and >>> restricted to a fixed size to allow only for RFC 4122 >>> [RFC4122 >>> ] compliant values. >>> >>> 2. >>> Section 2.16.2 >>> Add an extra "." at the end of the paragraph >>> >>> Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for >>> devices with constrained resources like batteries, which might >>> require a limited number of objects to be supported >>> (entPhysicalClass, entPhysicalName, entPhysicalUUID) >>> >>> >>> 3. >>> remove (UUID) below >>> >>> >>> 2.16.3. New TC for Universal Unique Identifier >>> >>> >>> Two new Textual Conventions (TC) UUID and UUIDorZero were created >> to >>> represent a Universal Unique Identifier (UUID), >>> >>> >>> 4. >>> >>> entPhysicalUUID OBJECT-TYPE >>> SYNTAX UUIDorZero >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "This object contains additional identification >> information >>> about the physical entity. The object contains a >> Universal >>> Unique Identifier, the syntax of this object must conform >>> to RFC 4122, section 4.1. >>> >>> A zero length octet string is returned if no UUID >>> information is known." >>> >>> Either remove "additional", or mention compared to what > [[DR]] Removing seems fine to me. > >> Ideally, there would also be some guidance whether systems also >> implementing entPhysicalUris are expected to report the UUID value also >> as part of entPhysicalUris or not. > [[DR]] Mouli - can you answer this? My take is that some agents may already report this information, and we do not want to change their implementations. > >> Note also that RFC 4122 is twice in >> the references, once normative and once informative. >> > [[DR]] Normative seems the right place. > >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > From dromasca@avaya.com Sun Jan 13 01:43:27 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7E21F8648 for ; Sun, 13 Jan 2013 01:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHVxPpZMPDsd for ; Sun, 13 Jan 2013 01:43:26 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 308D021F863F for ; Sun, 13 Jan 2013 01:43:26 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAAEvoFDGmAcF/2dsb2JhbABBA4F/bcBpgQiCHgEBAQEDEig0CwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgah2gBCp4mnAEEjBYPgwqCS2EDlxiEcYo2gm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="44149056" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Jan 2013 04:32:08 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jan 2013 04:38:48 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Sun, 13 Jan 2013 04:43:32 -0500 From: "Romascanu, Dan (Dan)" To: Benoit Claise Thread-Topic: [eman] AD review of draft-ietf-eman-rfc4133bis-05 Thread-Index: AQHN8BGbswUFkV+tXUKzN4tBQfWwx5hEotyAgAJLC5CAAGaJgP//sB8Q Date: Sun, 13 Jan 2013 09:43:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA05F442@AZ-FFEXMB04.global.avaya.com> References: <50F031AB.9070908@cisco.com> <20130111162037.GB5052@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA05F18B@AZ-FFEXMB04.global.avaya.com> <50F27E4B.4010200@cisco.com> In-Reply-To: <50F27E4B.4010200@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , eman mailing list Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 09:43:27 -0000 Hi,=20 We can do one by tomorrow if Mouli is available.=20 Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Sunday, January 13, 2013 11:29 AM > To: Romascanu, Dan (Dan) > Cc: Juergen Schoenwaelder; draft-ietf-eman-rfc4133bis@tools.ietf.org; > eman mailing list > Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 >=20 > Hi Dan, > > Hi, > > > > Juergen comments are accurate. As this document is now under AD > control, we should wait for instructions from Benoit about when to make > the required changes. > If you can make a new revision quickly, then do it. And I'll reply to > the IETF LC email, mentioning the new version. > Otherwise, collect all the feedback and produce a new version after the > LC. >=20 > Regards, Benoit > > > > See more in-line. > > > > Regards, > > > > Dan > > > > > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > >> university.de] > >> Sent: Friday, January 11, 2013 6:21 PM > >> To: Benoit Claise > >> Cc: draft-ietf-eman-rfc4133bis@tools.ietf.org; eman mailing list > >> Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 > >> > >> On Fri, Jan 11, 2013 at 04:37:15PM +0100, Benoit Claise wrote: > >>> Andy, Dan, Juergen, Mouli, > >>> > >>> Here is my review. > >>> I'm sending this draft to IETF LC now. Please insert this feedback > >>> part of it > >>> > >>> > >>> _TECHNICAL_ > >>> > >>> entity3Compliance MODULE-COMPLIANCE > >>> STATUS current > >>> DESCRIPTION > >>> "The compliance statement for SNMP entities that > implement > >>> _version 3 and 4 (full compliance)_ of the Entity > MIB." > >>> MODULE -- this module > >>> MANDATORY-GROUPS { > >>> entityPhysicalGroup, > >>> entityPhysical2Group, > >>> entityGeneralGroup, > >>> entityNotificationsGroup > >>> } > >>> GROUP entityLogical2Group > >>> DESCRIPTION > >>> "Implementation of this group is not mandatory for > agents > >>> that model all MIB object instances within a single > naming > >>> scope." > >>> > >>> Is this correct to say "version 3 and version 4"? Version 3 is now > >>> obsolete: how could we compliant? > >>> I believe it only be "version 4 (full compliance)" > >>> Should the name be changed from entity3Compliance to > >> entity4Compliance? > >>> I believe it makes sense since you have entity4CRCompliance later in > >>> the doc. > >> Even worse, it seems the definition of already existing compliance > >> groups have changed and with that the number of mandatory groups. > >> This is not allowed per RFC 2580 section 7. > >> > > > > [[DR]] Right. We need to re-establish entity3Compliance exactly to > what it was in RFC4133 and to create an entity4FullCompliance. > > > > > >>> _EDITORIAL_ > >>> > >>> 1. > >>> OLD > >>> > >>> > >>> 2.16.2. Modification to some of the MIB objects > >>> > >>> Addition of a new MIB object to the entPhysicalTable - > >>> entPhysicalUUID. In comparison to entPhysicalUris the new object is > >>> read-only and restricted to a fixed size to allow only for RFC 4122 > >>> [RFC4122 > >>> ] compliant values. > >>> > >>> NEW > >>> > >>> > >>> 2.16.2. Modification to some of the MIB objects > >>> > >>> Addition of a new MIB object to the entPhysicalTable - > >>> entPhysicalUUID, which contains a Universal Unique Identifier > >>> (UUID) > >>> In comparison to entPhysicalUris the new object is read-only and > >>> restricted to a fixed size to allow only for RFC 4122 > >>> [RFC4122 > >>> ] compliant values. > >>> > >>> 2. > >>> Section 2.16.2 > >>> Add an extra "." at the end of the paragraph > >>> > >>> Creation of a new MODULE-COMPLIANCE module entity4CRCompliance > for > >>> devices with constrained resources like batteries, which might > >>> require a limited number of objects to be supported > >>> (entPhysicalClass, entPhysicalName, entPhysicalUUID) > >>> > >>> > >>> 3. > >>> remove (UUID) below > >>> > >>> > >>> 2.16.3. New TC for Universal Unique Identifier > >>> > >>> > >>> Two new Textual Conventions (TC) UUID and UUIDorZero were > >>> created > >> to > >>> represent a Universal Unique Identifier (UUID), > >>> > >>> > >>> 4. > >>> > >>> entPhysicalUUID OBJECT-TYPE > >>> SYNTAX UUIDorZero > >>> MAX-ACCESS read-only > >>> STATUS current > >>> DESCRIPTION > >>> "This object contains additional identification > >> information > >>> about the physical entity. The object contains a > >> Universal > >>> Unique Identifier, the syntax of this object must > conform > >>> to RFC 4122, section 4.1. > >>> > >>> A zero length octet string is returned if no UUID > >>> information is known." > >>> > >>> Either remove "additional", or mention compared to what > > [[DR]] Removing seems fine to me. > > > >> Ideally, there would also be some guidance whether systems also > >> implementing entPhysicalUris are expected to report the UUID value > >> also as part of entPhysicalUris or not. > > [[DR]] Mouli - can you answer this? My take is that some agents may > already report this information, and we do not want to change their > implementations. > > > >> Note also that RFC 4122 is twice in > >> the references, once normative and once informative. > >> > > [[DR]] Normative seems the right place. > > > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >> Fax: +49 421 200 3103 > > From Quittek@neclab.eu Mon Jan 14 01:34:05 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0918A21F888A for ; Mon, 14 Jan 2013 01:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ogU2iczcPtO for ; Mon, 14 Jan 2013 01:34:03 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 86F8421F8712 for ; Mon, 14 Jan 2013 01:34:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 971E3102D0E; Mon, 14 Jan 2013 10:34:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsUX6LM7pOGw; Mon, 14 Jan 2013 10:34:02 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 75761102D0D; Mon, 14 Jan 2013 10:33:42 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.175]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 14 Jan 2013 10:33:41 +0100 From: Juergen Quittek To: Benoit Claise , Dan Romascanu Thread-Topic: [eman] AD review of draft-ietf-eman-rfc4133bis-05 Thread-Index: AQHN8BGUeKniviCYXU+z2jYX9xEpyZhEPkeAgAKkRACAAA1QgIABpHoA Date: Mon, 14 Jan 2013 09:33:41 +0000 Message-ID: In-Reply-To: <50F27E4B.4010200@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <103E21BD473944408D971C2B7B2837B5@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , eman mailing list Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:34:05 -0000 Hi all, I could make these changes tomorrow and post a new version. But I do not have the sources of the current version. Mouli, can you send them? Thanks, Juergen On 13.01.13 10:28, "Benoit Claise" wrote: >Hi Dan, >> Hi, >> >> Juergen comments are accurate. As this document is now under AD >>control, we should wait for instructions from Benoit about when to make >>the required changes. >If you can make a new revision quickly, then do it. And I'll reply to >the IETF LC email, mentioning the new version. >Otherwise, collect all the feedback and produce a new version after the >LC. > >Regards, Benoit >> >> See more in-line. >> >> Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>> university.de] >>> Sent: Friday, January 11, 2013 6:21 PM >>> To: Benoit Claise >>> Cc: draft-ietf-eman-rfc4133bis@tools.ietf.org; eman mailing list >>> Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 >>> >>> On Fri, Jan 11, 2013 at 04:37:15PM +0100, Benoit Claise wrote: >>>> Andy, Dan, Juergen, Mouli, >>>> >>>> Here is my review. >>>> I'm sending this draft to IETF LC now. Please insert this feedback >>>> part of it >>>> >>>> >>>> _TECHNICAL_ >>>> >>>> entity3Compliance MODULE-COMPLIANCE >>>> STATUS current >>>> DESCRIPTION >>>> "The compliance statement for SNMP entities that >>>>implement >>>> _version 3 and 4 (full compliance)_ of the Entity MIB." >>>> MODULE -- this module >>>> MANDATORY-GROUPS { >>>> entityPhysicalGroup, >>>> entityPhysical2Group, >>>> entityGeneralGroup, >>>> entityNotificationsGroup >>>> } >>>> GROUP entityLogical2Group >>>> DESCRIPTION >>>> "Implementation of this group is not mandatory for agents >>>> that model all MIB object instances within a single >>>>naming >>>> scope." >>>> >>>> Is this correct to say "version 3 and version 4"? Version 3 is now >>>> obsolete: how could we compliant? >>>> I believe it only be "version 4 (full compliance)" >>>> Should the name be changed from entity3Compliance to >>> entity4Compliance? >>>> I believe it makes sense since you have entity4CRCompliance later in >>>> the doc. >>> Even worse, it seems the definition of already existing compliance >>> groups have changed and with that the number of mandatory groups. This >>> is not allowed per RFC 2580 section 7. >>> >> >> [[DR]] Right. We need to re-establish entity3Compliance exactly to what >>it was in RFC4133 and to create an entity4FullCompliance. >> >> >>>> _EDITORIAL_ >>>> >>>> 1. >>>> OLD >>>> >>>> >>>> 2.16.2. Modification to some of the MIB objects >>>> >>>> Addition of a new MIB object to the entPhysicalTable - >>>> entPhysicalUUID. In comparison to entPhysicalUris the new object is >>>> read-only and restricted to a fixed size to allow only for RFC 4122 >>>> [RFC4122 >>>> ] compliant values. >>>> >>>> NEW >>>> >>>> >>>> 2.16.2. Modification to some of the MIB objects >>>> >>>> Addition of a new MIB object to the entPhysicalTable - >>>> entPhysicalUUID, which contains a Universal Unique Identifier >>>> (UUID) >>>> In comparison to entPhysicalUris the new object is read-only and >>>> restricted to a fixed size to allow only for RFC 4122 >>>> [RFC4122 >>>> ] compliant values. >>>> >>>> 2. >>>> Section 2.16.2 >>>> Add an extra "." at the end of the paragraph >>>> >>>> Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for >>>> devices with constrained resources like batteries, which might >>>> require a limited number of objects to be supported >>>> (entPhysicalClass, entPhysicalName, entPhysicalUUID) >>>> >>>> >>>> 3. >>>> remove (UUID) below >>>> >>>> >>>> 2.16.3. New TC for Universal Unique Identifier >>>> >>>> >>>> Two new Textual Conventions (TC) UUID and UUIDorZero were created >>> to >>>> represent a Universal Unique Identifier (UUID), >>>> >>>> >>>> 4. >>>> >>>> entPhysicalUUID OBJECT-TYPE >>>> SYNTAX UUIDorZero >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "This object contains additional identification >>> information >>>> about the physical entity. The object contains a >>> Universal >>>> Unique Identifier, the syntax of this object must conform >>>> to RFC 4122, section 4.1. >>>> >>>> A zero length octet string is returned if no UUID >>>> information is known." >>>> >>>> Either remove "additional", or mention compared to what >> [[DR]] Removing seems fine to me. >> >>> Ideally, there would also be some guidance whether systems also >>> implementing entPhysicalUris are expected to report the UUID value also >>> as part of entPhysicalUris or not. >> [[DR]] Mouli - can you answer this? My take is that some agents may >>already report this information, and we do not want to change their >>implementations. >> >>> Note also that RFC 4122 is twice in >>> the references, once normative and once informative. >>> >> [[DR]] Normative seems the right place. >> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Mon Jan 14 01:38:11 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE7321F85E7 for ; Mon, 14 Jan 2013 01:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77v+ictl8SgB for ; Mon, 14 Jan 2013 01:38:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B842921F85B2 for ; Mon, 14 Jan 2013 01:38:10 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C74D20BE8; Mon, 14 Jan 2013 10:38:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BC4T0xm_iWQa; Mon, 14 Jan 2013 10:38:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D12820BDF; Mon, 14 Jan 2013 10:38:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0087523F439C; Mon, 14 Jan 2013 10:38:09 +0100 (CET) Date: Mon, 14 Jan 2013 10:38:09 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20130114093809.GA18241@elstar.local> Mail-Followup-To: Juergen Quittek , Benoit Claise , Dan Romascanu , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , eman mailing list References: <50F27E4B.4010200@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [eman] AD review of draft-ietf-eman-rfc4133bis-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:38:11 -0000 On Mon, Jan 14, 2013 at 09:33:41AM +0000, Juergen Quittek wrote: > Hi all, > > I could make these changes tomorrow and post a new version. > But I do not have the sources of the current version. > Benoit asked me to do a MIB doctors review and unfortunately there is more to fix. I will post my review soon so you can get things into reasonable shape tomorrow. In fact, I would appreciate if things can be turned around quickly since loosing context is always a pain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Jan 14 01:55:13 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C0F21F888E; Mon, 14 Jan 2013 01:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E1ZhONgQYwL; Mon, 14 Jan 2013 01:55:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED65521F8570; Mon, 14 Jan 2013 01:55:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DEF620BEF; Mon, 14 Jan 2013 10:55:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UsgGGDpPXFDi; Mon, 14 Jan 2013 10:55:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D275820BCD; Mon, 14 Jan 2013 10:55:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8DC2B23F44C0; Mon, 14 Jan 2013 10:55:05 +0100 (CET) Date: Mon, 14 Jan 2013 10:55:05 +0100 From: Juergen Schoenwaelder To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org Message-ID: <20130114095505.GA18424@elstar.local> Mail-Followup-To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org, ops-ads@tools.ietf.org, eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org, ops-ads@tools.ietf.org Subject: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:55:13 -0000 I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB doctors efforts to review all documents containing MIB modules. See 4181 for some more details. This document has a number of serious issues that need to be resolved before it is ready to be brought to the IESG. I appreciate a quick turn around and in particular if some of the more senior co-editors can make sure issues mentioned below are properly addressed. a) The compliance definitions must be updated to follow SMIv2 rules. This was already mentioned on the list. In short, it is not appropriate to rewrite existing compliance or group definitions. Instead, new ones must be created as needed. b) Move the RFC 2119 requirements language paragraph at the end of section 1 where it belongs (right now it sits at the end of the I-D boilerplate which gets replaced, not in the body of the document) c) The overview states "This is presently true for at least 3 standard MIBs". Did someone check whether this is still accurate? Or better, as an alternative, rephrase this sentence to get rid of "presently"? d) Section 2 provides a high-level overview over the changes of ENTITY-MIB version 2 and 3. There is unfortunately no such text for the version 4. e) I think a paragraph should be added to section 2.12.1 to describe the addition made by version 4 - and if it is just for document consistency. Version 4 of the Entity MIB provides [...] This would also be a good place to explain whether UUIDs are supposed to also be represented as URIs (and why or why not). f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] method of context identification"? For example, "an SnmpEngineID and ContextName pair [RFC3411] for context identification". g) Overall, replace MIBs with MIB modules. h) Section 2.16.2 needs to be updated once the conformance mess has been fixed. i) Proposal for a rewording of 2.16.1: Over time, there is the need to add new enumerated values to the PhysicalClass textual convention. To allow for such additions without requiring to re-issue this MIB module, a new MIB module called IANA-ENTITY-MIB has been created which provides the IANA-maintained textual convention IANAPhysicalClass. The PhysicalClass TC has been deprecated. j) The PhysicalClass TC has been removed from the document, which is another violation of SMIv2 update rules. The TC must be put back and the status of the TC should be changed to deprecated and an explanation added why this was done (see RFC 2579 section 5). k) RFC 4122 is listed both as normative and informative. I think it is normative, no? j) The EMAN example (section 4.3) is full of Cisco details, I think it is more suitable to follow the vendor neutral ACME style of the other examples. Furthermore, it appears to me that the UUID values shown are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please avoid all vendor specific terms. The indexing of the line card slot in the example also seems to be all messed up. And should the line card slot not be contained in the chassis? l) Security considerations: Anything to say about entPhysicalUris and entPhysicalUUID concerning the sensitivity of the data the carry? m) Since this document obsoletes older ENTITY-MIB definitions, are the old definitions still normative references? I would expect not. Note that the document header also does not state that this document obsoletes RFC 4133 - only the abstract does. n) The description of revision 201212110000Z of the ENTITY-MIB has an incomplete sentence... And there is no point in changing previous revision statements (in particular revision 200508100000Z). This also needs to be reverted back. o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible change since entPhysicalUris used to contain a whitespace separated list of URIs. Interestingly, this change is not mentioned anywhere in the changes text. As this change is not compatible, you have to revert it back. p) The description of ianaEntityMIB is not even a complete sentence. q) Proposed rewrite for the description of 'energyObject': OLD The enumeration ?energyObject? is applicable if the physical entity is some sort of a energy object i.e. a piece of equipment that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. NEW The enumeration 'energyObject' is applicable if the physical entity class is some sort of a energy object, i.e., a piece of equipment that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. Putting energyObject in single quotes etc. for consistency. r) Proposed rewrite for the description of 'battery': OLD The enumeration 'battery' is applicable of the physical entity class is some sort of an energy battery device. " NEW The enumeration 'battery' is applicable if the physical entity class is some sort of a battery." (Fixing of->if, avoiding 'device', removing useless 'energy'.) s) The description of uuidTCMIB is not even a complete sentence. (The indentation of the SYNTAX clause is somewhat unusual but syntactically valid.) t) The last three paragraphs of the security considerations should be updated to match the new boilerplate text posted here: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Jan 14 02:32:06 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792AA21F8906; Mon, 14 Jan 2013 02:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UqFFzcaIHv6; Mon, 14 Jan 2013 02:32:05 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1CB21F8925; Mon, 14 Jan 2013 02:32:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EAW2YU010369; Mon, 14 Jan 2013 11:32:02 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EAVfZT025358; Mon, 14 Jan 2013 11:31:51 +0100 (CET) Message-ID: <50F3DE8D.2030202@cisco.com> Date: Mon, 14 Jan 2013 11:31:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org, ops-ads@tools.ietf.org, eman@ietf.org References: <20130114095505.GA18424@elstar.local> In-Reply-To: <20130114095505.GA18424@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 10:32:06 -0000 Juergen, draft-ietf-eman-rfc4133bis authors, I did the AD review and the IETF LC started. Juergen, based on AD review email, discovered an important problem with the MIB. Then I proposed to quickly post a new version, before the actual MIB doctor job started (*) Looking at the list of requested changes from Juergen, it's better to wait for the end of the IETF LC to post the next version. However, in the mean time, I advice the draft-ietf-eman-rfc4133bis authors to work on temp version to get Juergen's green light on the new text. Btw, I agree with Juergen's comments. (*) I made a process mistake with this draft: mea culpa. Normally, the MIB doctor review is done between the WG LC and the start the IETF LC. So I sent this draft to IETF LC too fast. So thanks to Juergen for his quick review. Regards, Benoit > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. > > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick > turn around and in particular if some of the more senior co-editors > can make sure issues mentioned below are properly addressed. > > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. > > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) > > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? > > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. > > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. > > Version 4 of the Entity MIB provides [...] > > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". > > g) Overall, replace MIBs with MIB modules. > > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. > > i) Proposal for a rewording of 2.16.1: > > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. > > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an explanation > added why this was done (see RFC 2579 section 5). > > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? > > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? > > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. > > p) The description of ianaEntityMIB is not even a complete sentence. > > q) Proposed rewrite for the description of 'energyObject': > > OLD > > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > NEW > > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > Putting energyObject in single quotes etc. for consistency. > > r) Proposed rewrite for the description of 'battery': > > OLD > > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " > > NEW > > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." > > (Fixing of->if, avoiding 'device', removing useless 'energy'.) > > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) > > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > /js > From moulchan@cisco.com Mon Jan 14 02:44:19 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF821F8931; Mon, 14 Jan 2013 02:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm0e65j+bGKZ; Mon, 14 Jan 2013 02:44:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 712B821F88E1; Mon, 14 Jan 2013 02:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7705; q=dns/txt; s=iport; t=1358160258; x=1359369858; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xY0XVHThOwFlBwZitYlZIwkzquLrM8+LVxj451kLYKQ=; b=dCauBaV6pxi9V0mhvNOKUJKtBt2R4PKwrDiapz97hpOb6rH+pbljBbur +90VTKhAFJkoueUcANNwHslQhvuMxOJjuKSb4oW+AZ4/B2yysCaCSBbHf rVOz8pwsOHBe3nF69IPfJSO2ZFgbHxCT9efrZ6uh66lGuwGVHZN9tSgn8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFABvh81CtJV2Z/2dsb2JhbAA+BrYWh2YWc4IeAQEBBAEBASQTNBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiBEMtAGMcAYcgzthA4tSi1WFPolvgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,466,1355097600"; d="scan'208";a="162111393" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jan 2013 10:44:18 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0EAiHQa017145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 10:44:17 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 04:44:17 -0600 From: "Mouli Chandramouli (moulchan)" To: "Benoit Claise (bclaise)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" Thread-Topic: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j09YUnlfJCpFUmUM5SweCXWsZhJBMmA//+eVqA= Date: Mon, 14 Jan 2013 10:44:16 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42867EBA0@xmb-rcd-x08.cisco.com> References: <20130114095505.GA18424@elstar.local> <50F3DE8D.2030202@cisco.com> In-Reply-To: <50F3DE8D.2030202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.82.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 10:44:19 -0000 Benoit, As you have suggested we shall submit an interim version to address the com= ments of Juergen Schoenwaelder.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ben= oit Claise (bclaise) Sent: Monday, January 14, 2013 4:02 PM To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org; ops-ad= s@tools.ietf.org; eman@ietf.org Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Juergen, draft-ietf-eman-rfc4133bis authors, I did the AD review and the IETF LC started. Juergen, based on AD review=20 email, discovered an important problem with the MIB. Then I proposed to=20 quickly post a new version, before the actual MIB doctor job started (*) Looking at the list of requested changes from Juergen, it's better to=20 wait for the end of the IETF LC to post the next version. However, in the mean time, I advice the draft-ietf-eman-rfc4133bis=20 authors to work on temp version to get Juergen's green light on the new=20 text. Btw, I agree with Juergen's comments. (*) I made a process mistake with this draft: mea culpa. Normally, the=20 MIB doctor review is done between the WG LC and the start the IETF LC.=20 So I sent this draft to IETF LC too fast. So thanks to Juergen for his=20 quick review. Regards, Benoit > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. > > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick > turn around and in particular if some of the more senior co-editors > can make sure issues mentioned below are properly addressed. > > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. > > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) > > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? > > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. > > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. > > Version 4 of the Entity MIB provides [...] > > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". > > g) Overall, replace MIBs with MIB modules. > > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. > > i) Proposal for a rewording of 2.16.1: > > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. > > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an explanati= on > added why this was done (see RFC 2579 section 5). > > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? > > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? > > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. > > p) The description of ianaEntityMIB is not even a complete sentence. > > q) Proposed rewrite for the description of 'energyObject': > > OLD > > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > NEW > > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > Putting energyObject in single quotes etc. for consistency. > > r) Proposed rewrite for the description of 'battery': > =20 > OLD > > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " > > NEW > > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." > > (Fixing of->if, avoiding 'device', removing useless 'energy'.) > > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) > > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > /js > _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From dromasca@avaya.com Mon Jan 14 08:05:22 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921F21F87BA; Mon, 14 Jan 2013 08:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.395 X-Spam-Level: X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+8-i9qsw4Es; Mon, 14 Jan 2013 08:05:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 869B521F8738; Mon, 14 Jan 2013 08:05:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAIbQt1CHCzI1/2dsb2JhbAA6BAMDgX9ttU6HSxZzgh4BAQEBAgESFRM/BQcCAgIBCA0BAgEEAQELFAkHGxcUCQgCBAENBQgTB4doBgELoXudDASMPAUMBBJugkthA4tNi1CEcUyJa4JygWM+ X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="384361863" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jan 2013 10:55:35 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jan 2013 10:39:51 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 11:05:21 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j1HkH9GpL6Iw0undeMeNNuIRZhI4EuA Date: Mon, 14 Jan 2013 16:05:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> In-Reply-To: <20130114095505.GA18424@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" , "ops-ads@tools.ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:05:22 -0000 Hi Juergen,=20 Thanks for the detailed review.=20 Please see in-line the responses and proposals for update.=20 For a couple of points I am waiting for answers from Mouli.=20 Please let us know if the proposed resolutions answer your concerns. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 11:55 AM > To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org > Cc: ops-ads@tools.ietf.org; eman@ietf.org > Subject: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. >=20 > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick turn > around and in particular if some of the more senior co-editors can make > sure issues mentioned below are properly addressed. >=20 > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. >=20 [[DR]] Right. The existing compliance and group definitions will be kept as= in RFC4133 today and we shall create two new compliance groups entity4Comp= liance and entity4CRCompliance.=20 =20 > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) >=20 [[DR]] Actually I believe that this document does not need any reference to= RFC 2119 at all, so we can take out that paragraph and the reference to [2= 119] out completely.=20 > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? >=20 [[DR]] This text is taken 'as is' from RFC 4133. None of the three example = MIB modules was deprecated. So it's still true.=20 In general we avoided making changes in the document unless necessary. > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. >=20 [[DR]] Proposed Solution:=20 Add at the end of Section 2 the following text:=20 Version 3 of this MIB addresses new requirements, which have emerged since the publication of the third Entity MIB (RFC 4133 [RFC4133]). There is a need to add new enumerated values for physical classes, a=20 need to provide identification information for entity objects in=20 a Universal Unique Identifier (UUID) formats, and a need to describe Constrained Resources (CR) entities. The PhysicalClass Textual=20 Convention (TC) was deprecated and a new IANAPhysicalClass TC was=20 created. A new TC UUIDorZero was created to represent a UUID and a new object was added to the entPhysicalTable to identify the UUID.=20 > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. >=20 > Version 4 of the Entity MIB provides [...] >=20 > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). >=20 [[DR]] I will let Mouli address this, as I am not sure 100% about the respo= nse to the issue of representation.=20 > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". >=20 [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a bug I= suggest to avoid such changes.=20 > g) Overall, replace MIBs with MIB modules. >=20 [[DR]] Same as the previous point.=20 > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. >=20 [[DR]]=20 OLD:=20 Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for devices with constrained resources like batteries, which might require a limited number of objects to be supported (entPhysicalClass, entPhysicalName, entPhysicalUUID)=20 NEW:=20 Creation of two new MODULE-COMPLIANCE modules entity4Compliance for full compliance with version 4 of the Entity MIB and=20 entity4CRCompliance for devices with constrained resources like batteries, which might require a limited number of objects to be supported (entPhysicalClass, entPhysicalName, entPhysicalUUID)=20 > i) Proposal for a rewording of 2.16.1: >=20 > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. >=20 [[DR]] OK > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an > explanation > added why this was done (see RFC 2579 section 5). >=20 [[DR]] OK - we shall change the status to deprecated and add text clarifyin= g=20 that starting with version 4 of the MIB module the use of the IANAPhysicalC= lass TC is recommended instead.=20 > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? >=20 [[DR]] yes. > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? >=20 [[DR]] Mouli - can you please look at these?=20 > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? >=20 [[DR]] good point, although entPhysicalUri was not listed previously as sen= sitive. I would suggest to add the two objects to the list of objects that = expose information about the physical entities within a managed system, whi= ch may be used to identify the vendor, model, and version information of ea= ch system component.=20 > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. >=20 [[DR]] The header should be updated.=20 > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. >=20 [[DR]] OK. Actually the 2012... revision will not be mentioned any longer.= =20 > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. [[DR]] It's the first time this comment is made (as a few other as well). S= ure, if the change is not backwards compatible, this needs to be reversed.= =20 >=20 > p) The description of ianaEntityMIB is not even a complete sentence. >=20 [[DR]] s/This MIB module/This MIB Module defines a Textual Convention that = provides an indication of the general hardware type of a particular physica= l entity./ > q) Proposed rewrite for the description of 'energyObject': >=20 > OLD >=20 > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. >=20 > NEW >=20 > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. >=20 > Putting energyObject in single quotes etc. for consistency. >=20 [[DR]] OK.=20 > r) Proposed rewrite for the description of 'battery': >=20 > OLD >=20 > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " >=20 > NEW >=20 > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." >=20 > (Fixing of->if, avoiding 'device', removing useless 'energy'.) >=20 [[DR]] OK.=20 > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) >=20 [[DR]] s/This MIB module/This MIB module defines a Textual Convention that = provides an indication of the general hardware type of a particular physica= l entity./ > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: >=20 > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security >=20 [[DR]] OK.=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Jan 14 08:45:35 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07D821F86C8; Mon, 14 Jan 2013 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqTdTdchwrak; Mon, 14 Jan 2013 08:45:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B630C21F8546; Mon, 14 Jan 2013 08:45:33 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A4C320BEC; Mon, 14 Jan 2013 17:45:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1wvrotM8gZWf; Mon, 14 Jan 2013 17:45:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A068B20BE0; Mon, 14 Jan 2013 17:45:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D6BF323F6085; Mon, 14 Jan 2013 17:45:33 +0100 (CET) Date: Mon, 14 Jan 2013 17:45:33 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130114164533.GB19548@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:45:35 -0000 On Mon, Jan 14, 2013 at 04:05:21PM +0000, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > Thanks for the detailed review. > > Please see in-line the responses and proposals for update. > > For a couple of points I am waiting for answers from Mouli. > > Please let us know if the proposed resolutions answer your concerns. I will only respond to those issues where we either disagree or where further clarification may be necessary. > > d) Section 2 provides a high-level overview over the changes of > > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > > the version 4. > > > [[DR]] Proposed Solution: > > Add at the end of Section 2 the following text: > > Version 3 of this MIB addresses new requirements, which have emerged > since the publication of the third Entity MIB (RFC 4133 [RFC4133]). > There is a need to add new enumerated values for physical classes, a > need to provide identification information for entity objects in > a Universal Unique Identifier (UUID) formats, and a need to describe > Constrained Resources (CR) entities. The PhysicalClass Textual > Convention (TC) was deprecated and a new IANAPhysicalClass TC was > created. A new TC UUIDorZero was created to represent a UUID and a > new object was added to the entPhysicalTable to identify the UUID. I am not sure the "need to describe Constrained Resources (CR) entities" explains it well. Perhaps there is a "need for conformance statements for Constrained Resources (CR) entities" or something like that. > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > method of context identification"? For example, "an SnmpEngineID > > and ContextName pair [RFC3411] for context identification". > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a bug I suggest to avoid such changes. It is document clarity. But I won't insist on this, I just find the current text unnecessarily confusing. > > g) Overall, replace MIBs with MIB modules. > > > [[DR]] Same as the previous point. Again, it is document clarity. It is rather obvious that this change does not break anything, no? Let Bert decide - he is the owner of the one MIB many MIB modules song. ;-) > > k) RFC 4122 is listed both as normative and informative. I think it is > > normative, no? > > > > [[DR]] yes. So I assume you will remove the informative reference, right? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > > old definitions still normative references? I would expect not. Note > > that the document header also does not state that this document > > obsoletes RFC 4133 - only the abstract does. > > [[DR]] The header should be updated. And the references to the old revisions will become informative, right? > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > > incomplete sentence... And there is no point in changing previous > > revision statements (in particular revision 200508100000Z). This > > also needs to be reverted back. > > [[DR]] OK. Actually the 2012... revision will not be mentioned any longer. Yes, but there will be a 2013... revision. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > > change since entPhysicalUris used to contain a whitespace separated > > list of URIs. Interestingly, this change is not mentioned anywhere > > in the changes text. As this change is not compatible, you have to > > revert it back. > [[DR]] It's the first time this comment is made (as a few other as well). Sure, if the change is not backwards compatible, this needs to be reversed. Yes, apparently the level of review this MIB module enjoyed has not been very extensive. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Jan 15 05:07:35 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAA721F86FD; Tue, 15 Jan 2013 05:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL2j8e3xFVTf; Tue, 15 Jan 2013 05:07:34 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB521F86D4; Tue, 15 Jan 2013 05:07:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAIbQt1CHCzI1/2dsb2JhbAA6BwOBf221TodLFnOCHgEBAQECARIoPwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgTB4doBgGiBoxpkCMEjDwRgQSCS2EDlx2EcYo3gnKCIQ X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="384496367" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2013 07:57:49 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jan 2013 07:42:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 08:07:43 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j1HkH9GpL6Iw0undeMeNNuIRZhI4EuAgAB8L4CAAQBy8A== Date: Tue, 15 Jan 2013 13:07:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> In-Reply-To: <20130114164533.GB19548@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:07:35 -0000 See in-line.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 6:46 PM > To: Romascanu, Dan (Dan) > Cc: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org; > ops-ads@tools.ietf.org; eman@ietf.org > Subject: Re: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 > On Mon, Jan 14, 2013 at 04:05:21PM +0000, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > > > Thanks for the detailed review. > > > > Please see in-line the responses and proposals for update. > > > > For a couple of points I am waiting for answers from Mouli. > > > > Please let us know if the proposed resolutions answer your concerns. >=20 > I will only respond to those issues where we either disagree or where > further clarification may be necessary. >=20 > > > d) Section 2 provides a high-level overview over the changes of > > > ENTITY-MIB version 2 and 3. There is unfortunately no such text > for > > > the version 4. > > > > > [[DR]] Proposed Solution: > > > > Add at the end of Section 2 the following text: > > > > Version 3 of this MIB addresses new requirements, which have > emerged > > since the publication of the third Entity MIB (RFC 4133 [RFC4133]). > > There is a need to add new enumerated values for physical classes, > a > > need to provide identification information for entity objects in > > a Universal Unique Identifier (UUID) formats, and a need to > describe > > Constrained Resources (CR) entities. The PhysicalClass Textual > > Convention (TC) was deprecated and a new IANAPhysicalClass TC was > > created. A new TC UUIDorZero was created to represent a UUID and a > > new object was added to the entPhysicalTable to identify the UUID. >=20 > I am not sure the "need to describe Constrained Resources (CR) entities" > explains it well. Perhaps there is a "need for conformance statements > for Constrained Resources (CR) entities" or something like that. >=20 [[DR]] OK.=20 > > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > > method of context identification"? For example, "an SnmpEngineID > > > and ContextName pair [RFC3411] for context identification". > > > > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a > bug I suggest to avoid such changes. >=20 > It is document clarity. But I won't insist on this, I just find the > current text unnecessarily confusing. >=20 > > > g) Overall, replace MIBs with MIB modules. > > > > > [[DR]] Same as the previous point. >=20 > Again, it is document clarity. It is rather obvious that this change > does not break anything, no? Let Bert decide - he is the owner of the > one MIB many MIB modules song. ;-) >=20 [[DR]] I also sing the song when I review new documents, but in this case w= e would interfere in the text of the document that is now at version 4.=20 > > > k) RFC 4122 is listed both as normative and informative. I think it > is > > > normative, no? > > > > > > > [[DR]] yes. >=20 > So I assume you will remove the informative reference, right? >=20 [[DR]] Right. > > > m) Since this document obsoletes older ENTITY-MIB definitions, are > the > > > old definitions still normative references? I would expect not. > Note > > > that the document header also does not state that this document > > > obsoletes RFC 4133 - only the abstract does. > > > > [[DR]] The header should be updated. >=20 > And the references to the old revisions will become informative, right? >=20 [[DR]] Right. > > > n) The description of revision 201212110000Z of the ENTITY-MIB has > an > > > incomplete sentence... And there is no point in changing previous > > > revision statements (in particular revision 200508100000Z). This > > > also needs to be reverted back. > > > > [[DR]] OK. Actually the 2012... revision will not be mentioned any > longer. >=20 > Yes, but there will be a 2013... revision. >=20 [[DR]] of course :-) > > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed > to > > > Uri imported from the URI-TC-MIB. Is is _not_ a backwards > compatible > > > change since entPhysicalUris used to contain a whitespace > separated > > > list of URIs. Interestingly, this change is not mentioned > anywhere > > > in the changes text. As this change is not compatible, you have > to > > > revert it back. > > [[DR]] It's the first time this comment is made (as a few other as > well). Sure, if the change is not backwards compatible, this needs to be > reversed. >=20 > Yes, apparently the level of review this MIB module enjoyed has not been > very extensive. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From moulchan@cisco.com Tue Jan 15 05:09:54 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F7521F8783; Tue, 15 Jan 2013 05:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60aKFlhb6u1H; Tue, 15 Jan 2013 05:09:50 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A8C4821F86AA; Tue, 15 Jan 2013 05:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3741; q=dns/txt; s=iport; t=1358255390; x=1359464990; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7MzupuMFk6xAIErFtllXq3/IISj7lcX4fB5qRXl0ysY=; b=IS+55mDl7/Iej/EWbEDSlvUY1TXwixjKtPtFNSWpoULCbZBkAbvucWax xkEneV7zvWubNAvM0mvD2GZDuOEKx4/7hMDR4uahCJ++IBt394L94LPju clrck0rrX6iGefOE9yE/zIQGC7ZXHiVLAid+AdEThU8nElxKzv5+pK2T7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAEpU9VCtJXG+/2dsb2JhbABCA7YNhC6DRxZzgh4BAQEDAQEBATc0CwUHAgICAQgQAQQBAQsUCQcbDAsUCQgCBAENBQiICwYMqEGOTASOBoJNYQOXKI8tgnWCJA X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="162554752" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jan 2013 13:09:50 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0FD9oBb031488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 13:09:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 07:09:49 -0600 From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j09YUnlfJCpFUmUM5SweCXWsZhJYgOAgADkw0A= Date: Tue, 15 Jan 2013 13:09:49 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ops-ads@tools.ietf.org" , "eman@ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:09:54 -0000 Hello Juergen,=20 Thanks for the review. Replies inline.=20 Regards Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: Monday, January 14, 2013 9:35 PM To: Juergen Schoenwaelder; mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis= @tools.ietf.org Cc: eman@ietf.org; ops-ads@tools.ietf.org Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Hi Juergen,=20 Thanks for the detailed review.=20 Please see in-line the responses and proposals for update.=20 For a couple of points I am waiting for answers from Mouli.=20 Please let us know if the proposed resolutions answer your concerns. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 11:55 AM > To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org > Cc: ops-ads@tools.ietf.org; eman@ietf.org > Subject: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 [ycm] snip ...=20 > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. >=20 > Version 4 of the Entity MIB provides [...] >=20 > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). >=20 [[DR]] I will let Mouli address this, as I am not sure 100% about the respo= nse to the issue of representation.=20 [ycm]=20 [ycm] Thanks for the comment. To be consistent, we shall add the following = paragraph on in Section 2.12.1.=20 NEW=20 =20 Version 4 of the Entity MIB provides an additional MIB object for each phy= sical entity.=20 entPhysicalUUID - This object provides an additional unique identification = about the physical entity. =20 This object contains a globally unique identifier for the physical entity w= ith the format as defined in RFC 4122 [RFC4122].=20 The UUID shall be represented as URIs.=20 To support the existing implementations of ENTITY-MIB v3, entPhyiscalUris = object which uses the URI syntax can=20 be used to store the UUID value of the physical entity. Caution should to b= e exercised since this MIB object is read-write. =20 With the implementation of ENTITY-MIB v4, the value of UUID can be stored i= n new MIB object entPhysicalUUID (which is read-only)=20 and the UUID value can also be duplicated in entPhysicalUris MIB object. To= enable this capability, the syntax of the=20 two MIB objects should be similar.=20 [ycm]=20 > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? >=20 [[DR]] Mouli - can you please look at these?=20 [ycm] I will remove the reference to Cisco terns and use a generic name as= ACME and also the 128 bit UUID values in the URI representation.=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Tue Jan 15 06:09:09 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA921F87C8; Tue, 15 Jan 2013 06:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAHHz0lxh2di; Tue, 15 Jan 2013 06:09:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1476B21F8798; Tue, 15 Jan 2013 06:09:08 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C63420BF8; Tue, 15 Jan 2013 15:09:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n3BdAq9ocZJo; Tue, 15 Jan 2013 15:09:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28B3E20BF0; Tue, 15 Jan 2013 15:09:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7584523F7CC8; Tue, 15 Jan 2013 15:09:08 +0100 (CET) Date: Tue, 15 Jan 2013 15:09:07 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130115140907.GA21588@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:09:10 -0000 On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > > > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > > > method of context identification"? For example, "an SnmpEngineID > > > > and ContextName pair [RFC3411] for context identification". > > > > > > > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a > > bug I suggest to avoid such changes. > > > > It is document clarity. But I won't insist on this, I just find the > > current text unnecessarily confusing. > > > > > > g) Overall, replace MIBs with MIB modules. > > > > > > > [[DR]] Same as the previous point. > > > > Again, it is document clarity. It is rather obvious that this change > > does not break anything, no? Let Bert decide - he is the owner of the > > one MIB many MIB modules song. ;-) > > > > [[DR]] I also sing the song when I review new documents, but in this case we would interfere in the text of the document that is now at version 4. So what? Time to fix this. Anyway, I will not fight for this if editors believe it is best to not update vocabularity to current rules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jan 15 06:15:20 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE5921F86FD; Tue, 15 Jan 2013 06:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypz-wdIH6vZq; Tue, 15 Jan 2013 06:15:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C21F8457; Tue, 15 Jan 2013 06:15:19 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC72020BF0; Tue, 15 Jan 2013 15:15:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z5ii84ZSe2e7; Tue, 15 Jan 2013 15:15:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 444D920BF3; Tue, 15 Jan 2013 15:15:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6F00023F7D25; Tue, 15 Jan 2013 15:15:20 +0100 (CET) Date: Tue, 15 Jan 2013 15:15:20 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20130115141520.GB21588@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" , "mib-doctors@ietf.org" Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:15:20 -0000 On Tue, Jan 15, 2013 at 01:09:49PM +0000, Mouli Chandramouli (moulchan) wrote: > [ycm] snip ... > > > e) I think a paragraph should be added to section 2.12.1 to describe > > the addition made by version 4 - and if it is just for document > > consistency. > > > > Version 4 of the Entity MIB provides [...] > > > > This would also be a good place to explain whether UUIDs are > > supposed to also be represented as URIs (and why or why not). > > > [[DR]] I will let Mouli address this, as I am not sure 100% about the response to the issue of representation. > [ycm] > [ycm] Thanks for the comment. To be consistent, we shall add the following paragraph on in Section 2.12.1. > > > NEW > > Version 4 of the Entity MIB provides an additional MIB object for each physical entity. > > entPhysicalUUID - This object provides an additional unique identification about the physical entity. > This object contains a globally unique identifier for the physical entity with the format as defined in RFC 4122 [RFC4122]. > The UUID shall be represented as URIs. Sure? This is not what the definitions do (and I think it would even be wrong to do this). Please check your document. > To support the existing implementations of ENTITY-MIB v3, entPhyiscalUris object which uses the URI syntax can > be used to store the UUID value of the physical entity. Caution should to be exercised since this MIB object is read-write. Why caution? I suggest to either spell out what the issue is or leave this out. > With the implementation of ENTITY-MIB v4, the value of UUID can be stored in new MIB object entPhysicalUUID (which is read-only) > and the UUID value can also be duplicated in entPhysicalUris MIB object. To enable this capability, the syntax of the > two MIB objects should be similar. Again, I think the last sentence should be removed since the syntax is actually different. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trac+eman@trac.tools.ietf.org Wed Jan 16 10:10:22 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFB521F8B58 for ; Wed, 16 Jan 2013 10:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROsbkBc8tZNG for ; Wed, 16 Jan 2013 10:10:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 855E221F8B08 for ; Wed, 16 Jan 2013 10:10:21 -0800 (PST) Received: from localhost ([127.0.0.1]:46515 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TvXR8-0006DU-32; Wed, 16 Jan 2013 19:10:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com X-Trac-Project: eman Date: Wed, 16 Jan 2013 18:10:06 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/27 Message-ID: <057.e10adf845382d57bfcdea737b48b358b@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-applicability-statement@tools.ietf.org, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bnordman@lbl.gov, brad.schoening@verizon.net, moulchan@cisco.com Resent-Message-Id: <20130116181021.855E221F8B08@ietfa.amsl.com> Resent-Date: Wed, 16 Jan 2013 10:10:21 -0800 (PST) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: [eman] #27: Add text on compenents from consensus at IETF 85 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:10:22 -0000 #27: Add text on compenents from consensus at IETF 85 Juergen to add text from discussion at last meeting that reflected consensus on components. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-eman-applicability- jparello@cisco.com | statement@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: applicability- | Keywords: statement | Severity: - | -------------------------+------------------------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Jan 16 10:13:04 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902921F885B for ; Wed, 16 Jan 2013 10:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0o-xuktYxsr for ; Wed, 16 Jan 2013 10:13:03 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE621F881A for ; Wed, 16 Jan 2013 10:13:03 -0800 (PST) Received: from localhost ([127.0.0.1]:46830 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TvXTx-0000s0-Nd; Wed, 16 Jan 2013 19:13:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: ietf@quittek.at, jparello@cisco.com X-Trac-Project: eman Date: Wed, 16 Jan 2013 18:13:01 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/27#comment:1 Message-ID: <072.82e94327ef905138c8a42b2fe17fec51@trac.tools.ietf.org> References: <057.e10adf845382d57bfcdea737b48b358b@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <057.e10adf845382d57bfcdea737b48b358b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@quittek.at, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #27: Add text on compenents from consensus at IETF 85 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:13:04 -0000 #27: Add text on compenents from consensus at IETF 85 Changes (by jparello@cisco.com): * owner: draft-ietf-eman-applicability-statement@tools.ietf.org => ietf@quittek.at -- -------------------------------------+------------------------------ Reporter: jparello@cisco.com | Owner: ietf@quittek.at Type: defect | Status: new Priority: major | Milestone: Component: applicability-statement | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------ Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Jan 16 10:14:58 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFCF21F873B for ; Wed, 16 Jan 2013 10:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-v5UybscLSl for ; Wed, 16 Jan 2013 10:14:58 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2397621F86AE for ; Wed, 16 Jan 2013 10:14:58 -0800 (PST) Received: from localhost ([127.0.0.1]:47009 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TvXVf-0006qj-M3; Wed, 16 Jan 2013 19:14:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bnordman@lbl.gov, n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 16 Jan 2013 18:14:47 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/21#comment:6 Message-ID: <079.8fc3cda5a420dbc863365da63731e0dc@trac.tools.ietf.org> References: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bnordman@lbl.gov, n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #21: h. Clarify the intended application of the Domain concept? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:14:58 -0000 #21: h. Clarify the intended application of the Domain concept? Comment (by jparello@cisco.com): Bruce has the token for this (v7) to (v8) -- ---------------------------------------+------------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: bnordman@lbl.gov Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Jan 16 10:22:10 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820321F8BE7 for ; Wed, 16 Jan 2013 10:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoeHyZP0mnRA for ; Wed, 16 Jan 2013 10:22:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1621F87F5 for ; Wed, 16 Jan 2013 10:22:08 -0800 (PST) Received: from localhost ([127.0.0.1]:47409 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TvXcj-0002uW-Ge; Wed, 16 Jan 2013 19:22:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 16 Jan 2013 18:22:05 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:10 Message-ID: <079.4ea9e9b7c3fc2b6cd44e419b57773d45@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:22:10 -0000 #4: Reorganise sections Comment (by jparello@cisco.com): sections should be organize and then copy edited to close this. -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From bclaise@cisco.com Sun Jan 20 02:29:53 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC021F8552; Sun, 20 Jan 2013 02:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHaFfhfH97p6; Sun, 20 Jan 2013 02:29:52 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 468BC21F854E; Sun, 20 Jan 2013 02:29:51 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0KATm3l014615; Sun, 20 Jan 2013 11:29:49 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0KATBsA029184; Sun, 20 Jan 2013 11:29:21 +0100 (CET) Message-ID: <50FBC6F7.4090405@cisco.com> Date: Sun, 20 Jan 2013 11:29:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <50FADCD7.7070700@gmail.com> In-Reply-To: <50FADCD7.7070700@gmail.com> Content-Type: multipart/alternative; boundary="------------050700090207050501010100" Cc: eman mailing list , General Area Review Team , draft-ietf-eman-rfc4133bis.all@tools.ietf.org Subject: Re: [eman] Gen-ART LC review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 10:29:53 -0000 This is a multi-part message in MIME format. --------------050700090207050501010100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Brian for your review, Let me answer two points below, starting with BENOIT> Regards, Benoit draft-ietf-eman-rfc4133bis-05-carpenter.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-eman-rfc4133bis-05.txt Reviewer: Brian Carpenter Review Date: 2013-01-19 IETF LC End Date: 2013-01-25 IESG Telechat date: Summary: Ready (nits) -------- Comment: -------- I didn't find any mention of a MIB Doctor review in the tracker. Since two authors are MIB Doctors, it should be OK. BENOIT> The MIB doctor review takes place now, part of the IETF LC BENOIT> See http://www.ietf.org/iesg/directorate/mib-doctors.html BENOIT> The doctor is Juergen Schoenwaelder. I did not review the details of the MIB module. Nits: ----- In the Abstract, "This document specifies version of the Entity MIB" seems to lack a "4". I would have expected a short paragraph starting "Version 4 of this MIB addresses new requirements... " just before section 2.1. BENOIT> That makes sense. --------------050700090207050501010100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Thanks Brian for your review,

Let me answer two points below, starting with BENOIT>

Regards, Benoit

draft-ietf-eman-rfc4133bis-05-carpenter.txt

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-eman-rfc4133bis-05.txt
Reviewer: Brian Carpenter
Review Date: 2013-01-19
IETF LC End Date: 2013-01-25
IESG Telechat date: 

Summary:  Ready (nits)
--------

Comment:  
--------

I didn't find any mention of a MIB Doctor review in the tracker. Since two
authors are MIB Doctors, it should be OK.


BENOIT> The MIB doctor review takes place now, part of the IETF LC
BENOIT> See http://www.ietf.org/iesg/directorate/mib-doctors.html
BENOIT> The doctor is Juergen Schoenwaelder.


I did not review the details of the MIB module.

Nits:
-----

In the Abstract, "This document specifies version of the Entity MIB"
seems to lack a "4".

I would have expected a short paragraph starting "Version 4 of this MIB
addresses new requirements... " just before section 2.1.

BENOIT> That makes sense.
 
--------------050700090207050501010100-- From bclaise@cisco.com Mon Jan 28 05:16:45 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE6F21F87C3; Mon, 28 Jan 2013 05:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=4.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJML9YGZxbHn; Mon, 28 Jan 2013 05:16:44 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id BD6BB21F86FF; Mon, 28 Jan 2013 05:16:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0SDGei9018271; Mon, 28 Jan 2013 08:16:40 -0500 (EST) Received: from [10.61.109.8] (dhcp-10-61-109-8.cisco.com [10.61.109.8]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0SDGdrn004255; Mon, 28 Jan 2013 08:16:39 -0500 (EST) Message-ID: <51067A37.10404@cisco.com> Date: Mon, 28 Jan 2013 13:16:39 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> <20130115140907.GA21588@elstar.local> In-Reply-To: <20130115140907.GA21588@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:16:46 -0000 Dan, > On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > >>>>> f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] >>>>> method of context identification"? For example, "an SnmpEngineID >>>>> and ContextName pair [RFC3411] for context identification". >>>>> >>>> [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a >>> bug I suggest to avoid such changes. >>> >>> It is document clarity. But I won't insist on this, I just find the >>> current text unnecessarily confusing. >>> >>>>> g) Overall, replace MIBs with MIB modules. >>>>> >>>> [[DR]] Same as the previous point. >>> Again, it is document clarity. It is rather obvious that this change >>> does not break anything, no? Let Bert decide - he is the owner of the >>> one MIB many MIB modules song. ;-) >>> >> [[DR]] I also sing the song when I review new documents, but in this case we would interfere in the text of the document that is now at version 4. > So what? Time to fix this. Anyway, I will not fight for this if > editors believe it is best to not update vocabularity to current I agree with Juergen on the two points above. Every single time I speak SNMP/MIB with someone, I try to use the right language, and correct my interlocutor if needed, with a little of education. I don't understand why we don't jump on the opportunity to correct this document. There are two types of audience for this new document: 1. The people who have not read the first 3 versions. So I guess not that familiar with the SNMP/MIB. They would benefit from the right terminology 2. The persons who need a diff with the previous version. So I guess familiar with SNMP/MIB. And the improvements would be obvious to them. Therefore, there is no harm in improving the document. And I don't buy in the argument that we need to keep consistency with RFC 4133 ..; for something that is not clear. Regards, Benoit > rules. > > /js > From dromasca@avaya.com Mon Jan 28 05:24:36 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41B21F8585; Mon, 28 Jan 2013 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiscjRb6FV8j; Mon, 28 Jan 2013 05:24:35 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9249E21F843A; Mon, 28 Jan 2013 05:24:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAP0QA1HGmAcF/2dsb2JhbABFgmu0CYdeFnOCHgEBAQEDEihLBAIBCA0BAwQBAQEKFAkHMhQJCAIEARIIDgyHbQGhY5x0kF5hA5waijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="46190102" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Jan 2013 08:24:00 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2013 08:23:54 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 08:24:44 -0500 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" Thread-Topic: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN/VnCceBnsMGWTE+6n3qI796HE5heuiTA Date: Mon, 28 Jan 2013 13:24:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA078EC3@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> <20130115140907.GA21588@elstar.local> <51067A37.10404@cisco.com> In-Reply-To: <51067A37.10404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:24:36 -0000 Sure, there are 7 instances of 'MIBs' in the latest version of the document= - we can replace them all by 'MIB modules'.=20 Are there any other issues that need to be edited before submitting a revis= ed version? We (the authors) believe that we fixed all issues raised by the= MIB Doctor review, but mistakes are always possible.=20 Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, January 28, 2013 3:17 PM > To: Romascanu, Dan (Dan); mib-doctors@ietf.org; draft-ietf-eman- > rfc4133bis@tools.ietf.org; ops-ads@tools.ietf.org; eman@ietf.org > Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman- > rfc4133bis-05.txt >=20 > Dan, > > On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > > > >>>>> f) In 2.12.2, can we find a better phrase than "SNMP ARCH > [RFC3411] > >>>>> method of context identification"? For example, "an > SnmpEngineID > >>>>> and ContextName pair [RFC3411] for context identification". > >>>>> > >>>> [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix > >>>> a > >>> bug I suggest to avoid such changes. > >>> > >>> It is document clarity. But I won't insist on this, I just find the > >>> current text unnecessarily confusing. > >>> > >>>>> g) Overall, replace MIBs with MIB modules. > >>>>> > >>>> [[DR]] Same as the previous point. > >>> Again, it is document clarity. It is rather obvious that this change > >>> does not break anything, no? Let Bert decide - he is the owner of > >>> the one MIB many MIB modules song. ;-) > >>> > >> [[DR]] I also sing the song when I review new documents, but in this > case we would interfere in the text of the document that is now at > version 4. > > So what? Time to fix this. Anyway, I will not fight for this if > > editors believe it is best to not update vocabularity to current > I agree with Juergen on the two points above. >=20 > Every single time I speak SNMP/MIB with someone, I try to use the right > language, and correct my interlocutor if needed, with a little of > education. > I don't understand why we don't jump on the opportunity to correct this > document. > There are two types of audience for this new document: > 1. The people who have not read the first 3 versions. So I guess not > that familiar with the SNMP/MIB. They would benefit from the right > terminology 2. The persons who need a diff with the previous version. So > I guess familiar with SNMP/MIB. And the improvements would be obvious to > them. >=20 > Therefore, there is no harm in improving the document. And I don't buy > in the argument that we need to keep consistency with RFC 4133 ..; for > something that is not clear. >=20 > Regards, Benoit > > rules. > > > > /js > > From internet-drafts@ietf.org Tue Jan 29 08:53:57 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DCC21F84DC; Tue, 29 Jan 2013 08:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODyUa9luss8W; Tue, 29 Jan 2013 08:53:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3621F84F6; Tue, 29 Jan 2013 08:53:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129165357.30233.92734.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 08:53:57 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-requirements-11.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:53:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Requirements for Energy Management Author(s) : Juergen Quittek Mouli Chandramouli Rolf Winter Thomas Dietz Benoit Claise Filename : draft-ietf-eman-requirements-11.txt Pages : 26 Date : 2013-01-29 Abstract: This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions: Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-requirements-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Quittek@neclab.eu Tue Jan 29 09:24:27 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1801521F8A03; Tue, 29 Jan 2013 09:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxj6tIHZjUXR; Tue, 29 Jan 2013 09:24:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC6721F89DA; Tue, 29 Jan 2013 09:24:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3562A102F82; Tue, 29 Jan 2013 18:24:25 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzrcVBItxM3H; Tue, 29 Jan 2013 18:24:25 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1B665102F84; Tue, 29 Jan 2013 18:24:10 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.175]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Jan 2013 18:23:48 +0100 From: Juergen Quittek To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-requirements-11.txt Thread-Index: AQHN/kVhGKdXADadG0WalMzda3E49g== Date: Tue, 29 Jan 2013 17:23:41 +0000 Message-ID: In-Reply-To: <20130129165357.30233.92734.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <66777A7380C86D4BB11C978849E98EAF@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] I-D Action: draft-ietf-eman-requirements-11.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:24:27 -0000 Dear all, This new version contains very few modifications based on feedback received on the IETF last call from the Gen-art review and the security directorate review. The only noteworthy change is an additional sentence in the security considerations section clarifying the needs for authentication and authorization of entities requesting access to energy monitoring information. Thanks, Juergen On 29.01.13 17:53, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Energy Management Working Group of the >IETF. > > Title : Requirements for Energy Management > Author(s) : Juergen Quittek > Mouli Chandramouli > Rolf Winter > Thomas Dietz > Benoit Claise > Filename : draft-ietf-eman-requirements-11.txt > Pages : 26 > Date : 2013-01-29 > >Abstract: > This document defines requirements for standards specifications for > energy management. The requirements defined in this document concern > monitoring functions as well as control functions: Monitoring > functions include identification of energy-managed devices and their > components, monitoring of their power states, power inlets, power > outlets, actual power, power properties, received energy, provided > energy, and contained batteries. Control functions serve for > controlling power supply and power state of energy-managed devices > and their components. > This document does not specify the features that must be implemented > by compliant implementations but rather features that must be > supported by standards for energy management. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-eman-requirements > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-eman-requirements-11 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-11 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman