Subject: [Capwap] Comments inline for Dan's comment on MIB drafts

From: young <[email-masked]>
Date: Fri, 25 Jul 2008 20:00:02 +0800

According to Dan's comments for on draft-ietf-capwap-base-mib-00 and
draft-ietf-capwap-802dot11-mib-00, I gave my comments inline (each one
is identified by -->).
Most comments are accepted, thanks a lot. 
As Dan's said, the MIB drafts should take more time in the work of
synchronization between the MIB and the CAPWAP protocol document. New
version of MIB drafts
will do it.

Message: 1
Date: Tue, 22 Jul 2008 13:39:32 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

This is only a partial reviews and not yet a full MIB Doctor review. I am
seeing a lot of problems in modeling and lack of synchronization between the
MIB and the CAPWAP protocol document, so I would recommend that the authors
of the protocol document and other WG members do a detailed check and
comparison between the two documents. 
--> Yes. New version of MIB drafts will do it.

1. smilint complains about: 

mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier
`capwapWTPId' differs from `CapwapWTPId' only in case
-->Yes, a new name should be found for TC `CapwapWTPId". I will take
sometime to get a good name.

mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier
`capwapRadioId' differs from `CapwapRadioId' only in case\
-->Yes, a new name should be found for TC `CapwapRadioId". I will take
sometime to get a good name.

mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier
`capwapStationId' differs from `CapwapStationId' only in case
-->Yes, a new name should be found for TC CapwapStationId". I will take
sometime to get a good name.

mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier
`capwapChannelType' differs from `CapwapChannelType' only in case
--> Rename the `capwapChannelType' as "capwapBaseProtocolChannel"

mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier
`capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in case
--> Rename capwapWTPAuthenMethod as capwapBaseAuthenMethod
--> Rename CapwapWTPAuthenMethod as capwapBaseWTPAuthenMethod

The problem is that object names are similar to TC names, excepting
capitalization

2. smilint complains about: 

mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index element
`capwapWTPId' of row `capwapWTPStateEntry' should be not-accessible in SMIv2
MIB
mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index element
`capwapRadioId' of row `capwapRadioBindEntry' should be not-accessible in
SMIv2 MIB

Objects that are indices in tables should be not-accessible, and if there is
a need to use the objects for notifications they should be duplicated in the
table. 
-->OK

