Subject: [OPSAWG] Addition of Available Space to Host-Resources-MIB

From: Sheppy Reno <[email-masked]>
Date: Tue, 11 Sep 2012 11:48:57 -0400

After working with SNMP for quite a while we’ve repeatedly run into issues
where monitoring software is unable to accurately determine the utilization
of volumes on some Linux partitions due to regular processes being unable
to access the reserved file space.  I believe that the best way to correct
this issue is to include an additional data point in the Host Resources MIB
(RFC2790) that will return available space.  This should have no negative
impact on systems that do not utilization reserved space, but will allow
for a much more accurate picture of the space that is truly available on
those partitions using reserved space.

I’ve been reading through the IETF site a bit, but I’m still not sure as to
the best process to get this implemented.  I was hoping someone on here
could give me some tips on proceeding with this.  From what I can see, I
just need to update RFC2790 with the below information and resubmit.

RFC 2790

Add:

hrStorageAvail OBJECT-TYPE

                SYNTAX                Integer32 (0..2147483647)

                MAX-ACCESS     read-only

                STATUS                current

                DESCRIPTION

                                “The amount of the storage represented by
this entry

                                that is available to non-superusers, in
units of

                                hrStorageAllocationUnits.”

                ::= { hrStorageEntry 8 }

Thanks,

Sheppy Reno

---

From: Melinda Shore <[email-masked]>
Date: Tue, 11 Sep 2012 07:57:16 -0800

On 9/11/12 7:48 AM, Sheppy Reno wrote:
> I’ve been reading through the IETF site a bit, but I’m still not sure as
> to the best process to get this implemented.  I was hoping someone on
> here could give me some tips on proceeding with this.  From what I can
> see, I just need to update RFC2790 with the below information and
> resubmit. 

Probably the best approach would be to write up your proposal in the
form of an internet draft describing the problem you're encountering,
your proposal, and the rationale for your proposal.
Melinda

---

From: Sheppy Reno <[email-masked]>
Date: Tue, 11 Sep 2012 12:15:04 -0400

> your proposal, and the rationale for your proposal.

Melinda,
Thanks for the prompt response.  My issues arise from not knowing how to
properly submit this as an internet draft.
http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared
towards new drafts than to updates for current RFCs.  From the information
on that page I would assume that the proper way to proceed would be to
modify RFC2790, add in the Internet Draft comments in the header, remove
anything mentioning RFC, etc.  I'm just worried because this seems like a
counterintuitive approach to submitting a modification.

Is there a process by which I just submit the changes instead of rebuilding
the entire RFC this is based on?  I don't mind doing the extra work if a
complete rewrite of the original RFC is required, but I want to make sure
I'm making the submission properly.
Thanks,
Sheppy

---

From: t.petch <[email-masked]>
Date: Tue, 11 Sep 2012 18:12:23 +0100

Sheppy

