Re: [mpls] MIB Dr. review of draft-ietf-tp-linear-mib-09

["Ryoo, Jeong-dong " <[e-mail]>]

Joan,


Thank you so much for your work on this.

The document has been greatly improved through your review and comments in the previous revisions.


Best regards,


Jeong-dong









________________________________
보낸 사람 : "Joan Cucchiara" <[e-mail]>
보낸 날짜 : 2016-10-18 12:05:52 ( +09:00 )
받는 사람 : 류정동 <[e-mail]>
참조 : Loa Andersson <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Benoit Claise <[e-mail]>
제목 : Re: 회신: MIB Dr. review of draft-ietf-tp-linear-mib-09



Jeong-dong,





Thank you for the quick turn-around and also for the thoroughness of addressing this last round of comments.   I believe the MIB review is complete.





Thanks again for all your time and effort during this process,



-Joan







On Wed, Oct 12, 2016 at 10:29 AM, 류정동 <[e-mail]<mailto:[e-mail]>> wrote:



Dear Joan,





Thank you so much for your review and comments.



All your comments had been incorporated into the revision posted a few minutes ago as follows.





Name:           draft-ietf-mpls-tp-linear-protection-mib



Revision:       10



Title:          MPLS Transport Profile Linear Protection MIB



Document date:  2016-10-12



Group:          mpls



Pages:          45



URL:            https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-mib-10.txt



Status:         https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection-mib/



Htmlized:       https://tools.ietf.org/html/draft-ietf-mpls-tp-linear-protection-mib-10



Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-linear-protection-mib-10





Would you please let us know if you have any further comments on this document at your earliest convenience?





Best reagrds,





Jeong-dong









________________________________________



보낸 사람: Joan Cucchiara [[e-mail]<mailto:[e-mail]>]



보낸 날짜: 2016년 10월 8일 토요일 오전 9:53



받는 사람: Loa Andersson; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>



참조: 류정동; Benoit Claise



제목: MIB Dr. review of draft-ietf-tp-linear-mib-09





Authors,





Thank you for addressing the comments so thoroughly, and especially for



clarifying the example in section 7.    Much appreciated.





The MIB compiles with smilint and smicngPRO.   Comments are below.





Thank you,



-Joan





Comments:



----------------





1) Section 6.1 Relationship to the MPLS OAM Maintenance Identifiers MIB Module





   "The mplsLpsMeConfigTable entry is extended by the entry in the



   mplsOamIdMeTable defined in [RFC7697]."





The above statement is backwards....think the intention is to say something like:



Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in the mplsLspMeConfigTable.





2) later in this same section, section 6.1





   "An entry of this table is related to a single entry in mplsOamIdMeTable."





The above is confusing because you've already discuss the sparse augments relationship.  Please remove



the above sentence.







MIB Module



------------



3)  mplsLpsConfigIndexNext  -   please rename to mplsLpsConfigDomainIndexNext.



Since this scalar is only used for the mplsLpsConfigDomainIndex index's values, the name should reflect that.



NOTE:  this name change should be propagated elsewhere in the draft.  Please do a search and replace.





4) mplsLpsConfigDomainIndex  (editorial)



  "Managers should..."





s/Managers/Operators/







5) mplsLpsConfigCommand



Why is there NO DEVAL?   Wouldn't "noCmd" be an appropriate DEFVAL?







6) mplsLpsConfigRowStatus DESCRIPTION clause





RowStatus objects reflect the status of the Row, not a determination of whether or not values



are "appropriate".  Please remove the last sentence of this DESCRIPTION:





         "...An entry may not exist in the active state unless all



          objects in the entry have an appropriate value."







7)  mplsLpsConfigDomainIndex and mplsLpsMeConfigDomain





Since MIBs often get stripped out of RFCs, the relationship between the mplsLpsConfigDomainIndex and



the mplsLpsMeConfigDomain needs to be included in the MIB Module itself.





Both DESCRIPTION clauses need to be updated to describe the relationship between these objects.   Verbage such as "When the



value of mplsLpsConfigDomainIndex is the same as the value of mplsLpsMeConfigDomain, that means..." and then explain what



this means.





8)  mplsLpsMeConfigDomain DESCRIPTION (editorial)



         "This object holds the value of protection domain index wherein



          this ME included in.





s/included in/is included/





---