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

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 18 Feb 2009 22:40:25 -0500

Dan,

Think we are down to one or two questions!

   Thanks,
     -Joan

>
> ----- Original Message ----- 
> From: "Daniel Joyal" <[email-masked]>
> To: "Joan Cucchiara" <[email-masked]>
> Cc: "Vishwas Manral" <[email-masked]>; "Acee Lindem" 
> <[email-masked]>
> Sent: Tuesday, February 17, 2009 5:18 PM
> Subject: RE: MIB Dr. review of draft-ietf-ospf-ospfv3-mib-13.txt
>
>
> Hi Joan,
>
> Thanks for your patience in doing the review twice!
> See comments and questions in-line.
>
> Cheers,
> -Dan
>
>> -----Original Message-----
>> From: Joan Cucchiara [mailto:[email-masked]]
>> Sent: Wednesday, February 11, 2009 12:47 AM
>> To: [email-masked]
>> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica;
>> Joyal, Daniel (BL60:SF23); Vishwas Manral; Acee Lindem
>> Subject: 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"
>>
>
> I don't have access to smicngPRO. Is it complaining that
> MIN-ACCESS is equal to MAX-ACCESS for these objects?

Yes.  Please remove the following lines in the conformance
section, then these warnings will be resolved:

OBJECT ospfv3StubRouterSupport
          MIN-ACCESS read-only
          DESCRIPTION
               "Write access is not required."

OBJECT ospfv3IfState
          MIN-ACCESS read-only
          DESCRIPTION
               "Write access is not required."

>
>>
>> smlint
>> -----------
>> Line  Severity   Problem
>> 3096 5 warning: `InetAddress' should be used instead of
>> `InetAddressIPv6'
>>
>
> The message is intended to warn that the IP address is
> specific to a particular address family in cases where
> the MIB should support multiple address families.
> But the OSPFv3 MIB only supports the IPv6 address family.
> The OSPFv3 MIB is not compatible with OSPFv2 implementations.
> In this case, can the warning be ignored?

Yes.

>
>>
>> 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 (--).
>>
>>
>> -------------
>>
>
> The boilerplate requirements changed after the last revision
> was posted. I will update the boilerplate such that no
> ID_NIT issues are raised.

Thanks!

>
>> >
>> >
>> > General Comments
>> > -----------------
>> >
>> > 1) Need to have a read-only conformance.
>>
>> (NEW)  NIT: would change the name from
>> ospfv3Compliance to ospfv3FullCompliance.
>
> Will change.
>
>>
>>
>> >
>> > 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.
>
> Does the tool take the standard ascii text file as input?
> I'll try to find a user guide for the tool to see what it
> is expecting regarding file formatting.
>

I mention this as an FYI.
You do not need fix this for MIB DR review.  As I recall,
the RFC Editor has fixed this kind of formatting issue in the past.

>>
>>
>>
>> 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.
>
> How would an implementation behave for an unknown(0) address type?

For this MIB, unknown(0) could be a placeholder as Rows were being created, 
until the
real values became available (e.g. depends on how rows were created, or
how an agent fills in the info from a cfg file during restarts).

This would not be appropriate for InetAddressType that was part of the 
Index.

In this MIB, it might be appropriate for ospfv3VirtNbrAddressType until the
actual value was available (e.g. for implementations that don't have all the
information available at once during agent start/restart).

To state my question another way, would  adding  Unknown and SIZE(0) as 
options
be helpful (or provide more flexibility) for implementations?  If the answer 
is no, then
don't add it, if the answer is yes, then would seem appropriate to add it. 
I'm not suggesting
that this be added, only asking the question.

>
>>
>>
>> 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.
>
> OK. I'll restrict in conformance section.

Thanks.

>
>>
>>
>>
>>
>>
>> >
>> >
>> > Comments in Order of the document
>> > ----------------------------------
>> >
>>
>>
>> (NEW): Ospfv3LsidTC should be renamed to Ospfv3LsIdTC to be
>> consistent with the names of the other TCs.
>>
>
> Will change.
>
>>
>>
>> >
>> > *) 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.
>>
>
> Will add DEFVAL.
>
>> > *) ospfv3AreaLsdbTypeKnown (and also ospfv3LinkLsdbTypeKnown)
>> >
>> > Please indicate what true(1) means in the DESCRIPTION
>> >
>>
>> Not Done.
>
> Will add.
>
>>
>>
>>
>>
>> >
>> > *) 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.
>>
>
> Does your comment apply to this table only? Can I remove the
> StorageType object and add to Description clause as was done
> with other tables?

