Subject: [Capwap] The list of changes should be done according to David's comments

From: young <[email-masked]>
Date: Mon, 14 Dec 2009 17:28:10 +0800

Hi, David:

According to the latest discussion in the mailing list, here I gave a list of
changes should be done according to your review comments.

[*] 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.
[Status] 
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 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".
[Editors] 
1) David L. Black agreed to use “management” instead of “creation”.
2) I can't do better job than a native speaker of English
[Status]
Margaret or Dan, please considers how to handle it.

Terminology section:
[*]- Add a definition of PHY, it's undefined in this document.
[Editors] would use “physical layer (PHY)”in the place where it (PHY) first appear
[Status] David L. Black agree to it

[*]- 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?
[Editors] 
I got the definition of station (STA) and WTP from RFC5415.
[Status] 
David L. Black said: 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.
[Editors] Changes would be done according to the David L. Black’s suggestion, 
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;

[*] 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.
[Editors] 
would use the word “ifIndex”.
[Status] 
David L. Black agreed to it.

[*] 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.
[Editors]
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.
[Status] Dan or Margaret please confirm 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.
[Editors]
1) Margaret or Dan, please confirm whether is it allowed to 
have the Message Element Extension in the MIB drafts?
2) The word "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" ?
3) 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?
[Status]
Need more comments in the mailing list.

[*] Appendix A (change history) should include a request to the
RFC Editor to remove it before publication of the RFC.
[Editors] 
would add” RFC Editor - please remove it before publication of the RFC” before the
Appendix A.

[*] 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.).
[Editors]
It would be changed

 [*]  == Outdated reference: A later version (-05) exists of
     draft-ietf-capwap-802dot11-mib-04
[Editors] 
would use version 05 as reference

[*] 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)>
[Editors] 
could updated with [email-masked]. 
[Status]
More latest info about Chris and David Perkins is required.

Regards
Richard

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2009 11:09:32 +0100

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: young [mailto:[email-masked]] 
> Sent: Monday, December 14, 2009 11:28 AM
> To: [email-masked]; [email-masked]
> Subject: [Capwap] The list of changes should be done 
> according to David'scomments
> 
> Hi, David:
> 
> According to the latest discussion in the mailing list, here 
> I gave a list of changes should be done according to your 
> review comments.
> 
> [*] 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.
> [Status]
> Dan's working on it.

The IANA allocations required by this document can be made in an
Informational RFC. 

...

> 
> [*] 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.
> [Editors]
> 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.

Confirmed. The WG agreed on this change and on the Errata as being a
clarification to RFC 5415 which does not impact interoperability. 

...
> 
> [*] 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.
> [Editors]

Content of 5.7 was addressed above. Section 9 refers to a usage of
Message Element Extensions which a vendor can chose to implement or not.
It is not normative text and multi-vendor interoperability is not
required. I do not see why it ought to be in a separate document and why
this document should be standards track. Other opinions are welcome,
though.

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 10:29:53 -0500

Dan,

> Content of 5.7 was addressed above.

I agree, this is resolved.

> Section 9 refers to a usage of
> required.

Multi-vendor interoperability is not required??  This looks like an
assertion that the CAPWAP WTP and AC are always from the same vendor
when this MIB is implemented - that doesn't sound right.

> I do not see why it ought to be in a separate document and why

The rationale for a separate document is that this is changing
(extending)
the CAPWAP protocol, and I'm surprised to find protocol changes in a MIB
draft.  With the 5.7 concern resolved (that was a modification to a
standards track RFC), a standards track draft is no longer needed, but
I still think a separate document may be preferable.  

Thanks,
--David

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Monday, December 14, 2009 5:10 AM
> To: young; [email-masked]; Black, David
> Subject: RE: [Capwap] The list of changes should be done according to
David'scomments

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2009 16:41:38 +0100

In line, leaving the still open issue.

Dan

> From: [email-masked] [mailto:[email-masked]] 

...

> Multi-vendor interoperability is not required??  This looks 
> like an assertion that the CAPWAP WTP and AC are always from 
> the same vendor when this MIB is implemented - that doesn't 
> sound right.

Maybe I mis-understood. The second field in the extension is a
vendor-ID. Why is this here? If the purpose is multivendor
interoperability we may not need it. 

> 
> > I do not see why it ought to be in a separate document and why this 
> > document should be standards track. Other opinions are welcome, 
> > though.
> 
> the CAPWAP protocol, and I'm surprised to find protocol 
> changes in a MIB draft.  With the 5.7 concern resolved (that 
> was a modification to a standards track RFC), a standards 
> track draft is no longer needed, but I still think a separate 
> document may be preferable.  
> 

Why? These extensions are specially designed so that a WTP gets from the
ACs the information to instrument the MIB objects. 

> > > Subject: [Capwap] The list of changes should be done according to 
> > > David'scomments
> > >
> > > Hi, David:
> > >
> > > According to the latest discussion in the mailing list, 
> here I gave 
> > > a list of changes should be done according to your review 
> comments.
> > >
> 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.
> > > [Status]
> > > Dan's working on it.
> > 
> > > 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.
> > > [Editors]
> > > [*] 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.
> > > [Editors]
> > > 1) Margaret or Dan, please confirm whether is it allowed 
> to have the 
> > > Message Element Extension in the MIB drafts?
> >

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 11:00:43 -0500

More inline - it looks like we have an IANA Considerations issue
at a minimum,  --David

> Sent: Monday, December 14, 2009 10:42 AM
> To: Black, David; [email-masked]; [email-masked]
David'scomments
> > > Message Element Extensions which a vendor can chose to implement
or
> > not.

