Try chell...@gmail.com dbh
> -----Original Message----- > From: young [mailto:yo...@h3c.com] > Sent: Sunday, November 29, 2009 10:42 PM > To: black_da...@emc.com; dperk...@snmpinfo.com; > yzh...@fortinet.com; gen-art@ietf.org; m...@lilacglade.org; > droma...@avaya.com > Cc: cap...@frascone.com > Subject: [Capwap] 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 <chell...@cisco.com>... 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 > chell...@cisco.com? > > Regards > Richard > > -----邮件原件----- > 发件人: black_da...@emc.com [mailto:black_da...@emc.com] > 发送时间: 2009年11月26日 8:48 > 收件人: yo...@h3c.com; dperk...@snmpinfo.com; yzh...@fortinet.com; > gen-art@ietf.org > 抄送: mm...@avaya.com; dorothy.gell...@gmail.com; m...@lilacglade.org; > droma...@avaya.com; cap...@frascone.com; black_da...@emc.com > 主题: 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: > > 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 <chell...@cisco.com>... User > unknown' (delivery > attempts: 0)> > > > Thanks, > --David > > > > -----Original Message----- > > From: Black, David > > Sent: Wednesday, November 25, 2009 7:43 PM > > To: yo...@h3c.com; dperk...@snmpinfo.com; chell...@cisco.com; > > yzh...@fortinet.com; gen-art@ietf.org > > Cc: Black, David; mm...@avaya.com; dorothy.gell...@gmail.com; > > m...@lilacglade.org; Dan (Dan) Romascanu; cap...@frascone.com > > 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 > > black_da...@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
