Subject: Re: snmpconf Comments on BCP-09

From: "Wayne F. Tackabury" <[email-masked]>
Date: Thu, 01 Aug 2002 16:11:37 -0400

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

---

From: Dave Shield <[email-masked]>
Date: Fri, 02 Aug 2002 10:10:24 +0100

A couple of grammatical typos that I spotted in the new text:

> >     security warning....
>    ......  Here it is (paragraph 2 of the section has turned into two 
> paragraphs now):
> 
>                                            ...... When notifications are
> or more trap PDUs to be created......                     ^^^^^^^^^^
                                                            "can cause"
                   vv
>       .........  If it is bad enough that the system is having to

Extraneous "If".

> >35) MIB module, object bldgHVACoolOrHeatMins.
>              initialization of the this row,....
                                 ^^^^^^^^
                               just "this"

> >6a) In section 3.3.1 ....

> The section now reads as follows....:

>    2)                      ........... *Restricting instance
>       set to active(1) is in fact a reasonable limitation,...

This doesn't make sense (even in full).
Is there something missing after "set to active(1)" ?
Or perhaps it should read something like:

   "Restricting instance modifiability after a RowStatus object is
    set to active(1) is in fact a reasonable limitation...."

But the "like this, so that" clause throws things off somewhat.

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

And a couple of "understandability comments" from a lurker.
These may be unnecessary, or too late - so feel free to ignore them.

Still with the
> >6a) In section 3.3.1 ....
                                stuff

> in a conceptual row, a description must define what can be modified.
                       ^^^^^^^^^^^^^

Is it worth specifying which description this should come in?
i.e. "the RowStatus object description must define...."

Because this could potentially be the description of the table, of the
row entry, of the writeable column object, or the RowStatus object.
(Unless the MIB designer has read the details of the RowStatus description
very carefully).
  I know you mention the later, after the example - but that's a little
way further on (and currently on the next page) so is easy to miss.

Also it's easy to misunderstand the two "wrong assumptions" being described
here as being discussions of "wrong implementation approaches" (i.e. the
exact opposite of what is intended).   Particularly with the discussion
of the second case as being a reasonable limitation - this detracts from
the fundamental point that this is an optional limitation, rather than
a mandatory requirement.
  This might be a bit clearer if the discussion of why you might want
to do this was detached from the basic "wrong assumption" description.
I.e:

>   ..... it is often wrongly assumed in some implementations
> that:
> 
>       RowStatus object is active(1).

  " Both of these are reasonable limitations, but need not necessarily
  hold true.  For example, a set of RowStatus may have agent system
  side-effects which depend on committed columnar object instance values,
  so restricting instance modifiability after a RowStatus object is
  set to active(1) may be appropriate.
    However, where this restriction exists...."

> >28) MIB module,                               .... There

> *EXAMPLE* MIB module cluttering up the document?

It might be worth having "initial" and "first review" revision log entries,
in order to show the effect of a single revision cycle.  Anything more
would probably be unnecessary, but the fact that the original example
contained a mismatch between LAST-UPDATED and the (sole) REVISION datestamp
shows that even experienced MIB designers can get this wrong.

Dave

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Aug 2002 18:23:13 -0700

At 01:11 PM 8/1/2002, Wayne F. Tackabury wrote:
>>...
>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:
>

This practice is problematic. The 128 sub-OID limit is an arbitrary
rule that was added to SMIv2.  The SMIng WG is likely to change the
limit to 256 sub-OIDs in SMIv3. (I think there should be no limit,
or a limit of 65535 subOIDs!) It was placed there with the assumption 
that SNMP PDUs (over UDP) were <= 484 octets in length.  It was
placed there without much forethought and before it was fashionable
to use strings in an INDEX clause.

The current practice of creating an arbitrary SIZE clause that allows
for (128 - static_oid_length - 1) sub-OIDs is going to cause more
problems over time than it solves.  There is absolutely no "protocol sense"
to the limit of 128.  When it changes to a larger number in the
near future, all MIBs that artificially conform to this limit will be 
obsolete, and will need to be updated. 

>>....

Andy

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 05 Aug 2002 09:41:18 -0700

HI,

It looks like you have done much work and that is to be commended.
I'll look over the updated document today and send in comments.
If you don't hear from me by the end of the day, don't assume I
don't have any comments, but instead assume that I have too many
comments to write and send you by the end of the day. (I hope that
the later is not the situation.)

At 04:11 PM 8/1/2002 -0400, Wayne F. Tackabury wrote:
>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.
...<and the rest cut>...

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 05 Aug 2002 10:46:36 -0700

HI,

