[mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-id-mib-03.txt

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

Authors,

For this review, I looked over the  comments from 02 to see how these comments were addressed.  
(Version 02 comments are copied below and comments for Version 03 are prefaced with JEC.)

As you can see most of the Version 02 comments have been addressed, so thank you for that!

A few comments from 02 have not been updated in version 03.
The 3 comments which I think needs some attention are:

1) MplsOamPhbTCValue 
Textual Convention should have a reference within MPLS.    Even if the values have been assigned by
the authors, an indication of where BHP Traffic Classes are derived from within MPLS OAM seems
reasonable.  

2) mplsOamIdMeMpIfIndex
The REFERENCE for RFC6371 doesn't seem to refer to this object. Could 
REFERENCE be checked?  (I thought a change here was agreed to but didn't see an updated REF.)

3) No ReadOnly conformance.  Please confirm that WG is agreeable to
have a MIB that does not have a ReadOnly Conformance.
As you are aware, some operators prefer not to use SNMP 
for configuration, so if this MIB does not support a ReadOnly Conformance,
then vendors will not be compliant if they support this MIB as it
exists now.

4) Security Section (see below).


Thanks,
  -Joan



Specific Comments on this version 03 are prefaced with  JEC:
============================================

Section 3.3 Acronyms


* MIP is specified slightly differently in the referenced docs.
Please be consistant.

JEC: Updated.


Section 6.

This example, specifies the mplsOamIdMeMpEntry as a MEP, but why 
isn't the SourceMepIndex or SinkMepIndex == mplsOamIdMeMpIndex?

Also, there are at least 2 MEPs in an ME, and at least one ME
in a MEG and these relationships are not completely evolved
in this example.  I think the example should be expanded
to agree with what is stated in the first paragraph.


JEC:  The example was not evolved, but the first text was modified
to agree with the example, so I can live with that.



MIB Module comments
-------------------

* TC:  MplsOamPhbTCValue


         MplsOamPhbTCValue ::= TEXTUAL-CONVENTION
            STATUS              current
            DESCRIPTION
                "This is the Per-hop Behavior (PHB) traffic class values
                 for the MPLS OAM operations."
            SYNTAX        INTEGER {
                            be (1),
                            af1 (2),
                            af2 (3),
                            af3 (4),
                            af4 (5),
                            ef (6),
                            cs6 (7),
                            cs7 (8)
                          }


Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of 
Differentiated Services", specifies that MPLS TP will use DSCP as per 
rfc2474 and other specs.   Is that the intent wrt this TC?

If not, please explain where these values are defined, otherwise, 
if these values are as per rfc3270, then please be consistant with the labels.

TC labels should correspond more closely to DiffServ BHB traffic class values.
In other words, 

http://www.iana.org/assignments/dscp-registry/dscp-registry.xml

   Name     Space  Reference
   CS0         000000 [RFC2474]
   CS1         001000 [RFC2474]
   CS2         010000 [RFC2474]
   CS3         011000 [RFC2474]
   CS4         100000 [RFC2474]
   CS5         101000 [RFC2474]
   CS6         110000 [RFC2474]
   CS7         111000 [RFC2474]
   AF11        001010 [RFC2597]
   AF12        001100 [RFC2597]
   AF13        001110 [RFC2597]
   AF21        010010 [RFC2597]
   AF22        010100 [RFC2597]
   AF23        010110 [RFC2597]
   AF31        011010 [RFC2597]
   AF32        011100 [RFC2597]
   AF33        011110 [RFC2597]
   AF41        100010 [RFC2597]
   AF42        100100 [RFC2597]
   AF43        100110 [RFC2597]
   EF PHB      101110 [RFC3246]
   VOICE-ADMIT 101100 [RFC5865]


Continuing with that thought: I believe this TC could (and should) be 
formalized into an IANA-Maintained MIB if these values are the same
as the above IANA-Maintained assignments for DFCPs.  
(NOTE: this was mentioned also in the LC comments.)  Please discuss.

Also, this TC should have a REFERENCE clause.


JEC:  Not done.   So, a REF clause to at least explain where MPLS OAM PHB is 
described would be helpful.  


* mplsOamIdMegIndex
There is no information about how to employ mplsOamIdMegIndexNext to 
obtain a value for this index.   Please update the DESCRIPTION accordingly.

