[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Comments on BCP-09



WG Members:

In case you're confused about why we're still talking about the BCP, we 
*did* close last call, but Dave Perkins put a fair amount of effort into 
reviewing it and didn't get a chance to submit comments until after 
close.  We decided to give his comments a look-see.  July was a busy month 
for me (the primary typist on this round), so I didn't get a chance to 
close my updates until yesterday.  We're attempting to close this out, and 
get this resubmitted.  At this point, it isn't our intent to force another 
last call, since nothing semantic has changed.

Now, as for Mr. Perkins...

Hi Dave...here's the specific interpretations we made of and actions we 
took on your comments on the BCP.

Before I begin, let me tell you where we stand.  I've given copious notes 
below of what we've done (more notes than there were changes, by and large 
:).  I've put a candidate draft -10 off of my web page at 
http://home.tiac.net/~wayne/snmpconf/index.htm.  WE'VE NOT YET SUBMITTED IT 
TO THE I-D editor.  I'd like you to review these changes.  Sure, there are 
a lot, so if you want to skip straight to stuff we either couldn't 
understand your comments or somewhat intentionally didn't change it because 
we didn't agree with you, or where I'm somewhat inferring what you were 
after, look below at items:

3,10,12,13,19,20,24,26,28,29,30,32,36,38,40,42,45

I have, however, strived to include a positive acknowledgement of all of 
your 46 points.

I need response on this pretty soon, and I mean by like this Monday close 
of business.  One of the authors has consented to hound you down at your 
plush office there at Riverstone to try to make this happen. :)  Of course, 
you don't have to respond on any specific point, or any at all, and that 
might be good to focus on what is worth focusing on.  However, IF YOU DO 
NOTHING by about end of Monday, then the -10 as indicated in these comments 
(and as it shows up on my web page) will be submitted (well, assuming one 
of the other editors or wg members doesn't catch anything as well).  For 
that matter, we may still submit -10 unless we get convinced that we missed 
the gist of one of your prior comments or you convince us of something 
we're currently unconvinced on.  If you do make such an attempt, please use 
descriptions a bit more specific and florid than, e.g., "this is bogus". :)

For the record, the philosophy has been that if we can conceive of anything 
at all to address a concern of yours (in some cases, of course, such an 
"anything" was pretty obvious :), we've done it.

I needn't tell you how anxious the authors are to advance this at this 
point.  Having said that, it's clear you've put a lot of effort into this, 
for which we are deeply impressed you have our sincere gratitude.  Thanks. :)

Regards,
Wayne

At 10:03 PM 6/26/2002 -0700, David T. Perkins wrote:

>2) several places in the document are two spaces where a single
>    space should be. Need to do a search, to find them and then
>    fix the source document.

Fixed, to the best of my ability to track this down using a regular 
expression.  For whatever reason, a lot of these showed up in examples we 
plucked directly from other RFC's.


>3) In section 1.2, the document states that the scale of networks
>    has increased, but gives no examples.

I don't know about this, and after discussion with Jon, haven't made a 
change.  I understand you wanting to have quantitatively specific examples, 
but I think this detracts from the point being made: port density creates 
an issue of scalability of the very number of managed elements that the 
management systems were not designed with.  Discussing that backbone 
interfaces have gone from 10 Mb to 1 Gb somewhat distorts the thrust.

>4) The start of the third paragraph, change
>     "Management Framework is used successfully" to
>     "Management Framework has been used successfully"

Done.


>5) the definition of "policy-based management (in middle of the
>    second para before section 2) doesn't seem too different
>    from non-policy-based management. I suggest that at least
>    it be modified to include the phrase "rule-based", as
>    shown by
>     "...is a methodology where rule-based configuration
>      information is distributed..."

That works for me with some changes.  It now reads: "...is a methodology 
where configuration information is derived from rules and network-wide 
objectives, and is distributed to potentially many network elements with 
the goal..."


>6a) In section 3.3.1, para 5, second sentence is somewhat confusing,
>    since it is telling you what is wrong, but not telling you
>    what is correct.
>  b) in point 2, the second sentence reads pretty awkwardly.

The section now reads as follows, with new text to hammer home the point :) 
in emphasis (and also to raise a slight point about underlying system 
interaction):

The RowStatus textual convention specifies that, when used
in a conceptual row, a description must define what can be modified.
*While the description of the conceptual row and its columnar object types
is the correct place to derive this information on instance
modifiability*, it is often wrongly assumed in some implementations
that:

   1) objects either must all be presently set or none need be set
      to make a conceptual RowStatus object transition to active(1)
   2) objects in a conceptual row cannot be modified once a
      RowStatus object is active(1). *Restricting instance
      modifiability like this, so that after a RowStatus object is
      set to active(1) is in fact a reasonable limitation,
      since such a set of RowStatus may have agent system side-effects
      which depend on committed columnar object instance values.*
      However, where this restriction exists on an object, it should be
      made clear in a DESCRIPTION clause *such as the following*:



>7) There are extra lines after section 3.3.2 section head before
>    the section text.
>
>8) In section 3.3.2, second para, the first sentence should be
>    changed to the following:
>      Fate sharing of SNMP table data should be explicitly defined
>      where possible using the SMI index qualifier AUGMENTS.

Done and done.


>9) section 3.4.2, last para, makes a point that DNS names used
>    as an index don't create a potential problem. However, unless
>    the DNS definitions have been changed, DNS names can be
>    upto 128 chars (and maybe international char sets make this
>    worse). A DNS name consisting of close to 128 octets used
>    as an index would mean that the instance could not be specified.
>    This has a higher probability of a problem when two DNS
>    names are used in the index.

Good point, this suggests different than what we were after.  The point is 
to specify the SIZE clause for anything using a InetAddress as an index 
(which the prior paragraph calls out).  The paragraph now reads:

One need consider the SMI limitation on the 128 sub-identifier
specification when using certain kinds of network address index
types.  The most likely practical liability encountered in practice
has been with DNS names, which can in fact be in excess of 128
bytes.  The problem can be, of course, compounded when multiple
indices of this type are specified for a table.


>
>10) section 3.7, this discussion about persistence is not clear,
>     and it does not reflect reality. That is, when and how
>     "running" configuration is written to persistent storage
>     is very dependent on the system. Writing a table with
>     a "StorageType" object does not change the storage model
>     implemented in a device. Note the setting the value to
>     "nonVolatile" does not mean that the row will be written
>     to persistent storage before the operation returns. Also,
>     a implementation may not allow different rows to have different
>     values StorageType.
>     This section is important, but also different types of
>     implementations have different models for managing
>     persistence of configuration data. This needs to be made
>     clear.

Well, this section is about MIB module design, and this point *is* called 
out early on in the section.  So, to split the difference, I added a 
closing paragraph as follows:

It is important, however, to reiterate that the persistence is ultimately
controlled by the capabilities and features (with respect to the storage
model of management data) of the underlying system on which the MIB Module
agent is being implemented.  This falls into very much the same kind of
issue set as, for example, the situation where the size of data storage
in the system for a Counter object type is not the same as that in the
corresponding MIB Object Type.  To generalize, the final word on the
"when" and "how" of storage of persistent data is dictated by the system
and the implementor of the agent on the system.

>
>11) Section 3.10.1, second sentence, the term "context" is used,
>     but this sentence does not mean "SNMP contexts". Instead,
>     of context, the phrase "SNMP parameters as found in
>     table snmpTargetParmsTable from RFC 2573" should be used.

If you say so. :)  Done.

>
>12a) Section 3.10.2, first para, first sentence, change "informs"
>      to "notifications".
>   b) Second para, first sentence, change "InformRequests" to
>      "notifications".
>   c) Third para should be removed since it is just nonsense.
>   d) Fourth para, first sentence, change "of TRAP or InformRequest
>      PDUs" to "notifications".

I did a), b), and d), but and c).  Actually, Mike and I worked on tweaking 
that paragraph, so it depends on what you're after.  You've established in 
the past the fact that you don't believe a reliable notification 
acknowledgement system can be built over Response's issued after receipt of 
InformRequest's.  Perhaps I'm overstating it, but if that's your belief, 
it's fine, just not necessarily shared by all common practice right 
now.  If you think the paragraph read like InformRequest's are the panacea 
to synchronization, I loosened that up a little.  Here is what it reads now 
after significant horse-trading (and correlation with real implementations, 
including our own):

