Subject: Re: [Capwap] My (Richard) comments to the Gen-ART review of draft-ietf-capwap-base-mib-06

From: <[email-masked]>
Date: Mon, 30 Nov 2009 21:52:49 -0500

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
> > ----------------------------------------------------
> > 
> 
> 
> 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 1 Dec 2009 10:59:46 -0500

Hi,

David Perkin's email should also be updated in the MIB drafts.
Try [email-masked]

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

your friendly email hunter-downer,
dbh

> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, November 30, 2009 11:34 AM
> To: 'young'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Capwap] My (Richard) comments to the Gen-ART 
> review ofdraft-ietf-capwap-base-mib-06
> 
> Try [email-masked] 
> 
> dbh
> 
> > From: young [mailto:[email-masked]] 
> > Sent: Sunday, November 29, 2009 10:42 PM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > Cc: [email-masked]
> > Subject: [Capwap] My (Richard) comments to the Gen-ART review 
> > of draft-ietf-capwap-base-mib-06
> > 
> > Hi, All :
> > 
with
> > > [*].
MIB 
> > WTP between 

> > > Section 5.4: "The ifIndex [RFC2863] is used as a common handler"
I

> > Extension is
> > optional?
> > RFC Editor 
> > work, but 
> > > was
> > >     first submitted before 10 November 2008.  Should you add the

> > > disclaimer?
> > Do the chairs or
> > the mailing list know his other email address except the 
> > [email-masked]?
> > 
> > Regards
> > Richard
> > 
> > -----邮件原件-----
> > not report a specific reason.  Check the address and try again.
If
> it

---

From: young <[email-masked]>
Date: Thu, 03 Dec 2009 11:45:26 +0800

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.

> 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?

> [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. 

>  is a known errata item and assumed to be fixed in future by 
[David]
Make sure that this errata item is filed against RFC 5415 with the RFC
Editor.
-------------------------
[Richard] Dan or Margaret please confirm 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.

> > 5.7 ought to be in a separate draft that could be standards track.
----------------------------------
David, Dan or Margaret, Please check the following text.

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

Dan's working on it.

I think that's ok.

 

Ok.

>  is a known errata item and assumed to be fixed in future by 

Make sure that this errata item is filed against RFC 5415 with the RFC
Editor.

disclaimer?

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 20:24:03 -0500

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)

> protocol itself, and the MIB adds additional management functionality.

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

> 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:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: David Perkins <[email-masked]>
Date: Mon, 21 Dec 2009 20:26:55 -0800

HI,

If you would like me to take a look at any specific issues, please list them
and the deadline for a response.

Also, I'd prefer that this gmail email address was not made public. I know
that all email sent to dperkins@snmpinfo will currently bounce, since that
the input queue is full of junk email, which I haven't yet had the time to
remove and switch to another system that does reasonable spam filtering.
However, that is the email address that should be used. By the way, I have
had the same phone number 408-394-8702 for many years, and don't plan on
changing it. You can reach me there. Finally, I'm trying to arrange to
attend the spring IETF meeting to throw a 20th birthday and a SMIC is free
party. If so, then you can see that I'm still around.

PS Look who is one of the coaches of the San Carlos city champion AA  Little
League team in 2009.
http://www.sancarlosll.org/
My guy in 3rd from the right in the front row.

Regards,
/david t. perkins

2009/12/1 David Harrington <[email-masked]>