3. smilint complains about:
mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group
`capwapStationsGroup' is not referenced in this module
--> The capwapStationsGroup should be added into  MANDATORY-GROUPS .

4. It would be better that all objects in the MIB module have a common
naming prefix beyond capwap which is common to all capwap MIB modules. Maybe
capwapBase or capwapProto. 
--> OK. All objects in the MIB file should use a common naming prefix
"capwapBase".

5. The Introduction should refer to the CAPWAP work as to stable work not
'under way'
--> OK. 

6. Overview - it looks to me that the first objective ('To work well under
centralized architectures') and the fifth one ('to meet operator
requirements for centralized architectures') are redundant
---> The  first objective is to explain the objective from technique
perspective. The SNMP design should follow the CAPWAP protocol design idea.
---> The fifth one is to explain the objective from operator perspective.
--> Could have a better way to explain the objective?

7. 'The SNMP agent run on the AC side, and it MAY not be required on the WTP
side' - it is not clear what is meant here, and the usage of the RFC2119
language is not appropriate. Does it mean to say 'The CAPWAP-MIB MUST be run
on the AC devices and is NOT REQUIRED on the WTP devices'?  
---> Yes. 'The CAPWAP-MIB MUST be run on the AC devices and is NOT REQUIRED
on the WTP devices' will be used.

8. Instead of 'ifIndex [RFC2863] will play a role in bridging between MIB
standards defined by different SDOs' better say 'ifIndex [RFC2863] will be
used as common handler for corresponding interfaces in the CAPWAP-MIB and
specific wireless technologies MIB modules'. 
--> Ok

9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is very
import' - s/import/important/
--> Yes. should be important.

10. There is no need for section 6.1 to duplicate the textual conventions
defined in the MIB module itself
--> OK, the section 6.1 will be removed.

11. Section 7.2 - does not ifName map into WTP name? same ifDescr into WTP
descriptor? 
-->ifIndex will corresponding to a radio(Not a WTP), so ifName will not map
into a WTP name.
--> It is same for ifDescr.

12. Section 7.3 - what is the entPhysicalClass that is recommended for the
usage of RFC4133? 
--> I think the RFC4133 does not have a valid Physical class for CAPWAP
architecture.
--> I suggest to use other(1) for entPhysicalClass.

13. Naming consistency - it would be good to keep object names under a node
with the same prefix as the node name - e.g. capwapAC -> capwapACWTPSessions
or better capwapBaseAC -> capwapBaseACWTPSessions, etc.
--> Ok, capwapBaseAC will be used.

14. CapWapWTPAuthenMethod - it would be better to put other(1) as the first
enumerated value. 
-->OK

15. Objects like capwapWTPSessionsLimit have a limited range in the CAPWAP
protocol dictated by the numbers of bits used for their representation (16
for example) - it would be appropriate to limit the range of the Unsigned32
accordingly
--> Yes

16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT construct
should be used as SYNTAX
--> Yes

17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5 of
the protocol document. 
-->Should use 512

18. capwapWTPState has one state dtls(1) while the state diagram in section
2.3.1 of the protocol document mentions three different states 'DTLS Setup',
DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover all three? If so
please be explicit in the DESCRIPTION clause
-->The dtls(1) supposes to cover all three. DESCRIPTION will give the
information.

19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an
enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should be
used here. 
--->CapwapWTPMACType should add one option "all(3) Support both Local-MAC
and Split-MAC mode"

20. The SYNTAX of capwapStationVlanName should be SnmpAdminString
-->OK

21. It would be good to find a more adequate name for the capwapVariables
group
--> How about "capwapBaseParameters"?

22. why is there a need to define a special group for objects for
notifications, instead of defining these objects in the other configuration
tables in the MIB module
--> The objects such as capwapImageFailureReason are only required for
notifications.

23. What is the functionality of the capwapIdEntryNum? The reference to
section 4.6.15 in the protocol document seems to be wrong, this is the
CAPWAP transport protocol
--> Yes, capwapIdEntryNum is not required.

Regards,

Dan

Message: 2
Date: Tue, 22 Jul 2008 14:30:53 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: [Capwap] comments on draft-ietf-capwap-802dot11-mib-00
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

This is not yet a full MIB Doctor review.

1. smilint complains 

mibs/CAPWAP-DOT11-MIB:117: [5] {identifier-case-match} warning: identifier
`capwapDot11WLANId' differs from `CapwapDot11WLANId' only in case

You need to define name objects different from TC names

---> Yes, a new name should be found for TC `CapwapDot11WLANId". I will take
sometime to get a good name.

2. The Introduction should refer to the CAPWAP work as to stable work not
'under way'
--> OK

3. There is no need for section 6.1 to duplicate the textual conventions
defined in the MIB module itself
--> The section 6.1 will be removed.

4. There is no definition of the persistency of read-write or read-create
objects for the capwapDot11WLANConfigTable, or a StorageType object in the
rows. 
--> The section will be updated.

5. The names of the capwapWTPMacType and capwapWTPTunnelMode objects do not
respect the naming convention for the MIB module. 
--> OK. All objects in the MIB file should use a common naming prefix
"capwapDot11".

Regards,

Dan

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2008年7月23日 18:16
收件人: [email-masked]
主题: Capwap Digest, Vol 32, 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. Comments on draft-ietf-capwap-base-mib-00 (Romascanu, Dan (Dan))
   2. comments on draft-ietf-capwap-802dot11-mib-00
      (Romascanu, Dan (Dan))
   3. Last Call: draft-ietf-capwap-protocol-binding-ieee80211
      (CAPWAP Protocol Binding for IEEE 802.11) to Proposed Standard
      (The IESG)
   4. Last Call: draft-ietf-capwap-protocol-specification (CAPWAP
      Protocol Specification) to Proposed Standard (The IESG)
   5. Issue 150: binding doc. 802.11 wlan config req/resp msg
      typevalueissue (Pat Calhoun (pacalhou))
   6. Issue 149: Incompatibility with message element numbering
      between drafts 10 and 11 (Pat Calhoun (pacalhou))

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

Message: 1
Date: Tue, 22 Jul 2008 13:39:32 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

This is only a partial reviews and not yet a full MIB Doctor review. I
am seeing a lot of problems in modeling and lack of synchronization
between the MIB and the CAPWAP protocol document, so I would recommend
that the authors of the protocol document and other WG members do a
detailed check and comparison between the two documents. 

1. smilint complains about: 

mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier
`capwapWTPId' differs from `CapwapWTPId' only in case
mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier
`capwapRadioId' differs from `CapwapRadioId' only in case
mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier
`capwapStationId' differs from `CapwapStationId' only in case
mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier
`capwapChannelType' differs from `CapwapChannelType' only in case
mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier
`capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in
case

The problem is that object names are similar to TC names, excepting
capitalization

2. smilint complains about: 

mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index
element `capwapWTPId' of row `capwapWTPStateEntry' should be
not-accessible in SMIv2 MIB
mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index
element `capwapRadioId' of row `capwapRadioBindEntry' should be
not-accessible in SMIv2 MIB