InformRequest PDUs, when compared to TRAP PDUs, have an inherent advantage 
when the concern is the reduction of unnecessary messages from the system
generating the NOTIFICATION-TYPE data, when in fact retransmission of
this data is required.  That is, an InformRequest PDU is acknowledged by 
the receiving entity with a Response PDU. The receipt of this response 
allows the entity which generated the InformRequest PDU to verify (and 
record an audit entry, where such facilities exist on the agent system) 
that the message was
received.  As a matter of notification protocol, this receipt guarantee
is not available when using TRAP PDUs, and if it is required, must
be accomplished by the agent using some mechanism out of band to SNMP,
and usually requiring the penalty of polling.


>13) Section 3.11, second paragraph, use of term "incumbent"
>     is not correct here. Not sure what is the main issue being
>     addressed here. In general, a management application must
>     understand the semantics of configuration (that is, the
>     management app must know what is valid and what is not
>     valid configuration settings) and only request configuration
>     settings that are believed to be valid and will succeed,
>     since the actual failure can not be determined from the
>     protocol returned error code.

First of all: usage was

Typically, there is an incumbent and sizable burden on the configuration 
application to determine if the configuration request failure is the result 
of a resource issue, a security issue, or an application error.

 From American Heritage Dictionary:

in·cum·bent    (in-kumb-unt) adj.

    1. Imposed as an obligation or duty; obligatory: felt it was incumbent 
on us all to help.

Works for me :).

Second, the point is an important one--configuration *applications* may 
well have to do some finessing to determine, in certain common error cases, 
how to correlate from a notable lack of detail from the agent, how to 
detect those common (and network operator-grok'able) errors and their 
information.  If you need more examples, I have many from real life in the 
last year or two I'll be happy to share with you. :)

>
>14) Section 3.11, 4th and 5th paras, these look like that
>     they need to be combined.

oh, 4th and 5th.  Yep, done.

>
>15) Section 3.11, last paragraph is completely nonsensical.

Dunno, there is a point there.  It is that configuration failures create a 
notification audience and content requirement which may not be the same as 
those for operational failure notifications and the like.  I've rewritten 
the last sentence to hit you over the head with it:

In other words, in many management environments, the network
operators interested in NOTIFICATION-TYPEs generated from configuration
failures may not completely overlap with the community of network
operators interested in NOTIFICATION-TYPEs generated from, for example,
network interface failures.


>16) Section 3.12, last para, reference to RFC 2591 is not correct.
>     Note that RFC 2591 (section 6) is incorrect (or at least
>     misleading) in its description that implies that VACM
>     provides per user access control. VACM does not provide
>     per user, but instead provides per group granularity.
>     This makes a difference, and renders the last paragraph
>     in section 3.12 pretty bogus.

Point taken.  The sentence in the middle now reads:

If so, an "OwnerString" may be used as the first component of a table's 
index to allow VACM to be used to protect access to subsets of rows, at 
least at
the level of securityName or groupName provided. RFC 2591 [23], Section 6 
presents this technique in detail.


>17) Section 3.13.1, fourth para that starts with
>     "These informational object types...". Change to
>     "Such informational object types...".
>
>18) Section 3.13.1, first para after definition of PortList TC.
>     Change the last word of the sentence of the para from "reset"
>     to "written".

Done and done.


>19a) Section 3.13.2, para 4 implies that only the table
>     entLogicalTable from the Entity MIB (RFC 2737) can be
>     used to discover values of ContextNames. However, the
>     table vacmContextTable from MIB module
>     SNMP-VIEW-BASED-ACM-MIB (in RFC 2575) provides a list
>     of ContextName values via object vacmContextName.
>     While there is not a pointer to items such as
>     entLogicalType (found in entLogicalTable), a management app
>     can probe each context name value to determine objects
>     for the context name value.
>   b) Given an update to talk about table vacmContextTable,
>      point #2 is incorrect.
>   c) the first para following the two points is nonsense.
>      Taken at face value, both points are incorrect.

Reread the paragraph following them, which provides guidance for context 
scoping (and a small limitation) independently of the Entity MIB.  It's 
reasonably well-understood amongst folks I've discussed this with, 
particularly app writers, that the Entity MIB approach is the most 
efficient one, but in the real world, it has remained to date a hard sell 
to base a design for application techniques based upon the presumed 
near-universal existence of EntMIB agents.  That's the point being made here.

>20a) Section 4.2. This topic has already been covered. It is
>     incorrectly in the "agent implementation" section, since
>     it has nothing to do with agent design.