You should look too at RFC4181 which gives the current guidelines for
writing a MIB module, which is what you would, de facto, be doing.  The
practice has moved on and this RFC will give you some idea of what would
be involved in making even a one word change to a MIB module from an
earlier time:-(

Tom Petch

----- Original Message -----
From: "Sheppy Reno" <[email-masked]>
To: "Melinda Shore" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2012 5:15 PM
Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB

Melinda,
Thanks for the prompt response.  My issues arise from not knowing how to
properly submit this as an internet draft.
http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared
towards new drafts than to updates for current RFCs.  From the
information
on that page I would assume that the proper way to proceed would be to
modify RFC2790, add in the Internet Draft comments in the header, remove
anything mentioning RFC, etc.  I'm just worried because this seems like
a
counterintuitive approach to submitting a modification.

Is there a process by which I just submit the changes instead of
rebuilding
the entire RFC this is based on?  I don't mind doing the extra work if a
complete rewrite of the original RFC is required, but I want to make
sure
I'm making the submission properly.
Thanks,
Sheppy

------------------------------------------------------------------------
--------

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Sep 2012 13:35:01 -0400

> be involved in making even a one word change to a MIB module from an

Is it really necessary to do a bis document just for adding a single 
OID? Why not just define the new OID by itself and refer to the existing 
RFC?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 11 Sep 2012 15:30:22 -0400

Hi Sheppy,

Updating a standard is a fairly difficult task. 

This is deliberate; If standards were constantly changing, it would be hard
to get consistent implementations across products.

The IETF would need to publish a new RFC to obsolete the existing RFC.

Before they would do this, the IESG (standards approval committee) would
need to verify that the change to the standard represented IETF consensus.

So any proposed change would need to be discussed by the IETF community
before being accepted.

There are likely other changes people would like, so changing the standard
would likely include a number of changes, all of which would need IETF
community consensus.

Updating a standard MIB is a slightly more difficult task than normal.

MIB modules contain compliance statements to ensure/encourage
interoperability across implementations.

There are specific rules about how to update a MIB so that existing
compliant implementations do not become non-compliant.

That's why writing up a proposal is important - so the IETF can read/study
your proposal in detail.

A simpler approach would be to write a new MIB module that could be
implemented in addition to the standard, without updating the standard MIB
module.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sheppy Reno
Sent: Tuesday, September 11, 2012 12:15 PM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB

On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore <[email-masked]>
wrote:

On 9/11/12 7:48 AM, Sheppy Reno wrote:
> I've been reading through the IETF site a bit, but I'm still not sure as

 

Melinda,

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Sep 2012 13:17:36 -0700

Hi -

To make what the other folks have been saying more concrete:

Submit an internet draft.  The draft would contain a MIB module.
That MIB module would contain two definitions.  The first would
be for a "conceptual row" containing a single object (which you
defined as "hrStorageAvail" below) with an AUGMENTS clause
referring to the base conceptual row in the Host Resources MIB.
The second would be the definition you proposed below.

Including boilerplate and your explanation of the rationale, the
whole thing should weigh in at about seven pages.

Randy

----- Original Message ----- 
From: "Sheppy Reno" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 11, 2012 8:48 AM
Subject: [OPSAWG] Addition of Available Space to Host-Resources-MIB

RFC 2790

Add:

                MAX-ACCESS     read-only

                STATUS                current

                DESCRIPTION

                ::= { hrStorageEntry 8 }

Thanks,

Sheppy Reno

--------------------------------------------------------------------------------

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 Sep 2012 10:41:06 +0200

I agree with the suggestions made by David and Randy.

My only observation would be to: 

Ø  A simpler approach would be to write a new MIB module that could be implemented in addition to the standard, without updating the standard MIB module.

Actually I believe that in RFC terminology the new RFC including the incremental MIB module (if approved) will update RFC 2790, but will not obsolete it. 

Dan

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of ietfdbh
Sent: Tuesday, September 11, 2012 10:30 PM
To: 'Sheppy Reno'
Cc: [email-masked]
Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB

Hi Sheppy,

This is deliberate; If standards were constantly changing, it would be hard to get consistent implementations across products.

Before they would do this, the IESG (standards approval committee) would need to verify that the change to the standard represented IETF consensus.

So any proposed change would need to be discussed by the IETF community before being accepted.

There are likely other changes people would like, so changing the standard would likely include a number of changes, all of which would need IETF community consensus.

MIB modules contain compliance statements to ensure/encourage interoperability across implementations.

There are specific rules about how to update a MIB so that existing compliant implementations do not become non-compliant.

That's why writing up a proposal is important - so the IETF can read/study your proposal in detail.

A simpler approach would be to write a new MIB module that could be implemented in addition to the standard, without updating the standard MIB module.

David Harrington

[email-masked] <mailto:[email-masked]> 

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sheppy Reno
Sent: Tuesday, September 11, 2012 12:15 PM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB

On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore <[email-masked]> wrote:

 

Melinda,
Thanks for the prompt response.  My issues arise from not knowing how to properly submit this as an internet draft.  http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared towards new drafts than to updates for current RFCs.  From the information on that page I would assume that the proper way to proceed would be to modify RFC2790, add in the Internet Draft comments in the header, remove anything mentioning RFC, etc.  I'm just worried because this seems like a counterintuitive approach to submitting a modification.
 
Is there a process by which I just submit the changes instead of rebuilding the entire RFC this is based on?  I don't mind doing the extra work if a complete rewrite of the original RFC is required, but I want to make sure I'm making the submission properly.
Thanks,
Sheppy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 Sep 2012 10:46:41 +0200

Hi Simon,

According to SMI and MIB definition rules OIDs (actually I believe that you meant new objects) can be defined only within MIB modules. 

The proposal made by Randy does what you are suggesting following the SMI MIB definition rules, by defining a minimal MIB module that augments the existing MIB module defined in RFC 2790. 

It's the minimal thing that I can think about, it still requires defining a MIB module in an RFC. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Simon Perreault
> Sent: Tuesday, September 11, 2012 8:35 PM
> To: [email-masked]
> > writing a MIB module, which is what you would, de facto, be doing.
> > The practice has moved on and this RFC will give you some idea of what
> > would be involved in making even a one word change to a MIB module
> > from an earlier time:-(
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Sep 2012 08:06:50 -0400

Le 2012-09-12 04:46, Romascanu, Dan (Dan) a écrit :
> According to SMI and MIB definition rules OIDs (actually I believe
> that you meant new objects) can be defined only within MIB modules.
>
> The proposal made by Randy does what you are suggesting following the
> SMI MIB definition rules, by defining a minimal MIB module that
> augments the existing MIB module defined in RFC 2790.
>

Thanks, that answers my question perfectly.

Simon

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Sep 2012 09:30:01 -0700

> The second would be the definition you proposed below.

<rant-with-no-real-expectations-of-change>

You know, I know that's the right approach.  I've always known that.
But...  I've always hated it.

I've always failed to see why we can't add a new column to an existing
table, which is all that is needed.  Simply republish the existing MIB
with the new column.

There are really only two downsides:

1) Badly written management code that is doing a full table walk and is
   not looking at the output careful to realize it should discard some
   things it doesn't care about being returned.  I honestly don't know
   how much of this type of code exists in the world, where after the
   last column in a table it can't handle extra data.  Maybe it's more
   than I'd like.

2) It'd drop the existing DRAFT standard back to PROPOSED.  I actually
   don't care about this too much.  We (the IETF) has already admitted
   that we have issues with "levels".  In reality, we need only the new
   parts to be PROPOSED and everything else remain DRAFT, but we can't
   do that without doing the augment-in-a-new-draft-thing, which is
   painful to the end user: IE, the people that matter.