I did a quick scan of you message summarizing the changes. There is
no way I can complete a review of the document by end of day and
provide you with useful comments.

There are a few concepts where we are way apart. If this was
not a BCP, we could just "agree to disagree" and move on.

I'm not sure how to proceed. What do you suggest?

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Mon, 05 Aug 2002 14:53:19 -0400

>not a BCP, we could just "agree to disagree" and move on.

Well, not speaking to that here, but in the "glass may be half full" spirit...

A lot of your comments were about things you'd like to see in the 
MIB.  Aside from some things (only one point that really ended up being in 
your enumerated list as I recall) which we responded to with "this isn't a 
real HVAC MIB, but is used to demonstrate certain principles, so don't 
worry about it", we *attempted* to address all of them as I recall to a 
greater or lesser degree.  If we fell short of any there (for example, a 
different text you wanted to see on table and row objects in the 
DESCRIPTION clause comes to mind), maybe we can just get more 
clarification?  There wasn't anything we *objected* to including in those 
edits, maybe we just missed the mark and need to re-aim?

Of the non-MIB stuff, there were maybe five things (not looking at the 
list) that we did a "thanks, but no thanks" on in addressing the item in 
your list.  Now, only two of them *that I recall* (I'm in a bit of a hurry 
here, my numbers could be wrong) were substantial, the main one being that 
in general, you don't find INFORM REQUESTs that useful (forgive me if I'm 
characterizing it too strongly).  Given the experience of the authors, we 
may need a higher ruling on that one. The other was about authentication 
traps, and we actually emboldened our point to give it more credibility (by 
looking at it from another angle).

Unless I'm all wet because you have a variety of new issues here.  In any 
event, any wg chairs in the listening audience care to chime in here?

Regards,
Wayne

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 05 Aug 2002 17:43:47 -0700

HI,

I appreciate you working on trying to find common ground.

Here are the concepts that I don't believe that the BCP
expresses correctly:
1) scaling - when the number of ports was 2 per box then poorly
   designed MIBs, SNMP agents, and/or management apps didn't cause
   too much of a problem. When it increased to 10-50 per box,
   things got sluggish. Now with some boxes having 100s of
   ports, then bad designs and practices result is a non-workable
   approach. And with virtual stuff layered on top of the
   physical, there can be many tables where there or 100s
   and maybe 1000s or instances.
2) configuration persistence (and StorageType) - the point is that
   managing persistence of configuration is very system specific,
   and that the StorageType model doesn't fit reality. Don't
   encourage a MIB design pattern that is not workable.
3) notification terminology - it seems like almost everybody gets
   this messed up. And I'll tell you, until I wrote the "Understanding
   SNMP MIBs" book, I was just as confused (and/or sloppy) as
   everyone else. The document really doesn't read as if
   the document authors got it all worked out before starting.
   The result, even with some corrections incorporated, is
   less than desirable.
4) Section 3.10.2 is still factually incorrect, and paragraph
   3 is still majorly factually incorrect. The following statement
   "InformRequest PDUs. when compared to TRAP PDUs, have an
   inherent advantage when the concern is the reduction of
   unnecessary from the system generating NOTIFICATION-TYPE
   data, when in fact retransmission, of this data is required."
   and the remainder of the paragraph mashes together two
   separate issues, resulting is nonsense. The title of the
   section is "Limiting unnecessary transmissions of notifications".
   In this category, I would expect to see the MIB design
   issue of designing notifications (using the NOTIFICATION-TYPE
   construct) so that one notification can be sent to report
   on many events, and to dampen the reporting of events
   due to a flapping situation (a hysterics mechanism such as
   that found in RMON). Instead, a side trip is made into the
   separate issue of using Informs vs Traps.
5) Designing management apps that use sets - the SNMP protocol is
   not designed to return "semantic" (that is, application layer)
   errors to a management application. This results in a tight
   coupling between the semantic knowledge that must be understood
   by a management application designer. This requires that
   management applications be designed so that "sets never fail".
   Because if they do fail, a management app cannot determine
   via SNMP why the set failed. MIB designers can lessen the
   burden on management apps designers (and agent designers)
   so "sets never fail", except under well defined situations
   or when memory resources on a managed system are at total
   exhaustion. Section 3.11, covers this aspect of management
   application design. Unfortunately, a sentence in the second
   paragraph uses the term "incumbent", which means "duty" or
   "obligation". Management apps have no such duty. The cause
   and effect and the resulting actions needed to be taken
   to counter the effect are not correctly distinguished and
   assigned.
6) Fine grained access control assignment - a desirable property
   is to allow management apps to create resource instances
   via an SNMP set, and to gain "exclusive" or "owner" access
   as found in file creation operations found in many operating
   systems, such as the Unix variants. However, the VACM-based
   access control is VERY different than Unix-like file access
   control. A design pattern was introduced in the MIB modules
   from the DISMAN WG which attempted to mimic the Unix-like
   access control behavior on creation. This design pattern
   is flawed (and many have not yet realized it). Please
   describe the objective, show the MIB design pattern and
   describe how it is flawed. (Note that another design pattern
   to give fined grained access control is found in table
   usmUserTable in RFC 2574.) The pluses and minuses of
   the design pattern used there should be pointed out.
   Finally, an improved MIB design pattern should be presented.
7) Usage of OwnerString - the advantages and disadvantages of
   the OwnerString TC should be described without muddling with
   other concepts.
8) SNMPv3 Contexts - section 3.13.2 totaly misses the point about
   contexts, which is that contexts in most, if not all cases, are 
   the result of the "failure by a MIB designer to correctly predict
   the future". Contexts are "an escape mechanism to add another
   level of indexing". The entity logical table was not really
   designed to support context discovery. And it is not required.
   Note that the last sentence of section 3.13.2 is factually
   incorrect in its assertion that context are administratively
   established.
9) the problems with the description of authentication notification.
   First, it is specified to be in RFC 1215, and implied to be used
   in only SNMPv1. The current definition of the authentication
   notification is found in RFC 1907. And it is generated when
   SNMPv1, SNMPv2, and SNMPv3 (with USM) result in authentication
   failures. Now, it is the case that the notification was not well
   designed, and in some deployments due to improper agent design,
   and/or poor choice of security configurations, that its generation
   should be turned off. This section should explain each of these
   factors instead of repeating the herd mentality of "always
   turn of generation". If the notification is not turned on,
   then the objects snmpInBadCommunyUses, usmStatsUnknownUserNames,
   usmStatsNotInTimeWindows, and usmStatsWrongDigests must be
   monitored to determine authentication failures.

Sorry, but I don't have more time for feedback today. There are lots
of words that I could say about the fallacy of believing in the
reliable delivery of notifications.

Regards,
/david t. perkins

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 5 Aug 2002 18:52:51 -0700

On Mon, Aug 05, 2002 at 05:43:47PM -0700, David T. Perkins wrote:
>   failures. 

Ok we should fix that.

>   Now, it is the case that the notification was not well
>   should be turned off.

Even with proper agent design, and reasonable security
configurations this notification is flawed.

>   This section should explain each of these
>   turn off generation". 

Sorry there isn't a reasonable network left in existance 
where turning it on makes sense to me unless you can turn 
back time to say 1980.

>   If the notification is not turned on,

Yes, we should add that one should poll these objects instead.

The notification authenticationFailure is flawed for the simple
reason it is sent *ONCE* per invalid pdu. Since most networks are
designed with n notification senders and m notification 
receivers, n tends to be much bigger than m. notification senders 
are often optimized to send packets faster than general purpose
systems hosting notification receivers.

Hence if one wishes to bowl over a network management system, 
one simply starts sending improper authenticated packets with spoofed
source addresses. If a firewall is in the way, then first 
compromise some host on the inside and repeat. 

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 06 Aug 2002 01:00:28 -0700

HI,

It's surprising that there is so much agreement in the below. One
would think that we work together or something.
>where turning it on makes sense to me unless you can turn 
Warning! Time-space continuum violation.

>compromise some host on the inside and repeat. 
Sometimes when we agree with the resulting action, there is a
disagreement with the reason. Why, because learning a lesson
is more important than a single solution. So, the problem, AGAIN,
with the BCP is the repeated reason (which is incorrect).
So, Mike, do you want to describe the dampening algorithm that
should be used, or do you want me to describe it?

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Aug 2002 11:13:48 +0200

>>>>> David T Perkins writes:

David> 6) David> Fine grained access control assignment - a desirable
David> property is to allow management apps to create resource
David> instances via an SNMP set, and to gain "exclusive" or "owner"
David> access as found in file creation operations found in many
David> operating systems, such as the Unix variants. However, the
David> VACM-based access control is VERY different than Unix-like file
David> access control. A design pattern was introduced in the MIB
David> modules from the DISMAN WG which attempted to mimic the
David> Unix-like access control behavior on creation. This design
David> pattern is flawed (and many have not yet realized it). Please
David> describe the objective, show the MIB design pattern and
David> describe how it is flawed.

Can you please send a message to the DISMAN WG list which explains why
the design pattern is flawed so that we can all understand the issue
and either fix it or at least document it somewhere?

Thanks,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>