Come again?  Specific points for agent implementation, independent of the 
features for MIB module design, are covered here.  There are also 
considerations for management applications, hinted at by the last sentence, 
but not elaborated here.


>   b) in the third para, the phrase "an inform" should be
>      replaced by "a notification".

Done.


>21) Section 5.1.3, first para, says that an agent should
>     have the capability of sending a notification "whenever
>     a configuration operation is attempted or completed."
>     The "attempted" should be dropped.

Point taken and I'll raise you one: "whenever a
configuration operation is completed or is detected to have 
failed".  That's what I was after (assuming I wrote this section :).


>22) Section 6.2, second para, the phrase "access control"
>     should be dropped because "authorization" is already
>     specified, and the two are the same.

They are only in the SNMP framework, you're right. :)  Done.


>23a) Section 6.3 should be titled "Authentication Notifications"
>      instead of "Authentication Traps".
>   b) The term "trap" should be replaced by "notification" in
>      all places in the text in this section.

Point taken, done. (except where V1 traps are being identified specifically).


>24) Section 6.3, last sentence, repeats often incorrect
>     security warning. That is, it says to turn off generation
>     of authenticationFailure notifications because a
>     community string can be obtained by sniffing the
>     notification (sent using SNMPv1 or SNMPv2c). However,
>     this is just silly. First, the community string in
>     a notification should be different than that used
>     in GETs/SETs/etc. Secondly, if traffic can be sniffed,
>     then when a manager does a GET/SET/etc, a community
>     string can be obtained from any successful operation.
>     Don't repeat urban legends.

Urban legend though it may be to you, it is the subject of a CERT advisory 
from a year or so ago which cannot be ignored.  You may be able to goose 
the management station to generate traps which are routed unidirectionally 
to flow on sniffable network links which would otherwise be firewalled from 
carrying PDU information (in other words, to travel beyond a secure 
perimeter because a firewall has been configured to only filter 
unidirectionally).

You raise a good point though--the community string used in these should be 
different from those used for other management operations, and should be 
useless to gain access to management data (and for goodness sakes,to *set* 
management data).  I'll add that, thanks for catching it.

Furthermore, Mike raised the invalid attempt -> generated trap linkage 
which can be murder in the face of a DOS attack.  What's the resulting 
paragraph?  Here it is (paragraph 2 of the section has turned into two 
paragraphs now):

There are other liabilities where authentication notifications are
generated without proper security infrastructure. When notifications are
sent in SNMPv1 trap PDUs, unsolicited packets to a device can causes one
or more trap PDUs to be created and sent to management stations.  If
these traps flow on shared access media and links, the community string
from the trap may be gleaned and exploited to gain access to the device.
At the very least, this risk should be mitigated by having the
authentication trap PDU be conveyed with a community string which is
only used for authentication traps from the agent, and would be useless
for access inbound to the agent to get at other management data.

A further liability of authentication traps can be seen when they
are being generated in the face of a Denial Of Service (DOS) attack, in the
form of a flood of PDUs with invalid community strings, on the
agent system.  If it is bad enough that the system is having to
respond to and recover from the invalid agent data accesses, but the
problem will be compounded if a separate Autentication notification
PDU is sent to each recipient on the management network.


>25) Section 7.1, first para, the grammar is broken here.

I split it into two sentences now, I think the result is clearer:

In the past few years of output from standards organizations and
networking vendor marketing departments, the term 'policy' has been
heavily used, touted, and contorted in meaning.  The result is that
the true meaning of 'policy' is unclear without greater qualification
where it is used.



>26) Section 7 in whole seems too wordy for what it's saying.

It's been the result of enormous horsetrading and exact sentence reshaping 
over the last year.  It says, in fact, a whole lot imho.  It is balancing, 
or attempting to, the interests of people for whom "policy-based 
configuration" is completely unknown before they sit down with this, and 
those who are very specific about this discussion trodding on the toes of 
other IETF initiatives.  You might think the mention of template objects is 
overdone and obvious--it in fact is not based upon other feedback I've 
gotten on this document which has been published to the list.  Specific 
issues about scheduling, notification issuance, and scalability of 
management data are discussed.  The example of the VLAN has been challenged 
and defended on multiple occasions. :)

Nothing's sacred, I'll consider anything, but without more specific 
examples, I'd like to keep the, possibly overly specific, nature of this 
prose intact.


>27) Section 8 - example MIB. This MIB is an example of how
>     not to write a MIB module!

