Subject: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 11 Feb 2009 00:46:32 -0500

Dan J. and Vishwas,

First, I do apologize for being late with this review,
thank you for your patience.

A great deal of work went into this
latest revision!  Thanks for that!

The MIB compilers' outputs are given,
followed by output from
IDNITS (http://tools.ietf.org/tools/idnits/)
followed by comments.

Most all comments are from prior review. Please note,
where agreement was reached, the comments have been deleted.

Thanks,
  Joan

smicngPRO output
-----------------

W: f(OSPFv3-MIB.my), (3532,18) MIN-ACCESS value identical to access 
specified for "ospfv3StubRouterSupport"
W: f(OSPFv3-MIB.my), (3649,18) MIN-ACCESS value identical to access 
specified for "ospfv3IfState"

smlint
-----------
Line  Severity   Problem
3096 5 warning: `InetAddress' should be used instead of `InetAddressIPv6'

IDNITS
------
idnits 2.11.01

tmp/draft-ietf-ospf-ospfv3-mib-13.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update 
this
     to the boilerplate described in the IETF Trust License Policy document
     (see http://trustee.ietf.org/license-info), which is required from
     December 16, 2008.  Version 1.34 of xml2rfc can be used to produce
     documents with boilerplate according to the mentioned Trust License
     Policy document.

  -- Found old boilerplate from RFC 3978 Section 5.1 on line 16.

     The obsolete RFC 3978 Section 5.1 text:
     "By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of BCP 79."

  -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC 4748 on
     line 4482.

     The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text:
     "This document and the information contained herein are provided on an
      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

  -- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on line 4493.

     The obsolete RFC 3979 Section 5 paragraph 1 text:
     "The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights.
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79."

  -- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on line 4500.

     The obsolete RFC 3979 Section 5 paragraph 2 text:
     "Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr."

  -- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on line 4506.

     The obsolete RFC 3979 Section 5 paragraph 3 text:
     "The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      [email-masked]."

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative 
references
     to lower-maturity documents in RFCs)

     No issues found here.

     Summary: 1 error (**), 1 warning (==), 5 comments (--).

-------------

>
>
> General Comments
> -----------------
>
> 1) Need to have a read-only conformance.

(NEW)  NIT: would change the name from
ospfv3Compliance to ospfv3FullCompliance.

>
> 5) The MIB did not extract using mstrip (MIB tool).
> If possible, could this be fixed?

This is a NIT, but still had trouble with mstrip tool.

6) NEW: Use of InetAddressType and InetAddress
In several places in the MIB, the DESCRIPTION states something
like "only IPv6 global address type expected" and then
InetAddress (SIZE (16)) is given.

First, I have to ask if this is truly the intention or would
having {unknown(0), ipv6(2) }  and (SIZE (0|16)) be more appropriate.

Second, you restrict InetAddress at the object, but the InetAddressType
as part of the conformance. Could you please choose one place or the other?

I tend to prefer these restrictions be in the conformance
section because it is slightly less painful to revise the conformance
section, than to revise objects  (but this is just my opinion).
At any rate, would ask that you be consistent so
restrict both InetAddressType and InetAddress either in the object's
SYNTAX or add to the Conformance Section.

>
>
> Comments in Order of the document
> ----------------------------------
>

(NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC
to be consistent with the names of the other TCs.

>
> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this
> table may have a DEFVAL clause of zero (this is mentioned in
> the DESCRIPTION clauses).
>

Not Done.  Even though these are read-only objects, the DEFVAL
helps Agent developers so would add this, unless there is a
reason not to.

> *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown)
>
> Please indicate what true(1) means in the
> DESCRIPTION
>

Not Done.

>
> *) ospfv3HostTable
>
> Need to have a storageType object added to this table.
>

Sorry, I was not correct when I said that a storageType was
needed.  The MIB Guidelines specifies to either add a storageType
object OR add a description to the  Entry (as you have done in other
Tables.)  To quote from rfc4181:

     - "There either MUST be one columnar object with a SYNTAX value of
       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
       else the row object (table entry) DESCRIPTION clause MUST specify
       what happens to dynamically-created rows after an agent restart."