Yes.

> Are the Description clauses for other
> like tables acceptible for this table?
>

Yes.

>>
>> >
>> >
>> >
>> >
>> > *) ospfv3HostEntry and ospfv3HostStorageType
>> >
>>
>> Same comment as above.
>>
>
> Same questions as above.
>
>>
>>
>> >
>> > *)ospfv3IfTable
>> >
>>
>> NIT:  REFERENCE clause "parameters parameters", please change
>> to "parameters"
>>
>
> Will change.
>
>>
>>
>>
>> *) ospfv3IfAdminStat
>> Please rename to ospfv3IfAdminStatus
>>
>
> Will change.

Should also have asked about ospfv3AdminStat (the scalar)
also.  Could you rename this to ospfv3AdminStatus?

Also, if the ospfv3IfAdminStatus is enabled, but the ospfv3AdminStatus 
(scalar)
is disabled, then does this mean that all the interfaces behave as if they 
are  disabled?

In other words, does the scalar (ospfv3AdminStatus) takes precedence over 
the
individual interface's ospfv3IfAdminStatus value?

If so, could you please add a mention of this to the description of 
ospfv3IfAdminStatus and
also ospfv3IfState?

>
>>
>>
>> *) 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.
>>
>
> The object ospfv3IfState gives the operational state of the
> OSPF interface.

Okay, please add a Reference for this.

As mentioned above in the discussion of ospfv3IfAdminStatus, please expand 
the
description clause to mention how the adminStatuses effect this object.

>
>>
>>
>> >
>> >
>> > *) 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?
>
> Yes it does. Configured neighbors are used when running OSPF
> on NBMA subnets (OSPF nbma and point-to-multipoint link types).
> The configured neighbors table just gives OSPF information
> for sending hellos to potential neighbors. Once a hello is
> received from a neighbor in the configured neighbor table,
> an entry for that neighbor is created in the neighbor table
> and adjacency state is maintained there. Neighbors on multi-access
> or point-to-point subnets can use multicast addressing, so
> only neighbor table entries are created.
>
>>
>> If so, can some explanation be given on how to look up a
>> related entry in the ospfv3NbrEntry table once the
>> ospfv3CfgNbrEntry is populated?
>
> OK. I will better describe the relationship between
> the tables.

Thanks for the clarification.  If you can include  in these table 
DESCRIPTIONs
what you explained above, that would be great.

>
>>
>> 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"
>
> Will change.
>
>>
>>
>> >
>> >
>> >
>> > 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.
>
> I've seen accessible-for-notify used in other MIBs, but I defer
> to your expert judgement on this. Which objects to you think
> need a timestamp?
>

Dan, Sorry I made a mistake here.
I think I didn't quite understand how these accessible-for-notify objects 
were
used in several notifications, but now I see, so timestamps don't make
sense, neither does changing these objects to read-only.

Please leave them as accessible-for-notify BUT please also modify the 
DESCRIPTION
clause which is confusing.  Since these are not read-only, please remove the 
phrase
which begins "When the last value...."

>>
>> *) 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.
>
> I believe the text about the zero value is derived from the OSPFv2 MIB
> comment by a MIB reviewer.
>
>     ospfPacketSrc OBJECT-TYPE
>          SYNTAX       IpAddress
>          MAX-ACCESS   read-only
>          STATUS       current
>          DESCRIPTION
>             "The IP address of an inbound packet that cannot
>             be identified by a neighbor instance.  When
>             the last value of a trap using this object is
>             needed, but no traps of that type have been sent,
>             this value pertaining to this object should
>             be returned as 0.0.0.0."
>          ::= { ospfTrapControl 4 }
>
> I thought the same description would apply to OSPFv3, but instead
> returning a value of an octet string of all zeros. Does
> this make sense?

Since the object has a STATUS of accessible-for-notify
the above suggestion  of modifying the DESCRIPTION clause to remove
the "When the last value...."  will resolve the issue.

If this was a read-only object then either the "all zeros"
or using InetAddress SIZE(0 | 16) so that a zero-length octet string would 
be returned if a
read was done of this address but there was not yet a valid value for it.

   -Joan

>
>>
>>
>> >
>> > Compliance Statements
>> > -------------------------
>> >
>>
>> *) NIT: ospfv3Compliance should be renamed to ospfv3FullCompliance
>
> Will change.
>
>>
>>
>>
>>
>