Subject: [Capwap] How to track these issue?

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

Dear Dan：

I am OK with Bert and David's comments, and issues you just reminded.
Whether should we use the http://www.capwap.org/cgi-bin/roundup.cgi/MIB/
To track them? 
Or I just post a message in the mailing list to explain all the changes
should
Be done once we almost have consensus..
If we use the method 1, I suggest to use" [IESG][BASE]+ the caption of each
issue caption ". 
I can do that (record each issue and track the progress of the discussion),
and require Bert or David to confirm whether the issue could
Be closed in the end.

Regards
Richard

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2009年12月9日 3:58
收件人: [email-masked]
主题: Capwap Digest, Vol 49, Issue 16

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. More issues on the CAPWAP MIB documents (Romascanu, Dan (Dan))
   2. Re: Capwap Digest, Vol 49, Issue 11 (Yong Zhang)

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

Message: 1
Date: Tue, 8 Dec 2009 12:25:26 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: [Capwap] More issues on the CAPWAP MIB documents
To: <[email-masked]>
Cc: "Bert Wijnen \(IETF\)" <[email-masked]>
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="us-ascii"

Bert draws me the attention on a few more issues related to the CAPWAP
MIB that I believe deserve attention: 

1. Unsigned32s is used in a number of place where possibly a Gauge is
better (limited integer that can increase or decrease between a min and
max limit) - capwapBaseWtpSessions, capwapBaseWtpSessionsLimit,
capwapBaseStationSessions, capwapBaseStationSessionsLimit,
capwapBaseWtpProfileWtpMaxDiscoveryInterval,
capwapBaseWtpRadiosInUseNum, capwapBaseWtpRadioNumLimit,
capwapBaseWtpDataChannelDeadInterval, capwapBaseAcWaitDTLSTimer,
capwapBaseAcWaitJoinTimer, 
 
2. In many TCs and objects the enumerations (INTEGER type) start from
value zero. I think that this was discussed during the AD review, and
the answer was that it is so on purpose to be consistent with the values
carried in the CAPWAP protocol fields. I think that this needs to be
explained in the DESCRIPTION clauses of the TCs and respective objects. 
 
3.. There are proper details in the DESCRIPTION clauses of InetAddress
objects as to which object defines the format... it is probably logical,
but it ought to be documented
 
4. There is no description in RowStatus objects as to which writable
objects can be changed when a row is active (if any).
 
Also, please address the IANA question in the review of
draft-ietf-capwap-802dot11-mib

QUESTION: What should we use in the "name" field for the two ifType
assignments?

Action #1:

Upon approval of this document, IANA will assign the following
ifType numbers at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description Reference
------- | ------------ | ------------------------------- | ---------
TDB1 | ??? | WTP Virtual Radio Interface | [RFC-capwap-802dot11-mib-05]
TDB2 | ??? | WLAN Profile Interface | [RFC-capwap-802dot11-mib-05]

Thanks and Regards,

Dan

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

