RE: Call for Reviewers: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-06.txt

["David B Harrington" <dbharrington@comcast.net>]

Hi,

I already commented on this draft to Sumanth, so I suppose I can do it
officially. My comments were not constrained by RFC4181 since it was
not a MIB Doctor review, but merely an individual reviewing a
document.

If anybody else is willing, I am certainly willing to let them do it,
since I am currently editing five drafts, co-chairing a WG, and doing
secdir reviews as well, so my time is really limited. I will note that
this document deals with events and some convergence of syslog and
snmp events, so it is highly topical for many MIB Doctors.

Here were my comments to Sumanth:

Hi Sumanth,

I was just taking a quick peek at some of the mibs being announced and
spotted the Cablelabs work.
I quickly noticed something that I recommend you fix, and while
looking further found some other things. 

It is something the IETF community has not done a good job of
educating people about, so it is somehwat common, but is likely to be
become more problematic in the future. Since Cablelabs is an important
standards-setting organization, I think it is important that DOCSIS
MIBs get this right.

Throughout the development of SNMP, there has always been the concept
of a separation between the pieces. There are three parts to the
"SNMP" suite, better referred to as the Internet-standard Management
Framework. Part 1 is the MIB - the data models. Part 2 is the protocol
- SNMP. And Part 3 is the SMI, which binds the protocol and the data
models.

The protocol is supposed to know nothing of what is being managed, and
the MIB is not supposed to know anything about the protocol being used
to carry its data. This will become more important as IETF management
"converges" toward reusable parts. MIB data is likely to be made
available to Netconf, syslog is likely to be carried over netconf, and
an SMIv3 may be developed that permits developing an information model
that can be used to generate both SMIv2 MIBs and XML data models.

So keeping the separation of MIB and protocol is fairly important.


Your document talks about the SNMP SMIv2. But SNMP and SMIv2 are
actually separate IETF standards.

The framework is actually the "Internet-standard Management
Framework", which says that the protocol is separate from the data
models, etc., and the current preferred protocol choice within the
Internet-Standard Managemt Framework happens to be SNMPv3.

Unless you meant to refer to the "architecture for describing SNMP
management frameworks" defined in RFC3411, but this is all about the
architecture of an agent and the elements of procedure of the
protocol, not about MIBs.

Note that there is boilerplate text that you can use for the abstract
and introduction that get this all done in the politically-correct
wording. I just published a template that might be helpful to you as
well. See draft-harrington-text-mib-doc-template-00.txt. If you work
in xml2rfc, I can also share an XML template I have been working on.

traps and informs are SMIv2 traps and informs, that typically get
processed by SNMP but in the future might be able to be processed by
netconf or other protocols. (Note that NOTIFICATION-TYPE is IMPORTed
from SNMPv2-SMI, so even we get this worng sometimes ;-)

It is bad practice to create dependencies on the protocol within the
MIB. So pktcDevEvSyslogAddressType  should not talk about what SNMP
error should be generated. If you design the MIB correctly, the SNMP
will return the appropriate error code. I am not sure that "wrong
value" would be the correct error message in the case cited either.
You do NOT want equipment vendors to have to change their SNMP stack
to support a specific MIB module's choice of error codes, and you do
not want NMSs to have to know what MIB they are looking at to know how
to interpret the error code received.

Be very careful about creating dependencies in the Description of an
object. If you change the description in  a manner that would make a
compliant agent non-compliant, (i.e. if you change the semantics), you
will need to obsolete the object and define a new object with a
different name and OID in order to do an update to the object. You
really want to asvoid that situation. So objects that talk explicitly
About snmp and syslog might be difficult if you later want to add
support for netconf events or other event types.

Note that snmp trap may be problematic. An smiv1 trap difffers in some
ways from an smiv2 trap, and you don't that to trip you up in the
future.

EventDescrText is an snmpAdminString that contains a "display string".
The SMIv1 DisplayString differs from the SMIv2 snmpAdminString in some
ways. Be sure implementors do not mistake the requirements of the
snmpAdminString type vs the DisplayString type.

I note that snmpAdminStrng is being used to contain structured data.
Make sure that the structured data will still fit within the
definition of an snmpAdminString. It might be better to use a
structured octet string in some cases. E.g. AdditionalInfo). 

Some of these will trigger alarms when put through a MIB Doctor
review, so you should try to get them fixed before you get to that
stage.





David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Wednesday, June 21, 2006 12:19 PM
> To: mreview@ops.ietf.org
> Cc: Woundy, Richard; jf.mule@cablelabs.com
> Subject: Call for Reviewers: 
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> tmess-06.txt
> 
> 
> This is a call for a volunteer to do a MIB Doctor review for
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> tmess-06.t
> xt. Please let me know who is willing and available to 
> perform a review
> of this I-D on a reasonable time schedule. 
> 
> Thanks and Regards,
> 
> Dan
> 
>  
> 
>