I suspect that you may have misunderstood, and the cause of the
misunderstanding is a new open issue that requires attention:

Section 9 says:

      CAPWAP Message Element          Vendor Identifier       Element ID

      CAPWAP Protocol Timers          Id assigned by IANA           1
      CAPWAP Protocol Variables       Id assigned by IANA           2

That's badly specified.  It looks like what's going on here is that
this is a CAPWAP "Vendor Specific Payload" (37) for which IANA is being
asked to allocate a Vendor Identifier (see RFC 5415, 4.6.39), but that
request is not in the IANA Considerations section of the draft.  At
a minimum, this omission needs to be corrected.

This sort of use of a vendor-id to signal a standardized extension has
been done elsewhere - IPsec NAT traversal is a past example.

If this extension really is intended to be vendor-specific, it belongs
in a document entitled "Vendor-X's extensions to the CAPWAP protocol" or
something like that, and should not be part of the standard MIB draft.

> > > I do not see why it ought to be in a separate document and why
this
> ACs the information to instrument the MIB objects.

Is a protocol implementer going to expect to look at the MIB document
to find additional pieces of the protocol that need to be implemented?

Maybe ... as I noted earlier, I'm surprised to find a MIB document
defining protocol extensions, and I suspect I won't be the only one
who's surprised.

Thanks,
--David

> > > Message Element Extensions which a vendor can chose to implement
or
> > not.
> > > required. I do not see why it ought to be in a separate document
and
> > why

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2009 17:13:11 +0100

In line. 

Regards,

Dan

> Sent: Monday, December 14, 2009 6:01 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Capwap] The list of changes should be done 
> More inline - it looks like we have an IANA Considerations 
> issue at a minimum,  --David
> 
> I suspect that you may have misunderstood, and the cause of 
> the misunderstanding is a new open issue that requires attention:
> 
> Section 9 says:
> 
> That's badly specified.  It looks like what's going on here 
> is that this is a CAPWAP "Vendor Specific Payload" (37) for 
> which IANA is being asked to allocate a Vendor Identifier 
> (see RFC 5415, 4.6.39), but that request is not in the IANA 
> Considerations section of the draft.  At a minimum, this 
> omission needs to be corrected.

Yes. 

> 
> This sort of use of a vendor-id to signal a standardized 
> extension has been done elsewhere - IPsec NAT traversal is a 
> past example.
> 
> If this extension really is intended to be vendor-specific, 
> it belongs in a document entitled "Vendor-X's extensions to 
> the CAPWAP protocol" or something like that, and should not 
> be part of the standard MIB draft.
> 
> changes in a 
> > > MIB draft.  With the 5.7 concern resolved (that was a 
> modification 
> > > to a standards track RFC), a standards track draft is no longer 
> > > needed, but I still think a separate document may be preferable.
> > >
> > 
> Is a protocol implementer going to expect to look at the MIB 
> document to find additional pieces of the protocol that need 
> to be implemented?

If he/she implements the MIB - otherwise they won't need it. 

And actually the same question can be asked if the MIB document is split
in two. 

> 
> Maybe ... as I noted earlier, I'm surprised to find a MIB 
> document defining protocol extensions, and I suspect I won't 
> be the only one who's surprised.
> 
> Thanks,
> --David
>

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 12:48:11 -0500

Dan,

The draft authors clearly need to fix the IANA problem, including
telling IANA exactly what needs to be allocated.  As noted below,
I'm reasonably confident that they're using a vendor-id for a
standardized extension to the CAPWAP protocol.

At this point, I suggest that you and I should "agree to disagree"
about whether to split the protocol extensions out of this MIB
draft.  As things stand, I'd guess that this topic will wind up
on the IESG's plate to sort out.

Thanks,
--David

> Sent: Monday, December 14, 2009 11:13 AM
David'scomments
> > > Why? These extensions are specially designed so that a WTP gets
from
> > the

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2009 18:51:58 +0100

Fine with me.

Thank you for the attentive review. 

Dan

> Sent: Monday, December 14, 2009 7:48 PM
> The draft authors clearly need to fix the IANA problem, 
> including telling IANA exactly what needs to be allocated.  
> As noted below, I'm reasonably confident that they're using a 
> vendor-id for a standardized extension to the CAPWAP protocol.
> 
> about whether to split the protocol extensions out of this 
> MIB draft.  As things stand, I'd guess that this topic will 
> wind up on the IESG's plate to sort out.
> 
> Thanks,
> --David
> 
> 
> > > More inline - it looks like we have an IANA 
> Considerations issue at 
> > > a minimum,  --David
> > >
> > > > > > Section 9 refers to a usage of Message Element Extensions 
> > > > > > which a vendor can chose to
> implement
> > > or
> > > > > not.
> > > this is a CAPWAP "Vendor Specific Payload" (37) for which IANA is 
> > > being asked to allocate a Vendor Identifier (see RFC 
> 5415, 4.6.39), 
> > > but that request is not in the IANA Considerations section of the 
> > > draft.  At a minimum, this omission needs to be corrected.
> > 
> > Yes.
> > 
> > >
> extension 
> > > has been done elsewhere - IPsec NAT traversal is a past example.
> > >
> > > If this extension really is intended to be vendor-specific, it 
> > > belongs in a document entitled "Vendor-X's extensions to 
> the CAPWAP 
> > > protocol" or something like that, and should not be part of the 
> > > standard MIB draft.
> > >
> > > document to find additional pieces of the protocol that 
> need to be 
> > > implemented?
> > 
> document