Message: 2
Date: Tue, 8 Dec 2009 11:57:47 -0800
From: Yong Zhang <[email-masked]>
Subject: Re: [Capwap] Capwap Digest, Vol 49, Issue 11
To: "Bert (IETF) Wijnen" <[email-masked]>
Cc: young <[email-masked]>, [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Bert,

The "8-bit" in RFC5415 4.6.25 ECN Support just means the size of "ECN
Support", does not means it is BITS type.

In the RFC5415/5416. when bits are used, there always a diagram which
shows the bit position.

0 -  Limited ECN Support
1 -  Full and Limited ECN Support

For ECN support, if it is defined as a bit, then 1 should be Full ECN
Support only.

There is a lot of capwap variables are defined using enumerated value
start from 0, such as 4.6.21.  Discovery Type,  4.6.34.  Radio
Operational State, 4.6.44.  WTP MAC Type...

Just think using the same values as what defined in the capwap
protocol will make the MIB easier to use. Do you know any widely used
protocol/mib that redefined the enumerated values in the MIB? If that
is a convention way, we can change our MIB definition.

Thanks!

Yong

On Mon, Dec 7, 2009 at 5:26 PM,  <[email-masked]> wrote:
> 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. Re: Thanks for your guidance and quick response
> ? ? ?(Bert Wijnen (IETF))
> ? 2. Re: Thanks for your guidance and quick response
> ? ? ?(Bert Wijnen (IETF))
> ? 3. Re: [Gen-art] Please check the comments to the issues of ?the
> ? ? ?MIB drafts ([email-masked])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Dec 2009 23:18:14 +0100
> From: "Bert Wijnen \(IETF\)" <[email-masked]>
> Subject: Re: [Capwap] Thanks for your guidance and quick response
> To: "young" <[email-masked]>
> Cc: "MIB Doctors \(E-mail\)" <[email-masked]>,
> ? ? ? ?[email-masked]
> Message-ID: <9B311E4130314C6CB374C282316E5535@BertLaptop>
> Content-Type: text/plain; charset="gb2312"
>
> More detail W.r.t. my comments on this:
>
>>> capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>>> ? ? SYNTAX ? ? ?INTEGER {
>>> ? ? ? ? ? ? ? ? ? limited(0),
>>> ? ? ? ? ? ? ? ? ? fullAndLimited(1)
>>> ? ? ? ? ? ? ? ? }
>>> ? ? MAX-ACCESS ?read-create
>>> ? ? STATUS ? ? ?current
>>>
>>> Normally we recommend that ENUMERATIONS do NOT start with zero,
>>> unless
>>> there is a good reason (which we then like to see in the DESCRIPTION
>>> clause).
>>> So... what is the reason?
>>>
>
> You point to RFC5415 sect 4..6.25, where I read:
>
> ? The ECN Support message element is sent by both the WTP and the AC to
> ? indicate their support for the Explicit Congestion Notification (ECN)
> ? bits, as defined in [RFC3168].
>
> ? ? ?0
> ? ? ?0 1 2 3 4 5 6 7
> ? ? +-+-+-+-+-+-+-+-+
> ? ? | ?ECN Support ?|
> ? ? +-+-+-+-+-+-+-+-+
>
> ? Type: ? 53 for ECN Support
>
> ? Length: ? 1
>
> ? ECN Support: ? An 8-bit value representing the sender's support for
> ? ? ?ECN, as defined in [RFC3168]. ?All CAPWAP Implementations MUST
> ? ? ?support the Limited ECN Support mode. ?Full ECN Support is used if
> ? ? ?both the WTP and AC advertise the capability for "Full and Limited
> ? ? ?ECN" Support; otherwise, Limited ECN Support is used.
>
> ? ? ?0 - ?Limited ECN Support
>
> ? ? ?1 - ?Full and Limited ECN Support
>
>
> So from that, I do not see why you could not change your enumeration at 1.
> Bit zero is not a zero value, and bit 1 is not a 1 value. They represent
the
> values 8 and 4, and so you have to convert them anyways to go into the
> MIB OBJECT. So I would RECOMMEND to do
>
>
> ?capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
> ? ? SYNTAX ? ? ?INTEGER {
> ? ? ? ? ? ? ? ? ? limited(1),
> ? ? ? ? ? ? ? ? ? fullAndLimited(2)
> ? ? ? ? ? ? ? ? }
> ? ? MAX-ACCESS ?read-create
> ? ? STATUS ? ? ?current
>
>
>
>
>>> Same question for: capwapBaseWtpDiscoveryType
>>> And for: capwapBaseWtpEventsStatsLastFailureType
>>> And possibly others!! pls check.
>>>
>> [Richard]
>> The enumeration in RFC5415 starts with zero.
>> So how about the description updated in the following way?
>> capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>> ? ? SYNTAX ? ? ?INTEGER {
>> ? ? ? ? ? ? ? ? ? limited(0),
>> ? ? ? ? ? ? ? ? ? fullAndLimited(1)
>> ? ? ? ? ? ? ? ? }
>> ? ? MAX-ACCESS ?read-create
>> ? ? STATUS ? ? ?current
>> ? ? DESCRIPTION
>> ? ? ? ? "Represents the support for the Explicit Congestion
>> Notification
>> ? ? ? ? ?(ECN) bits, as defined in
>> [RFC3168].
>> ? ? ? ? ?The following enumerated values are
>> supported:
>> ? ? ? ? ? ?limited(0) ? ? ? ?- Limited ECN
>> support
>> ? ? ? ? ? ?fullAndLimited(1) - Full and limited ECN support
>> ? ? ? ? ?Since the enumeration in RFC5415 starts with zero, the MIB
>> ? ? ? ? ?object follow the same rule."
>> ? ? REFERENCE
>> ? ? ? ? "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."
>>
>
> See above!!!
>
> Bert
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.frascone.com/pipermail/capwap/attachments/20091207/629ee0c2/att
achment.htm
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Dec 2009 23:38:13 +0100
> From: "Bert Wijnen \(IETF\)" <[email-masked]>
> Subject: Re: [Capwap] Thanks for your guidance and quick response
> To: "young" <[email-masked]>
> Cc: "MIB Doctors \(E-mail\)" <[email-masked]>,
> ? ? ? ?[email-masked]
> Message-ID: <2BA2820C22DB479C860FDFFE07933D5A@BertLaptop>
> Content-Type: text/plain; charset="gb2312"
>
> more details/advise about my commet:
>
> ?> In the MODULE-COMPLIANCE, I would have expected at least that
> ?> some (or all) of the IF-MIB module would also be mandatory???!!!
>
> ?[Richard]
> ?In fact, I don't understand why it is required?
> ?The ifGeneralInformationGroup in the IF-MIB module is mandatory, and
> ?The CAPWAP-BASE-MIB relies on the IF-MIB. There are no
> ?special requirement to the IF-MIB.
> ?Please let me know what should be done here?
> Section 7.2 of draft-ietf-capwap-base-mib-06.txt states that
> ? ? ? The IF-MIB module is required to be supported on the AC.
>
> So when I see a MODULE-COMPLIANCE, I would have expected something like:
>
> capwapBaseCompliance MODULE-COMPLIANCE
> ? STATUS current
> ? DESCRIPTION
> ? ? ? "Describes the requirements for conformance to the
> ? ? ? ?CAPWAP-BASE-MIB module."
>
> ? MODULE ?IF-MIB
> ? ? ? MANDATORY-GROUPS {
> ? ? ? ? ? ?some mandatory groups from the IF-MIB, possibly all?
> ? ? ? }
> ? ... potentially some optional groups from IF-MIB as well?
>
> ? ... and then follow the MANDATORY GROUPS of THIS MODULE (the
CAPWAP-BASE-MIB module)
>
> ? MODULE -- this module
> ? ? MANDATORY-GROUPS {
> ? ? ? capwapBaseAcNodeGroup,
> ? ? ? capwapBaseWtpProfileGroup,
> ? ? ? capwapBaseWtpStateGroup,
> ? ? ? capwapBaseWtpGroup,
> ? ? ? capwapBaseRadioGroup,
> ? ? ? capwapBaseStationGroup
> ? ? }
>
>
> For an example, see RFC3811, but also RFC3289
>
> But then, maybe if indeed the WHOLE IF-MIB MUST be supported, then just
stating that
> may be OK.
>
> Bert
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.frascone.com/pipermail/capwap/attachments/20091207/a81efa69/att
achment.htm
>
> ------------------------------
>
> Message: 3
> Date: Mon, 7 Dec 2009 20:24:03 -0500
> From: <[email-masked]>
> Subject: Re: [Capwap] [Gen-art] Please check the comments to the
> ? ? ? ?issues of ? ? ? the MIB drafts
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>,
> ? ? ? ?<[email-masked]>, <[email-masked]>, <[email-masked]>,
> ? ? ? ?<[email-masked]>
> Cc: [email-masked], [email-masked]
> Message-ID:
> ? ? ? ?<[email-masked]>
> Content-Type: text/plain; ? ? ? charset="gb2312"
>
> I see two items that I need to comment on:
>
> (1)
>
>> How about: physical layer (PHY) in the place where it first appears?
>
> Ok, that will suffice.
>
> (2)
>
>> [David]
>> The first bullet in 5.1 implies that all management of a WTP is via this
>> MIB. ?OTOH, The first bullet in 5.4 says that the MIB is optional for a
>> WTP. ?The combination allows unmanaged WTPs - I don't think that was what
>> was intended, rather the basic level of WTP management is in the CAPWAP
>> protocol itself, and the MIB adds additional management functionality.
>> -------------------------
>> [Richard] 5.1 is to explain the function. 5.4 (the MIB is optional for a
>> WTP) is to explain that SNMP agent is not REQUIRED on the WTP devices.
>> If you feel is not clear, kindly suggest how to updates the text.
>
> I think one small change in Section 5.1 will suffice:
>
> OLD
> ? - Support centralized management and monitoring of WTPs from the AC;
>
> NEW
> ? - Support centralized management and monitoring of WTPs from the AC in
> ? ? ? ?combination with the CAPWAP protocol;
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
Behalf Of young
>> Sent: Wednesday, December 02, 2009 10:45 PM
>> To: Black, David; [email-masked]; [email-masked];
[email-masked]; [email-masked];
>> [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: [Gen-art] Please check the comments to the issues of the MIB
drafts
>>
>> Hi, All:
>>
>> Please check the left issues.
>> My new comments are under "---------"
>> Some issues need the guidance from Dan or Margaret.
>> BTW, the email address of David Perkins and Chris are updated in the
>> reception address.
>>
>> > [Richard] It is a very general conception.
>> > I checked the RFC5415, it does not give the definition of PHY.
>> > How about: physical layer (PHY) in the place where it first appears?
>> > I am ok with adding a definition of PHY if it is a better solution.
>> [David] I think a definition is preferable. ?For wired Ethernet, the PHY
is
>> a
>> specific piece of functionality (can be in a separate chip) that sits
>> between the transceiver and the Ethernet controller. ?The PHY definition
>> in this draft needs to indicate whether the term covers only this area
>> of functionality vs. covers the entire physical layer including the
>> transceivers and communication medium (e.g., radio transceivers,
>> antennas and wireless signals in this case).
>> -------------------------
>> [Richard]
>> Frankly, it is difficult for me to give an accurate definition to the
PHY.
>> The better way is to get it from the existing standards.
>> I checked the IEEE 802.11-2007. It does not give the definition there.
>> See (copy from IEEE 802.11-2007):
>> 1.1 Scope
>> The scope of this standard is to define one medium access control (MAC)
and
>> several physical layer (PHY)
>> specifications for wireless connectivity for fixed, portable, and moving
>> stations (STAs) within a local area.
>> So I suggest:
>> How about: physical layer (PHY) in the place where it first appears?
>>
>> > > Section 5.1 should explain the division of management of a WTP
between
>> > > the actual CAPWAP protocol and this MIB. ?The first bullet creates
>> > > this confusion, and that bullet is not consistent with the first
>> > > bullet in 5.4. ?That lack of consistency ?should be corrected in
>> > > addition to providing the explanation.
>> > [Richard] I did not get the point. Kindly give more input
>> [David]
>> The first bullet in 5.1 implies that all management of a WTP is via this
>> MIB. ?OTOH, The first bullet in 5.4 says that the MIB is optional for a
>> WTP. ?The combination allows unmanaged WTPs - I don't think that was what
>> was intended, rather the basic level of WTP management is in the CAPWAP
>> protocol itself, and the MIB adds additional management functionality.
>> -------------------------
>> [Richard] 5.1 is to explain the function. 5.4 (the MIB is optional for a
>> WTP) is to explain that SNMP agent is not REQUIRED on the WTP devices.
>> If you feel is not clear, kindly suggest how to updates the text.
>> Thanks.
>> To Dan: Please give your option.
>>
>> > > [*] The text in Section 5.7 attempts to modify RFC 5415. ?That's not
a
>> > > good idea for an Informational document. ?It is ok to say that if the
>> > > additional requirements are not followed, this MIB will not be useful
>> > > or usable.
>> > [Richard]
>> > The WG already made the consensus on it after IETF 75th,
>> > and the WG agree to use the following text.
>> > The section 4.6.40 [RFC5415] does not clarify that the WTP's Base MAC
>> > ?address MUST be included in the WTP Board Data message element. ?This
>> > ?is a known errata item and assumed to be fixed in future by
>> > the editors of
>> > the RFC5415.
>> [David]
>> Make sure that this errata item is filed against RFC 5415 with the RFC
>> Editor.
>> -------------------------
>> [Richard] Dan or Margaret please confirm it.
>>
>> > > [*] 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. ?Here's an example from Section
>> >
>> > [Richard] Margaret or Dan, please consider how to handle it.
>> > For the text, I can't do better job than a native speaker of English:(
>>
>> [David] Understood - I would hope that one of your co-authors would step
up
>> to
>> do this.
>> -------------------------
>> [Richard] I am not sure that David Perkins or Chris could put effort on
it.
>> So Dan or Margaret please consider how to handle it.
>>
>> > > [*] 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.
>> >
>> ----------------------------------
>> David, Dan or Margaret, Please check the following text.
>> > [Richard] ?Margaret or Dan, please confirm whether it is allowed to
have
>> > the Message Element Extension in the MIB drafts.
>> > The "manageable" in the current text "To enable CAPWAP protocol timers
and
>> > variables [RFC5415] manageable ?through CAPWAP protocol" is not very
>> clear.
>> > Maybe the word "viewable " is better.
>> > How ?about we use the text ?"To enable CAPWAP protocol timers and
>> variables
>> > [RFC5415] viewable on the AC through CAPWAP protocol" ?
>> >
>> > Since the MIB objects (such as "capwapBaseAcMaxRetransmit" )
corresponding
>> > to the CAPWAP protocol timers and variables are optional, whether it is
>> > required to add some text
>> > in the Section 9 to clarify that the CAPWAP Message Element
>> > Extension is optional?
>>
>> Regards
>> Richard
>> -----????-----
>> ???: [email-masked] [mailto:[email-masked]]
>> ????: 2009?12?1? 10:53
>> ???: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> ??: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> ??: RE: My (Richard) comments to the Gen-ART review of
>> draft-ietf-capwap-base-mib-06
>>
>> Richard,
>>
>> Comments embedded ...
>>
>> Thanks,
>> --David
>>
>> > Hi, All :
>> >
>> > Please check my comments identified by the [Richard].
>> > To David: Thanks a lot.
>> >
>> > > The important open issues that need to be resolved are tagged with
[*].
>> > >
>> > > [*] Intended document status is now Informational. ?That needs to be
>> > > changed on the title page, but more importantly, someone (draft
>> > > shepherd?) should double-check whether the requested IANA allocations
>> > > are appropriate for an Informational document. If there's a problem
>> > > here, the IESG should be warned that a process exception may be
>> > > needed, as I think the allocations are necessary for this draft.
>> >
>> > [Richard] Margaret or Dan, please confirm it.
>>
>> Dan's working on it.
>>
>> > > [*] 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. ?Here's an example from Section
>> >
>> > [Richard] Margaret or Dan, please consider how to handle it.
>> > For the text, I can't do better job than a native speaker of English:(
>>
>> Understood - I would hope that one of your co-authors would step up to
>> do this.
>>
>> > > 5.6 - the use of the word "conception" is incorrect in this phrase:
>> > > ? ? ? ?the protocol of [RFC5416] defines WLAN conception
>> > > A better word would be "creation".
>> >
>> > [Richard] Hi, David. ?Whether "management" instead of "creation" is
>> > better?
>>
>> I think that's ok.
>>
>> > > Terminology section:
>> > > - Add a definition of PHY, it's undefined in this document.
>> >
>> > [Richard] ?It is a very general conception.
>> > I checked the RFC5415, it does not give the definition of PHY.
>> > How about: physical layer (PHY) in the place where it first appears?
>> > I am ok with adding a definition of PHY if it is a better solution.
>>
>> I think a definition is preferable. ?For wired Ethernet, the PHY is a
>> specific piece of functionality (can be in a separate chip) that sits
>> between the transceiver and the Ethernet controller. ?The PHY definition
>> in this draft needs to indicate whether the term covers only this area
>> of functionality vs. covers the entire physical layer including the
>> transceivers and communication medium (e.g., radio transceivers,
>> antennas and wireless signals in this case).
>>
>> > > - Add a definition of WLAN, while it's defined elsewhere, WLAN
>> > > ? ? ? ?is a crucial concept for this draft and hence needs a
>> > > ? ? ? ?definition here.
>> > [Richard] I am ok.
>> >
>> > > - The definition of station (STA) is sufficiently general to
>> > > ? ? ? ?include WTPs. ?Was that intended?
>> >
>> > [Richard] I got the definition?of station (STA) and WTP from RFC5415.
>>
>> Then I presume this was intended.
>>
>> > > Section 5.1 should explain the division of management of a WTP
between
>> > > the actual CAPWAP protocol and this MIB. ?The first bullet creates
>> > > this confusion, and that bullet is not consistent with the first
>> > > bullet in 5.4. ?That lack of consistency ?should be corrected in
>> > > addition to providing the explanation.
>> > [Richard] ?I did not get the point. Kindly give more input
>>
>> The first bullet in 5.1 implies that all management of a WTP is via this
>> MIB. ?OTOH, The first bullet in 5.4 says that the MIB is optional for a
>> WTP. ?The combination allows unmanaged WTPs - I don't think that was what
>> was intended, rather the basic level of WTP management is in the CAPWAP
>> protocol itself, and the MIB adds additional management functionality.
>>
>> > > Section 5.4: "The ifIndex [RFC2863] is used as a common handler" I
>> > > don't think it's a "handler". ?The ifIndex is actually an index.
>> > [Richard] ?How about use "index" instead of "handler".
>>
>> Ok.
>>
>> > > [*] The text in Section 5.7 attempts to modify RFC 5415. ?That's not
a
>> > > good idea for an Informational document. ?It is ok to say that if the
>> > > additional requirements are not followed, this MIB will not be useful
>> > > or usable.
>> > [Richard]
>> > The WG already made the consensus on it after IETF 75th,
>> > and the WG agree to use the following text.
>> > The section 4.6.40 [RFC5415] does not clarify that the WTP's Base MAC
>> > ?address MUST be included in the WTP Board Data message element. ?This
>> > ?is a known errata item and assumed to be fixed in future by
>> > the editors of
>> > the RFC5415.
>>
>> Make sure that this errata item is filed against RFC 5415 with the RFC
>> Editor.
>>
>> >
>> > > [*] 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.
>> >
>> > [Richard] ?Margaret or Dan, please confirm whether it is allowed to
have
>> > the Message Element Extension in the MIB drafts.
>> > The "manageable" in the current text "To enable CAPWAP protocol timers
and
>> > variables [RFC5415] manageable ?through CAPWAP protocol" is not very
>> clear.
>> > Maybe the word "viewable " is better.
>> > How ?about we use the text ?"To enable CAPWAP protocol timers and
>> variables
>> > [RFC5415] viewable on the AC through CAPWAP protocol" ?
>> >
>> > Since the MIB objects (such as "capwapBaseAcMaxRetransmit" )
corresponding
>> > to the CAPWAP protocol timers and variables are optional, whether it is
>> > required to add some text
>> > in the Section 9 to clarify that the CAPWAP Message Element
>> > Extension is optional?
>> >
>> > > Appendix A (change history) should include a request to the RFC
Editor
>> > > to remove it before publication of the RFC.
>> > [Richard] It is ok.
>> >
>> > > idnits 2.11.15 found a couple of nits:
>> > >
>> > > ?== The document seems to lack a disclaimer for pre-RFC5378 work, but
>> was
>> > > ? ? first submitted before 10 November 2008. ?Should you add the
>> disclaimer?
>> > > ? ? (See the Legal Provisions document at
>> > > ? ? http://trustee.ietf.org/license-info for more information.).
>> >
>> > [Richard] It is ok.
>> >
>> > > ?== Outdated reference: A later version (-05) exists of
>> > > ? ? draft-ietf-capwap-802dot11-mib-04
>> >
>> > [Richard] It is ok.
>> >
>> > The following recipient(s) could not be reached:
>> >
>> > ? ? ? [email-masked] on 11/25/2009 7:43 PM
>> > ? ? ? ? ? ? The e-mail system was unable to deliver the
>> > message, but did not
>> > report a specific reason. ?Check the address and try again.
>> > If it still
>> > fails, contact your system administrator.
>> > ? ? ? ? ? ? < sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 -
>> > Unknown address
>> > error 550-'5.1.1 <[email-masked]>... User unknown' (delivery
>> > attempts: 0)>
>> >
>> > [Richard] I am not able get the Chris' other email address.
>> > Do the chairs or the mailing list know his other email address except
the
>> > [email-masked]?
>> >
>> > Regards
>> > Richard
>> >
>> > -----????-----
>> > ???: [email-masked] [mailto:[email-masked]]
>> > ????: 2009?11?26? 8:48
>> > ???: [email-masked]; [email-masked]; [email-masked];
>> > [email-masked]
>> > ??: [email-masked]; [email-masked]; [email-masked];
>> > [email-masked]; [email-masked]; [email-masked]
>> > ??: RE: Gen-ART review of draft-ietf-capwap-base-mib-06
>> >
>> > Another open issue is that the email address for Chris Elliott
>> > in this draft is wrong and needs to be corrected ...
>> >
>> > The following recipient(s) could not be reached:
>> >
>> > ? ? ? [email-masked] on 11/25/2009 7:43 PM
>> > ? ? ? ? ? ? The e-mail system was unable to deliver the
>> > message, but did
>> > not report a specific reason. ?Check the address and try again. ?If it
>> > still fails, contact your system administrator.
>> > ? ? ? ? ? ? < sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 - Unknown
>> > address error 550-'5.1.1 <[email-masked]>... User
>> > unknown' (delivery
>> > attempts: 0)>
>> >
>> >
>> > Thanks,
>> > --David
>> >
>> >
>> > > -----Original Message-----
>> > > From: Black, David
>> > > Sent: Wednesday, November 25, 2009 7:43 PM
>> > > To: [email-masked]; [email-masked]; [email-masked];
>> > > [email-masked]; [email-masked]
>> > > Cc: Black, David; [email-masked]; [email-masked];
>> > > [email-masked]; Dan (Dan) Romascanu; [email-masked]
>> > > Subject: Gen-ART review of draft-ietf-capwap-base-mib-06
>> > >
>> > > I have been selected as the General Area Review Team (Gen-ART)
>> > > reviewer for this draft (for background on Gen-ART, please see
>> > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>> > >
>> > > Please resolve these comments along with any other Last Call
>> > > comments you may receive.
>> > >
>> > > Document: draft-ietf-capwap-base-mib-06
>> > > Reviewer: David L. Black
>> > > Review Date: November 25, 2009
>> > > IETF LC End Date: December 7, 2009
>> > >
>> > > Summary:
>> > > This draft is on the right track, but has open issues, described
>> > > in the review.
>> > >
>> > > Comments:
>> > > This draft defines a MIB for the CAPWAP protocol. ?It also extends
>> > > that protocol, which is a peculiar thing to do in a MIB document.
>> > > I've left review of the actual MIB definitions to the expertise
>> > > of the MIB Doctors.
>> > >
>> > > The important open issues that need to be resolved are tagged
>> > > with [*].
>> > >
>> > > [*] Intended document status is now Informational. ?That needs to
>> > > be changed on the title page, but more importantly, someone
>> > > (draft shepherd?) should double-check whether the requested
>> > > IANA allocations are appropriate for an Informational document.
>> > > If there's a problem here, the IESG should be warned that a
>> > > process exception may be needed, as I think the allocations are
>> > > necessary for this draft.
>> > >
>> > > [*] 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. ?Here's an example from Section
>> > > 5.6 - the use of the word "conception" is incorrect in this phrase:
>> > > ? the protocol of [RFC5416] defines WLAN conception
>> > > A better word would be "creation".
>> > >
>> > > Terminology section:
>> > > - Add a definition of PHY, it's undefined in this document.
>> > > - Add a definition of WLAN, while it's defined elsewhere, WLAN
>> > > ? is a crucial concept for this draft and hence needs a
>> > > ? definition here.
>> > > - The definition of station (STA) is sufficiently general to
>> > > ? include WTPs. ?Was that intended?
>> > >
>> > > Section 5.1 should explain the division of management of a
>> > > WTP between the actual CAPWAP protocol and this MIB. ?The
>> > > first bullet creates this confusion, and that bullet is not
>> > > consistent with the first bullet in 5.4. ?That lack of
>> > > consistency ?should be corrected in addition to providing
>> > > the explanation.
>> > >
>> > > Section 5.4: "The ifIndex [RFC2863] is used as a common handler"
>> > > I don't think it's a "handler". ?The ifIndex is actually an index.
>> > >
>> > > [*] The text in Section 5.7 attempts to modify RFC 5415. ?That's
>> > > not a good idea for an Informational document. ?It is ok to
>> > > say that if the additional requirements are not followed, this
>> > > MIB will not be useful or usable.
>> > >
>> > > [*] 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.
>> > >
>> > > Appendix A (change history) should include a request to the
>> > > RFC Editor to remove it before publication of the RFC.
>> > >
>> > > idnits 2.11.15 found a couple of nits:
>> > >
>> > > ? == The document seems to lack a disclaimer for pre-RFC5378
>> > > work, but was
>> > > ? ? ?first submitted before 10 November 2008. ?Should you add
>> > > the disclaimer?
>> > > ? ? ?(See the Legal Provisions document at
>> > > ? ? ?http://trustee.ietf.org/license-info for more information.).
>> > >
>> > > ? == Outdated reference: A later version (-05) exists of
>> > > ? ? ?draft-ietf-capwap-802dot11-mib-04
>> > >
>> > > Thanks,
>> > > --David
>> > > ----------------------------------------------------
>> > > David L. Black, Distinguished Engineer
>> > > EMC Corporation, 176 South St., Hopkinton, MA ?01748
>> > > +1 (508) 293-7953 ? ? ? ? ? ? FAX: +1 (508) 293-7786
>> > > [email-masked] ? ? ? ?Mobile: +1 (978) 394-7754
>> > > ----------------------------------------------------
>> > >
>> >
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/gen-art
>
>
> ------------------------------
>
> _________________________________________________________________
> 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 11
> **************************************
>

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

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

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Dec 2009 09:38:54 +0100

Hi Richard,

This is up to you and the WG to decide. My personal preference is for method 1, which is maybe more work for you but individual tracking allows for each issue to be tracked separately until its closure. 

If you use this and prefix I suggest that you use IETFLC (IETF Last Call) as prefix rather than IESG. The document is not yet on the IESG table, when it will get there you may get new comments from the other Area Directors. 

Thanks and Regards,

Dan

> From: young [mailto:[email-masked]] 
> Sent: Wednesday, December 09, 2009 4:01 AM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: 'Bert (IETF) Wijnen'; [email-masked]
> Subject: How to track these issue?
> 
> Dear Dan：
> 
> Whether should we use the 
> http://www.capwap.org/cgi-bin/roundup.cgi/MIB/
> To track them? 
> Or I just post a message in the mailing list to explain all 
> the changes should Be done once we almost have consensus..
> If we use the method 1, I suggest to use" [IESG][BASE]+ the 
> caption of each issue caption ". 
> I can do that (record each issue and track the progress of 
> the discussion), and require Bert or David to confirm whether 
> the issue could Be closed in the end.
> 
> Regards
> Richard
> 
> -----邮件原件-----
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Capwap digest..."
> 
> 
> Today's Topics:
> 
> Bert draws me the attention on a few more issues related to 
> the CAPWAP MIB that I believe deserve attention: 
> 
> 1. Unsigned32s is used in a number of place where possibly a 
> Gauge is better (limited integer that can increase or 
> decrease between a min and max limit) - 
> capwapBaseWtpSessions, capwapBaseWtpSessionsLimit, 
> capwapBaseWtpDataChannelDeadInterval, 
> capwapBaseAcWaitDTLSTimer, capwapBaseAcWaitJoinTimer, 
>  
> 2. In many TCs and objects the enumerations (INTEGER type) 
> start from value zero. I think that this was discussed during 
> the AD review, and the answer was that it is so on purpose to 
> be consistent with the values carried in the CAPWAP protocol 
> fields. I think that this needs to be explained in the 
> DESCRIPTION clauses of the TCs and respective objects. 
>  
> 3.. There are proper details in the DESCRIPTION clauses of 
> InetAddress objects as to which object defines the format... 
> it is probably logical, but it ought to be documented
>  
> 4. There is no description in RowStatus objects as to which 
> writable objects can be changed when a row is active (if any).
>  
> QUESTION: What should we use in the "name" field for the two 
> ifType assignments?
> 
> Action #1:
> 
> Upon approval of this document, IANA will assign the 
> following ifType numbers at 
> The "8-bit" in RFC5415 4.6.25 ECN Support just means the size 
> of "ECN Support", does not means it is BITS type.
> 
> In the RFC5415/5416. when bits are used, there always a 
> diagram which shows the bit position.
> 
> 0 -  Limited ECN Support
> For ECN support, if it is defined as a bit, then 1 should be 
> Full ECN Support only.
> 
> There is a lot of capwap variables are defined using 
> enumerated value start from 0, such as 4.6.21.  Discovery 
> Type,  4.6.34.  Radio Operational State, 4.6.44.  WTP MAC Type...
> 
> Just think using the same values as what defined in the 
> capwap protocol will make the MIB easier to use. Do you know 
> any widely used protocol/mib that redefined the enumerated 
> values in the MIB? If that is a convention way, we can change 
> our MIB definition.
> 
> Thanks!
> 
> Yong
> 
> > 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]
> >
> > ? 1. Re: Thanks for your guidance and quick response ? ? 
> ?(Bert Wijnen 
> > (IETF)) ? 2. Re: Thanks for your guidance and quick response ? ? 
> > ?(Bert Wijnen (IETF)) ? 3. Re: [Gen-art] Please check the 
> comments to 
> > the issues of ?the ? ? ?MIB drafts ([email-masked])
> >
> >
> > 
> > Cc: "MIB Doctors \(E-mail\)" <[email-masked]>, ? ? ? 
> > ?[email-masked]
> >>> capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE ? ? SYNTAX ? ? 
> >>> ?INTEGER { ? ? ? ? ? ? ? ? ? limited(0), ? ? ? ? ? ? ? ? ? 
> >>> fullAndLimited(1) ? ? ? ? ? ? ? ? } ? ? MAX-ACCESS 
> ?read-create ? ? 
> >>> STATUS ? ? ?current
> >>>
> >>> unless there is a good reason (which we then like to see in the 
> >>> DESCRIPTION clause).
achment.htm
CAPWAP-BASE-MIB module)
stating that
Behalf Of young
drafts
is
PHY.
and
between
a
up
it.
Section
have
and
corresponding
[*].
between
a
Section
have
and
corresponding
Editor
the

---

From: young <[email-masked]>
Date: Wed, 09 Dec 2009 17:32:01 +0800

Hi, Bert and David：

What's your opinion？

Regards
Richard

-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2009年12月9日 16:39
收件人: young; [email-masked]
抄送: Bert (IETF) Wijnen; [email-masked]
主题: RE: How to track these issue?

Hi Richard,

This is up to you and the WG to decide. My personal preference is for method
1, which is maybe more work for you but individual tracking allows for each
issue to be tracked separately until its closure. 

If you use this and prefix I suggest that you use IETFLC (IETF Last Call) as
prefix rather than IESG. The document is not yet on the IESG table, when it
will get there you may get new comments from the other Area Directors. 

Thanks and Regards,

Dan

achment.htm
CAPWAP-BASE-MIB module)
stating that
Behalf Of young
drafts
is
PHY.
and
between
a
up
it.
Section
have
and
corresponding
[*].
between
a
Section
have
and
corresponding
Editor
the

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 09 Dec 2009 11:13:19 +0100

I do not care much.
I would think you want to check with your WG chairs on this. They may care.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Dec 2009 09:43:49 -0500

Hi,

That is a decision to be made by the editors and chairs. They are the ones that have to do the work.
Ask the chairs how they want to handle tracking issues.
They may decide you should just track them yourselves, as editors.

Keep in mind that no matter which tracking system or wiki or web page you choose to use to track issues, the official place to track and resolve issues is the WG mailing list. 

dbh

> Sent: Wednesday, December 09, 2009 4:32 AM
> To: 'Bert (IETF) Wijnen'; [email-masked]
> Cc: [email-masked]
> Subject: [Capwap] 答复: How to track these issue?
> 
> Hi, Bert and David：
> 
> What's your opinion？
> 
> Regards
> Richard
> 
> -----邮件原件-----
> > ? ? ? 
> ?<[email-masked]>

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 10:36:03 -0500

I agree with Bert's comments.

Thanks,
--David

> From: Bert (IETF) Wijnen [mailto:[email-masked]]
> Sent: Wednesday, December 09, 2009 5:13 AM
> To: young
> Cc: Black, David; 'Romascanu, Dan (Dan)'; [email-masked]
> Subject: Re: 答复: How to track these issue?
> 
> I do not care much.