[mpls] MIB DR. review of draft-ietf-mpls-tp-oam-id-mib-01.txt

["Joan Cucchiara" <[e-mail]>]

Hello,

Please accept this MIB review as part of the WG LC comments.
Compiler output which is followed by General Comments and
then more specific comments.

Thank you,
  -Joan


smicngPRO
E: f(MPLS-OAM-ID-STD-MIB.my), (111,8) Row "mplsOamIdMegEntry" may not have 
columns with MAX-ACCESS of read-write if any column is read-create
E: f(MPLS-OAM-ID-STD-MIB.my), (162,17) Index item "mplsOamIdMegIndex" must 
be defined with syntax that includes a range
E: f(MPLS-OAM-ID-STD-MIB.my), (240,19) Size of default value for 
"mplsOamIdMegIdIcc" is outside allowed range
E: f(MPLS-OAM-ID-STD-MIB.my), (257,19) Size of default value for 
"mplsOamIdMegIdUmc" is outside allowed range
E: f(MPLS-OAM-ID-STD-MIB.my), (433,23) Index item "mplsOamIdMegIndex" must 
be defined with syntax that includes a range
E: f(MPLS-OAM-ID-STD-MIB.my), (434,23) Index item "mplsOamIdMeIndex" must be 
defined with syntax that includes a range
E: f(MPLS-OAM-ID-STD-MIB.my), (435,23) Index item "mplsOamIdMeMpIndex" must 
be defined with syntax that includes a range

Compiles cleanly with smilint.

GENERAL COMMENTS
--------------------------------------
0) The draft proposes supporting LSPs, pseudowires
and sections.  Was the LC posted on pwe3 WG?

1) The MIB Module and Managed Objects do not
reflect that this is MPLS-TP, why is that?

2) Terminology is not consistent with rfc5654 or rfc5860.
They use the terms MPLS in Transport Networks, or
MPLS Transport Profile, and this draft
refers to this as "MPLS based Transport Profile".  Please
be consistent with these RFCs.

3) In general need more REFERENCES and more specific REFERENCES.
Specifying an entire RFC is not nearly as helpful as specifying
a section or subsection of an rfc.

4) Inconsistent use of RFC names.  For example in Section 3.2

"This document uses terminology from the MPLS architecture document
[RFC3031], MPLS Traffic Engineering Management information [RFC3812],
MPLS Label Switch Router MIB [RFC3813] ....and MPLS-TP Identifiers document
[RFC6370]."

Sometimes a very informal name for document title, sometimes part of
a title and sometimes the full title.  Please consistently give
the full title, so:
MPLS Label Switching Architecture [RFC3031],
MPLS Label Switching (MPLS) Label Switching Router (LSR) Management
Information Base (MIB) [RFC3812] and so forth.


5) Similar to the above, please reference MIB Modules by the
Module Name.  Someplaces do this, but some say MPLS Traffic Engineering MIB
or LSR MIB.  Again, please just be consistent.

6) Please capitalize the MIB.


SPECIFIC COMMENTS
-------------------------------
Section 5.1

s/in this table for MPLS tunnel/ in this table for MPLS tunnels/


Section 6.

Please rework the title of this Section.  It is awkward to read.

s/for MPLS co-routed/ for an MPLS co-routed/

s/of MPLS tunnel/of an MPLS tunnel/


MIB MODULE
------------

*) DESCRIPTION
  "MPLS OAM Identifiers mib objects for LSPs and Pseudowires"

s/mib/MIB/


*) Why is there no IndexNext scalar to assist operators
in configuring the mplsOamIdMegTable?

*) mplsOamIdMegIndex
May want to consider starting the index at 1 per
the rfc4181 Section 4.6.1.1

*) Mix of read-write and read-create in this table,
and when creating a row (i.e. utilizing RowStatus, should
use read-create.)

*) some of these SnmpAdminString values say that NULL is acceptable,
so maybe SIZE starting at 0 ?


*) mplsOamIdMegServiceType
DESCRIPTION clause is awkward.

Indicates the service type for the MEG?

What is the "service pointer", could you please
state which object and be very specific, i.e.
points to an entry in the mplsTunnelTable [RFC3812], etc.

Same issue with the next 2 paragraphs.


* Order of these objects.   Typically, all objects
are appear before StorageType and RowStatus.
I don't believe this is mandatory, but certainly,
convention.  If objects are added after RowStatus that
usually happens for revisions of the RFC.

*) mplsOamIdMeTable

Are entries in this table created dynamically and/or
manually?  Please clarify.

*) mplsOamIdMeIndex and mplsOamIdMeMpIndex
Same comment as above with regard to a IndexNext scalar
and starting these indices at 1 as suggested by rfc4181 Section 4.6.1.1


*) mplsOamIdMeMpIfIndex
Please include in the DESCRIPTION which ifType is
associated with the various possiblities for this
value.


*) mplsOamIdMeMepDirection

The DESCRIPTION is confusing.  If the mplsOamIdMeMpType is
not mep(1), what happens if this value is set?  What happens
upon a get request?


*) mplsOamIdMeProactiveOamPhbTCValue/mplsOamIdMeOnDemandOamPhbTCValue

Was the intention to make this a TC?
Is this something that IANA should administer?


*) same comments as before with regards to the order
of StorageType and RowStatus objects.


*) Notifications

Why are these accessible-for-notify objects not
included as part of the Tables?  I think they would
be relevant and helpful in monitoring.

The mplsOamIdDefectCondition
When is this supposed to be sent?  I think
the DESCRIPTION should be specific about
when this notification is triggered.

*) OID layout is not as suggested by rfc4181

   \-2 mplsOamIdConformance
     \-v-1 mplsOamIdGroups
       | \-v-1 mplsOamIdMegGroup
       |   |-2 mplsOamIdMeGroup
       |   |-3 mplsOamIdNotificationObjectsGroup
       |   \-4 mplsOamIdNotificationGroup
       \-2 mplsOamIdCompliances
         \---1 mplsOamIdModuleFullCompliance

rfc4181, Appendix D.
 xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)




*) Compliance

There is no read-only compliance. Has it been made clear
to the WGs (MPLS and PWE3) that SNMP sets will need to
be supported in order to be compliant with the MIB?


8. Security Considerations

This section needs to be completed.
Please rework this section.

9.IANA Considerations

This section needs to be completed.



10.2 Informative References

What order are these in?

-- end --





----- Original Message ----- 
From: "Loa Andersson" <[e-mail]>
To: <[e-mail]>
Cc: "MPLS-TP ad hoc team" <[e-mail]>; 
<[e-mail]>
Sent: Friday, October 12, 2012 8:52 AM
Subject: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib


> Working Group,
>
> this is to start a two week working group last call on
> draft-ietf-mpls-tp-oam-id-mib-01.
>
> Please send your comments to the mpls working group mailing
> list ([e-mail]).
>
> Please send both technical comments, and if you are happy with the
> document as is also indications of support.
>
> This working group last call will end on October 28.
>
> /Loa
> for the wg co-chairs
> -- 
>
>
> Loa Andersson                         email: [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                              [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls