[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AD review: draft-ietf-snmpconf-pm-13.txt
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
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 , , , , and
, , , ,
which I cannot find any citations for...
Probably left over from old MIB boilerplate
I think they can be removed.
- Reference  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 .
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