In netconf we now have the ability to augment in place (Yay!), but the
output of netconf is less human readable in it's raw-ish form because of
the namespace tag marking explosions (Boo!).

Yes, I'm ranting about the known-failings of the SMI, which no matter
how hard we try to move from it's still very very very important in the
IETF world as new changes and new MIBs are being written constantly.
But the failings of the SMI actually aren't the SMI at all, it's how we
let ourselves use the SMI in publications "don't change it at all, even
when it's safe to do so".

[note that conformance statements aren't a problem, IMHO, you just need
to add another and let the existing one remain.  A device can still be
conformant to the old conformance requirements.]

</rant-with-no-real-expectations-of-change>
 
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Sheppy Reno <[email-masked]>
Date: Wed, 12 Sep 2012 12:38:12 -0400

If I submit this as an AUGMENT would it still mean that hrStorageAvailable
would appear grouped with the rest of the hrStorage table in an SNMP walk
or would it be a completely separate MIB?

I've read http://tools.ietf.org/html/rfc2578#page-29 quite a few times, but
I can't say that its any clearer now than it was the first read through.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Sep 2012 18:52:47 +0200

> when it's safe to do so".

Yes, the SMIv2 is just fine with adding a column. Easy, nothing breaks.

It is the procedures and requirements we created through all the years
and with the best intentions that may make this one object addition a
rather unattractive exercise paired with a fear that once we open up a
document, we might end up with a rather large request for all sorts of
changes and we would not know where to draw the line. The later can be
dealt with by having restrictive words in a WG charter for such a MIB
module update. The former can be dealt with by positive thinking; lets
not spent time worrying about all the potential problems but instead
see how we can make the processes work most efficient if we agree that
such an update indeed makes sense.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2012 18:55:13 +0200

