Subject: [Capwap] The reply to Bert's comment

From: young <[email-masked]>
Date: Tue, 15 Dec 2009 18:02:22 +0800

Hi, Bert:

Thanks. Here I give a list of changes should be made.
Since I have to take a business trip, I have to keep 
two issues open.

W:
SMICng (strict checking) tells me:
 f(capwap-base.mi2), (851,17) Item "capwapBaseWtpStateWtpBaseMacAddress"
should have SIZE specified
[Editors] 
According to the following text in the RFC5415，The MAC Address is EUI-48
[EUI-48] or EUI-64.
So the change would be: 
capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (8))
Also, I think size of CapwapBaseStationIdTC, CapwapBaseWtpIdTC should be 8.
My doubt:
Whether is it required to add a new MIB object to specify the MAC address
type? EUI-48 or EUI-64. I am not sure.

[new issue] 
1)	Also Bert raised another issue: Although the Reference of the
capwapBaseWtpStateWtpBaseMacAddress tells the Section 4.6.40 in the RFC5415,
it does not clearly tell that the MIB object corresponding to the sub
element Base MAC Address in the RFC5415. 
For the reference part, is there any common rule in the IETF? 
Do we need to update the Reference like:
    REFERENCE
        " The sub-element Base MAC Address in the Section 4.6.40. of CAPWAP
Protocol Specification, RFC 5415."
If we follow this change (or similar), lots of changes for other references
are required.

W:
SMICng (strict checking) tells me:
f(capwap-base.mi2), (974,17) Item "capwapBaseWtpBaseMacAddress" should have
SIZE specified
[Editors] 
According to the following text in the RFC5415，The MAC Address is EUI-48
[EUI-48] or EUI-64.
So the change would be: capwapBaseWtpBaseMacAddress PhysAddress  (SIZE (8))

W: 
SMICng (strict checking) tells me:
f(capwap-base.mi2), (2038,17) Item "capwapBaseNtfStationIdList" should have
SIZE specified
[Editors] 
Suggest capwapBaseNtfStationIdList  OCTET STRING (SIZE (6..1024))
Should the size give a minimal value 6? Thus, at least, it should contain
one item of Station Id (EUI-48).

W: 
SMICng (strict checking) tells me:
f(capwap-base.mi2), (1293,7) Row "capwapBaseStationEntry" does not have a
consistent indexing sche
me - cannot specify an index item from additional "base row"
capwapBaseWtpEntry, since can have only
one "base row" which is capwapBaseWirelessBindingEntry
The INDEX is as follows:
 
    INDEX {
      capwapBaseWtpCurrId,
      capwapBaseWirelessBindingRadioId,
      capwapBaseStationId
    }
 
The first one is the first index in another table
The second one is the 2nd index in yet another table
The 3rd one is an index (the 3rd one) in this table capwapBaseStaionTable.
 
That is indeed some sort of weird indexing. So that is why SMICng gives a
warning.
It does not mean it is absolutely a fatal error. But it would be good that
the CAPWAP
WG checks if this is indeed the indexing they intended and wanted
[Editors] 
I think the index is correct.
capwapBaseWtpCurrId is to indicate the Id of WTPs which are connecting to
the AC.
Another index capwapBaseWtpProfileId is together with
capwapBaseWirelessBindingRadioId.
capwapBaseWtpProfileId is to identify a WTP profile which would be used by a
specific WTP (capwapBaseWtpCurrId). Since the relationship between
capwapBaseWtpCurrId and 
capwapBaseWtpProfileId is 1:1. So the index in such way should be ok.
Yes, It would be better if the description could give some explain to the
reason. 
Could you suggest the text for it? Thanks.

W:
SMICng (strict checking) tells me:
f(capwap-base.mi2), (1509,13) Row "capwapBaseRadioEventsStatsEntry" does not
have a consistent ind
exing scheme - cannot specify an index item from additional "base row"
capwapBaseWtpEntry, since can
have only one "base row" which is capwapBaseWirelessBindingEntry

