Dear Bert and Dan,
thanks very much for your review. We are new to MIB authoring and we obviously overlooked some important points. Apologies.
Also we only used smilint for compiling. We will use SMICng in the future, it seems more complete indeed.
We have no problem with the requested changes. We only need clarifications on the following points:
3- is it enough to state in the I-D that all parameters are persistent if not stated otherwise in the parameters description?
And we would add a note in the Description field of the ones that should not be.
5- it was not our intention to condition the support of an agent dynamically
on a certain value of another object. We want to condition this support on the actual functionality of the device.
When it is stated "This group is mandatory for an RCST that claims to support the SNMPMISC option.", we do not intend to link this to the value of the options declaration parameter. It is linked to the actual conformance of the device to the SatLabs Recommendations. Of course, the value returned in the options declaration parameter must be in line with the device's conformance.
But this value is only used by the management server to know which options are supported.
Do you think it is sufficient to add this clarification to the description of the MODULE-COMPLIANCE? or perhaps we should delete
'claim' in the descriptions and only leave 'supports' so that is it understood not to be dynamically linked to the returned value of the options support parameter.
I understand we may have additional comments from Jari. We will wait for these before updating the I-D. It may take a couple of weeks since my colleagues of the SatLabs Group have to review the changes.
kind regards,
Stephane
-----"Romascanu, Dan (Dan)" <dromasca at avaya.com> wrote: -----
To: "Romascanu, Dan (Dan)" <dromasca at avaya.com>, "Jari Arkko" <jari.arkko at piuha.net>, "Bert Wijnen (IETF)" <bertietf at bwijnen.net>
From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
Date: 05/14/2009 06:21PM
cc: <gorry at erg.abdn.ac.uk>, <draft-combes-ipdvb-mib-rcs at tools.ietf.org>, <ipdvb-chairs at tools.ietf.org>, "Martin Stiemerling" <stiemerling at netlab.nec.de>, <mib-doctors at ietf.org>
Subject: RE: [MIB-DOCTORS] Call for a volunteer to reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.txt
With Bert's helped I would like to add a number of comments that I
believe need to be considered and acted upon before this document is
published - even at Informational status:
1. It looks more appropriate that the title of the document be 'The
SatLabs Group DVB-RCS MIB'.
2. In a number of places you make use of Integer32 although we are
dealing with obviously non-negative numbers. Unsigned32 is the
recommended SYNTAX for things like dvbRcsSystemOduAntennaGain, etc.
3. There is no information about persistency behavior although there are
a large number of writeable objects.
4. You make use of obsoleted/deprecated OBJECT-TYPEs (like
DisplayString and IpAddress - recommended use if of SnmpAdminString and
RFC 4001 TCs)
5. The conformance clauses are broken. You cannot condition the support
of an agent dynamically on a certain value of another object. This seems
to be the case with the SNMPMISC bit conditioning other groups support
like in
GROUP dvbRcsRcstExtSystemGroup
DESCRIPTION "This group is mandatory for an RCST
that claims to support the SNMPMISC option."
I find this strange too:
OBJECT dvbRcsSystemOduAntennaGain
MIN-ACCESS read-only
DESCRIPTION "Write access is supported if the
dvbRcsRcstOduListGroup is not supported."
Or:
OBJECT dvbRcsRequestClassPidPoolReference
MIN-ACCESS not-accessible
DESCRIPTION "Read-only access required if MPEG option
is claimed. Write access only required if also SNMPMISC
6. on tables with dynamic row creation there is no information about
whether writable objects in the dynamically created rows can change
value while the RowStatus object is active.
7. The Security Considerations section does not list the vulnerabilities
of objects with read-write or read-create access. See
http://www.ops.ietf.org/mib-security.html for an indication about how a
complete Security Considerations section should be structure for a MIB
RFC.
Dan
> -----Original Message-----
> From: Romascanu, Dan (Dan)
> Sent: Thursday, May 14, 2009 6:26 PM
> To: 'Jari Arkko'; Bert Wijnen (IETF)
> Cc: gorry at erg.abdn.ac.uk;
> draft-combes-ipdvb-mib-rcs at tools.ietf.org;
> ipdvb-chairs at tools.ietf.org; Martin Stiemerling
> Subject: RE: [MIB-DOCTORS] Call for a volunteer to
> reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-m
> ib-rcs-04.txt
>
> Please wait, there are some more problems.
>
> Dan
>
>
> > -----Original Message-----
> > From: Jari Arkko [mailto:jari.arkko at piuha.net]
> > Sent: Thursday, May 14, 2009 6:04 PM
> > To: Bert Wijnen (IETF)
> > Cc: Romascanu, Dan (Dan); gorry at erg.abdn.ac.uk;
> > draft-combes-ipdvb-mib-rcs at tools.ietf.org;
> > ipdvb-chairs at tools.ietf.org; Martin Stiemerling
> > Subject: Re: [MIB-DOCTORS] Call for a volunteer to
> > reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-m
> > ib-rcs-04.txt
> >
> > Thanks. Gorry, would it be possible to get a new version
> quickly, just
> > for this fix?
> >
> > Jari
> >
> >
> > Bert Wijnen (IETF) wrote:
> > > SMICng tells me:
> > >
> > > C:\bw\smicng\work>smicng dvbrcs.inc
> > > E: f(dvbrcs.mi2), (1461,16) Default value for
> > > "dvbRcsCtrlRebootCommand" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1477,16) Default value for
> > > "dvbRcsCtrlRcstTxDisable" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1492,16) Default value for
> > > "dvbRcsCtrlUserTrafficDisable" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1509,16) Default value for
> "dvbRcsCtrlCwEnable"
> > > must be a name and not a number
> > > E: f(dvbrcs.mi2), (1524,16) Default value for
> > > "dvbRcsCtrlOduTxReferenceEnable" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1539,16) Default value for
> > > "dvbRcsCtrlOduTxDCEnable" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1554,16) Default value for
> > > "dvbRcsCtrlOduRxDCEnable" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1572,16) Default value for
> > > "dvbRcsCtrlDownloadFileCommand" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1592,16) Default value for
> > > "dvbRcsCtrlUploadFileCommand" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1609,16) Default value for
> > > "dvbRcsCtrlActivateConfigFileCommand" must be a name and
> > not a number
> > > E: f(dvbrcs.mi2), (1623,16) Default value for
> > > "dvbRcsCtrlRcstLogonCommand" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1637,16) Default value for
> > > "dvbRcsCtrlRcstLogoffCommand" must be a name and not a number
> > > E: f(dvbrcs.mi2), (1650,16) Default value for
> > > "dvbRcsCtrlRcstRxReacquire" must be a name and not a number
> > >
> > > *** 13 errors and 0 warnings in parsing
> > >
> > > Taking the first example at line 1461, I see:
> > > dvbRcsCtrlRebootCommand OBJECT-TYPE
> > > SYNTAX INTEGER {
> > > idle (1),
> > > normal (2),
> > > alternate (3)
> > > }
> > > MAX-ACCESS read-write
> > > STATUS current
> > > DESCRIPTION
> > > "This variable shall force the RCST to reboot
> > > (1)- idle
> > > (2)- normal reboot (from current software load)
> > >
> > > (3)- reboot from alternate load (swap to
> > alternate load
> > > before reboot)"
> > > DEFVAL {1}
> > > ::={dvbRcsRcstControl 1}
> > >
> > > If you change the DEFVAL to: DEFVAL { idle }
> > > then the error is fixed.
> > > Same for the others.
> > >
> > > I have not reviewed this further (yet).
> > >
> > > ----- Original Message -----
> > > *From:* Romascanu, Dan (Dan) <mailto:dromasca at avaya.com>
> > > *To:* Jari Arkko <mailto:jari.arkko at piuha.net> ;
> > > gorry at erg.abdn.ac.uk <mailto:gorry at erg.abdn.ac.uk>
> > > *Cc:* draft-combes-ipdvb-mib-rcs at tools.ietf.org
> > > <mailto:draft-combes-ipdvb-mib-rcs at tools.ietf.org> ;
> > > ipdvb-chairs at tools.ietf.org
> > <mailto:ipdvb-chairs at tools.ietf.org> ;
> > > Bert Wijnen (IETF) <mailto:bertietf at bwijnen.net> ; Martin
> > > Stiemerling <mailto:stiemerling at netlab.nec.de>
> > > *Sent:* Thursday, May 14, 2009 4:46 PM
> > > *Subject:* RE: [MIB-DOCTORS] Call for a volunteer to
> > >
> > >
> >
> reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-0
> > > 4.txt
> > >
> > > Yes, Bert and me are looking at this right now - we'll
> > comment back
> > > soon.
> > >
> > > Dan
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jari Arkko [mailto:jari.arkko at piuha.net]
> > > > Sent: Thursday, May 14, 2009 2:04 PM
> > > > To: gorry at erg.abdn.ac.uk <mailto:gorry at erg.abdn.ac.uk>
> > > > Cc: draft-combes-ipdvb-mib-rcs at tools.ietf.org
> > > <mailto:draft-combes-ipdvb-mib-rcs at tools.ietf.org>;
> > > > ipdvb-chairs at tools.ietf.org
> > > <mailto:ipdvb-chairs at tools.ietf.org>; Romascanu, Dan
> (Dan); Bert
> > > > Wijnen (IETF); Martin Stiemerling
> > > > Subject: Re: [MIB-DOCTORS] Call for a volunteer to
> > > >
> reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-m
> > > > ib-rcs-04.txt
> > > >
> > > > Yes -- Dan?
> > > >
> > > > Jari
> > > >
> > > > Gorry Fairhurst wrote:
> > > > > Dear Jari
> > > > >
> > > > > I suspect this is now your I-D to track, instead of Mark.
> > > > >
> > > > > The authors have submitted an updated revision of
> the draft
> > > (-05 in
> > > > > the I-D archive). This was an individual informational
> > > > document (for
> > > > > IPR reasons) and has already started MIB Doctor
> > review, but was
> > > > > returned to the authors to apply corrections. In the
> > > > mean-time, there
> > > > > was also a change of I-D boilerplate and update
> to some MIB
> > > > counters.
> > > > >
> > > > > Could you ask the MIB Review to now resume?
> > > > >
> > > > > Best wishes,
> > > > >
> > > > > Gorry Fairhurst
> > > > > (ipdvb WG Chair)
> > > > >
> > > > > Mark Townsley wrote:
> > > > >>
> > > > >> Charis, Authors,
> > > > >>
> > > > >> May we have a new version that addresses this naming
> > > > convention issue
> > > > >> so that we can continue?
> > > > >>
> > > > >> It looks like the document has been sitting for a few
> > > > months due to
> > > > >> this hangup, apologies for not forwarding this
> > issue on to you
> > > > >> immediately (store and forward through an
> overloaded AD is
> > > not the
> > > > >> best manner of getting a message from one person
> > to another, but
> > > > >> that's another issue - it was my ultimate responsibility
> > > > and for that
> > > > >> I apologize).
> > > > >>
> > > > >> - Mark
> > > > >>
> > > > >> Romascanu, Dan (Dan) wrote:
> > > > >>> */Mark,/*
> > > > >>> *//* */Can we have this issue fixed? /*
> > > > >>> *//* */The recommended naming conventions for MIB
> > objects and
> > > > >>> modules are described in Appendix C of RFC 4181.
> > In general, RFC
> > > > >>> 4181 should be mandatory reading for everybody writing
> > > > and reviewing
> > > > >>> MIB documents. /*
> > > > >>> *//* */Dan/*
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > >
> > --------------------------------------------------------------------
> > > > >>> ----
> > > > >>>
> > > > >>> *From:* Bert Wijnen (IETF)
> > [mailto:bertietf at bwijnen.net]
> > > > >>> *Sent:* Tuesday, November 18, 2008 7:09 PM
> > > > >>> *To:* Romascanu, Dan (Dan); MIB Doctors (E-mail)
> > > > >>> *Cc:* Mark Townsley
> > > > >>> *Subject:* Re: [MIB-DOCTORS] Call for a volunteer to
> > > > >>>
> > > > >>>
> > > >
> > reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs
> > > > >>> -04.txt
> > > > >>>
> > > > >>>
> > > > >>> Only having taken a very very cursory browse of this
> > > doc, I DO
> > > > >>> have one
> > > > >>> SERIOUS concern. And that is that all the
> object names
> > > > >>> (descriptors) do
> > > > >>> not follow ANY naming convention.
> > > > >>> I would URGE them to prefix all their
> descriptors
> > > with a
> > > > >>> common prefix
> > > > >>> that will help avoid naming conflicts in the future.
> > > > >>> I am not sure if/when I will have time to do a
> > > > close review.
> > > > >>> But I would recommend that they do that
> proper naming
> > > > FIRST before
> > > > >>> anyone
> > > > >>> spends too much time on this
> > > > >>> Bert
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>> *From:* Romascanu, Dan (Dan)
> > <mailto:dromasca at avaya.com>
> > > > >>> *To:* MIB Doctors (E-mail)
> > <mailto:mib-doctors at ietf.org>
> > > > >>> *Cc:* Mark Townsley <mailto:townsley at cisco.com>
> > > > >>> *Sent:* Sunday, November 16, 2008 11:47 PM
> > > > >>> *Subject:* [MIB-DOCTORS] Call for a volunteer to
> > > > >>>
> > > > >>>
> > > >
> > reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs
> > > > >>> -04.txt
> > > > >>>
> > > > >>>
> > > > >>> MIB Doctors,
> > > > >>>
> > > > >>> We need a volunteer to perform a MIB
> Doctor review
> > > on the
> > > > >>> I-D
> > > > >>>
> > > > >>>
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.txt
> > > > >>> .
> > > > >>> This is an AD-sponsored contribution targeting
> > > > Informational
> > > > >>> RFC,
> > > > >>> sponsored by Mark Townsley.
> > > > >>>
> > > > >>> Thanks and Regards,
> > > > >>>
> > > > >>> Dan
> > > > >>> _______________________________________________
> > > > >>> MIB-DOCTORS mailing list
> > > > >>> MIB-DOCTORS at ietf.org
> <mailto:MIB-DOCTORS at ietf.org>
> > > <mailto:MIB-DOCTORS at ietf.org>
> > > > >>>
> https://www.ietf.org/mailman/listinfo/mib-doctors
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >