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

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

>
> 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
>
>
>
> _______________________________________________
> 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
> 
> 
> >  Checking nits according to 
> http://www.ietf.org/ietf/1id-guidelines.txt:
> >