Here the index objects are:
 
    INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }
 
That looks better, but again the the 2nd index is a 2nd index object in
another
table that gets added as the 2nd index here. Pls make sure this is what the
WG intends and wants and that the indexing makes sense.

For these "does not have a consistent indexing scheme" warnings, it would be
good to add
some comment lines to the MIB module that explain why this indexing is
OK/INTENDED.
Something like:
 
    -- The following indexing is intended because we want to show a table
that
    -- ... here you text ...
    INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }
 
That way, when the SYNTAX check is done, and the MIB doctor checks the MIB
module,
then he can see the explanation and see that the indexing is indeed intended
and nit
inconsistent by accident.
 [Editors] same as above one.

W: 
capwapBaseAcNameListRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This variable is used to create, modify, and/or delete a row
         in this table."
    ::= { capwapBaseAcNameListEntry 4 }

I thought that a RowStatus object MUST describe if and under which
conditions
any writable (including read-create) objects can be modified if the row is
Active?

The same holds true for some (all?) other RowStatus objects
 [Editors] 
Yes. It should be modified. Since I would take business trip, I have to give
the text after I got back.  We keep it open.

W: 
capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "When capwapBaseWtpProfileWtpStaticIpEnable is true,
         it represents the static IP address to be assigned to the WTP."
    REFERENCE
        "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 9 }

I thought that nay object of SYNTAX InetAddress MUST state in its
DESCRIPTION
clause which object of SYNTAX InetAddressType specifies the format?
Further, it seems that "dns" is a valid InetAddressType. So in that case,
the
DESCRIPTION clauses MUST explain when the dns name is resolved.
See RFC4001 for details.
Same question for various other objects of SYNATX InetAddress.
[Editors] 

1) For capwapBaseWtpProfileWtpStaticIp

The change would be:

capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the static IP address type used by the WTP.
The object supports the value of ipv4(1) and ipv4z(3), and does not
support the value of unknown(0) , ipv6(2) , ipv6z(4) and dns(16) ."
    ::= { capwapBaseWtpProfileEntry 8 }

* Please refer to the Section 4.6.48 in the RFC5415.

Add “The IP address type supported is specified by the
capwapBaseWtpProfileWtpStaticIpType”.

capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "When capwapBaseWtpProfileWtpStaticIpEnable is true,
         it represents the static IP address to be assigned to the WTP.
         The IP address type supported is specified by the
capwapBaseWtpProfileWtpStaticIpType."
    REFERENCE
        "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 9 }

capwapBaseWtpProfileWtpNetmask OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "When capwapBaseWtpProfileWtpStaticIpEnable is true,
         it represents the netmask to be assigned to the WTP.
         The IP address type supported is specified by the
capwapBaseWtpProfileWtpStaticIpType."
    REFERENCE
        "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 10 }

capwapBaseWtpProfileWtpGateway OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "When capwapBaseWtpProfileWtpStaticIpEnable is true,
         it represents the gateway to be assigned to the WTP.
         The IP address type supported is specified by the 
capwapBaseWtpProfileWtpStaticIpType."
    REFERENCE
        "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 11 }

2) For capwapBaseWtpStateWtpIpAddress
The change would be:

capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE
    SYNTAX      InetAddressType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address type of a WTP.
The object supports the value of ipv4(1) , ipv6(2) , ipv4z(3), ipv6z(4) and
dns(16), and does not support the value of unknown(0) ."
    ::= { capwapBaseWtpStateEntry 2 }

capwapBaseWtpStateWtpIpAddress OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address of a WTP. The IP address type is 
specified by the capwapBaseWtpStateWtpIpAddressType. "
    ::= { capwapBaseWtpStateEntry 3 }

W: 
capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
    SYNTAX      INTEGER {
                  limited(0),
                  fullAndLimited(1)
                }
    MAX-ACCESS  read-create
    STATUS      current