In any case, the description in the StorageType object conflicts with the
Table's description.

Also, if the agent is able to create/delete rows then
this needs to be documented...(from rfc4181):

     -"If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause."

Please clarify.

>
>
>
>
> *) ospfv3HostEntry and ospfv3HostStorageType
>

Same comment as above.

> *)ospfv3IfTable

NIT:  REFERENCE clause "parameters parameters", please
change to "parameters"

*) ospfv3IfAdminStat
Please rename to ospfv3IfAdminStatus

*) Why is there no ospfv3IfOperStatus object?
Typically, the AdminStatus if for setting and
the OperStatus is used to read if the status
changes.  I think both would be appropriate here.
Please comment.

>
>
> *) ospfv3NbrTable and ospfv3CfgNbrTable
>
> What is the relationship between these 2 tables?
> The indexing is different between the 2 tables and so
> I'm wondering what the relationship is between them.
>

So to restate my question, there is an ospfv3CfgNbrEntry which is
a single neighbor that has been configured and there is
an ospfv3NbrEntry which contains info about a single neighbor, so
does the ospfv3CfgNbrEntry also have an associated ospfv3NbrEntry?

If so, can some explanation be given on how to look up a
related entry in the ospfv3NbrEntry table once the ospfv3CfgNbrEntry is
populated?

If there is no relationship between these two tables then
please state that in the DESCRIPTION clauses for the tables.

*) ospfv3NbrRtrId

NIT:  says "32-bit integer" and should be "32-bit unsigned integer"

>
>
>
> Notifications
> ------------
>
> In general the accessible-for-notify objects should probably be
> changed into read-only objects.  Additionally, a timestamp should
> be associated with some of these.  There is an assumption made that
> it is better to send out notifications rather than poll, but I'd
> rather give the operator the choice on that.
>
>

Please comment.

*) ospfv3PacketSrc

Same sort of issue as discussed in the General Comment Section
above.  This one especially mentions returning 0, but it is an
InetAddressIPv6 which has OCTET STRING (SIZE (16))
so please clarify what is expected by the agent.

>
> Compliance Statements
> -------------------------
>

*) NIT: ospfv3Compliance should be renamed to
ospfv3FullCompliance

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 11 Feb 2009 08:29:45 -0500

Opps!  Wanted to send to  a few more folks!

----- Original Message ----- 
From: "Joan Cucchiara" <[email-masked]>
To: <[email-masked]>
Cc: "Ronald Bonica" <[email-masked]>; "Dan Romascanu" 
<[email-masked]>
Sent: Wednesday, February 11, 2009 12:46 AM
Subject: [OSPF] MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: "Daniel Joyal" <[email-masked]>
Date: Wed, 11 Feb 2009 15:22:00 -0500

Thanks Joan. I'll send additional questions and comments in
a separate e-mail.

-Dan 

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2009 8:30 AM
> To: Joan Cucchiara; [email-masked]; Joyal, Daniel (BL60:SF23); 
> Vishwas Manral
> Cc: Ronald Bonica; Dan Romascanu; MIB Doctors (E-mail); David 
> Ward; Acee Lindem; Abhay Roy
> Subject: Re: [OSPF] MIB Dr. review of 
> draft-ietf-ospf-ospfv3-mib-13.txt
> 
> 
> >  -- Found old boilerplate from RFC 3979 Section 5 paragraph 
> 1 on line 
> > 4493.
> >
> >  -- Found old boilerplate from RFC 3979 Section 5 paragraph 
> 2 on line 
> > 4500.
> >
> >  -- Found old boilerplate from RFC 3979 Section 5 paragraph 
> 3 on line 
> > 4506.
> >
> >  Checking nits according to 
> http://www.ietf.org/ietf/1id-guidelines.txt:
> >  
> > as part of the conformance. Could you please choose one 
> place or the 
> > other?
> >