AD review: draft-ietf-snmpconf-pm-13.txt

["Wijnen, Bert (Bert)" <bwijnen@xxxxxxxxxx>]

I am kind of ready to request an IETF Last Call for PS.

However, I still see these issues/concerns, and so it
might be better to fix them first. I know that IANA for
example looks at IETF Last Calls and will come up with
my issue on IANA Considerations below.

So here we go:

- Not sure if the Index entries that can go over 128 subids
  are documented completely in accordance with our
    draft-ietf-ops-mib-review-guidelines-01.txt 
  document. I have asked Mike Heard to check. 
- The secuirty considerations potentially has these issues
  - It does not clearly describe which object or which tables
    are sensitive and WHY. The security ADs (I am pretty sure) 
    will be looking for that, and I think rightfully so.
  - You refer to RFC3231 for the security mechanisms used.
    I think that what is done here is conceptually indeed the
    same, but the actual implementation is a tidbit different.
    I have to wonder if non-MIB experts and non VACM experts
    can easily understand it with pointing back to 3231. And
    the security ADs may be the first ones to complain.
    I suggest that it may be much better if you took the text
    from 3231 and adapted it to describe exactly what the
    mechanisms are in this MIB module.
- In the references (normative) I see [5], [6], [7], [8], and
  [9], [11], [12],  [19], 
  which I cannot find any citations for... 
  Probably left over from old MIB boilerplate
  I think they can be removed.
- Reference [14] is also not cited, but probably should be cited
  somewhere in sect 8
- Sect 8.3.16
       utf8Output. The stringprep profile used is specified below in
       Section XXX. If sucessful, the function returns 1.
  Pls fill in XXX (I think it is 9)
- Inside DESCRIPTION clauses on the MIB module I see things like
  for example: RFC3454 [16].
  The citation gets lost when the MIB module is extracted, and the
  RFC number seems sufficient. So I would propose to remove any
  citations within DESCRIPTION (or REFERENCE) clauses.
- I see no IANA considerations section, and I think you need to
  instruct IANA to register the Stringprep Profile.
- Page 98/99 says:
         3) OIDs that represent one or a collection of capabilities
         which could be any collection of MIB Objects or hardware or
         software functions may be created in working groups and
         registered with IANA. Other entities (e.g., vendors) may also
         make registrations. Software will register these standard
         capability OIDs as well as vendor specific OIDs.
  If you keep that, then I suspect we need to add in IANA Considerations
  section how/what IANA needs to do or not do. And under which conditions
  such registrations can be done. See RFC2434 for guidelines.
- I am still bothered by your UTF8String. You had explained why you 
  had done it and want to keep it. So I will accept that the WG agrees
  with that. But the UTF8String is only different in case from Utf8String
  as in RFC2287. I do not think that this is wise. So if you do want to
  keep it, I'd like to see the name changed. Is it only meant for the
  Policy MMIB and or related MIBs? Then maybe PmUTF8String makes more sense

Thanks,
Bert