[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Call for Reviewers: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-06.txt
David,
Thank you for volunteering. You are the guy, unless somebody really
wants it. I know that you are busy so I will not push hard for a quick
return, but do you have an expected date for an 'a la 4181' review?
One question I have is whether your comments were made wrt. draft-06 or
a previous version? If they were made for a previous version, did you
check whether the editors addressed in any way your comments?
In any case, I would recommend the editors to attend the MIB EDU
tutorial in Montreal.
Dan
> -----Original Message-----
> From: David B Harrington [mailto:dbharrington@comcast.net]
> Sent: Wednesday, June 21, 2006 10:05 PM
> To: Romascanu, Dan (Dan); mreview@ops.ietf.org
> Subject: RE: Call for Reviewers:
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> tmess-06.txt
>
> 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
> >
> >
> >
> >
>
>