[mpls] 회신: Review of draft-ietf-mpls-tp-linear-protection-mib-08.txt

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

Joan,

A new version (09) of draft-ietf-mpls-tp-linear-protection-mib has been uploaded.
Please, see how we resolved your comments in your previous email starting with [Authors].

I would like to appreciate your review on this revision.

Best regards,

Jeong-dong
(on behalf of the co-authors)


________________________________________
보낸 사람: 류정동
보낸 날짜: 2016년 7월 4일 월요일 오전 10:31
받는 사람: Joan Cucchiara; 'Loa Andersson'
참조: [e-mail]; [e-mail]; [e-mail]; [e-mail]; Joan Cucchiara
제목: RE: Review of draft-ietf-mpls-tp-linear-protection-mib-08.txt

Joan,

Thank you for the comments.
We will work on resolving the issues.

Best regards,


Jeong-dong









________________________________
보낸 사람 : "Joan Cucchiara" <[e-mail]>
보낸 날짜 : 2016-06-30 02:51:55 ( +09:00 )
받는 사람 : 'Loa Andersson' <[e-mail]>
참조 : [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Joan Cucchiara <[e-mail]>, [e-mail] <[e-mail]>
제목 : Review of draft-ietf-mpls-tp-linear-protection-mib-08.txt



Authors,

Thank you for addressing the review comments quickly and I apologize for
being late with the follow-on review. The MIB compiles cleanly with
smingPRO and smilint.

In the previous review the relationship between some tables in the
MPLS-OAM-ID-STD-MIB and in this draft were not clear. While changes have
been made, more clarification is needed. Please keep in mind that
developers need to understand the relationships between these tables and how
the rows in these tables are created (i.e., network management entity and/or
operator).

I have reviewed the changes made from 07 to this draft. I have deleted the
07 comments that are resolved in this new version. If there is still a
clarification that is needed, I added additional comments prefaced by "JEC".


Thanks,

-Joan



Specific Comments:
==================

Section 1. Introduction

"However, since the MIB module specified in this document are ..." <--
plural

JEC: minor edit. In the above sentence, s/are/is/

[Authors] Fixed.


Section 5.4 The Table Structure

* The mplsLpsConfigTable

As a reviewer, this is confusing because the relationship with these tables
is unclear and so it is very difficult to review the MIB Module. Please
clarify the relationship with these tables and to the mplsOamIdMeTable in
the MPLS-OAM-ID-STD-MIB.

[Authors] More text has been added in Sections 5.4 and 6.1 to clarify the relationship.



JEC: This section specifies "The protection domain is identified by
mplsLpsConfigDomainName." and the object's DESCRIPTION indicates that this
value is supposed to be unique, so my question is why does this need to be
unique, and if it really does need to be unique, then why isn't this an
INDEX? Please clarify.

[Authors] It does not have to be unique. It is to facilitate easy administrative identification of each protection domain. The DESCRIPTION sentence has been corrected.


mplsLpsConfigDomainName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Textual name represents the MPLS-TP linear protection domain.
Each protection domain is identified by a unique protection
domain name. "
::= { mplsLpsConfigEntry 2 }

(This object should probably have a DEFVAL{""} since 0 length string is
allowed.)

[Authors] The second sentence in DESCRIPTION has been removed. DEFVAL{""} is added. 


Section 7. Example of Protection Switching Configuration

JEC: The example in this section needs to be reworked. Please use different
values for some of these indices. Too many of these indices are "1" and
that is not very helpful. If the indices are supposed to be the same
values that would be good to know with additional comments too.

[Authors] Modified with different values. For better understanding, the example has been enhanced by showing all necessary entries in the tables. 



MIB Module

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

* mplsLpsConfigDomainName -- Is there a DEFAULT value for this object?

The string size is 1..32 with no option of 0 length string, so wanted to
check about a default value? Under what circumstances can this value be
modified? Please give a REFERENCE.

[Authors] 0 size string is allowed. DEFVAL{""} is added.


JEC: Now that a 0 length string is allowed, there should probably be a
DEFVAL{ ""}; Additionally, why is it necessary to have each Domain Name be
unique? If it MUST be unique, then perhaps it should be an INDEX. Also,

it is unclear how rows in this table are supposed to be created. Could that
be included in the Table's description?

[Authors] mplsLpsConfigDomainName doesn’t have to be unique. It is to facilitate easy administrative identification of each protection domain. This table is created by a network operator, who wants to run MPLS-TP protection protocol and mechanism for the protection domain. New text has been added to clarify better.


* mplsLpsConfigMode - Needs REFERENCE (and please try to be specific).
Under what circumstances can this be modified?

[Authors] REFERENCE is given with a specific sub-section number of the referred document. The following text has been added: “The value of this object is not supposed to be changed during operation. When the value should be changed, protection processes in both LERs MUST be restarted with the same new value.” 


JEC: Still needs a REFERENCE. Need to add what sort of SNMP error code
will be returned when an attempt is made to change this value and RowStatus
== "active", e.g. inconsistentValue Error ?

[Authors] If this value is changed at an LER during operation, then the node will generates protection protocol packets with a different Capabilities TLV value. Then, it will result in mplsLpsEventCapabilitiesMismatch notification, which has already been covered. New text has been added in the DESCRIPTION of this object to clarify better.



JEC: * mplsLpsConfigSdBadSeconds -- see this 2 times in the DESCRIPTION
clause.

This object may be modified if the associated
mplsLpsConfigRowStatus object is equal to active(1).

This object may be modified if the associated
mplsLpsConfigRowStatus object is equal to active(1). "


[Authors] Fixed


JEC: * mplsLpsConfigSdBadSeconds and mplsLpsConfigSdGoodSeconds Did not
see such features as these in the REFERENCE sited. Could you please confirm
REFERENCE. Not clear on how these are used with the SdThreshold. Where
does the DEFVAL of 10 come from?

[Authors] Yes, the REFERENCE should be corrected. The reference should be ITU-T Recommendations G.8121 (Equipment Spec.) and G.8151 (Management Spec.). The DESCRIPTION in mplsLpsConfigSdThreshold explains how those bad/good second values are used. The default value comes from Table 8-1 of G.8151. The DESCRIPTION texts for those objects are now modified to describe them better.


* mplsLpsConfigWaitToRestore
Why is this not in minutes? If someone configures this to be 30 seconds is
that valid? Doesn't seem so based on the DESCRIPTION. Please clarify.

JEC: The DESCRIPTION clause still mentions seconds. ("This object holds
the Wait To Restore timer value in seconds.") Units are in minutes and
the rest of DESCRIPTION clause is in minutes. Please be consistent.

[Authors] Fixed


JEC: * mplsLpsMeConfigDomainIndexValue, is this an INDEX? The name leads
me to believe it is, as does the DESCRIPTION, but have no idea how the
objects in this entry are configured. Please add a REFERENCE clause, or
clarify somehow. This is crucial to the success or failure of this MIB.
Is the network management entity (e.g SNMP Agent/subagent) suppose to create
these rows? Is an operator? Please add details on how entries are made in
this table. You say that it is a Sparse Augments relationship but even
still, very unclear on
how rows are created. If this is NOT an INDEX, then please remove the
term "Index" from the name of this object.

Have to ask If the intention is that one or more entries (i.e. rows in this
table) could be related to a single entry in mplsOamIdMeTable? If so, then
an index is needed.

[Authors] No, this is not an INDEX. mplsLpsMeConfigDomainIndexValue is renamed as mplsLpsMeConfigDomain. This object identifies the protection domain this ME belongs to. As explained in Sections 5.4 and 7 in the revised draft, one protection domain has two MEs, one for the working path and the other for the protection path. 

As described in Section 6.1, each time that an entry is created in the mplsOamIdMeTable for which the LER supports MPLS-TP linear protection, a row is created automatically in the mplsLpsMeConfigTable. This text in Section 6.1 is repeated in the DESCRIPTION in the revised draft.

An entry of this table is related to a single entry in mplsOamIdMeTable. When a point-to-point path needs to be monitored, one ME should be configured for the path and one entry in mplsOamIdMeTable will be created. But, the entry in mplsOamIdMeTable may or may not participate in protection switching. If an ME participates in protection switching, an entry in mplsLpsMeConfigTable must be created, and the objects in the entry indicates which protection domain this ME belongs to and whether this ME is for either working path or protection path. If an ME does not participate in protection switching, an entry in mplsLpsMeConfigTable does not need to be created. This text has been added in the DESCRIPTION.


*mplsLpsMeConfigState is a read-create.

JEC: DESCRIPTION says "operational state" but the name says "ConfigState"
and this is a read-create? Need to decide which this is and be consistent.
Do you need another object for the operational state which is a read-only?

[Authors] This object is to configure an ME to be either the working path or the protection path. The name has been changed to “…ConfigPath” in the revised draft. The DESCRIPTION has been modified, too.


Notifications

* mplsLpsEventFopTimOut Notification
Please rename this to mplsLpsEventFopTimeout

JEC: Not done, please rename to be consistent with other objects in the MIB
Module.

[Authors] Fixed.

---