> the namespace tag marking explosions (Boo!).

Use the current SVN revision of pyang and translate it to JSON. If the data model schema is sane, the namespaces will be completely gone. If the schema is less sane, the names of YANG modules will be used as namespace identifiers where necessary.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Sep 2012 11:32:50 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 12, 2012 9:23 AM
> Subject: Re: Addition of Available Space to Host-Resources-MIB
... 
> <rant-with-no-real-expectations-of-change>
...
> 1) Badly written management code that is doing a full table walk and is
...

I wouldn't worry about it.  I seem to recall this being one of the
cases tested in the early interoperability bake-offs way back when.
This argument is just as (in)valid with regard to the use of any
less-used protocol feature, or to the addition of anything to a
data model.

> 2) It'd drop the existing DRAFT standard back to PROPOSED.  I actually
...

It also doesn't bother me, but I think that's a question for the folks
with products in that market segment.

> </rant-with-no-real-expectations-of-change>

Keeping the amount of paperwork to a minimum, how about doing
something that, while perfectly legal as far as I can tell,
might *really* irk badly written code:

   hrExtStorageEntry OBJECT-TYPE
       SYNTAX     HrExtStorageEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
           "A (conceptual) entry for one logical storage area on
           the host, containing extensions to the information
           contained in the corresponding hrStorageEntry."
       AUGMENTS { hrStorageEntry }
       ::= { hrStorageTable 2 }

-- yes, that's a TWO!

hrExtStorageAvail OBJECT-TYPE
                SYNTAX                Integer32 (0..2147483647)
                MAX-ACCESS     read-only
                STATUS                current
                DESCRIPTION
                                "The amount of the storage represented by this entry
                                that is available to non-superusers, in units of
                                hrStorageAllocationUnits."
                ::= { hrExtStorageEntry 8 }

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Sep 2012 11:53:12 -0700

Hi -

> To: "Wes Hardaker" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, September 12, 2012 9:38 AM

The question mixes two distinct issues.

How stuff is grouped for presentation to the user is up to the designer of
the tool in question, and should not be determined by whether the relevant
portions of the data model were defined in one or multiple MIB modules,
or how they're scattered by so-called lexicographical ordering.

(If you think about how SMI indexing works in SNMP protocol, closely related
bits of information are already scattered all over the place in the responses
to getNext or getBulk.  It's lame, but that's how it was designed.)

The designer of, for example, a "host resources" tool needs to develop an
information model to suit the use cases s/he would like to address, and then
figure out how that information model can be realized using the available
data models, modulo their implementation quirks.  Most management
applications deal with multiple data models, even if their developers haven't
consciously made the decision to do so.  Consider how many MIB objects
have discontinuity indicators defined in other MIB modules.

Without the philosophizing, here's the tradeoff.  You can
  A) try to re-spin the host resources MIB.  While this would
       put the new column in the table and keep brainless
       MIB-walker happy, this is also the most work in terms
       of IETF process, editorial and reviewer cycles.  I do not
       see any way in which this would be a significant win for
       intelligent management applications.

  B) create a new MIB module, using AUGMENTS, etc.
       While this won't help the brainless MIB walker, for
       intelligent management applications, and even for
       fairly simple-minded script-driven applications, this
       works as well as (A), with orders of magnitude less
       institutional overhead.

  C) You can try to change the process to make (A) less
        of an institutional burden.

Of these, only (B) has in my opinion much chance of being
accomplished quickly.
   
Randy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 13 Sep 2012 10:59:14 -0700

[I'd like to remind people that it was a rant; I don't expect something
different than the AUGMENT approach to actually be taken]

>        intelligent management applications.

