Subject: [Capwap] More discussion on the Station Index Issue

From: young <[email-masked]>
Date: Wed, 23 Dec 2009 09:49:10 +0800

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
>
>
>
>
>   

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

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

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

End of Capwap Digest, Vol 49, Issue 34
**************************************

_________________________________________________________________
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, 23 Dec 2009 08:30:58 +0100

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

Bert

young wrote:
>>   1.