JEC: Updated.



* mplsOamIdMegOperatorType
Why does this say "should have valid values...", isn't this a MUST?
Also, s/while making/when/

JEC:  Updated.


* mplsOamIdMegIdCc

s/contains non-null ICC/MUST contain a/

s/otherwise null ICC value/otherwise a null ICC value/

s/should be assigned/MUST be assigned/


JEC:  Updated.


* mplsOamIdMegIdIcc

Same comments as above.   Please use MUST.

JEC:  Updated.


* mplsOamIdMegIdUmc
Same comments as above.  Please use MUST.

JEC:  Updated.



* mplsOamIdMegServiceType
Could you please specify the service pointer by the object's name?

Also, the references are within the DESCRIPTION which is fine, but
they should also be in a REFERENCE clause.

JEC:  Updated.  I was asking that actual object names be used in this
DESCRIPTION clause.  For example, the phrase "the service pointer
in the mplsOamIdMeTable" to change to THAT object's name, 
i.e. mplsOamIdMeServicePointer.  Similar comment wrt the paragraph 
on the pointer in PW.


* mplsOamIdMeIndexNext and mplsOamIdMpIndexNext
These objects are not referred to by mplsOamIdMeIndex or mplsOamIdMeMpIndex.
There is not enough description to understand how the IndexNext objects
are to be used. 

JEC:  Updated.


* MplsOamIdMeTable

The mplsOamIdMeEntry states "An entry in this table
represents MPLS-TP maintenance entity."   Yet, looking at the 
              INDEX { mplsOamIdMegIndex,
                      mplsOamIdMeIndex,
                      mplsOamIdMeMpIndex
                    }

This is not an ME because an ME by definition has 2 (source/sink)MEPs.
An entry in this table represents either a MEP or MIP, not an ME.

JEC: okay.


*) What is the benefit of combining MEP and MIP (i.e. the objects 
which contain "Mp" as part of their object name)?
Many other objects in this table, need to figure out if the entry
is describing a MEP or MIP before the value can be interpreted correctly.
Additionally, there is duplicate info in the form of having a Source and
Sink specified for each Mp. Could you elaborate on what the 
benefit is of having listing MEPs and MIPs in this way?

It seems like the original intent may have been to specify an ME
as being an entry in this table.  However, that would mean the table
should probably be indexed by MEG index, a ME index, a source MEP index 
and a sink MEP index.

This would  greatly simplify many of the object descriptions.  

Have you considered specifying MIPs in a 3rd table, such that each
ME would have 2 MEPs and zero or more MIPs?

Please discuss.   


JEC: okay.



*) mplsOamIdMeMpIfIndex

Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states
"Note that IF_Num had no relation with the ifNum object defined in 
RFC2863.  Further, no mapping is mandated between IF_Num and ifIndex in
RFC 2863."

I don't see any mention of ifIndex in RFC 6371, so could you tell me what
Section?   Is this object supposed to represent IF_NUM in rfc6370?

JEC: Not updated.   I think this is an oversight and you had already found
a correct REFERENCE but couldn't locate that email...


*) mplsOamIdMeServicePointer

The DESCRIPTION contains wording which is very loose.  Could you
please use wording which specifies a "SHOULD" or "MUST"?
Under what circumstances should this be 0.0?

JEC: Updated.

Compliance Statement of the MIB

*) Compliance (This has been asked before and I have not
seen any discussion about it.)

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?

JEC: Not done.


*) question above, about whether the intention is to support
ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may
affect this.

      "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
      MANDATORY-GROUPS {
         ifGeneralInformationGroup,
         ifCounterDiscontinuityGroup"


*)    mplsOamIdNotificationObjectsGroup  OBJECT-GROUP

I don't see a need to make a specific group for
these objects.  They are already specified by mplsOamIdGroups.

JEC:  Updated.


Section 8. Security Section

Need to reference specific read-create objects and also read-only which 
could impact the network.

Additionally, the incomplete sentence: 
"These are the tables and objects and their sensitivity/vulnerability: "
needs to be completed.

JEC: Not done.


Section 9.  IANA Considerations

s/specified this document/specified in this document/
missing the word "in"

JEC: Updated.


Section 11. 
Thank you for the ack!