Subject: Re: [MIB-DOCTORS] Call for a volunteer to reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 May 2009 18:21:22 +0200

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: [email-masked]; 
> [email-masked]; 
> [email-masked]; 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:[email-masked]]
> > Sent: Thursday, May 14, 2009 6:04 PM
> > To: Bert Wijnen (IETF)
> > Cc: Romascanu, Dan (Dan); [email-masked]; 
> > [email-masked];
> > [email-masked]; 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:[email-masked]>
> > >     *To:* Jari Arkko <mailto:[email-masked]> ;
> > >     [email-masked] <mailto:[email-masked]>
> > >     *Cc:* [email-masked]
> > >     <mailto:[email-masked]> ;
> > >     [email-masked]
> > <mailto:[email-masked]> ;
> > >     Bert Wijnen (IETF) <mailto:[email-masked]> ; Martin
> > >     Stiemerling <mailto:[email-masked]>
> > >     *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:[email-masked]]
> > >     > Sent: Thursday, May 14, 2009 2:04 PM
> > >     > To: [email-masked] <mailto:[email-masked]>
> > >     > Cc: [email-masked]
> > >     <mailto:[email-masked]>;
> > >     > [email-masked]
> > >     <mailto:[email-masked]>; 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:[email-masked]]
> > >     > >>>     *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:[email-masked]>
> > >     > >>>         *To:* MIB Doctors (E-mail) 
> > <mailto:[email-masked]>
> > >     > >>>         *Cc:* Mark Townsley <mailto:[email-masked]>
> > >     > >>>         *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
> > >     > >>>         [email-masked] 
> <mailto:[email-masked]>
> > >     <mailto:[email-masked]>
> > >     > >>>         
> https://www.ietf.org/mailman/listinfo/mib-doctors
> > >     > >>>
> > >     > >>
> > >     > >>
> > >     > >
> > >     > >
> > >     > >
> > >     >
> > >     >
> > >
> > 
> >

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 May 2009 08:50:41 +0300

Thank you both for the extensive review. Gorry, now would be a good time 
for you to ask the authors to revise the document accordingly. Also, is 
this far enough for you to make a publication request (or maybe you 
already did with Mark)? I need to review the document as well.

Jari

---

From: [email-masked]
Date: Fri, 15 May 2009 11:17:56 +0200

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)" <[email-masked]> wrote: -----

To: "Romascanu, Dan (Dan)" <[email-masked]>, "Jari Arkko" <[email-masked]>, "Bert Wijnen (IETF)" <[email-masked]>
From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: 05/14/2009 06:21PM
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Martin Stiemerling" <[email-masked]>, <[email-masked]>
Subject: RE: [MIB-DOCTORS] Call for a volunteer to reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.txt

Dan

> > >     > -----Original Message-----
> > >     > From: Jari Arkko [mailto:[email-masked]]
> > >     > Sent: Thursday, May 14, 2009 2:04 PM
> > >     > To: [email-masked] <mailto:[email-masked]>
> > >     > Cc: [email-masked]
> > >     > [email-masked]
> > >     > Wijnen (IETF); Martin Stiemerling
> > >     > Subject: Re: [MIB-DOCTORS] Call for a volunteer to
> > >     >
> > >     > 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)
> > >     > >>>     *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
> > >     > >>>
> > >     > >>>
> > >     >
> > >     > >>> -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)
> > >     > >>>         *To:* MIB Doctors (E-mail)
> > >     > >>>         *Cc:* Mark Townsley <mailto:[email-masked]>
> > >     > >>>         *Sent:* Sunday, November 16, 2008 11:47 PM
> > >     > >>>         *Subject:* [MIB-DOCTORS] Call for a volunteer to
> > >     > >>>
> > >     > >>>
> > >     >
> > >     > >>> -04.txt
> > >     > >>>
> > >     > >>>
> > >     > >>>         MIB Doctors,
> > >     > >>>
> > >     > >>>         We need a volunteer to perform a MIB
> Doctor review
> > >     on the
> > >     > >>> I-D
> > >     > >>>
> > >     > >>>
> > >     >
> > >
> >
> > >     > >>>         .
> > >     > >>>         This is an AD-sponsored contribution targeting
> > >     > Informational
> > >     > >>> RFC,
> > >     > >>>         sponsored by Mark Townsley.
> > >     > >>>
> > >     > >>>         Thanks and Regards,
> > >     > >>>
> > >     > >>>         Dan
> > >     > >>>         _______________________________________________
> > >     > >>>         MIB-DOCTORS mailing list
> > >     > >>>         [email-masked]
> > >     > >>>
> > >     > >>>
> > >     > >>
> > >     > >>
> > >     > >
> > >     > >
> > >     > >
> > >     >
> > >     >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 18 May 2009 13:48:09 +0200

Hi,
 
Thank you for the quick answer. See in-line. 
 
Dan

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Friday, May 15, 2009 12:18 PM
	To: Romascanu, Dan (Dan); Bert Wijnen (IETF)
	Cc: Jari Arkko; [email-masked];
[email-masked]; [email-masked];
Martin Stiemerling; [email-masked]
	Subject: RE: [MIB-DOCTORS] Call for a volunteer to
reviewhttp://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.
txt

	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

		To: "Romascanu, Dan (Dan)" <[email-masked]>, "Jari
Arkko" <[email-masked]>, "Bert Wijnen (IETF)"
<[email-masked]>
		From: "Romascanu, Dan (Dan)" <[email-masked]>
		Date: 05/14/2009 06:21PM
		cc: <[email-masked]>,
<[email-masked]>,
<[email-masked]>, "Martin Stiemerling"
<[email-masked]>, <[email-masked]>
		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

		
		
		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
<https://anakin.esa.int/,DanaInfo=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

		
		> > >     *Cc:*
[email-masked]
		> > >     > Cc:
[email-masked]

		> > <mailto:[email-masked]>
<mailto:[email-masked]>
http://www.ietf.org/internet-drafts/draft-combes-ipdvb-mib-rcs-04.txt
<https://anakin.esa.int/internet-drafts/,DanaInfo=www.ietf.org+draft-com
bes-ipdvb-mib-rcs-04.txt> 
		> https://www.ietf.org/mailman/listinfo/mib-doctors
<https://anakin.esa.int/mailman/listinfo/,DanaInfo=www.ietf.org,SSL+mib-
doctors>