Note: I tend to optimize for the "most people" most of the time.  There
are a whole heck of a lot of brainless mib-walkers, but there is only
one document author.  In terms of time-spent, I suspect putting more
work on the document author and less on the brainless means a positive
energy balance if "it must be done in the first place".

But I realize that's not the right approach in terms of optimizing for
the author, reviewers, iesg, etc.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 13 Sep 2012 10:59:52 -0700

Ladislav Lhotka <[email-masked]> writes:

> Use the current SVN revision of pyang and translate it to JSON. If the
> data model schema is sane, the namespaces will be completely gone. If
> the schema is less sane, the names of YANG modules will be used as
> namespace identifiers where necessary.

I very much realize that there are tool-ways around doing things.  And
they should be used, I agree.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 13 Sep 2012 11:04:09 -0700

>        AUGMENTS { hrStorageEntry }

Heh.  I'd be more tempted to simply define the new column in a new MIB
module and import the existing entry spec and just place the new column
into the table from afar.

IE, just do this:

>                                "The amount of the storage represented
>                                by this entry that is available to
>                                non-superusers, in units of

(which is actually a copy of what you put because you forgot to add the
2 to your OID clause in the first place)
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Sheppy Reno <[email-masked]>
Date: Thu, 13 Sep 2012 14:15:19 -0400

I'm in the position of having to go through IETF because none of the work
arounds that I proposed were acceptable for various reasons (a large part
of it boils down to manpower considerations).  It seems that from
everything I've read, that updating the Host-Resources-MIB RCF itself is
the proper way to implement this -- manpower considerations aside.  I
believe that this is the right way to go and another RFC said something to
the effect that once an OID is placed somewhere it can't be moved.  I'd
rather not go through the process of getting it added as an augment only to
find out that RFC2790 was superseded in the next year or two and I'm unable
to get this added correctly.

Sorry if I seem a bit dense, but RFCs relating to the ins and outs of RFC
documentation is very difficult to navigate for the uninitiated.

As far as manpower is concerned, assuming I want to proceed with getting
RFC2790 itself updated are there steps that I can take to reduce the
overhead of others as much as possible?

Thanks again,
Sheppy

---

From: t.petch <[email-masked]>
Date: Fri, 14 Sep 2012 14:54:22 +0100

----- Original Message -----
From: "Sheppy Reno" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 13, 2012 7:15 PM
> overhead of others as much as possible?

Get everything perfect first time:-)

With any I-D/RFC, you either get it adopted by a Working Group or you do
it as an individual submission.  In terms of your work, both are about
equal.  In terms of the work of others, the latter tends to burden some
people more than the former so there is a push to use a WG.  There is no
WG currently in the IETF that focuses on MIBs, this, OPSAWG, is about
the nearest.  The key players are the WG chairs and an Area Director;
the web site tells you who they are and you can see on the WG list
archive what they have said lately about what and form a view as to how
supportive they are.  Well, ask them directly if that is your style.
Look too at the WG charter

"The OPSAWG will undertake only work items that are proved to have at
least a reasonable level of interest from the operators and users
community and have a committed number of editors and reviewers."

Um.

On the route of individual submission, it as an AD and a WG chair (or
perhaps a former WG chair) who have a lot more work to do to push an I-D
through to a standard; you would need their active support.  Hence the
push to use a WG - and if the WG and/or its chairs are reluctant to take
it on, then the work is unlikely to happen.

As you probably gather, SNMP and MIB modules are regarded somewhat as a
legacy technology, Netconf/Netmod being the current incarnation.  So if
you were to propose the conversion of the hr MIB module to netmod, then
I would expect you to see more enthusiasm; but that is, of course, a
quantum leap.

Tom Petch

---

From: David Harrington <[email-masked]>
Date: Fri, 14 Sep 2012 11:40:49 -0400

Hi,

Comments inline.

--
David Harrington
[email-masked]
+1-603-828-1401

On 9/14/12 9:54 AM, "t.petch" <[email-masked]> wrote:

>people more than the former so there is a push to use a WG.

I see things differently.
I think the individual draft requires less work by others.
An AD can sponsor the draft, and ask the IESG to approve it.

A WG is used to get a wider review of the proposal.

>There is no

I have not seen a large demand for this proposed object from operators.
I think asking the WG for review will be important to
1) establish operator demand,
2) establish implementation feasibility of providing this information via
SNMP,
3) help to ensure that a clear, unambiguous definition of "available"

>it on, then the work is unlikely to happen.

IIRC, a WG chair is NOT needed to push an ID through to standard.
An AD can sponsor it alone, although most like to see a separate document
shepherd (who might be a chair or ex-chair).
The AD just needs to convince the IESG to approve it as a standard.
And the IESG might want some proof of operator demand, implementation
feasibility, and community consensus on the definition.

>I would expect you to see more enthusiasm; but that is, of course, a

Since the object being proposed reports operational state, and is a
read-only object that is not configurable, and detection of significant
state change may be important for applications, periodic polling of a MIB
object using SNMP seems the appropriate choice of tool; I don't see this
as configuration information appropriate for the netconf/YANG toolset
(except as part of an overall HR configuration data model - but that's a
whole different proposal). Therefore I would not expect more enthusiasm
for a netconf/YANG solution.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Sep 2012 09:13:34 -0700 (PDT)

>        AUGMENTS { hrStorageEntry }

I wouldn't do that.  It that violates RFC 2578 7.10 (1):

(1)  If the object corresponds to a conceptual table, then only a single
     assignment, that for a conceptual row, is present immediately
     beneath that object.  The administratively assigned name for the
     conceptual row object is derived by appending a sub-identifier of
     "1" to the administratively assigned name for the conceptual table.

and it's not unlikely that some implementations exploit this 
restriction in some way.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Sep 2012 09:36:46 -0700 (PDT)

Greetings,

It's not clear from what you write below whether or not you have 
considered and rejected the idea of creating a proprietary 
supplemental MIB module to augment the IETF Host-Resources-MIB.  
Basically, this is suggestion (B) in Randy Presuhn's message

http://www.ietf.org/mail-archive/web/opsawg/current/msg02368.html

but with the supplemental object(s) registered under an enterprise 
OID subtree (available from IANA for the asking) instead of an IETF 
OID subtree.

This approach would not require any standardization effort at all, 
just the effort to write the supplemental MIB module and to 
implement the object(s) in it.  If the IETF community has low 
interest in standardizing the extension you are asking for, then 
this is probably the right way to go.  On the other hand, if your 
extension is seen as broadly useful, updating the Host-Resources-MIB 
itself is probably the right way to go.

It's true that once an object is defined and registered under a 
given OID the object's semantics are not allowed to change (except 
in some very limited ways spelled out in RFC 2580) and that OID 
under which it is registered cannot be reused for something else.  
But I don't follow why you are worried that if you create an 
augmenting table for your proposed extension that you would be left 
high and dry by a subsequent update of the Host-Resources-MIB.  Such 
updates (if they occur) are supposed to be backward-compatible.

Mike Heard

---

From: Melinda Shore <[email-masked]>
Date: Fri, 14 Sep 2012 10:36:19 -0800

On 9/14/12 8:36 AM, C. M. Heard wrote:
> this is probably the right way to go. 

I think that's probably the case - I haven't seen anybody else
express interest or support, although the discussion so far has
really focused on how to get it done if it's decided that it
should be.

If this turns out to be the best option (a proprietary
supplemental MIB) it might be possible to publish it as an
individual contribution, documenting something that's out
there and deployed.

Thanks, Mike.

Melinda

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Sep 2012 13:18:00 -0700 (PDT)

> individual contribution, documenting something that's out

That's true.  However, the person doing the work is the one who 
would have to decide if it's worth the effort.  There is no 
obligation on the part of an implementor to publish proprietary MIB 
extensions.  Being able to "just do it" and not go through any IETF 
or RFC Editor process hassles is one of the upsides of the 
proprietary MIB extension approach.

