Capwap Mailing List: Re: My (Richard) comments to the Gen-ART review ofdraft-ietf-capwap-base-mib-06

[David Harrington (ietfdbh]

Hi,

David Perkin's email should also be updated in the MIB drafts.
Try dperkins3600 [at] gmail.com

You should ask if he needs his address and affiliation updated as
well.

your friendly email hunter-downer,
dbh

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh [at] comcast.net] 
> Sent: Monday, November 30, 2009 11:34 AM
> To: 'young'; Black_David [at] emc.com; dperkins [at] snmpinfo.com; 
> yzhang [at] fortinet.com; gen-art [at] ietf.org; mrw [at] lilacglade.org; 
> dromasca [at] avaya.com
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] My (Richard) comments to the Gen-ART 
> review ofdraft-ietf-capwap-base-mib-06
> 
> Try chelliot [at] gmail.com 
> 
> dbh
> 
> > -----Original Message-----
> > From: young [mailto:young [at] h3c.com] 
> > Sent: Sunday, November 29, 2009 10:42 PM
> > To: Black_David [at] emc.com; dperkins [at] snmpinfo.com; 
> > yzhang [at] fortinet.com; gen-art [at] ietf.org; mrw [at] lilacglade.org; 
> > dromasca [at] avaya.com
> > Cc: capwap [at] 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:
> > 
> >       chelliot [at] 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 <chelliot [at] 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 
> > chelliot [at] cisco.com?
> > 
> > Regards
> > Richard
> > 
> > -----邮件原件-----
> > 发件人: Black_David [at] emc.com [mailto:Black_David [at] emc.com] 
> > 发送时间: 2009年11月26日 8:48
> > 收件人: young [at] h3c.com; dperkins [at] snmpinfo.com; yzhang [at] 
> > fortinet.com;
> > gen-art [at] ietf.org
> > 抄送: mmani [at] avaya.com; dorothy.gellert [at] gmail.com;
> mrw [at] lilacglade.org;
> > dromasca [at] avaya.com; capwap [at] frascone.com; Black_David [at] 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:
> > 
> >       chelliot [at] 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 <chelliot [at] cisco.com>... User 
> > unknown' (delivery
> > attempts: 0)>
> > 
> > 
> > Thanks,
> > --David
> >  
> > 
> > > -----Original Message-----
> > > From: Black, David 
> > > Sent: Wednesday, November 25, 2009 7:43 PM
> > > To: young [at] h3c.com; dperkins [at] snmpinfo.com; chelliot [at] 
> > > cisco.com; 
> > > yzhang [at] fortinet.com; gen-art [at] ietf.org
> > > Cc: Black, David; mmani [at] avaya.com; dorothy.gellert [at] gmail.com; 
> > > mrw [at] lilacglade.org; Dan (Dan) Romascanu; capwap [at] 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_david [at] 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
> > 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
>