| The RowStatus issue | <– Date –> <– Thread –> |
From: young (young h3c.com)
|
|
| Date: Mon, 21 Dec 2009 21:28:50 -0800 (PST) | |
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 }
-----邮件原件-----
发件人: capwap-request [at] frascone.com [mailto:capwap-request [at] frascone.com]
发送时间: 2009年12月21日 19:48
收件人: capwap [at] frascone.com
主题: Capwap Digest, Vol 49, Issue 32
Send Capwap mailing list submissions to
capwap [at] frascone.com
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
capwap-request [at] frascone.com
You can reach the person managing the list at
capwap-owner [at] frascone.com
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 <young [at] h3c.com>
Subject: [Capwap] ??: The Status of the CAPWAP WG MIB issues
To: "'Bert Wijnen (IETF)'" <bertietf [at] bwijnen.net>,
capwap [at] frascone.com, Black_David [at] emc.com, elwynd [at]
dial.pipex.com
Cc: yzhang [at] fortinet.com
Message-ID: <001d01ca8233$637a68b0$81449a0a [at] h3c.huawei3com.com>
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:bertietf [at] bwijnen.net]
????: 2009?12?21? 17:23
???: young; capwap [at] frascone.com; Black_David [at] emc.com;
elwynd [at] dial.pipex.com
??: yzhang [at] fortinet.com
??: 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:young [at] h3c.com>
To: capwap [at] frascone.com ; Black_David [at] emc.com ; 'Bert Wijnen
<mailto:bertietf [at] bwijnen.net> (IETF)' ; elwynd [at] dial.pipex.com
Cc: yzhang [at] fortinet.com
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
**************************************
-
The RowStatus issue young, December 21 2009
- Re: The RowStatus issue Bert (IETF) Wijnen, December 21 2009
Results generated by Tiger Technologies using MHonArc.