FW: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt

Is it just me who missed an announcement, or has no follow up occured?
WHy can we not keep momentum once we're moving?

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email protected]]
Sent: donderdag 28 augustus 2003 1:22
To: [email protected]
Subject: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt


We're getting close. Still afe nits.

- sect 2, first para seems to end with an incomplete sentence?

- sect 3 refers to RFC3512 as a BCP. Well, fist of all it is not
  good to talk too much about the maturity level of documents
  inside an RFC. that maturity level is an external label,
  that may change over the lifetime of an RFC.
  But in any case, way back when we decided to make RFC3512 an
  Informational RFC, and that is what it is.

- You have kept the PM-MIB as a normative reference. Based on the
  text, that still seems to make sense... but.. this means that this
  doc will be depending on the PM-MIB to be approved as PS as well.
  So if I bring this one ot IESG, and if we approve it, then it will
  hang in RFC-Editor queue till PM-MIB is ready for RFC as well.
  I can accept the way it is... just let me know if that is indeed
  what you wanted/intended.

- Security section. So do I understand there is no sensitivity to
  reading any of the objects in this MIB? If such is the case, it
  might be good to state so. Now you only talk about write access.

- If you're gonna rev once more anyway, then
   diffServConfigId OBJECT-TYPE
       SYNTAX         SnmpAdminString (SIZE(1..116))
       MAX-ACCESS     not-accessible
       STATUS         current
       DESCRIPTION
          "A unique id for the per-hop-behavior policy.  The range
          of up to 116 octets is chosen to stay within the SMI
          limit of 128 subidentifiers in an object identifier."
       ::= { diffServConfigEntry 1 }
  s/SMI/SNMP/, cause the SMI does not limit it, it is the SNMP PDU
  that does not allow for more than 128 subids in an OID in a
  varBind. I should have seen this last time.

- StorageType, I stated:
     But in any event, you need to say something about write 
     access for permanent entries. See the StorageTypeTC in RFC2579
  I see nothing about it. What I mean is some text in DESCRIPTION
  clause aka:
       Conceptual rows having the value 'permanent' need not
       allow write-access to any columnar objects in the row.
  if such is indeed the case.

- I do not see that you addressed:
  11. RowStatus
     Need to say which (if any) objects can be changed while a
     row is active. See RowStatus TC in RFC2579
  It may be as simple as
      All writable objects in this row may be modified at
      any time.
  If such is indeed the case.


Bert