Objects that are indices in tables should be not-accessible, and if
there is a need to use the objects for notifications they should be
duplicated in the table. 

3. smilint complains about:

mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group
`capwapStationsGroup' is not referenced in this module

4. It would be better that all objects in the MIB module have a common
naming prefix beyond capwap which is common to all capwap MIB modules.
Maybe capwapBase or capwapProto. 

5. The Introduction should refer to the CAPWAP work as to stable work
not 'under way'

6. Overview - it looks to me that the first objective ('To work well
under centralized architectures') and the fifth one ('to meet operator
requirements for centralized architectures') are redundant

7. 'The SNMP agent run on the AC side, and it MAY not be required on the
WTP side' - it is not clear what is meant here, and the usage of the
RFC2119 language is not appropriate. Does it mean to say 'The CAPWAP-MIB
MUST be run on the AC devices and is NOT REQUIRED on the WTP devices'?  

8. Instead of 'ifIndex [RFC2863] will play a role in bridging between
MIB standards defined by different SDOs' better say 'ifIndex [RFC2863]
will be used as common handler for corresponding interfaces in the
CAPWAP-MIB and specific wireless technologies MIB modules'. 

9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is
very import' - s/import/important/

10. There is no need for section 6.1 to duplicate the textual
conventions defined in the MIB module itself

11. Section 7.2 - does not ifName map into WTP name? same ifDescr into
WTP descriptor? 

12. Section 7.3 - what is the entPhysicalClass that is recommended for
the usage of RFC4133? 

13. Naming consistency - it would be good to keep object names under a
node with the same prefix as the node name - e.g. capwapAC ->
capwapACWTPSessions or better capwapBaseAC -> capwapBaseACWTPSessions,
etc.

14. CapWapWTPAuthenMethod - it would be better to put other(1) as the
first enumerated value. 

15. Objects like capwapWTPSessionsLimit have a limited range in the
CAPWAP protocol dictated by the numbers of bits used for their
representation (16 for example) - it would be appropriate to limit the
range of the Unsigned32 accordingly

16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT
construct should be used as SYNTAX

17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5
of the protocol document. 

18. capwapWTPState has one state dtls(1) while the state diagram in
section 2.3.1 of the protocol document mentions three different states
'DTLS Setup', DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover
all three? If so please be explicit in the DESCRIPTION clause

19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an
enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should
be used here. 

20. The SYNTAX of capwapStationVlanName should be SnmpAdminString

21. It would be good to find a more adequate name for the
capwapVariables group

22. why is there a need to define a special group for objects for
notifications, instead of defining these objects in the other
configuration tables in the MIB module

23. What is the functionality of the capwapIdEntryNum? The reference to
section 4.6.15 in the protocol document seems to be wrong, this is the
CAPWAP transport protocol

Regards,

Dan

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

Message: 2
Date: Tue, 22 Jul 2008 14:30:53 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: [Capwap] comments on draft-ietf-capwap-802dot11-mib-00
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

This is not yet a full MIB Doctor review.

1. smilint complains 

mibs/CAPWAP-DOT11-MIB:117: [5] {identifier-case-match} warning:
identifier `capwapDot11WLANId' differs from `CapwapDot11WLANId' only in
case