Normally we recommend that ENUMERATIONS do NOT start with zero, unless
there is a good reason (which we then like to see in the DESCRIPTION
clause).
So... what is the reason?
Same question for: capwapBaseWtpDiscoveryType
And for: capwapBaseWtpEventsStatsLastFailureType
And possibly others!! pls check.
[Editors] 
There is a lot of capwap variables are defined using enumerated value 
start from 0, such as 4.6.21.  Discovery Type,  4.6.34.  Radio 
Operational State, 4.6.44.  WTP MAC Type...
Just think using the same values as what defined in the capwap 
protocol will make the MIB easier to use.

Would add a note in the description of the capwapBaseWtpProfileWtpEcnSupport
:
capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
    SYNTAX      INTEGER {
                  limited(0),
                  fullAndLimited(1)
                }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the support for the Explicit Congestion Notification
         (ECN) bits, as defined in [RFC3168].
         The following enumerated values are supported:
           limited(0)        - Limited ECN support
           fullAndLimited(1) - Full and limited ECN support
         Note that the CAPWAP field [RFC 5415] modelled by this object 
takes zero as Starting value, this MIB object follows this rule."
    REFERENCE
        "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 20 }

A same chane change would be added to the following MIB objects:
> CapwapBaseMacTypeTC
> capwapBaseDataChannelDTLSPolicyConfig
> capwapBaseWtpProfileWtpEcnSupport
> capwapBaseWtpDiscoveryType 
> capwapBaseWtpEventsStatsLastFailureType
> capwapBaseRadioEventsStatsLastFailType
> capwapBaseNtfRadioOperStatusFlag
> capwapBaseNtfRadioStatusCause

[Bert new comments]
Bert could live with starting at zero.I would still think it be better to
start at 1.
But I leave it now up to Dan to decide.

W: 
capwapBaseWtpEventsStatsInitCount OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the number of reboots that have occurred at the
         request of a CAPWAP protocol message, such as a change in
         configuration that requires a reboot or an explicit CAPWAP
         protocol reset request.  A value of 65535 implies that this
         information is not available on the WTP."
    REFERENCE
        "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpEventsStatsEntry 2 }

I do not believe that a SYNTAX of Counter32 allows any value (like the
65535) 
to have a specific meaning !!!!! This is impossible given the semantics for
the
Counter32 SYNTAX.

Same for: capwapBaseWtpEventsStatsRebootCount
and possibly others, pls check and make sure.

[Editors]
According to the suggestion in the CAPWAP mailing list, the change would be:
capwapBaseWtpEventsStatsRebootCount OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Represents the number of reboots that have occurred due to a
          WTP crash. 
          Note that the CAPWAP field [RFC 5415] modelled by this counter 
          takes the value 65535 to indicate that the information is not
available
          on the WTP. This MIB object does not follow this behaviour which 
          would not be standard in SMIv2. If the WTP does not have the
information, 
          the agent will not instantiate the object."
     REFERENCE
         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415."
     ::= { capwapBaseWtpEventsStatsEntry 1 }

 A same change would be done to the capwapBaseWtpEventsStatsInitCount.

W: 
I wonder if there is a risk of sending too many notifications in a very
short time?
IS there a way to control the rate of notifications?
If the risk does not exist, then maybe some words about that would be good.
[Editors] 
Yes, controls flags for the notification are necessary.
The changes would be:

-- for notifications

capwapBaseNotifyControlObjects OBJECT IDENTIFIER
    ::= { capwapBaseObjects 6 }

capwapBaseChannelUpDownNotifyEnable  OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the Channel Up/Channel Down notification
should be generated.
           The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { disabled }
    ::= { capwapBaseNotifyControlObjects 1 }

capwapBaseDecryptErrorNotifyEnable OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the decryption error notification should be
generated.
             The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { enabled }
    ::= { capwapBaseNotifyControlObjects 2 }

capwapBaseJoinFailureNotifyEnable OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the notification of WTP join failure should

be generated.
           The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { enabled }
    ::= { capwapBaseNotifyControlObjects 3 }

