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.
[[DR]] Indeed - but please make the generic statement in the
DESCRIPTION clause of the MIB module itself, so that people reading only
the MIB and not the text of the future RFC can get the proper
information.
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.
[[DR]] OK but I recommend two things here. Call
this something different than 'SNMPMISC option' to avoid the confusion with
the bit in the TC, for example 'conformant to the SatLabs
Recommendations'. Second cannot in this case all groups that are supported in
similar conditions of module compliance be merged? This would simplify
the understanding of what is supported as module compliances have just
this goal, not some other logical groupings.
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
>
> > > >>>
> > >
> >>
> > > > >>
> >
> > >
> > > >
>
> > > > >
> > >
>
> > > >
> > >
>
>
> >