[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Final call for input for bcp
>>>>> On Fri, 02 Feb 2001 12:26:56 -0800, Mike MacFaden <firstname.lastname@example.org> said:
Mike> I'm making a final call here for input to the BCP.
Mike> A final version will be submitted at IETF 50 in March.
Coincidentally, I just finished reading it.
First off let me state that I think its an excellent document and I'm
glad its been written so I can point people at it. It's been needed
for a long time.
Unfortunately, I didn't have a pen with me when I was reading it at
times so I know I've missed a couple of things I wanted to mention.
1) section 184.108.40.206, 2nd paragraph, 2nd sentence begins with "textual
The first". "textual" needs to be deleted.
2) later in that same section:
Best current practice in internet deployed network elements is a dual
persistence model where: 1) a volatile memory configuration can
be retrieved/updated and 2) persistent boot configuration.
If you read this, its an incomplete sentence structure. #2 needs
to be reworded/extended to something like "2) A persistent
configuration can be used to store information across device
A second solution would be to change it to "where devices contain:
1) a volatile memory configuration which can be retrieved/updated
and 2) a persistent configuration that survives device reboots.
3) Section 220.127.116.11 describes problems arise when polling a garage
door. It would be good to specify a solution in between the last
two paragraphs of the section. Something like "A better solution
to this particular problem would be to define an
acmePortGarageDoorState object to be used for polling, and an
acmePortGarageDoorControl object that can be used to issues requsts
to change the state of the door. The acmePortGarageDoorState could
then include new enum values such as "closing(3)" and "opening(4)"
to actively reflect the true state of the door.
4) Section 18.104.22.168, first sentence "minde" -> "mind"
5) section 22.214.171.124 says to return a noSuchName exception if an object
doesn't exist, but I think a noSuchInstance exception is the proper
choice here. To quote from RFC1903:
the `noSuchInstance' exception tells the management
station that it should supply a value for this column
when the conceptual row is to be created.
As such, the management station can not issue any
management protocol set operations to create an
instance of this column.
6) section 126.96.36.199 mentions snmpv1 read-only community strings but
should probably say "SNMPv1 or SNMPv2c"
7) Section 188.8.131.52 could probably use something like the following
added to it:
Even if a device does support DES, it should be noted that
configuration of other keys via SNMP SETs protected by DES should
not be allowed if the other keys are longer than the 56 bit DES
keys protecting the SNMP transmission.
8) section 5.2.2 probably should discuss SET error handling, if your
going to recommend the conglomeration of as many configuration
directives as possible into a single SET. You should probably
mention that not all implementations support multiple varbinds in a
SET very well and management applications will have to take into
account these types of problems.
9) The 3rd paragraph of section 6.1 starting with "The policy
configuration software..." is hard to understand, or at least it
was for me. I can't offer a rewrite of it, as I'm still not
convinced I perfectly understand the concepts you're trying to get
10) The last sentence of 6.1 says:
Policies should not be distributed to systems
that do not have the resources to carry out the policy for a
reasonable period of time.
I think "for a reasonable period of time" should be either:
"within a reasonable period of time"
"in a reasonable period of time"
11) Section 6.2: "if they intent" -> "if they intend"
12) section 6.3: you might suggest that mib authors make sure they use
the standard time TC, the name of which escapes me at the moment,
to help resolves these issues at the MIB definition level.
13) Section 6.4: You might want to start with a sentence that defines
"conflict detection and resolution" more explicitly.
14) section 8: "A finite group of changes that taken as" -> "A finite
group of changes that when taken as"
16) section 8: "before the set is returned should" -> "before the SET
is restored when". "returned" could lead someone astray that the
original values are returned in the response to the failed SET.
17) section 8: DOS doesn't happen just because inadvertent abuse of
"network layer" mechanisms. Other mechanisms (processing power,
memory consumption, eg) can be used to cause DOS problems.
18) section 10: add 3) "policy based management" section is not yet