Subject: [Capwap] The RowStatus issue

From: young <[email-masked]>
Date: Tue, 22 Dec 2009 13:24:21 +0800

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

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2009年12月21日 19:48
收件人: [email-masked]
主题: Capwap Digest, Vol 49, Issue 32

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)

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

Message: 1
Date: Mon, 21 Dec 2009 19:47:35 +0800
From: young <[email-masked]>
Subject: [Capwap]  ??: The Status of the CAPWAP WG MIB issues
To: "'Bert Wijnen (IETF)'" <[email-masked]>,
	[email-masked],	[email-masked], [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="gb2312"

   Hi, Bert:

     Ok, there are two issues keep open 

1)      Index

2)      RowStatus

Check my comments inline.

-----????-----
???: Bert Wijnen (IETF) [mailto:[email-masked]] 
????: 2009?12?21? 17:23
???: young; [email-masked]; [email-masked];
[email-masked]
??: [email-masked]
??: Re: The Status of the CAPWAP WG MIB issues

SMICng Syntax check is clea now except for the 21 awarnings about index.

AS we stated, that is OK... as long as explanation gets added.

I noticed:

capwapBaseAcNameListName OBJECT-TYPE
    SYNTAX      OCTET STRING(SIZE(512))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the name of an AC, and it is expected to be
         an UTF-8 encoded string."
    REFERENCE
        "Section 4.6.5. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseAcNameListEntry 2 }

It seems weird to me (now taht I see this) that the size should be exact 512
octets ????

Did you mean max size 512 octets? There is probably a minimum size too?

And if it is UTF-8 , then it would be much better to use a proper UTF-8
syntax.

If you look here: http://ops.ietf.org/mib-common-tcs.html

you can find pointers/suggestions.

If the size needs to be 512, then LongUtf8String seems the one to choose
(with a SIZE of course).

[Richard]

Oh, a mistake. It should be OCTET STRING (SIZE(1..512))  for
capwapBaseAcNameListName.

The capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation need
changes.

    capwapBaseWtpProfileWtpName  OBJECT-TYPE

       SYNTAX      OCTET STRING (SIZE(1..512))

capwapBaseWtpProfileWtpLocation  OBJECT-TYPE

       SYNTAX      OCTET STRING (SIZE(1..1024))

For this one

capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
    SYNTAX      InetAddressType {ipv4(1), ipv4z(3)}
    MAX-ACCESS  read-create
    STATUS      current

I recommended to subtype, because ith is ONLY IPv4, AND because it is a

writable object.

 [Richard] Yes

This one

capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(6|8))

Should be

capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(4|8))

  [Richard]  Yes

And for this one:

capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE
    SYNTAX      InetAddressType {
                  ipv4(1),
                  ipv6(2),
                  ipv4z(3),
                  ipv6z(4),
                  dns(16)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address type of a WTP.
         Only ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) and dns(16)
         are supported by the object."
    ::= { capwapBaseWtpStateEntry 2 }

I had not recommended to use the subtyping. There are 2 reasons:

- it basically supports everything (OK, except the unknown).

- it is read-only, so having all subtypes listed out is not needed

  as much as in a the case of a writable object. It is not incorrect
however.

   [Richard]  

   Ok, no subtyping list required here. I am clear this time.

But this:

capwapBaseWtpStateWtpIpAddress OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(4|8|16|20))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address of a WTP.
         The format of this IP address is determined by
         the corresponding instance of object
         capwapBaseWtpStateWtpIpAddressType."
    ::= { capwapBaseWtpStateEntry 3 }

Seems wrong to me. a DNS name can be up to 255 characters I think.

In any case, it is often much longer than 20. I would not specify a size
here.

   [Richard]  

   Ok, no subtyping list required here.

I can live with your approach that rows must be made notInService, then
changed, then set 

back to active. But it is somewhat of a burdon to a Network Management
Station (application).

So I would think hard if it is really needed. Would it be allowed to just
change some rows,

or some objects in a row while it is active? If such changes on an active
row do not

jeopardize the service, then you might want to consider allowing that.

[Richard]

Yes, Before I sent out the new draft, I was hesitating here whether should
give more flexibility to NMS..

 OK, I would give an answer tomorrow.

Bert

----- Original Message ----- 

From: young <mailto:[email-masked]>  

To: [email-masked] ; [email-masked] ; 'Bert Wijnen
<mailto:[email-masked]>  (IETF)' ; [email-masked] 

Cc: [email-masked] 

Sent: Monday, December 21, 2009 7:30 AM

Subject: The Status of the CAPWAP WG MIB issues

Hi, All:

Till now, I got the review comments from David, Bert and Elwyn.
The drafts text was updated according to the discussion in the mailing list.
I already sent the updated drafts to the reviewer and ask them to confirm
whether the changes are ok or not.

There are few open issues left. Please remind me if I missed any one.
1) 
> Section 9 refers to a usage of
> Message Element Extensions which a vendor can chose to implement or
not.
> It is not normative text and multi-vendor interoperability is not 
> required.
[Reviewer] The issue was raised by David.
[Status] open

2)
> [*] I see lots of editorial problems in the text prior to the MIB 
> definitions, most of which are not called out in this review. I 
> strongly suggest an editorial pass by a native speaker of English 
> prior to IESG Review.
[Reviewer] The issue was raised by David.
[Status] open

3)
> [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB 
> draft?  MIB drafts generally do not make changes to the protocol that 
> they provide management for.  This section, and the changes in Section 
> 5.7 ought to be in a separate draft that could be standards track. 
[Reviewer] The issue was raised by David.
[Status] open

4) 
W: f(capwap-base.mi2), (1343,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
W: f(capwap-base.mi2), (1568,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
[Reviewer] The issue was raised by Bert.
[Editors] It needs more explain in the object's description 
[Status] Richard and Yong are preparing text

I believe the new drafts could be post soon once we have conclusion for all
the
Open issues.

Regards
Richard

  _____  

Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com 
Versie: 9.0.717 / Virusdatabase: 270.14.116/2578 - datum van uitgifte:
12/20/09 20:35:00

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20091221/9711bb9e/att
achment.htm 

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

_________________________________________________________________
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 32
**************************************

_________________________________________________________________
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: Tue, 22 Dec 2009 08:49:33 +0100

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

>          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