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 protected]."
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 protected]
https://www.ietf.org/mailman/listinfo/ospf
