[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