capwapBaseImageUpgradeFailureNotifyEnable OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the notification of WTP image upgrade
failure 
should be generated.
            The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { enabled }
    ::= { capwapBaseNotifyControlObjects 4 }

capwapBaseConfigMsgErrorNotifyEnable OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the notification of configuration message
error 
should be generated.
             The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { disable }
    ::= { capwapBaseNotifyControlObjects 5 }

capwapBaseRadioOperableStatusNotifyEnable OBJECT-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the notification of a radio's operational
state 
change should be generated.
             The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { disable }
    ::= { capwapBaseNotifyControlObjects 6 }

capwapBaseAuthenticationFailure NOTIFICATION-TYPE
    SYNTAX      INTEGER {
                  enabled(1),
                  disabled(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            " Represents whether the notification of authentication failure 
should be generated.
             The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
    DEFVAL { disable }
    ::= { capwapBaseNotifyControlObjects 7 }

In the Module compliance, the following changes are required.
    
 GROUP capwapBaseNotifyControlGroup
     DESCRIPTION
         "The capwapBaseNotifyControlGroup group is optional.
          If capwapBaseNotificationsGroup is supported,
          this group must be implemented."

capwapBaseNotifyControlGroup OBJECT-GROUP
    OBJECTS {
capwapBaseChannelUpDownNotifyEnable,
capwapBaseDecryptErrorNotifyEnable,
capwapBaseJoinFailureNotifyEnable,
capwapBaseImageUpgradeFailureNotifyEnable,
capwapBaseConfigMsgErrorNotifyEnable,
capwapBaseRadioOperableStatusNotifyEnable,
capwapBaseAuthenticationFailure
    }
    STATUS  current
    DESCRIPTION
        "Objects used to enable or disable notifications."
    ::= { capwapBaseGroups 18 }

W: 
In the MODULE-COMPLIANCE, I would have expected at least that some (or all)
of
the IF-MIB module would also be mandatory???!!!
Section 7.2 of draft-ietf-capwap-base-mib-06.txt states that 
       The IF-MIB module is required to be supported on the AC.
 So when I see a MODULE-COMPLIANCE, I would have expected something like:
 
capwapBaseCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Describes the requirements for conformance to the
        CAPWAP-BASE-MIB module."
 
   MODULE  IF-MIB 
       MANDATORY-GROUPS {
            some mandatory groups from the IF-MIB, possibly all?
       }
   ... potentially some optional groups from IF-MIB as well?
 
   ... and then follow the MANDATORY GROUPS of THIS MODULE (the
CAPWAP-BASE-MIB module)
  
   MODULE -- this module
     MANDATORY-GROUPS {
       capwapBaseAcNodeGroup,
       capwapBaseWtpProfileGroup,
       capwapBaseWtpStateGroup,
       capwapBaseWtpGroup,
       capwapBaseRadioGroup,
       capwapBaseStationGroup
     }
 
For an example, see RFC3811, but also RFC3289
But then, maybe if indeed the WHOLE IF-MIB MUST be supported, then just
stating that
may be OK.

 [Editors] 
Yes. Since I would take business trip, I have to give the text after I got
back. We keep it open.

Regards
Richard

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 16 Dec 2009 11:15:13 +0100

My comments/reactions/answers inline

> capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (8))

If it can be EITHER EUO48 or EUI64, then it sounds to me that the size
must be either
6 or 8. Any other size seems then invalid, right?

So the way to specify that would be:

     capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (6|8))

> type? EUI-48 or EUI-64. I am not sure.
It seems that if the above PhysAddress is used, that one can determine
from the
actual size of the instance of an object if it is EUI48 or EUI 64, no?

> If we follow this change (or similar), lots of changes for other references

I think the reference should just be to the section 4.6.0.
In the DESCRIPTION clause of the MIB object, you can describe what piece of
the spec, namely the sub-element, is to be represented in the object.

> So the change would be: capwapBaseWtpBaseMacAddress PhysAddress  (SIZE (8))
see above
> one item of Station Id (EUI-48).