I think you have to remember--this is an *example MIB*.  While we don't 
want to have anything truly stupid in here, bogging this down in 
operational details of the presumed agent implementation misses the 
point--there are several design techniques (and management app interaction 
techniques which follow), which are the point of this.  This isn't actually 
something we did under contract for the Carrier HVAC people. :)

That being said, we don't want to reflect substandard principles.  Bert and 
Dave Partain have been all over this module, and let me address your points 
as best I can (as I assume this was a summary comment)...


>28) MIB module, the value of the LAST-UPDATED and REVISION
>     clauses don't match. There is at least one REVISION
>     clause that is missing (and possibly a second). There
>     needs to be a REVISION clause that specifies when the
>     module was created. And there may be a REVISION clause
>     missing for the last update.

You are correct in the mismatch, good catch.  I just scanned roughly a 
dozen MIB module documents in the NM area, and they are currently, upon 
readiness of submission to the IESG, codified as (where they even have a 
REVISION clause, which the other MIB module from this wg does not, and it's 
a real MIB and such:):

REVISION        "xxxxxxxxxx"
DESCRIPTION     "Initial version of the MIB, published as RFC xxxx". <sic>

Do you really want the back and forth of the working group review of this 
*EXAMPLE* MIB module cluttering up the document?  So, I've at least made 
them match.


>29a) MIB module, TC HvacOperation. This TC to be consistent
>      with the descriptor in the MIB module maybe should have
>      been named BldgHvacOperation.
>   b) It is strange that there is not the enum value 'off(3)'.
>      And there might need to be a value of 'fanOnly(4)'.

a) is OK.  b) actually raises a bigger issue of how one would set up a 
bldgHVACCfgTemplateTable which says "turn the hvac off!", for example, to 
be scheduled on weekends. This would not be in the (now renamed) 
BldgHvacOperation TC, I'd think, since this is only affirmative actions on 
the HVAC itself.  We'd rather not open this pandora's box of possible other 
valuable enumerations, since it detracts from the point of the MIB and just 
exposes nerdy points about HVAC (a subject which at least I am, admittedly, 
an appalling neophyte. :)

>30) MIB module, object bldgHVACTable. Yes this is a example
>      MIB module, but the text of the DESCRIPTION that
>      describes to the reader about what is being done
>      should be removed and moved to an ASN.1 comment.
>      This is similar to showing an example C program
>      that contains the line like:
>          i++;
>      The comment for the line SHOULD NOT be "/* increment i */",
>      but should tell why this is being done.
>      There are several conventions for specifying what information
>      is in the DESCRIPTION clauses for tables and rows. One
>      of the best is that the table contains the following
>      information:
>         1) a general description of the table
>         2) a description of the relationship to the number of
>            rows in the table with physical or logical items.
>         3) a description of the relationship, if any, to
>            other tables.
>      For rows, the DESCRIPTION contains the following
>      information:
>         1) a simple description of the table, like
>            "A row in the table of ...."
>         2) a statement that specifies whether or not rows can
>            be created and/or deleted via direct operations
>            to the table, and if so, then name of RowStatus
>            object (or for pre-RowStatus tables, then a description
>            of what is needed for creation/deletion). For
>            example, the DESCRIPTION may contain text like
>            "Creation and deletion are allowed via SNMP
>            operations controled by object xxxRowStatus"

Hmmm...OK, I think I get the idea of what you want in, what you want out, 
and what you want shifted from the row description to the table 
description.  Here's what I have for the table now:

    bldgHVACTable    OBJECT-TYPE
            SYNTAX      SEQUENCE OF BldgHVACEntry
            MAX-ACCESS  not-accessible
            STATUS      current
            DESCRIPTION
             "This table is the representation and data control
            for building HVAC by each individual office.
            The table has rows for, and is indexed by a specific
            floor and office number. Each such row includes
            HVAC statistical and current status information for
            the associated office. The row also contains a
            bldgHVACCfgTemplate columnar object that relates the
            bldgHVACTable row to a row in the bldgHVACCfgTemplateTable.
            If this value is nonzero, then the instance in the row
            that has a value for how the HVAC has been configured
            in the associated template (bldgHVACCfgTeplateTable row).
            Hence, the bldgHVACCfgTeplateTable row contains the
            specific configuration values for the offices as described
            in this table."
        ::= { bldgHVACObjects 1 }

