[Gen-art] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06
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. [*] 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:( 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? 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. - 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. 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 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. [*] 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. [*] 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: chell...@cisco.com 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
Re: [Gen-art] 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
