Subject: snmpconf Final call for input for bcp

From: Mike MacFaden <[email-masked]>
Date: Fri, 02 Feb 2001 12:26:56 -0800

Hi,

I'm making a final call here for input to the BCP.
A final version will be submitted at IETF 50 in March.

Regards,
Mike MacFaden
www.riverstonenet.com

---

From: Wes Hardaker <[email-masked]>
Date: 07 Feb 2001 14:48:27 -0800

>>>>> On Fri, 02 Feb 2001 12:26:56 -0800, Mike MacFaden <[email-masked]> 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.
However:

1) section 5.1.1.4, 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
   reboots".

   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 5.1.2.2 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 5.1.2.4, first sentence "minde" -> "mind"

5) section 5.1.3.2 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:

                 noSuchInstance:
                 the `noSuchInstance' exception tells the management
                 station that it should supply a value for this column
                 when the conceptual row is to be created.

   and

                 noSuchObject:
                 As such, the management station can not issue any
                 management protocol set operations to create an
                 instance of this column.

6) section 5.1.5.1 mentions snmpv1 read-only community strings but
   should probably say "SNMPv1 or SNMPv2c"

7) Section 5.1.5.3 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
   across.

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"
          or
       "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
    complete.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Jon Saperia <[email-masked]>
Date: Thu, 08 Feb 2001 16:36:11 -0500

> times so I know I've missed a couple of things I wanted to mention.

Wes, thanks for all the great comments. We continue to work on the
document and will work to include your points. 

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/