and for the row:

            DESCRIPTION
            "A row in the bldgHVACTable.  Each row represents a particular
            office in the building, qualified by its floor and office
            number.  A given row instance can be created or deleted by
            set operations  upon its bldgHVACStatus columnar
            object instance."

N.B.: identification of required objects (or lack thereof) are specified in 
the CREATION-REQUIRES, and semantics of whether things can be set on an 
active row instance are specfied in the RowStatus DESCRIPTION, per 
RowStatus TC usage and sage advice given elsewhere in the BCP.

>31) MIB module. There are formatting problems that result in
>     text of the DESCRIPTION clauses to not be indented
>     appropriately.

I've ruthlessly gone through setting the MIB "tab stops" at 5, 9, and 
13.  Let me know if you think I missed any.

>32a) MIB module, object bldgHVACCfgTemplatePtr. It is not clear
>      why RowPointer is used instead of Unsigned32 (cloning the
>      data type of the index). The DESCRIPTION text is not
>      clear in what it is trying to say.
>   b) last paragraph in DESCRIPTION seems bogus

I'm not sure there's a reason *not* to use RowPointer.  I generally prefer 
to use it since it means that references to a row in a table don't have to 
change or be deprecated if the indexing scheme for the destination table 
changes.  FWIW, in prior commentary, Bert W. encouraged us to move all of 
our row references cross-table to be RowPointers.

OTOH, since I've pointed out that this *is* a sample MIB and doesn't need 
to undergo future development (if you buy my comment) I'll change this to 
just clone bldgHVACCfgTemplateIndex.

I've removed the last paragraph, since I think the notion of "discovering" 
rooms is something that Jon was interested in exposing at one point, and to 
mention it here clearly means some supporting documentation about that 
procedure would have to be provided.  I've added another one describing 
what zero *really* means here (per the example section provided at the end).
>
>33a) MIB module, object bldgHVACFanSpeed. This object assumes
>      that the speed can always be determined. It doesn't allow
>      for cases when it cannot.
>   b) The last sentence in the DESCRIPTION is redundant with
>      the UNITS clause.

But the point is that you can, imagine that this is a sample MIB (if we 
were really to attempt to take on the case you mention, it would be the tip 
of the iceberg of a set of error cases we'd need industrial-strength 
handling and notification of).  I'll update the DESCRIPTION to have more 
information...I think the unusual "revolutions per minute" UNITS needs some 
notation here.

>34) MIB module, object bldgHVACCurrentTemp. The lower range
>     only 0 degrees celcius. So can't get below freezing?
>     This is not too realistic.

It's fine by me, and completely realistic.  My residential heating control 
doesn't go beneath '50' in the fahrenheit display, much less 
freezing.  HVAC units simply aren't set up to display and manage 
temperatures chillier than that, unless it's an industrial meat locker or 
the studio where the David Letterman show is taped. :)

Tell you what, we'll put a comment that if the temperature should be 
beneath freezing, that the result will be the lowest possible 
setting.  Again, this is meant to be a sample MIB module reflecting 
comfortably well-known management notions within a familiar territory, not 
a MIB for controlling external temperature sensors on the space shuttle 
that we're submitting in a RFP to NASA.


>35) MIB module, object bldgHVACoolOrHeatMins. This is a counter,
>     but no discontinuity object specified! Not sure that this
>     is a useful object. It would be much more useful to have
>     a total coolMins, total heatMins, a startTime, and value
>     at startTime.

If you'll note in the description:

     If the system is re-initialized from a cooling to heating function
     or vice versa, then the counter would start over again.

What this means to us is that separate heating and cooling objects are not 
really needed.

That being said, we do see the value of a discontinuity object.  Check this 
out.

     bldgHVACDiscontinuityTime OBJECT-TYPE
         SYNTAX      TimeStamp
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The value of sysUpTime on the most recent occasion at which
             any heating or cooling operation for the office designated
              by this row instance experienced a discontinuity.  If
             no such discontinuities have occurred since the last re-
             initialization of the this row, then this object contains a
              zero value."
         ::= { bldgHVACEntry 7 }

>36) MIB module, object bldHVACOwner. This is completely BOGUS
>     and a perversion of the RMON's OwnerStrings.

It's only a SnmpAdminString...none of the authors or other consulted 
experts in the art can figure out your umbrage at this technique.  AND, 
it's called out in Sec. 3.12 of the -09 draft as a good thing.