If an empty list is not allowed/wanted, then yep, do use a min size that
can contain
one element. But this is up to the WG to decide.
> Could you suggest the text for it? Thanks.
Not sure it is clear to me yet.
Is it clear to other CAPWAP WG participants?

> the text after I got back.  We keep it open.

ok, will wait for the results to come in later
>     ::= { capwapBaseWtpProfileEntry 8 }
If that is what you want, then you would do something like

capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
    SYNTAX      InetAddressType {ipv4(1), ipv4z(3)}
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the static IP address type used by the WTP. 
         Only ipv4(1) and ipv4z(3) are supported by CAPWAP."
     ::= { capwapBaseWtpProfileEntry 8 }

You may get in trouble now... because WHY would you not support IPv6 ???
Does CAPWAP not support IPv6? If not, then I suggest you add an explanation
that states so. That explains it, and so if the base CAPWAP protocol has
been
approved without IPv6 support, then not supporting it in the MIB module is
fine too I think.

Another way to do this, is to just keep

    SYNTAX      InetAddressType

And then in the MODULE compliance specify that only ipv4 needs to be supported.
That way, the MIB module itself is prepared for IPv6, and if such ipv6 support is
ever needed in the future, then it is just a matter of adding/defining a new 
MODULE-COMPLIANCE without any changes to teh MIB module itself.

>     ::= { capwapBaseWtpProfileEntry 11 }
the above is good, although I think I would state it different
instead of

I think I would write

     The format of this IP address is determined by the corresponding
     instance of object  capwapBaseWtpProfileWtpStaticIpType."

So... it is not about "what is supported", it is how one can determine
what the
format of an instance of the InetAddress object is.
>     ::= { capwapBaseWtpStateEntry 2 }

see above
>     ::= { capwapBaseWtpStateEntry 3 }

see above
>     ::= { capwapBaseWtpProfileEntry 20 }
Dan Romascanu can tell you if this is acceptable.
Given the addition of the xaplantion, I can live with it.

>  A same change would be done to the capwapBaseWtpEventsStatsInitCount.
sounds OK to me.

>     ::= { capwapBaseNotifyControlObjects 7 }

Wow, that are a lot of toggles. I can live with it.
I could live with fewer toggles that enable/disable (a) set(s) of
notifications.
Up to the the editors and the WG.

Once comment on the above toggles. Might it be better to re-use the TC
TruthValue
from RFC2579? So instead of

(missing "Enable" from the next one??)

            "Represents whether the notification of authentication failure 

you could do:

     capwapBaseAuthenticationFailureEnabled NOTIFICATION-TYPE
         SYNTAX      TruthValue
         MAX-ACCESS  read-write
         STATUS      current
         DESCRIPTION
            "Represents whether the notification of authentication failure 
             should be generated.
             A value of true(1) means that the notification is enabled
             A value of false(2) means that the notification is disabled."
         DEFVAL { false }
         ::= { capwapBaseNotifyControlObjects 7 }

I happen to like re-use of SYNTAX/TC if possible.
But defining your own enumeration does work too.,

Some of the ...Enable objects do not have a DEFVAL ??
Is that intentional?

> Yes. Since I would take business trip, I have to give the text after I got

OK

Bert

---

From: Yong Zhang <[email-masked]>
Date: Wed, 16 Dec 2009 09:33:23 -0800

Bert,

CAPWAP supports IPv6. But for the capwapBaseWtpProfileWtpStaticIp, it
is used to support 4.6.48.  WTP Static IP Address Information in RFC
5415, P97, which said

   The WTP Static IP Address Information message element is used by an
   AC to configure or clear a previously configured static IP address on
   a WTP.  IPv6 WTPs are expected to use dynamic addresses.

So only IPv4 address ias needed for this MIB object.

Thanks!

Yong

2009/12/16 Bert (IETF) Wijnen <[email-masked]>:
>> Add "The IP address type supported is specified by the
>> capwapBaseWtpProfileWtpStaticIpType".
>>