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

[류정동 <[e-mail]>]

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]]
보낸 날짜: 2016년 10월 8일 토요일 오전 9:53
받는 사람: Loa Andersson; [e-mail]; [e-mail]; [e-mail]; [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/

---