Unless you can provide a convincing argument, with examples, of where this 
is forbidden that is more than subjective opinion, it stays.

>37) MIB module, object +. The RowStatus TC has
>     requirements of what must be specified in the DESCRIPTION
>     clause. These requirements are not met.

Point taken.  I've addressed this by spelling out that no columnar object 
in the bldgHVACTable entry can be modified while bldgHVACTable is active.

>38) MIB module. Table and row for TemplateInfo. DESCRIPTION
>     clause need to be fixed.

Per point 30 you mean?  Offenses here to the objections you raise there 
seem even more subtle, but I updated to be equally compliant, or offensive, 
depending on your point of view :):

     bldgHVACCfgTemplateInfoTable  OBJECT-TYPE
         SYNTAX      SEQUENCE OF BldgHVACCfgTemplateInfoEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "This table provides unique string identification for
             HVAC templates in a network. If it were necessary to
             configure rooms to deliver a particular quality of climate
             control with regard to cooling or heating, the index string
             of a row in this table could be the template name.
             The bldgHVACCfgCfgTemplateInfoDescription
             contains a brief description of the template service objective
             such as: provides summer cooling settings for executive
             offices. The bldgHVACCfgTemplateInfo in the
             bldgHVACCfgTemplateTable will contain the pointer to the
             relevant row in this table if it is intended that items
             that point to a row in the bldgHVACCfgTemplateInfoTable be
             identifiable as being under template control though this
             mechanism."
         ::= { bldgHVACObjects 2 }

     bldgHVACCfgTemplateInfoEntry  OBJECT-TYPE
         SYNTAX       BldgHVACCfgTemplateInfoEntry
         MAX-ACCESS   not-accessible
         STATUS       current
         DESCRIPTION
             "Each row represents a particular template and
             description.  A given row instance can be created or
             deleted by set operations upon its
             bldgHVACCfgTemplateInfoStatus columnar object
             instance."
         INDEX { bldgHVACCfgTemplateInfoIndex }
         ::= { bldgHVACCfgTemplateInfoTable 1 }

>
>39) MIB module. Object bldgHAVACCfgTemplateInfoId. Couldn't
>     figure why this is needed.

The Example provided is pretty clear, but I'll add some text to describe it 
(that this is to be meaningful to the HVAC administrator as to the unique 
scope of applicability for the associated template, e.g., "Executive 
offices", "Lobby areas", etc.)

>
>40) MIB module, Object bldgHVACCfgTemplateInfoOwner. DESCRIPTION
>     is bogus.

And that's because...?  This is a SnmpAdminString, it doesn't need 
significant usage overhead.  If I'm missing your rather tersely stated 
objection to this, please restate it.

>41) MIB module, Object bldgHVACCfgTemplateInfoStatus.
>     RowStatus problem.

Right.  I assume you mean the need to specify whether things can be 
modified in the active state again, per RFC 2579.  Done, as in (29).


>42) MIB module. Table and Row TemplateTable. Same problem with
>     DESCRIPION.

I'll address this, if you want something similar to (30) and (37)).

>43) MIB module. Object bldgHVACCfgTemplateTable. The DESCRIPTION
>     contains "[34]", which is not allowed. A useful name is
>     needed for the reference, since once the MIB module
>     is extracted from the MIB module, then what "[34]" refers
>     to will be lost.

It's outta there anyways...this was an obsolete reference.

>44) MIB module. Objects bldgHVACCfgTemplateDesiredTemp,
>     bldgHVACCfgTemplateCoolOrHeat, and
>     bldgHVACCfgTemplateInfoPtr. When they can be modified
>     MUST be specified in the RowStatus object.

Done

>45) MIB module. Objects bldgHVACCfgTemplateOwner and
>     bldgHVACCfgTemplateStorage. Same comments as similar objects.

You've discussed an owner object previously by saying you didn't understand 
its usefulness and we've slightly tweaked the description 
accordingly.  You've not discussed a storage object to date.       Do you 
instead mean *bldgHVACCfgTemplateStatus* and the fact that you'd like to 
see a RFC 2579-proscribed comment about columnar object 
modifiability?  Thought you did, it's done. :)


>46) Section 8.2, first sentence. Change "sample" to "example".

done.


>-- that's all
>
>Regards,
>/david t. perkins