Subject: [OSPF] FW: [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3-mib-13.txt

From: Acee Lindem <[email-masked]>
Date: Mon, 16 Mar 2009 10:03:31 -0400

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: March 16, 2009 9:54:51 AM EDT
To: "David Ward" <[email-masked]>, "Joan Cucchiara"  
<[email-masked]>
Cc: "Vishwas Manral" <[email-masked]>, "MIB Doctors (E-mail)"  
<[email-masked]>, "Dan Joyal" <[email-masked]>,  
<[email-masked]>, "Acee Lindem" <[email-masked]>, "Abhay Roy"  
<[email-masked]>
Subject: RE: [MIB-DOCTORS] MIB Dr. review ofdraft-ietf-ospf-ospfv3- 
mib-13.txt

My understanding is that the ball is in the editor's court. Am I wrong?

Dan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David Ward
> Sent: Saturday, March 14, 2009 12:16 AM
> To: Joan Cucchiara
> Cc: Vishwas Manral; MIB Doctors (E-mail); Dan Joyal;
> [email-masked]; David Ward; Acee Lindem; Abhay Roy
> Subject: Re: [MIB-DOCTORS] MIB Dr. review
> ofdraft-ietf-ospf-ospfv3-mib-13.txt
>
> Just an ICMP-8  that it would be good to get this wrapped up
> and into WG and then IETF LC before and during IETF74 so we
> can have a bit of facetoface review if necessary.
>
> -DWard
>
> On Feb 18, 2009, at 9:40 PM, Joan Cucchiara wrote:
>
>>
>> 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.
>>>
>>>>
>>>>
>>>>
>>>>
>>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>
>
>