| Some question on Base MIB comments | <– Date –> <– Thread –> |
From: young (young h3c.com)
|
|
| Date: Thu, 5 Feb 2009 20:00:01 -0800 (PST) | |
Hi, Thanks Dan's comments.
Most comments are quite clear.
Parts of them we have not got point, and some of them requires more
discussion in the mailing list. After discussion for open issues is over, we
could send out modification in details for each comment. If the modification
is ok, we would publish new version after it.
Regards
Richard
Here is some question we have for Base MIB:
T4. In order for ifIndex to be used as a common handler for the CAPWAP
MIB and for the interface specific MIB modules like a dot11 MIB from
IEEE one needs to ensure that the same numbering scheme and mapping is
used by all MIB modules, and that it behaves identically for events like
interface card swapping, reset or power loss. I do not see how this can
happen, I am not sure that this is possible at all, and in any case
there is no text in the CAPWAP MIB that explains this mechanism.
-----------------------------------------------------------------
Yes, when we use logic interface (such as Wireless Virtual Interface)
mechanism, it would have a risk to have this issue when AC reboot. It is not
only for fit AP, but could have for other device such as switch, router.
The device should have some methods to ensure ifIndex for an interface keep
same after device reboot.
Some general rule or mechanism should be defined, while it is better to make
it out of CAPWAP MIB drafts as it is a general issue.
T9. What is the Vendor Identifier mentioned in Section 9 as being
assigned by IANA? Is this something specific for this MIB document - in
this case it needs to be mentioned in the IANA considerations section?
-----------------------------------------------------------------
Yes, current description would lead to misunderstanding.
It should say:
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes"
Whether is it ok?
T10. Why does one need a special TC for CapwapBaseWtpIdTC? If this is
typically a serial number, then SnmpAdminString SIZE (1..128) should do.
-----------------------------------------------------------------
Station, radio, WTP are main objects under management by MIB drafts.
They would appear in the serval table and notification.
Suggest to have a TC for them.
Refer to entPhysicalSerialNum in RFC4133 and Dan's comment,
define CapwapBaseWtpIdTC with SnmpAdminString (SIZE (0..32))
T14 - the name of capwapBaseDataChannelSecOptions should better be
something that includes DTLSPolicy to make clear to what fields in the
AC Descriptor it corresponds. The DESCRIPTION should also be consistent
with the text in the protocol document
-----------------------------------------------------------------
Ok, change capwapBaseDataChannelSecOptions
with capwapBaseDataChannelDTLSPolicyOptions.
Change capwapBaseDataChannelSecConfig with
capwapBaseDataChannelDTLSPolicyConfig
Also, the DESCRIPTION should also be consistent with the text in the
protocol document
Whether is it ok?
T17 - Object names in capwapBaseWtpStateTable do not respect the naming
conditions relative to capwapBaseWtpStateEntry
-----------------------------------------------------------------
Whether it means that it should use capwapBaseWtpState as prefix for each
object under capwapBaseWtpStateTable.
If this way, I thought capwapBaseWtpId look better and meaningful than
capwapBaseWtpStateId. Here Id looks tight up with State not with Wtp.
T22 - why does the MIB support reserved(0) for
capwapBaseWtpFallbackEnable. Does setting to reserved(0) by the
management application have any significance?
-----------------------------------------------------------------
For MIB, whether it could not support reserved field defined by protocol?
If it is ok, reserved(0) would be removed in the MIB.
E8. No need to repeat the text in the DESCRIPTION clause if a TC is used
(e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions)
-------------------------------------------------------------------
How about we say DESCRIPTION's capwapBaseTunnelModeOption in this way?
As per CapwapBaseTunnelModeTC's DESCRIPTION
发件人: capwap-request [at] frascone.com [mailto:capwap-request [at] frascone.com]
发送时间: 2009年1月28日 18:35
收件人: capwap [at] frascone.com
主题: Capwap Digest, Vol 38, Issue 6
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. AD review of draft-ietf-capwap-base-mib-03.txt
(Romascanu, Dan (Dan))
2. Re: status of CAPWAP (Pat Calhoun (pacalhou))
3. Re: status of CAPWAP (Dan Harkins)
4. AD review of draft-ietf-capwap-802dot11-mib-02.txt
(Romascanu, Dan (Dan))
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Jan 2009 16:21:00 +0100
From: "Romascanu, Dan (Dan)" <dromasca [at] avaya.com>
Subject: [Capwap] AD review of draft-ietf-capwap-base-mib-03.txt
To: <capwap [at] frascone.com>
Message-ID:
<EDC652A26FB23C4EB6384A4584434A040132E57D [at] 307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="us-ascii"
Please find below the AD review of draft-ietf-capwap-base-mib-03.txt. I
have divided my comments into Technical and Editorial comments.
This document is not ready to be submitted to the IESG. It needs one
more iteration at least, but I suggest to do it after a serious scrutiny
from the WG members who know well the protocol.
Regards,
Dan
T1. Running smilint results in the following errors:
mibs/CAPWAP-BASE-MIB:480: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseWtpStateEntry' can exceed OID size limit by 6
subidentifier(s)
mibs/CAPWAP-BASE-MIB:582: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseWtpEntry' can exceed OID size limit by 6
subidentifier(s)
mibs/CAPWAP-BASE-MIB:1090: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseRadioBindEntry' can exceed OID size limit by 7
subidentifier(s)
mibs/CAPWAP-BASE-MIB:1181: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseStationEntry' can exceed OID size limit by 13
subidentifier(s)
mibs/CAPWAP-BASE-MIB:1249: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseWtpRebootStatsEntry' can exceed OID size limit by 6
subidentifier(s)
mibs/CAPWAP-BASE-MIB:1408: [5] {index-exceeds-too-large} warning: index
of row `capwapBaseRadioStatsEntry' can exceed OID size limit by 7
subidentifier(s)
The reason is that these tables are indexed with objects of SYNTAX of
CapwapBaseWtpIdTC which has a maximal size of 128, equal to the maximal
size allowed for the whole OID. Reducing the maximal size of the TC to
anything less or equal than 115 solves the problem.
T2. Section 5 - ' To reuse current MIB standards and future extensions
for a wireless binding technology' - it is not clear what 'future
extensions' may be and I would not commit to using them in advance, so I
would suggest to drop this
T3 What are the 'MIB standards of other SDOs' that need to be reused?
Please refer to them specifically at least by providing one example -
for instance where does Dot11OperationTable come from?
T4. In order for ifIndex to be used as a common handler for the CAPWAP
MIB and for the interface specific MIB modules like a dot11 MIB from
IEEE one needs to ensure that the same numbering scheme and mapping is
used by all MIB modules, and that it behaves identically for events like
interface card swapping, reset or power loss. I do not see how this can
happen, I am not sure that this is possible at all, and in any case
there is no text in the CAPWAP MIB that explains this mechanism.
T5. Section 7.2 - 'The interface SHOULD be modeled as an ifEntry' - Is a
SHOULD enough or rather a MUST is required here taking into account the
requirements in Section 5.
T6. The documents that define the MIB modules required for IMPORTs must
be listed in the Normative References section.
T7. In the example in Section 8 capwapBaseWtpId equals the
representation of the OCTET STRING '12345678' and not the number
12345678
T8. In the example in Section 8 ifPhysicalAddress should have six zeros.
T9. What is the Vendor Identifier mentioned in Section 9 as being
assigned by IANA? Is this something specific for this MIB document - in
this case it needs to be mentioned in the IANA considerations section?
T10. Why does one need a special TC for CapwapBaseWtpIdTC? If this is
typically a serial number, then SnmpAdminString SIZE (1..128) should do.
T11. In any case why is the SIZE in this TC fixed at 128?
T12. A number of read-write objects do not have the persistency behavior
defined in case of agent reboot - capwapBaseStationSessionsLimit,
capwapBaseDataChannelSecConfig, capwapBaseControlChannelAuthenConfig
T13 - Is more than one security policy possible to be configured on a
given AC? If not, then why is capwapBaseDataChannelSecConfig a BIT?
T14 - the name of capwapBaseDataChannelSecOptions should better be
something that includes DTLSPolicy to make clear to what fields in the
AC Descriptor it corresponds. The DESCRIPTION should also be consistent
with the text in the protocol document
T15 - is more than one credential type possible to be configured on a
given AC? If not then why is capwapBaseControlChannelAuthenConfig a BIT?
T16 - it would be good for management applications writers to mention in
the DESCRIPTION clause thatcapwapBaseAcnameListName is expected to be a
UTF-8 encoded string
T17 - Object names in capwapBaseWtpStateTable do not respect the naming
conditions relative to capwapBaseWtpStateEntry
T18 - same for capwapBaseWtpStateTable
T19 - capwapBaseWtpName is of SYNTAX AsnmpAdminString which is limited
to SIZE 255, while the WTP name can be up to 512 characters
T20 - same about capwapbaseWtpLocation which can be up to 1024
characters in length
T21 - Section 4.8 defines default value for a number of variables.
However, these are not reflected in the MIB - for example why is there
not a DEFAULT clause that will set capwapBaseWtpFallbackEnable to
enabled(1) as per 4.8.9? Or capwapBaseWtpMaxDiscoveries which has a
default of 10 defined in 4.8.5
T22 - why does the MIB support reserved(0) for
capwapBaseWtpFallbackEnable. Does setting to reserved(0) by the
management application have any significance?
T23 - According to 4.8.8 capwapBaseWtpRetransmitCount is a monotonous
increasing counter. The appropriate SYNTAX for such an object is
Counter32 and not Unsigned32
T24 - it would be useful to define UNITS clauses for objects like
capwapBaseWtpRetransmitCount
T25 - define a range (2..180) for capwapBaseWtpMaxDiscoveryInterval
T27 - Object names in capwapBaseRadioBindTable do not respect the naming
conditions relative to capwapBaseRadioBindEntry
T28 - What do the values reserved(0) and reserved(2) in
capwapBaseRadioWirelessBinding mean? Are they ever returned by an agent?
T29 - in other IETF documents (like RFC 4363) VLAN names are defined as
SnmpAdminString (SIZE (0..32)). I suggest the same for
capwapBaseStationVlanName. I am aware that section 4.6.8 allows for
names up to 512, but I do not find this justified. In any case, if the
full size defined in 4.6.8 is to be accommodated, then SnmpAdminString
would not be sufficient as its size is limited to 256.
T30 - Object names in capwapBaseWtpRebootStatsTable do not respect the
naming conditions relative to capwapBaseWtpRebootStatsEntry
T31 - Object names in capwapBaseWtpRadioStatsTable do not respect the
naming conditions relative to capwapBaseWtpRadioStatsEntry
E1. Even if this document uses terminology borrowed from other CAPWAP
documents, acronyms like WTP, AC, etc. should be expanded at the first
occurrence.
E2. It would be good for the document to be grammar and spelling checked
by a native English speaker.
E3. No need for sections 6.1, 6.2, 6.3 - these are standard in any MIB
module and their content is well known
E4. In Section 7.2 there is no need to mention information that is not
specific to the CAPWAP MIB
E5. In the example in Section 8 ifType should be equal with the value
assigned by IANA for the ifType - you may mark it xxx and enter an
editor note saying 'RFC Editor - please replace xxx with the value
allocated by IANA for IANAifType of 'WTP Virtual Radio Interface')
E6. Please indicate specifically for each field for the protocols timers
message the exact reference in than CAPWAP protocol document.
E7. The numbering of referred paragraphs in the REFERENCE clauses are
not synchronized with the latest version of the CAPWAP protocol document
as per http://www.rfc-editor.org/rfc/rfc3411.txt
E8. No need to repeat the text in the DESCRIPTION clause if a TC is used
(e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions)
E9 - capwapBaseWtpMaxRetransmitCnt is not a counter so the suffix Cnt
should be dropped from the name.
E10 - capwapBaseAcMaxRetransmitCnt is not a counter so the suffix Cnt
should be dropped from the name.
------------------------------
Message: 2
Date: Tue, 27 Jan 2009 09:12:47 -0800
From: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
Subject: Re: [Capwap] status of CAPWAP
To: "Dan Harkins" <dharkins [at] lounge.org>
Cc: capwap [at] frascone.com
Message-ID:
<4FF84B0BC277FF45AA27FE969DD956A207350950 [at] xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset="US-ASCII"
Hi Dan,
I'd prefer not to be the one to provide legal advice to folks on this
list. What I would, however, recommend is that you contact the IETF IP
counsel, Jorge Contreras at Wilmer Hale, who can provide you with this
information. You can find info on Jorge at
http://www.wilmerhale.com/jorge_contreras/.
PatC
-----Original Message-----
From: Dan Harkins [mailto:dharkins [at] lounge.org]
Sent: Monday, January 26, 2009 10:56 AM
To: Pat Calhoun (pacalhou)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] status of CAPWAP
Hi Pat,
Can you expand on _exactly_ what those consequences would be?
CAPWAP may not be the only document being held up but it may have
the most to lose if the "work around" limits derivative work. Hence
my concern.
Dan.
On Sun, January 25, 2009 11:00 pm, Pat Calhoun (pacalhou) wrote:
> Correct Dan, but publication will have many unintended consequences.
> From what I am being told, this is actively being addressed now, so I
> would prefer we hold off a little longer. CAPWAP is not the only
> document that is being held up. We already have the RFC numbers if
> anyone needs to reference them (e.g., EPCGlobal), and the latest
drafts
> can be used for anyone actively developing.
>
> Personally, if we believe these need to be published today, then I
would
> instead ask that we force the RFC Editor to adopt the old rules -
which
> applied when the spec was written.
>
> PatC
>
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins [at] lounge.org]
> Sent: Saturday, January 24, 2009 1:27 PM
> To: capwap [at] frascone.com
> Subject: [Capwap] status of CAPWAP
>
>
> Hi,
>
> Last week Mani wrote:
>
> By the way, following this, at the request of at least one of the
> authors, the three CAPWAP protocol drafts (the RFCs-to-be: 5415,
> -5416 and -5417) in the RFC-Ed queue have been requested to be
> placed on hold until this matter is resolved by way of an early
> work-around from IETF, under discussion in the IETF list.
>
> I am concerned about this. If any protocol needs to be able to evolve,
> and create derivative works, it is CAPWAP. Wireless networking is a
> rapidly changing field and having a "standard" that cannot change with
> it makes that "standard" pointless.
>
> I politely and respectfully ask the chairs to gauge WG consensus on
> the matter of what we want to do with our drafts with respect to RFC
> 5378
> and then to instruct the editor(s) to follow that consensus. If the
> editor(s) refuse(s) then I would expect he/she/they to be replaced
with
> someone who is willing to implement the will of the WG.
>
> These drafts are not any one person's or any one company's property
> and the hangups of any person or company shouldn't trump the will of
> the WG.
>
> regards,
>
> Dan.
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap
------------------------------
Message: 3
Date: Tue, 27 Jan 2009 09:32:11 -0800 (PST)
From: "Dan Harkins" <dharkins [at] lounge.org>
Subject: Re: [Capwap] status of CAPWAP
To: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
Cc: capwap [at] frascone.com
Message-ID:
<ca7af4b1204e4fd5a86abf64bca5e0c1.squirrel [at] www.trepanning.net>
Content-Type: text/plain;charset=iso-8859-1
Hi Pat,
I'm not looking for legal advice, from you or Jorge Contreras.
I'm just asking you to elaborate on your statement.
I know it was you who requested a hold-up in publication. I'd
just like to know what about RFC 5378 concerns you with respect to
these documents and what the "workaround" you are seeking looks like.
Like you agreed, these are the WG's documents. So you should tell
the WG what it is you want done to them.
Dan.
On Tue, January 27, 2009 9:12 am, Pat Calhoun (pacalhou) wrote:
> Hi Dan,
>
> I'd prefer not to be the one to provide legal advice to folks on this
> list. What I would, however, recommend is that you contact the IETF IP
> counsel, Jorge Contreras at Wilmer Hale, who can provide you with this
> information. You can find info on Jorge at
> http://www.wilmerhale.com/jorge_contreras/.
>
> PatC
>
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins [at] lounge.org]
> Sent: Monday, January 26, 2009 10:56 AM
> To: Pat Calhoun (pacalhou)
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] status of CAPWAP
>
>
> Hi Pat,
>
> Can you expand on _exactly_ what those consequences would be?
>
> CAPWAP may not be the only document being held up but it may have
> the most to lose if the "work around" limits derivative work. Hence
> my concern.
>
> Dan.
>
> On Sun, January 25, 2009 11:00 pm, Pat Calhoun (pacalhou) wrote:
>> Correct Dan, but publication will have many unintended consequences.
>> From what I am being told, this is actively being addressed now, so I
>> would prefer we hold off a little longer. CAPWAP is not the only
>> document that is being held up. We already have the RFC numbers if
>> anyone needs to reference them (e.g., EPCGlobal), and the latest
> drafts
>> can be used for anyone actively developing.
>>
>> Personally, if we believe these need to be published today, then I
> would
>> instead ask that we force the RFC Editor to adopt the old rules -
> which
>> applied when the spec was written.
>>
>> PatC
>>
>> -----Original Message-----
>> From: Dan Harkins [mailto:dharkins [at] lounge.org]
>> Sent: Saturday, January 24, 2009 1:27 PM
>> To: capwap [at] frascone.com
>> Subject: [Capwap] status of CAPWAP
>>
>>
>> Hi,
>>
>> Last week Mani wrote:
>>
>> By the way, following this, at the request of at least one of the
>> authors, the three CAPWAP protocol drafts (the RFCs-to-be: 5415,
>> -5416 and -5417) in the RFC-Ed queue have been requested to be
>> placed on hold until this matter is resolved by way of an early
>> work-around from IETF, under discussion in the IETF list.
>>
>> I am concerned about this. If any protocol needs to be able to evolve,
>> and create derivative works, it is CAPWAP. Wireless networking is a
>> rapidly changing field and having a "standard" that cannot change with
>> it makes that "standard" pointless.
>>
>> I politely and respectfully ask the chairs to gauge WG consensus on
>> the matter of what we want to do with our drafts with respect to RFC
>> 5378
>> and then to instruct the editor(s) to follow that consensus. If the
>> editor(s) refuse(s) then I would expect he/she/they to be replaced
> with
>> someone who is willing to implement the will of the WG.
>>
>> These drafts are not any one person's or any one company's property
>> and the hangups of any person or company shouldn't trump the will of
>> the WG.
>>
>> regards,
>>
>> Dan.
>>
>>
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>>
>> Archives: http://lists.frascone.com/pipermail/capwap
>>
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
------------------------------
Message: 4
Date: Wed, 28 Jan 2009 11:34:05 +0100
From: "Romascanu, Dan (Dan)" <dromasca [at] avaya.com>
Subject: [Capwap] AD review of draft-ietf-capwap-802dot11-mib-02.txt
To: <capwap [at] frascone.com>
Cc: "MIB Doctors \(E-mail\)" <mib-doctors [at] ietf.org>
Message-ID:
<EDC652A26FB23C4EB6384A4584434A0401362785 [at] 307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="US-ASCII"
Please find below the AD review of
draft-ietf-capwap-802dot11-mib-02.txt. The document needs at least one
more iteration before submission to the IESG. I would also advice that
the document is reviewed by as many CAPWAP and IEEE 802.11 knowledgeable
individuals to make sure that the modeling makes sense and all critical
management information is covered by the MIB modules that are defined.
The comments are divided into Technical and Editorial.
T1. T4. In order for ifIndex to be used as a common handler for the
CAPWAP MIB and for the interface specific MIB modules like a dot11 MIB
from IEEE one needs to ensure that the same numbering scheme and mapping
is used by all MIB modules, and that it behaves identically for events
like interface card swapping, reset or power loss. I do not see how this
can happen, I am not sure that this is possible at all, and in any case
there is no text in the document that explains this mechanism.
T2. Is the WLAN Service interface described in Section 7.2 modeled by
capwapDot11WlanConfigTable? If so please say it and make this clear by
using a more explicit naming convention. The model here is not clear to
me. On one hand you say 'the interface SHOULD be modeled as an ifEntry
...' Why only a SHOULD and not a MUST? What is the procedure for the
manager? Is he looking for all 802.11 interfaces on the AC and then
creates manually a WLAN Service entry in the table for each? What if the
ifNumber does not correspond to a 802.11 interface? What if the 802.11
interface disappears?
T3. What 'could be always enabled' means for ifAdminStatus and
ifOperStatus in the WLAN Service Interface table? Either change this to
MUST or explain in what cases these should be other than enabled.
T4. What does the statement that 'the other objects such as ifInOctets
... are unused' relative to the VLAN Service interface mean? Counters
are always zero?
T5. In 7.4 - does the text mean that the manager can reuse objects from
the IEEE 802.11 MIB modules, or that values of these objects are being
duplicates in this MIB module? (why? Which ones?) In any case the IEEE
802.11 standard that defines these objects must be a Normative Reference
for this document.
T6. The RFCs that define all MIB modules required for IMPORTSs must be
Normative References to this document.
T7. The value of the object capwapBaseWTPId in the example is the string
'12345678' not the integer 12345678
T8. The names of the objects in the capwapDot11WlanConfigTable are not
consistent (similar prefix) to capwapDot11WlanConfigEntry.
T9. The names of the objects in the capwapDot11WlanBindTable are not
consistent (similar prefix) to capwapDot11WlanBindEntry.
T10. What does 'Bits are exclusive for each other for a specific WLAN
Id' mean for capwapDot11WlanTunnelMode? That only one tunnel mode can be
configured (one bit set)? I assume this does not include the bit
unused(0). What happens if the manager sets more than one bit, ore no
bit, or unused(0) - how does the agent behave in this case?
T11. What is the persistency of the capwapDot11WlanTunnelMode at agent
reboot? Is the whole table persistent at agent reboot?
T12. I do not understand how does row creation in the
capwapDot11WlanBindTable work. It is indexed by ifIndex and
capwapDot11WlanId. The only visible object in this table except
RowStatus is capwapDot11WlanBssIfIndex which is read-only and the
description says that 'it is the same interface as identified by the
same value of ifIndex. But the manager cannot read its value until the
row exists. How does the manager know its value in order to create the
row in the table?
T13. Is the capwapDot11WlanBindTable persistent at agent reboot?
E1. Not all acronyms are expanded at first occurrence - e.g. WTP
E2. Please avoid using the construct 'the MIBs' (e.g. in Section 5).
s/the MIBs/the MIB modules/
E3. There is no need to include sections 6.1 and 6.2, they provide no
new or specific information for this MIB module.
E4. I suggest for this document to be verified by a native English
speaker for English spelling and grammar.
E5. ifIndex, ifDescr, ifName, ifAlias in the WLAN Service Interface and
WLAN BSS Interface table contain no specific information, I suggest to
just mention that they are used as per RFC 2863
Dan
------------------------------
_________________________________________________________________
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 38, Issue 6
*************************************
-
Some question on Base MIB comments young, February 5 2009
- Re: Some question on Base MIB comments Romascanu, Dan (Dan), February 8 2009
Results generated by Tiger Technologies using MHonArc.