Subject: Re: [MIB-DOCTORS] More discussion on the Station Index Issue

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 23 Dec 2009 08:30:58 +0100

I can live with that.
CAPWAP WG, pls speak up!

Bert

young wrote:
> Hi, Bert:
>
> My comment is identified by [Richard]
>
> The indexing is indeed (much) simpler... but...
> If there is a possibility of two associations, how do we answer these 
> questions:
> - which of the two entries should be shown in the MIB?
> - what if (because of some problem) the situation exists for a longer 
> time (maybe forever?)
>   that would probably be a bug, but if so, that is something one would 
> like to be able to detect with querying the MIB, no?
>
> [Richard]
> Since CAPWAP protocol should be able to support multiple wireless binding,
> It is hard to give a mandatory requirement to some requirement (such as, 
> which of the two entries should be shown in the MIB?).
> I think it should be decided by an implementation of a wireless binding.
> I don't know whether there is a case that exist for a longer time.
> How about we add key words such for "valid and meaningful" in the note?
> I updated the notes.
>
> Note that in some cases such as roaming that a station may associate
> with two WTPs for some (short) time. The MIB implementation MUST
> ensure there is only one valid and meaningful entry for a specific station.
>
>
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 
> 发送时间: 2009年12月22日 19:17
> 收件人: [email-masked]
> 主题: Capwap Digest, Vol 49, Issue 34
>
> Send Capwap mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.frascone.com/mailman/listinfo/capwap
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Capwap digest..."
>
>
> Today's Topics:
>
>    1. ??:  ??: The Status of the CAPWAP WG MIB issues (young)
>    2. Index issue of the station table (young)
>    3. Re: The RowStatus issue (Bert (IETF) Wijnen)
>    4. Re: Index issue of the station table (Bert (IETF) Wijnen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Dec 2009 13:27:01 +0800
> From: young <[email-masked]>
> Subject: [Capwap] ??:  ??: The Status of the CAPWAP WG MIB issues
> To: "'Romascanu, Dan (Dan)'" <[email-masked]>,	"'Bert (IETF)
> 	Wijnen'" <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=gb2312
>
> Hi, All:
>
> OK. I think so: the reuse of existing TC's
>
> Regards
> Richard
>
> -----????-----
> ???: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> ????: 2009?12?21? 21:09
> ???: Bert (IETF) Wijnen; young
> ??: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> ??: RE: [Capwap] ??: The Status of the CAPWAP WG MIB issues
>
>  
>
>   
>> -----Original Message-----
>> From: Bert (IETF) Wijnen [mailto:[email-masked]] 
>>     
>
>   
>>> capwapBaseWtpProfileWtpName OBJECT-TYPE
>>>
>>> SYNTAX OCTET STRING (SIZE(1..512))
>>>
>>>       
>> OK, that is good for the SIZE (although 1 seems very short. 
>> But that is what the RFC5415 specifies, so fine). But RFC5415 
>> slaso states that it is a UTF-8 string, ans so does your 
>> DESCRITPION clause. So I would STRONGLY recommend to use 
>> longUtf8String as the SYNTAX. You have to import it from the 
>> SYSAPPL-MIB [RFC2287]: Or, if you do not want to epend on 
>> that RFC, then define a UTF-8 based TC yourself. That is to 
>> say, I would prefer a UTF-8 based TC as SYNTAX over a OCTET-STRING.
>> OCTET STRING is not strictly an error though, so if the WG 
>> really wants to keep that, then pls check with yoru AD if he 
>> is OK with that.
>>
>> Bert
>>     
>
> I actually favor the reuse of existing TC's - so better in my opinion IMPORT
> from RFC 2287 rather than define a new TC. 
>
> Dan
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Dec 2009 14:07:16 +0800
> From: young <[email-masked]>
> Subject: [Capwap] Index issue of the station table
> To: "'Bert (IETF) Wijnen'" <[email-masked]>, [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi, Bert:
>
> I discuss with Yong today. Please check our opinion to the Index.
> The index design of  apwapBaseStationEntry could be simplified.
>
> The capwapBaseStationEntry is to display station 
> which is associated with the specific radio on the WTP.
> I used to concern the roaming case (A station association with 
> Two AP at same time), so give a very complex design of the indexes.
>
> Since the roaming time is very short, it is valid to use capwapBaseStationId
> As one and only index.
> It is also good for the performance.
> Also, I suggest to add a note to explain the roaming case:
>        Notes that in the some cases such as roaming that a station may
> associate
>          with two WTPs at a certain time, the MIB implementation MUST
>          ensure there is only one entry for a specific station. 
>
> Base on it, the change would be:
> capwapBaseStationTable OBJECT-TYPE
>     SYNTAX      SEQUENCE OF CapwapBaseStationEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A table of objects that display stations which are accessing
>          the wireless service provided by the AC."
>     REFERENCE
>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseWtps 5 }
>
> capwapBaseStationEntry OBJECT-TYPE
>     SYNTAX      CapwapBaseStationEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A set of objects that display a station which is
>          associated with the specific radio on the WTP.
>       Notes that in the some cases such as roaming that a station may
> associate
>          with two WTPs at a certain time, the MIB implementation MUST
>          ensure there is only one entry for a specific station. " 
>
>     INDEX { capwapBaseStationId }
>     ::= { capwapBaseStationTable 1 }
>
> CapwapBaseStationEntry ::= SEQUENCE {
>       capwapBaseStationId            CapwapBaseStationIdTC, 
>       capwapBaseStationWtpId         CapwapBaseWtpIdTC,
>       capwapBaseStationWtpRadioId    CapwapBaseRadioIdTC,
>       capwapBaseStationAddedTime     DateAndTime,
>       capwapBaseStationVlanName      SnmpAdminString
>     }
>     
> capwapBaseStationId OBJECT-TYPE
>     SYNTAX      CapwapBaseStationIdTC
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "Represents the unique identifier of the station."
>     REFERENCE
>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseStationEntry 1 }
>     
> capwapBaseStationWtpId OBJECT-TYPE
>     SYNTAX      CapwapBaseWtpIdTC
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "Represents the unique identifier of a WTP in running state."
>     ::= { capwapBaseStationEntry 2 }
>     
> capwapBaseStationWtpRadioId OBJECT-TYPE
>     SYNTAX      CapwapBaseRadioIdTC
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "Represents the identifier of a PHY radio on a WTP, which
>          is required to be unique on a WTP.
>          For example, WTP A and WTP B use a same value of
>          capwapBaseWirelessBindingRadioId for their first radio."
>     REFERENCE
>         "Section 4.3. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseStationEntry 3 }
>
> capwapBaseStationAddedTime OBJECT-TYPE
>     SYNTAX      DateAndTime
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>         "Represents the time when the station is added."
>     REFERENCE
>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseStationEntry 4 }
>
> capwapBaseStationVlanName OBJECT-TYPE
>     SYNTAX      SnmpAdminString (SIZE(0..32))
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>         "Represents VLAN name to which the station is associated."
>     REFERENCE
>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseStationEntry 5 }
>
> Regards
> Richard
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Dec 2009 08:49:33 +0100
> From: "Bert (IETF) Wijnen" <[email-masked]>
> Subject: Re: [Capwap] The RowStatus issue
> To: young <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=GB2312
>
> Richard, I think this looks good.
>
> You really need the opinion of some CAPWAP experts.
> They can best determine what it means if you change an attribute
> of a row during operational time (so while the row is active).
>
> One extra remark inline
>
> young wrote:
>   
>> Hi, Bert:
>>
>> Thanks. Frankly, for me, it is very difficult to decide the flexibility 
>> Of the RowStatus object. 
>> Hope you and mailing list would give more opinion.
>> Combing with your and Zhang Yong's opinion, my suggestion is:
>>
>> 1) Give more flexibility to the capwapBaseAcNameListRowStatus and 
>> capwapBaseMacAclRowStatus.
>>
>> capwapBaseAcNameListRowStatus OBJECT-TYPE
>>     SYNTAX      RowStatus
>>     MAX-ACCESS  read-create
>>     STATUS      current
>>     DESCRIPTION
>>         "This object is used to create, modify, and/or delete a row 
>>          in this table.
>>          The value of capwapBaseAcNameListName and 
>>          capwapBaseAcNameListPriority can be changed when this 
>>          object is in state ''active'' or in ''notInService''.
>>   
>>     
> the above is great. However, I think that a row can ALWAYS be changed when
> it is in "notInService" state, so it is not needed to mention that. At
> the other hand,
> it does not hurt to do so either.
>
> Bert
>   
>>          The capwapBaseAcNameListRowStatus may be changed to ''active'' 
>>          if all the managed objects in the conceptual row with 
>>          MAX-ACCESS read-create have been assigned valid values."         
>>     ::= { capwapBaseAcNameListEntry 4 }
>>
>> capwapBaseMacAclRowStatus OBJECT-TYPE
>>     SYNTAX      RowStatus
>>     MAX-ACCESS  read-create
>>     STATUS      current
>>     DESCRIPTION
>>         "This object is used to create, modify, and/or delete a row 
>>          in this table.
>>          The value of capwapBaseMacAclStationId can be changed when 
>>          this object is in state ''active'' or in ''notInService''.
>>          The capwapBaseMacAclRowStatus may be changed to ''active'' 
>>          if all the managed objects in the conceptual row with 
>>          MAX-ACCESS read-create have been assigned valid values."
>>
>>     ::= { capwapBaseMacAclEntry 3 }
>>
>> 2) Give some  flexibility to the capwapBaseWtpProfileRowStatus
>> Yes, I think it should be ok to allow more freely changing the 
>> value of capwapBaseWtpProfileName
>> capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation,
>> since these object are to give a description.
>>
>> It is not ok to freely change the capwapBaseWtpProfileWtpMacAddr, 
>> capwapBaseWtpProfileWtpModelNumber, 
>> capwapBaseWtpProfileWtpStaticIpEnable,
>> capwapBaseWtpProfileWtpStaticIpType,
>> capwapBaseWtpProfileWtpStaticIp,
>> capwapBaseWtpProfileWtpNetmask,
>> capwapBaseWtpProfileWtpGateway   
>> since they are very important properties (configuration) influencing the
>> behaviour.
>> Also, their value need not frequent change.
>>
>> It is acceptable to freely change the object left such as
>> capwapBaseWtpProfileWtpIdleTimeout. But I choose  a conservative way: No
>> free change on them.
>>
>> According to this logic, I give the description as followed.
>> capwapBaseWtpProfileRowStatus OBJECT-TYPE
>>     SYNTAX      RowStatus
>>     MAX-ACCESS  read-create
>>     STATUS      current
>>     DESCRIPTION
>>         "This object is used to create, modify, and/or delete a row
>>          in this table.         
>>          The value of capwapBaseWtpProfileName, 
>>          capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation
>>          can be changed when this object is in state ''active'' or in 
>>          ''notInService''.
>>          The other objects in a row can be modified only when the value
>>          of this object in the corresponding conceptual row is not
>>          ''active''. Thus to modify one or more of the objects in 
>>          this conceptual row,
>>               a. change the row status to ''notInService''
>>               b. change the values of the row
>>               c. change the row status to ''active''
>>          The capwapBaseWtpProfileRowStatus may be changed to ''active'' 
>>          if the managed objects capwapBaseWtpProfileName, 
>>          capwapBaseWtpProfileWtpMacAddr, 
>>          capwapBaseWtpProfileWtpModelNumber, capwapBaseWtpProfileWtpName 
>>          and capwapBaseWtpProfileWtpLocation in the conceptual row 
>>          have been assigned valid values. 
>>                  
>>          Deleting a WTP profile in use will disconnect the WTP to 
>>          the AC. So the network management system SHOULD
>>          ask the operator to confirm such an operation.
>>          When a WTP profile entry is removed from the table, 
>>          the corresponding WTP Virtual Radio Interfaces are also 
>>          removed from the CapwapBaseWirelessBindingTable and 
>>          ifTable [RFC2863].
>>          Also, the related object instances SHOULD be removed from
>>          the wireless binding MIB modules such as IEEE 802.11 
>>          MIB module [IEEE.802-11.2007]."
>>     ::= { capwapBaseWtpProfileEntry 21 }      
>>
>> 4) Since there are no frequent change required and service based.
>> I suggest to keep current text.
>>
>> capwapDot11WlanBindRowStatus 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.
>>          All the objects in a row can be modified only when the value
>>          of this object in the corresponding conceptual row is not
>>          ''active''. Thus to modify one or more of the objects in 
>>          this conceptual row,
>>               a. change the row status to ''notInService'',
>>               b. change the values of the row
>>               c. change the row status to ''active''"      
>>     ::= { capwapDot11WlanBindEntry 3 }
>>    
>> capwapDot11WlanRowStatus 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.
>>          All the objects in a row can be modified only when the value
>>          of this object in the corresponding conceptual row is not
>>          ''active''. Thus to modify one or more of the objects in 
>>          this conceptual row,
>>               a. change the row status to ''notInService'',
>>               b. change the values of the row
>>               c. change the row status to ''active''
>>          The capwapDot11WlanRowStatus may be changed to ''active'' 
>>          if all the managed objects in the conceptual row with 
>>          MAX-ACCESS read-create have been assigned valid values.         
>>          
>>          When the operator deletes a WLAN profile, the AC SHOULD 
>>          check whether the WLAN profile is bound with a radio. 
>>          If yes, the value of the Response-PDU's error-status field 
>>          is set to `inconsistentValue', and the value of its 
>>          error-index field is set to the index of the failed variable
>>          binding. If not, the row object could be deleted."
>>     ::= { capwapDot11WlanEntry 5 }
>>   
>>     
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Dec 2009 09:02:17 +0100
> From: "Bert (IETF) Wijnen" <[email-masked]>
> Subject: Re: [Capwap] Index issue of the station table
> To: young <[email-masked]>
> Cc: [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I suspect we need help from CAPWAP experts here. I have not followed CAPWAP
> work for 3-4 years now... so I am not up to speed on it.
>
> I have some comments inline anyways, but pls do not consider them 
> necessarily valid.
>
>
> young wrote:
>   
>> Hi, Bert:
>>
>> I discuss with Yong today. Please check our opinion to the Index.
>> The index design of  apwapBaseStationEntry could be simplified.
>>
>> The capwapBaseStationEntry is to display station 
>> which is associated with the specific radio on the WTP.
>> I used to concern the roaming case (A station association with 
>> Two AP at same time), so give a very complex design of the indexes.
>>
>> Since the roaming time is very short, it is valid to use
>>     
> capwapBaseStationId
>   
>> As one and only index.
>> It is also good for the performance.
>> Also, I suggest to add a note to explain the roaming case:
>>          Notes that in the some cases such as roaming that a station may
>> associate
>>          with two WTPs at a certain time, the MIB implementation MUST
>>          ensure there is only one entry for a specific station. 
>>
>>   
>>     
> The indexing is indeed (much) simpler... but...
> If there is a possibility of two associations, how do we answer these 
> questions:
> - which of the two entries should be shown in the MIB?
> - what if (because of some problem) the situation exists for a longer 
> time (maybe forever?)
>   that would probably be a bug, but if so, that is something one would 
> like to be able
>   to detect with querying the MIB, no?
>
>
>   
>> Base on it, the change would be:
>> capwapBaseStationTable OBJECT-TYPE
>>     SYNTAX      SEQUENCE OF CapwapBaseStationEntry
>>     MAX-ACCESS  not-accessible
>>     STATUS      current
>>     DESCRIPTION
>>         "A table of objects that display stations which are accessing
>>          the wireless service provided by the AC."
>>     REFERENCE
>>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>>     ::= { capwapBaseWtps 5 }
>>
>> capwapBaseStationEntry OBJECT-TYPE
>>     SYNTAX      CapwapBaseStationEntry
>>     MAX-ACCESS  not-accessible
>>     STATUS      current
>>     DESCRIPTION
>>         "A set of objects that display a station which is
>>          associated with the specific radio on the WTP.
>>       Notes that in the some cases such as roaming that a station may
>> associate
>>          with two WTPs at a certain time, the MIB implementation MUST
>>          ensure there is only one entry for a specific station. " 
>>
>>     INDEX { capwapBaseStationId }
>>     ::= { capwapBaseStationTable 1 }
>>
>> CapwapBaseStationEntry ::= SEQUENCE {
>>       capwapBaseStationId            CapwapBaseStationIdTC, 
>>       capwapBaseStationWtpId         CapwapBaseWtpIdTC,
>>       capwapBaseStationWtpRadioId    CapwapBaseRadioIdTC,
>>       capwapBaseStationAddedTime     DateAndTime,
>>       capwapBaseStationVlanName      SnmpAdminString
>>     }
>>     
>> capwapBaseStationId OBJECT-TYPE
>>     SYNTAX      CapwapBaseStationIdTC
>>     MAX-ACCESS  not-accessible
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents the unique identifier of the station."
>>     REFERENCE
>>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>>     ::= { capwapBaseStationEntry 1 }
>>     
>> capwapBaseStationWtpId OBJECT-TYPE
>>     SYNTAX      CapwapBaseWtpIdTC
>>     MAX-ACCESS  not-accessible
>>   
>>     
> since this is no longer an INDEX object, it should probably be read-only!!
>
>   
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents the unique identifier of a WTP in running state."
>>     ::= { capwapBaseStationEntry 2 }
>>     
>> capwapBaseStationWtpRadioId OBJECT-TYPE
>>     SYNTAX      CapwapBaseRadioIdTC
>>     MAX-ACCESS  not-accessible
>>   
>>     
>
> since this is no longer an INDEX object, it should probably be read-only!!
>   
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents the identifier of a PHY radio on a WTP, which
>>          is required to be unique on a WTP.
>>          For example, WTP A and WTP B use a same value of
>>          capwapBaseWirelessBindingRadioId for their first radio."
>>     REFERENCE
>>         "Section 4.3. of CAPWAP Protocol Specification, RFC 5415."
>>     ::= { capwapBaseStationEntry 3 }
>>
>> capwapBaseStationAddedTime OBJECT-TYPE
>>     SYNTAX      DateAndTime
>>     MAX-ACCESS  read-only
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents the time when the station is added."
>>     REFERENCE
>>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>>     ::= { capwapBaseStationEntry 4 }
>>
>> capwapBaseStationVlanName OBJECT-TYPE
>>     SYNTAX      SnmpAdminString (SIZE(0..32))
>>     MAX-ACCESS  read-only
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents VLAN name to which the station is associated."
>>     REFERENCE
>>         "Section 4.6.8. of CAPWAP Protocol Specification, RFC 5415."
>>     ::= { capwapBaseStationEntry 5 }
>>
>> Regards
>> Richard
>>
>>
>>     
>>
>>   1.
>>
>>