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 protected] [mailto:[email protected]] On Behalf Of
> young
> Sent: Wednesday, December 02, 2009 10:45 PM
> To: Black, David; [email protected]; [email protected]; [email protected];
> [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]
> 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 protected] [mailto:[email protected]]
> 发送时间: 2009年12月1日 10:53
> 收件人: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> 抄送: [email protected]; [email protected]; [email protected];
> [email protected]
> 主题: 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 protected] 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 protected]>... 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 protected]?
> >
> > Regards
> > Richard
> >
> > -----邮件原件-----
> > 发件人: [email protected] [mailto:[email protected]]
> > 发送时间: 2009年11月26日 8:48
> > 收件人: [email protected]; [email protected]; [email protected];
> > [email protected]
> > 抄送: [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected]
> > 主题: 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 protected] 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 protected]>... User
> > unknown' (delivery
> > attempts: 0)>
> >
> >
> > Thanks,
> > --David
> >
> >
> > > -----Original Message-----
> > > From: Black, David
> > > Sent: Wednesday, November 25, 2009 7:43 PM
> > > To: [email protected]; [email protected]; [email protected];
> > > [email protected]; [email protected]
> > > Cc: Black, David; [email protected]; [email protected];
> > > [email protected]; Dan (Dan) Romascanu; [email protected]
> > > 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 protected] Mobile: +1 (978) 394-7754
> > > ----------------------------------------------------
> > >
> >
> >
> >
> >
>
>
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