You need to define name objects different from TC names

2. The Introduction should refer to the CAPWAP work as to stable work
not 'under way'

3. There is no need for section 6.1 to duplicate the textual conventions
defined in the MIB module itself

4. There is no definition of the persistency of read-write or
read-create objects for the capwapDot11WLANConfigTable, or a StorageType
object in the rows. 

5. The names of the capwapWTPMacType and capwapWTPTunnelMode objects do
not respect the naming convention for the MIB module. 

Regards,

Dan

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

Message: 3
Date: Tue, 22 Jul 2008 05:45:44 -0700 (PDT)
From: The IESG <[email-masked]>
Subject: [Capwap] Last Call:
	draft-ietf-capwap-protocol-binding-ieee80211 (CAPWAP Protocol
Binding
	for IEEE 802.11) to Proposed Standard
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>

The IESG has received a request from the Control And Provisioning of 
Wireless Access Points WG (capwap) to consider the following document:

- 'CAPWAP Protocol Binding for IEEE 802.11 '
   <draft-ietf-capwap-protocol-binding-ieee80211-07.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-08-05. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ieee8
0211-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1527
5&rfc_flag=0

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

Message: 4
Date: Tue, 22 Jul 2008 05:46:24 -0700 (PDT)
From: The IESG <[email-masked]>
Subject: [Capwap] Last Call: draft-ietf-capwap-protocol-specification
	(CAPWAP Protocol Specification) to Proposed Standard
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>

The IESG has received a request from the Control And Provisioning of 
Wireless Access Points WG (capwap) to consider the following document:

- 'CAPWAP Protocol Specification '
   <draft-ietf-capwap-protocol-specification-11.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-08-05. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification
-11.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1446
7&rfc_flag=0

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

Message: 5
Date: Tue, 22 Jul 2008 14:34:44 -0700
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: [Capwap] Issue 150: binding doc. 802.11 wlan config req/resp
	msg	typevalueissue
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

All,

I have made the fixes for the issue raised. The crux of the issue is
that the message element numbering requires that the first three octets
be used for the IANA Enterprise Number, for which 802.11 uses 13277. The
issue is that the base draft also requires that requests be odd
numbered, and responses be even numbered. However, the -7 draft uses the
inverse, where the request is even numbered and the response is odd
numbered. 

The downside here is that this creates a backward compatibility issue
with -07, which has been through WG Last Call, but it is a necessary
change in order to comply with the numbering rules laid out in the base
draft.

So the new text looks like:

<text>
3.  IEEE 802.11 Specific CAPWAP Control Messages
[...]
           CAPWAP Control Message                    Message Type
                                                        Value

           IEEE 802.11 WLAN Configuration Request      3398913
           IEEE 802.11 WLAN Configuration Response     3398914
</text>

PatC

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

Message: 6
Date: Tue, 22 Jul 2008 14:34:43 -0700
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: [Capwap] Issue 149: Incompatibility with message element
	numbering	between drafts 10 and 11
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

All,

I have made the necessary changes to the document that will eventually
become -12 to ensure that the numbering of the message elements in the
base draft are consistent with -10. I do, however, want to note that -10
had an error. While the table in section 4.6 showed the value 22 for the
"Duplication IPv6 Address" message element, the value shown in the
message element definition in section 4.6.25 was 23 and incorrect. The
value in section 4.6.25, was both inconsistent with the table, but more
importantly, conflicted with the Idle Timeout message element (section
4.6.26). 

This bug did not exist in -11, since I had renumbered all message
elements. However, issue 149 requires me to change all of the message
element type values to those found in -10.  I wanted to note that I have
corrected this bug in -12, which of course, means that the two drafts
will differ in this regard. However, the message element table values
are consistent across both -10 and -12.

PatC

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

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