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

From: David Ward <[email-masked]>
Date: Fri, 13 Mar 2009 17:16:07 -0500

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.
>>
>>>
>>>
>>>
>>>
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 17 Mar 2009 20:49:40 -0500

Dan,

The editor's emailed me an updated mib yesterday with a compiler related 
question
which I'm working on now and should have an answer for them in the next day 
or
two.

   Thanks,
      -Joan

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
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]>
Sent: Monday, March 16, 2009 8:54 AM
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

> 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
>
> >>> Cc: Dan Romascanu; Abhay Roy; David Ward; Ronald Bonica; Joyal,
> >>> Daniel (BL60:SF23); Vishwas Manral; Acee Lindem
> >>> First, I do apologize for being late with this review,
> thank you for
> >>> your patience.
> >>>
> >>> The MIB compilers' outputs are given, followed by output
> from IDNITS
> >>> (http://tools.ietf.org/tools/idnits/)
> >>> followed by comments.
> >>>
> >>> 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"
> >>>
> >>
> 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:
> >
> specific to a
> >> particular address family in cases where the MIB should support
> >> multiple address families.
> >>>  ** 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.
> >>>
> 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.
> >>>
> >>>     "This document and the information contained herein
> are provided
> >>> on an
> SOCIETY,
> >>> THE
> >>>      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
> >>> INFRINGE
> >>>      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
> >>> FITNESS
> scope of
> >>> any
> >>>      Intellectual Property Rights or other rights that might be
> >>> claimed
> >>>      to pertain to the implementation or use of the technology
> >>> described
> represent
> >>> that
> >>>      attempt made to obtain a general license or
> permission for the
> >>> use
> >>>     "The IETF invites any interested party to bring to
> its attention
> >>> any
> >>>      rights that may cover technology that may be required to
> >>> implement
> >>>  == The copyright year in the IETF Trust Copyright Line does not
> >>> match the
> >>>     current year
> >>>
> >>>
> >>>     (See RFCs 3967 and 4897 for information about using normative
> >>> references
> >> 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
> >>> > -----------------
> >>> >
> >>> (NEW)  NIT: would change the name from ospfv3Compliance to
> >>> ospfv3FullCompliance.
> >>
> >> Will change.
> >>
> >>>
> >>>
> >>> >
> >> I'll try to find a user guide for the tool to see what it is
> >> expecting regarding file formatting.
> >>
> >
> > 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.
> >
> >
> >>>
> >>>
> >>>
> 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.
> >>
> > 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.
> >
> > until the actual value was available (e.g. for implementations that
> > don't have all the information available at once during agent
> > start/restart).
> >
> > 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.
> >
> >
> >>
> >>>
> >>>
> >>> 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
> DEFVAL helps
> >>> Agent developers so would add this, unless there is a
> reason not to.
> >>>
> >>
> >> Will add DEFVAL.
> >>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>