FW: Additional comments on: draft-aromanov-snmp-hiqa-04.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

FYI, this is what I sent to RFC_Editor.
I included Russ' comment as well. Russ, if you want I
can send a follow up to give you credit.

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: dinsdag 3 juni 2003 17:29
To: Rfc-Editor (E-mail)
Cc: Bert Wijnen (E-mail)
Subject: Additional comments on: draft-aromanov-snmp-hiqa-04.txt


RFC-Editor, the IESG has send you (or will do so shortly) a formal
response on this document in a separate email. 

Since I did check this doc in some more detail, I have additional
comment for you to consider. These come as personal comments, not
as IESG-consensus comments. It is up to you to handle them as you
see fit.


- Change the title from
     Developing High Quality SNMP Agents
  into something aka:
     Considerations for SNMP agent developers
  or even better:
     A. Romanov's Considerations for SNMP agent developers
  Justification:
  - the doc itself is (in my view) not high quality itself.
  - the doc discussus only a small part of the whole problem
    space and misses many tricky things in SNMP agent development
  - one needs to be an SNMP expert to understand what is
    being described.
- Change the "recommendations", i.e.
  - The author often speaks like "It is recommended", where
    it seems to make more sense to say "I recommend"
- References need to be made to the new SNMP STD documents (that
  is in the 341x range instead of 257x range). I understand that
  those were not yet RFCs when the I-D was submitted to RFC-Editor.
- Instead of talking about an "index string", I strongly recommend
  to talk about an "index sequence". Otherwise people too easily
  think about an ascii representation of OID components in the
  dotted notation, and the author means an array (or sequence) of
  unsigned integers that represent OID components (or sub-IDs).
- Same for "string of Object Identifiers" 
- In many places, when the author talks about "OID" he really means
  an OID component (i.e. one unsigned integer instead of a 
  sequence of unsigned integers).
- Bullet 3 on page 4 and 5. Strongly recommend to move the 1st
  sentence of the last para (i.e. 
       This OID range checking must start at the end of index string and
       progress towards its beginning. 
  to the beginning of bullet 3. Otherwise it is impossible to
  understand what the steps mean.
- I suggest that the author explains what he means by non-implied
  and explains that it is about INDEX objects that have the keyword
  IMPLIED associated with it. So it would then also be better to
  us non-IMPLIED instead of "non-implied".
- The security considerations section includes the following text:
      It is recommended to strictly follow design recommendation (1) in the
      previous section in order to eliminate vulnerabilities associated
      with the denial of service attacks exploiting replay windows.
   However, the previous section is about Intellectual Property.  It does 
   not contain a (1).  I assume that this is a reference to the
   recommendation to use a "low priority thread."  A much cleaner
   reference is needed.

By no means is this a detailed/extensive review. These are things I 
cam across when checking if the doc has conflicts with any IETF stds
track documents.

Thanks,
Bert