//cmh

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 14 Sep 2012 14:54:59 -0700

Hi -

> From: "C. M. Heard" <[email-masked]>
> Cc: "OPSAWG" <[email-masked]>
> Sent: Friday, September 14, 2012 1:18 PM
...
> proprietary MIB extension approach.

As I understand the post that started this thread, the problem is that
there are important use cases that the Host-Resources-MIB does
not adequately support.  To address these use cases, managed systems
need to make available an additional piece of information.  For this
to do anyone any good, this means (1) updating the instrumentation
in the managed systems, and (2) making that information available
in a reasonably "standardized" manner.

Addressing (2) is best accomplished with an RFC, even if its "merely"
informational.  An unpublished proprietary MIB or extension MIB is
of little value there.

This discussion has thus far not touched on (1) at all, and I note that
the folks who I know were most visible in Host-Resources-MIB
implementations have been conspicuously absent from this discussion.
Without some interest in (1), or at least some assurance that the
major code bases might get updated, the main value of a document
would be to describe the shortcoming and other possible operational
workarounds, if they exist.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 17 Sep 2012 09:52:43 -0700

> really focused on how to get it done if it's decided that it

FYI, I support the standardization of additional objects to the HR mib.
There are a number of requests I've heard over time that have needed to
add additions to the HR mib, and this is really just one of a few.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 17 Sep 2012 09:53:47 -0700

> workarounds, if they exist.

Speaking with my vendor hat on: Net-SNMP would almost certainly add
support for them.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Robert Story <[email-masked]>
Date: Mon, 17 Sep 2012 14:03:48 -0400

On Mon, 17 Sep 2012 09:52:43 -0700 Wes wrote:
WH> Melinda Shore <[email-masked]> writes:
WH> > I think that's probably the case - I haven't seen anybody else
WH> > express interest or support, although the discussion so far has
WH> > really focused on how to get it done if it's decided that it
WH> > should be.
WH> 
WH> FYI, I support the standardization of additional objects to the HR mib.

+1

WH> There are a number of requests I've heard over time that have needed to
WH> add additions to the HR mib, and this is really just one of a few.

Yep, I had the same though. If we're going to do this, digging up those and
doing them at the same time would make sense.

Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 17 Sep 2012 11:36:46 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> Cc: "C. M. Heard" <[email-masked]>; "OPSAWG" <[email-masked]>
> Sent: Monday, September 17, 2012 9:52 AM
...
> add additions to the HR mib, and this is really just one of a few.

Would you prefer to accomplish this by re-opening the Host-Resources-MIB,
or by creating a new MIB module (Host-Resources-Extensions-MIB)?

In either case, if there turns out to be sufficient interest in taking this on as a
WG item, I'd be willing to edit, if needed.

Randy

---

From: Robert Story <[email-masked]>
Date: Mon, 17 Sep 2012 17:36:55 -0400

On Mon, 17 Sep 2012 11:36:46 -0700 Randy wrote:
RP> Would you prefer to accomplish this by re-opening the
RP> Host-Resources-MIB, or by creating a new MIB module
RP> (Host-Resources-Extensions-MIB)?

I'm for whichever is most likely to make it though the process (which I
suspect would be the new MIB module).

RP> In either case, if there turns out to be sufficient interest in taking
RP> this on as a WG item, I'd be willing to edit, if needed.

I will review..

Robert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Sep 2012 23:53:04 +0200

> suspect would be the new MIB module).

Both options have a defined process. Before deciding, I suggest to
find agreement on the additions that are needed. It now sounds like
it is not just one object anymore... ;-)

/js

---

From: Robert Story <[email-masked]>
Date: Mon, 17 Sep 2012 18:32:58 -0400

On Mon, 17 Sep 2012 23:53:04 +0200 Juergen wrote:
JS> Both options have a defined process. Before deciding, I suggest to
JS> find agreement on the additions that are needed. It now sounds like
JS> it is not just one object anymore... ;-)

Indeed.. some other objects we might want to consider:

augment hrDiskStorageTable
  - hrDiskStorageCapacityHC (current KBytes not big enough for TB drives)

augment hrPartitionTable
  - hrPartitionSizeHC (current KBytes not big enough for TB drives)

I don't know if we also want to consider hrMemorySizeHC and hrSWRunPerfMemHC. How far off are systems with terrabytes of memory?

Robert

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 17 Sep 2012 16:22:00 -0700

> or by creating a new MIB module (Host-Resources-Extensions-MIB)?

I'd like a new MIB that drops the new objects into the existing
structures :-)

But...  there is no precedence for that.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 17 Sep 2012 20:18:34 -0700 (PDT)

> FYI, I support the standardization of additional objects to the HR
> mib. There are a number of requests I've heard over time that have needed
> toadd additions to the HR mib, and this is really just one of a few.

I second Wes call to fix RFC 2790. Having implemented that mib last year, saw
a number of objects now showing their age. here's two examples:

1. If one pxe boot an OS, then its possible for hrSystemInitialLoadParameters.0  to be truncated
    HOST-RESOURCES-MIB::hrSystemInitialLoadParameters.0 = STRING: "/mts/dbc2-c/mrm/pxe//t-bad88fe832d9130c4d88/CUR-visor-x64-26-obj/vmkboot.gz BOOTIF=01-00-30-48-7c-fb-20 debugLogToSerial=1 pxebo"

2. If one has disks larger than max int32, then
   hrDiskStorageCapacity reports incorrectly, see either agents show a negative value or latch at int32_t max.

  HOST-RESOURCES-MIB::hrDiskStorageCapacity.33 = INTEGER: -2147483648 KBytes # 2 TB disk

Mike MacFaden
Staff Engineer, R&D Apps, Palo Alto, VMware, Inc.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 17 Sep 2012 19:23:51 -0800

> it is not just one object anymore... ;-)

Okay, it sounds as if there's sufficient interest to have a discussion.
Does someone want to work with Sheppy on getting an initial problem
description and possibly a proposal written up?

Melinda

---

From: t.petch <[email-masked]>
Date: Tue, 18 Sep 2012 09:51:42 +0100

If change is to be made, I would like it to be an updated, Standards
track MIB module, rather than a patch of any shape or form. I would be
happy to help with the reviewing of it. I am a user of the HR MIB module
rather than implementer.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Sep 2012 12:09:12 +0200

> happy to help with the reviewing of it. I am a user of the HR MIB module

Same here. What I heard so far and what I consider useful as well:

- Updates to add high capacity counters that are needed for todays
  storage and memory sizes.

- Additional counters that deal with the notion of reserved space in
  various file systems.

- Some boot parameters limitations.

- We may want to extend hrDiskStorageMedia or even make it IANA
  controlled.

- Perhaps it makes sense to add hrSWRunPerfVirtualMem since
  hrSWRunPerfMem seems to report only the resident memory of a
  process. Perhaps it also makes sense to add hrSWRunPerfSharedMem.

- And of course, having a common notion of system load averages would
  be useful since this is something we always have to dig out of
  proprietary MIBs.

Anyway, I am planning to add support for any of these to the scli
program once there is an agent supporting these extensions I can test
against.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Sep 2012 12:04:23 +0200

All these seem useful extensions. 

I am willing to be a reviewer as well if this work is chartered. 

Question to Juergen - what would be a (rough) definition for the
hrSWRunPerfVirtualMem object? 

Dan

> Of Juergen Schoenwaelder
> Sent: Tuesday, September 18, 2012 1:09 PM
> To: t.petch
> Cc: [email-masked]
> > happy to help with the reviewing of it. I am a user of the HR MIB
> > module rather than implementer.
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Sep 2012 12:32:57 +0200

> hrSWRunPerfVirtualMem object? 

Something like this:

hrSWRunPerfVirtualMem OBJECT-TYPE
    SYNTAX     KBytes
    UNITS      "KBytes"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The total amount of virtual memory allocated to
        this process."
    ::= { hrSWRunPerfEntry 3 }

/js