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

[Sam Aldrin <[e-mail]>]

Hi Joan,

Once again, thank you for your review and valuable comments.
Will address them at the earliest.

thanks again
-sam
On Dec 2, 2013, at 10:03 AM, Joan Cucchiara <[e-mail]> wrote:

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