[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
My commetns were made against -06-
dbh
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Thursday, June 22, 2006 3:18 AM
> To: David B Harrington; mreview@ops.ietf.org
> Subject: RE: Call for Reviewers:
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even
> tmess-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
> > >
> > >
> > >
> > >
> >
> >
>