Subject: [Capwap] Fwd: [IANA #230137] General Request for Assignments (capwap-parameters)

From: Margaret Wasserman <[email-masked]>
Date: Fri, 17 Apr 2009 16:59:40 -0400

Hi All,

Attached please find further information about the China Broadband  
Wireless IP Standard Group's request for a CAPWAP Wireless Binding  
Identifier for WAPI (GB15629.11).  The requester has given permission  
for the attached information to be shared with the CAPWAP WG.

GB15629.11 includes a new security mechanism, WAPI,  that is not  
included in IEEE 802.11.  The attached PDF file describes WAPI, and  
includes the definition of several information elements (such as the  
WAPI Parameter Set Information Element) that cannot be configured  
using the existing CAPWAP 802.11 binding.  So, there seems to be a  
technical justification for the assignment of a new WBID for GB15629.11.

Please let me know by Friday, April 23rd if there are any concerns  
about assigning a new WBID for WAPI.  I will also be forwarding this  
information to the IETF's ITU-T and IEEE 802.11 liaison managers for  
comment.

Thanks,
Margaret

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

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

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 18 Apr 2009 09:12:54 -0400

In further review of this material, a question has arisen in my mind  
about our desired allocation policy for WBIDs...

First a bit of history, as I understand it:

We allocated a WBID for the IEEE 802.11 binding simultaneous with its  
publication as an IETF RFC.

When we decided to allocate a WBID for EPCglobal DCI, we received a  
brief summary of the actual CAPWAP binding that was described in that  
specification.  The full specification was not (yet) publicly  
available, nor had it been ratified by EPCglobal, but some of us had  
seen the specification, and our technical advisor, Bob O'Hara, was the  
editor of it.

Originally, the WG thought that we would assign a WBID for IEEE  
802.16, but we decided not to do so, because there is no CAPWAP  
binding defined (yet) for IEEE 802.16.  While IEEE 802.16 is a  
wireless standard that _could_ use CAPWAP, we decided to delay  
allocation of a WBID for IEEE 802.16 until an IEEE 802.16 CAPWAP  
binding is available.

So, I think we have precedent that a CAPWAP binding should be  
documented (although the document does not need to be publicly  
available) before a WBID is allocated.  Do others agree?

Although the material I have received from ChinaBWIPS does indicate  
that WAPI contains information elements that could be configured by  
CAPWAP using a separate binding, there does not seem to be a CAPWAP  
binding described in the specification that they have included with  
their request.  So, it seems that they may be in the same position as  
IEEE 802.16 -- they have a wireless standard that could make use of  
CAPWAP, but no CAPWAP binding has been defined for it.  If the WG  
agrees that a CAPWAP binding should be defined before a WBID is  
allocated, I will communicate that requirement to this requester.

I apologize for the confusion regarding this request, but this is the  
first WBID request we have received, so I am trying to understand what  
the criteria should be to grant or deny a WBID request.  Given that we  
only have a small number of WBIDs available (30 remaining), I believe  
that we need to set the bar at something higher than first-come-first- 
served, in order to prevent early exhaustion of these identifiers.

What do others think?

Thanks,
Margaret

On Apr 17, 2009, at 4:59 PM, Margaret Wasserman wrote:

> Identifier for WAPI (GB15629.11).  The requester has given  
> permission for the attached information to be shared with the CAPWAP  
> WG.
>
> <6N13774.pdf><Grounds for GB15629.11 WBID application.doc>

---

From: "David Harrington" <[email-masked]>
Date: Sat, 18 Apr 2009 09:37:12 -0400

Hi,

I am not a CAPWAP implementer, and have not been heavily involved in
the WG, but I think it makes sense to require a binding specification
be done (and published) as part of the request for a WBID.

I recommend that WBIDs be assigned on the basis of RFC5226's
"Specification Required" - the IETF WBID should be assigned only when
an associated binding specification is published as an RFC or other
permanent and readily available document, and a Designated Expert has
reviewed the specification to ensure it is clear enough for
interoperability.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Saturday, April 18, 2009 9:13 AM
> To: Margaret Wasserman
> Cc: capwap
> Subject: Re: [Capwap] Fwd: [IANA #230137] General Request for 
> Assignments(capwap-parameters)
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 18 Apr 2009 16:13:42 -0400

Hi David,

The CAPWAP RFC does not list a requirement of "Specification Required"  
for allocation of a WBID, it lists "Expert Review".  The WG could have  
chosen "Specification Required", but did not choose to do so.  "Expert  
Review" is generally considered a lower bar, because it does not  
(necessarily) require a permanent or readily available document  
defining anything.  It would be unusual, I think, to require publicly  
available documents for an assignment that requires "Expert Review".   
Typically, it is considered sufficient to provide any justifying  
documentation to the designated expert.

So, I am not asking whether we should require a "permanent and readily  
available document".  If the WG had wanted that, we could have  
required it.  What I _am_ asking is whether people think it is  
reasonable for me, as the designated expert, to require that a binding  
document exists (although perhaps not  publicly available) before a  
WBID is assigned.

Margaret

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 18 Apr 2009 13:59:26 -0700 (PDT)

Hi Margaret,

  How do you plan on satisfying a _requirement_ for a document to exist
if it is not publicly available? Are you just going to take someone's
word that some document exists or existed somewhere in some form at
some time? If that's the case then it's more like a request than a
requirement. The bar should be a bit higher than that.

  The document you attached to a previous email, Grounds for GB15629.11
WBID application.doc, makes a number of factual errors, beginning with
the very first sentence. Given that, I would personally like to see a
publicly available document to find out just what it is they're talking
about doing and why they need anything from us.

  So yes, I think it is eminently reasonable to require a document to
exist and I think that document must be public, although not necessarily
an RFC (but that sure would be nice, hint hint).

  regards,

  Dan.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 18 Apr 2009 20:19:48 -0400

Hi Dan,

> requirement. The bar should be a bit higher than that.

My understanding is that there are cases where IANA allocations are  
granted based on documents that are confidentially provided to the  
designated expert.  I have been told that I should not assume that  
documents that are sent to me, as the designated expert, can be shared  
with the CAPWAP WG or others unless I confirm that it is okay with the  
requester.

> about doing and why they need anything from us.

I think that we need to be clear about the goal here...  I have not  
been asked to approve the documents that the requester, nor have I  
been asked to agree with everything that they say.  I am just trying  
to determine if there is sufficient justification for a WBID  
allocation.  Because this is the first WBID request we've received,  
and because the WBID space is quite limited, I am trying to determine  
what "sufficient justification" would include.

I attached two documents to the e-mail that you mentioned.  The other  
was a standards proposal for WAPI (a security extension for IEEE  
802.11).  The WAPI specification contains information elements that  
are not configured by the CAPWAP 802.11 binding.  So, if  ChinaBWIPS  
writes a CAPWAP binding to provision WAPI WTPs, it seems very likely  
that they will require a new WBID for that CAPWAP binding.  I don't  
see any evidence that the binding has been written yet, though.

> an RFC (but that sure would be nice, hint hint).

I don't believe that it is reasonable for me to demand that there be a  
publicly available document in order to approve a WBID allocation for  
two reasons:

(1) If the WG wanted requesters to provide a publicly available  
document in order to get a WBID, they would have selected  
"Specification Required" as the IANA allocation policy instead of  
"Expert Review".

and

(2) The WG did not require a publicly available document in order to  
assign a WBID for EPCglobal DCI.  I think it is very important that we  
be consistent in what we require for these allocations.

I do think it is consistent with the documented IANA allocation policy  
and our previous decisions to require that a requester submit a copy  
of their CAPWAP binding document to the designated expert for review  
in order to get a WBID allocated.  I'll wait a few more days to make  
sure that the WG does not object to that policy before I pass on that  
requirement to this requester.  I hope it is clear, though, that if I  
do decide that a documented CAPWAP binding is required for a WBID  
allocation, one will be required for all WBID allocations, not just  
this one.

Thanks,
Margaret

---

From: "David Harrington" <[email-masked]>
Date: Sun, 19 Apr 2009 09:37:20 -0400

Hi,

I have a particular interest in this discussion because I have agreed
to be the designated expert for another protocol. I am sure I will run
into similar questions as you are running into.

In section 3 of rfc5228, it talks about some possible reasons to deny
a code point. One of those possible reasons is:
      - the code point is needed for a protocol extension, but the
        extension is not consistent with the documented (or generally
        understood) architecture of the base protocol being extended,
        and would be harmful to the protocol if widely deployed.  It
is
        not the intent that "inconsistencies" refer to minor
differences
        "of a personal preference nature".  Instead, they refer to
        significant differences such as inconsistencies with the
        underlying security model, implying a change to the semantics
of
        an existing message type or operation, requiring unwarranted
        changes in deployed systems (compared with alternate ways of
        achieving a similar result), etc.

I am not saying that the current request fits this specific reason,
but it raises a question. If the documentation is not permanaent and
available, what would stop a requester from asking for a WBID and then
changing the specification, after getting the assignment, in a manner
that would be not consistent with the documented architecture. If you,
for whatever reason, become aware that the associated specification is
modified in  a manner that becomes inconsistent with the architecture,
can you un-assign a code-point?

Will you, as designated expert, keep a copy of the private
specification used to get the code point to make sure you have a copy
of the original specification in case the IESG has questions? 

Do you plan to develop "specific documented criteria for performing an
evaluation" to ensure consistency for future requests? If the WG has
not developed such criteria, can the designated expert develop such
criteria? Can the criteria developed by a designated expert require
permanent and available documentation even though the WG did not
specify this? Can the criteria developed by a designated expert
require permanent and available documentation because it becomes
immediately apparent to the expert that such documentation will be
important to prudently manage a scarcity of code points?

(I realize you and I could have a private discussion about the
responsibilities of a designated expert, but I think the WG might want
to understand how their designated expert will handle such expert
decisions in the future. This might make a good topic for WG chairs
training. If you want me to take my discussion off the CAPWAP list, I
can do that.)

dbh

> Sent: Saturday, April 18, 2009 8:20 PM
> To: Dan Harkins
> Cc: David Harrington; 'capwap'

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 19 Apr 2009 17:17:26 +0200

Actually I believe that this discussion is of broader interest, and it
applies not only to CAPWAP, but to other IANA allocations that require
Expert Review policy. 

The issue is whether the polcy as per RFC 5228 (not 5226) is Expert
Review or Specification Required. For Expert Review 'The required
documentation and review criteria for use by the Designated Expert
should be provided when defining the registry'. There is no requirement
for the requester to provide a publicly available specification but for
IANA and the designated expert. This is different from the Specification
Required policy which talks indeed about a 'a permanent and readily
available public specification' and 'also implies use of a Designated
Expert'.

In general I prefer that the definition of the criteria to be used by
the Designated Expert be done in detail in the IANA considerations
sections of the RFCs. This is the best way to ensure consistency in time
of the advice that experts provide to IANA as experts change in time. 

Dan

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Sunday, April 19, 2009 4:37 PM
To: 'Margaret Wasserman'; 'Dan Harkins'
Cc: 'capwap'
Subject: Re: [Capwap] Fwd: [IANA #230137] General Request
forAssignments(capwap-parameters)

Hi,

I have a particular interest in this discussion because I have agreed to
be the designated expert for another protocol. I am sure I will run into
similar questions as you are running into.

In section 3 of rfc5228, it talks about some possible reasons to deny a
code point. One of those possible reasons is:
      - the code point is needed for a protocol extension, but the
        extension is not consistent with the documented (or generally
        understood) architecture of the base protocol being extended,
        and would be harmful to the protocol if widely deployed.  It is
        not the intent that "inconsistencies" refer to minor differences
        "of a personal preference nature".  Instead, they refer to
        significant differences such as inconsistencies with the
        underlying security model, implying a change to the semantics of
        an existing message type or operation, requiring unwarranted
        changes in deployed systems (compared with alternate ways of
        achieving a similar result), etc.

I am not saying that the current request fits this specific reason, but
it raises a question. If the documentation is not permanaent and
available, what would stop a requester from asking for a WBID and then
changing the specification, after getting the assignment, in a manner
that would be not consistent with the documented architecture. If you,
for whatever reason, become aware that the associated specification is
modified in  a manner that becomes inconsistent with the architecture,
can you un-assign a code-point?

Will you, as designated expert, keep a copy of the private specification
used to get the code point to make sure you have a copy of the original
specification in case the IESG has questions? 

Do you plan to develop "specific documented criteria for performing an
evaluation" to ensure consistency for future requests? If the WG has not
developed such criteria, can the designated expert develop such
criteria? Can the criteria developed by a designated expert require
permanent and available documentation even though the WG did not specify
this? Can the criteria developed by a designated expert require
permanent and available documentation because it becomes immediately
apparent to the expert that such documentation will be important to
prudently manage a scarcity of code points?

dbh

> > publicly available document to find out just what it is they're 
> > talking about doing and why they need anything from us.
> 

> > exist and I think that document must be public, although not 
> > necessarily an RFC (but that sure would be nice, hint hint).
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 19 Apr 2009 12:02:14 -0400

> available public specification' and 'also implies use of a Designated

In this case, the policy stated in the CAPWAP RFC is "Expert Review",  
not "Specification Required".

> of the advice that experts provide to IANA as experts change in time.

I agree with you, but that was not done in this case.  The pertinent  
IANA consideration text is:

"15.8. CAPWAP Wireless Binding Identifiers
"The Wireless Binding Identifier (WBID) field in the CAPWAP Header  
(see Section 4.3) is used to identify the wireless technology  
associated with the packet. This specification allocates the values  
one (1) and three (3). Due to the limited address space available, a  
new WBID request requires Expert Review. IANA created the CAPWAP  
Wireless Binding Identifier registry, whose format is:
"CAPWAP Wireless Binding Identifier Type Value Reference"
This text does not include any criteria that the designated expert  
should use to make a decision about whether or not to allocate a  
WBID.  Given the lack of provided criteria, I am attempting to  
establish a fair set of criteria that can be used for reviewing these  
requests.  Ideally, the criteria should be something that the WG  
agrees is fair that is also consistent with our past practice.
Margaret

---

From: "David Harrington" <[email-masked]>
Date: Mon, 20 Apr 2009 07:44:58 -0400

Hi,

I reviewed the specifications provided and have some questions.

Have the documents provided been adopted by ISO? They appear to be ISO
documents, but the standard numbers and dates have not been filled in.

The documents discuss changes to the WAPI standard. The frequency used
for GB 15629.11 is different than the frequency specified by ISO/IEC
8802-11, so this could affect interoperability. The security options
propose to extend the WAPI standard, and this could affect
interoperability.

Given the scarcity of the WBID number space, my feeling is that we
should wait until these changes are approved by ISO before committing
a WBID. I think we want to avoid assigning WBIDs for
works-in-progress.

I have concerns that every country could choose to specify their own
national variations of the international standards, thus hurting
interoperability and increasing costs for implementers and deployers.
While this is obviously a much larger issue than CAPWAP, I do not
think we should encourage non-interoperable changes to international
standards by assigning CAPWAP WBIDs for such variations. Does GB
15629.11 conflict with the interoperability goals of the WG?

(Margaret, I do not envy you being faced with these considerations)

If scarcity is already becoming a factor to consider, should the WBID
be redesigned now - before there are lots of
implementations/deployments - using a larger size to better meet the
potential need?

dbh

> Sent: Friday, April 17, 2009 5:00 PM
> To: capwap
> Subject: [Capwap] Fwd: [IANA #230137] General Request for 
> permission

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Apr 2009 13:58:47 +0200

See in-line. 

Dan

> Sent: Sunday, April 19, 2009 7:02 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Dan Harkins; capwap
> > should be provided when defining the registry'. There is no 
> > requirement for the requester to provide a publicly available 
> > specification but for IANA and the designated expert. This is 
> > different from the Specification Required policy which talks indeed 
> > about a 'a permanent and readily available public 
> specification' and 
> > 'also implies use of a Designated Expert'.
> 
> In this case, the policy stated in the CAPWAP RFC is "Expert 
> Review", not "Specification Required".

This was my point. I apologize if this was niot clear enough.

> > sections of the RFCs. This is the best way to ensure consistency in 
> > time of the advice that experts provide to IANA as experts 
> change in 
> > time.
> 
> I agree with you, but that was not done in this case.  The 
> pertinent IANA consideration text is:
> 
> "15.8. CAPWAP Wireless Binding Identifiers "The Wireless 
> Binding Identifier (WBID) field in the CAPWAP Header (see 
> Section 4.3) is used to identify the wireless technology 
> associated with the packet. This specification allocates the 
> values one (1) and three (3). Due to the limited address 
> space available, a new WBID request requires Expert Review. 
> IANA created the CAPWAP Wireless Binding Identifier registry, 
> whose format is:
> This text does not include any criteria that the designated 
> expert should use to make a decision about whether or not to 
> allocate a WBID.  Given the lack of provided criteria, I am 
> attempting to establish a fair set of criteria that can be 
> used for reviewing these requests.  Ideally, the criteria 
> should be something that the WG agrees is fair that is also 
> consistent with our past practice.

I believe that you are doing the right thing. After the WG reached some
consensus on the criteria we can keep this wisdom on the WG Web page and
on the OPS-Area Web page, and add it in the future to the IANA
considerations section of the protocol document if and when this will be
revised.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 20 Apr 2009 10:09:11 -0400

Hi David,

Thanks for your comments so far.  This discussion continues to be very  
helpful for me in trying to figure out what to do, both in this  
instance and for WBID allocations going forward.

On Apr 20, 2009, at 7:44 AM, David Harrington wrote:
> 8802-11, so this could affect interoperability.

Having worked with radio standards in another realm (RFID readers), I  
am aware of several radio standards that are defined to operate at  
different frequencies in different geographic domains.  This happens  
because frequency allocations are handled on a per-government level,  
and it isn't typically possible to choose a frequency that is  
available in all parts of the world.  So, while I can't say for sure,  
it is possible that 802.11 needs to operate on a different frequency  
in China because the standard frequencies used in other parts of the  
world are not available in China.  Typically this type of localization  
is specified at a very low level, though, and would not affect things  
at the CAPWAP level.

> The security options

These changes, on the other hand, are significant software-level  
changes to IEEE 802.11.  I do not believe that the ChinaBWIPS standard  
is interoperable with IEEE 802.11 devices that do not implement WAPI.   
However, it appears that there is some discussion in ISO of producing  
an interoperable spec that includes WAPI as a security option.

> a WBID. I think we want to avoid assigning WBIDs for

I agree, sort of.  First, I think we need to wait until a CAPWAP  
binding is approved, not just the WAPI standard.  However, I am not  
sure that it needs to be approved _by ISO_.  While I don't have enough  
information about ChinaBWIPS to understand its standards process, if  
ChinaBWIPS is a standards organization with official approved  
standards, it might be reasonable to assign a WBID when the CAPWAP  
WAPI binding is approved by ChinaBWIPS.  Right?

> implementations/deployments - using a larger size to better meet the

I am not sure how we would do that, or if it is justified at this  
point...

The WBID is 5 bits long, so it has 32 potential values.  We have 2  
assigned so far (for IEEE 802.11 and EPCglobal DCI).  We now have a  
request for a third.  So, I don't think that scarcity is any more of a  
factor than when the RFCs were approved last year.

Margaret

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 20 Apr 2009 10:25:36 -0600

[Some history:
In the case of candidate-draft evaluation (where CAPWAP appeared to
break new ground in terms of candidate protocols all being brand new and
introduced as individual submissions - that never before existed in
IETF) unlike many other candidate-protocol evaluation exercises in other
WGs which by an large pitted existing protocols against each other
(PANA, MIDCOM WGs being couple of examples I can relate to) though even
in those cases a new candidate protocol may have been just one
candidate.

In that sense - it was somewhat unique (though quite similar) exercise
in terms of candidate protocol evaluation and selection for CAPWAP.]

Current:
The situation here seems analogous (that almost all technologies that
are likely to request WBID allocation are likely to be from SDOs or
organizations that have specifications outside IETF and hence, being
able to perform allocation by expert review will require access to such
specs; not just a matter of disbursal of vendor-specific IDs.).

I would be interested to know if there are precedences to this
situation.

If there exist precedences - we can use those to see how those experts
dealt with it.

If not, we in CAPWAP seem to have no precedence in this situation as
well.

Other than that - the allocated WBID space seems reasonable.

-mani
-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Sunday, April 19, 2009 9:02 AM
To: Romascanu, Dan (Dan)
Cc: capwap
Subject: Re: [Capwap] Fwd: [IANA #230137] General
RequestforAssignments(capwap-parameters)

On Apr 19, 2009, at 11:17 AM, Romascanu, Dan (Dan) wrote:
> requirement

> time

---

From: "David Harrington" <[email-masked]>
Date: Mon, 20 Apr 2009 12:31:58 -0400

Hi,

comments inline.

> WAPI binding is approved by ChinaBWIPS.  Right?

One of the documents is apparently an ISO work-in-progress, and then 
ChinaBWIPS extends that with other frequency and security features. I
think the ChinaBWIPS extensions are proposed as an ISO
work-in-progress. 

We should at least wait until the ISO portions are approved before
accepting something that builds atop the ISO work. It would be good to
know what level of maturity the ChinaBWIPS has as an SDO; I don't have
that info.

dbh

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Apr 2009 18:33:30 +0200

Mani,

This analogy is not clear to me. 

Also, the candidate drafts evaluation method was not used by CAPWAP
first in the IETF. IPv6 (IPng it was named at that point in time) used
it  more than a decade ago, then AAA, then IPFIX, and these are only
examples that I remember, there may have been more. 

Here we do not deal with a pick-just-one-from-several choice. We have a
limited space, and we need to be picky in selecting the protocols that
bind with CAPWAP. We need criteria. We have similar situations with UDP
system (kernel) ports for example. 

Dan

> From: Mani, Mahalingam (Mani) 
> Sent: Monday, April 20, 2009 7:26 PM
> To: Margaret Wasserman; Romascanu, Dan (Dan)
> Cc: capwap
> Subject: RE: [Capwap] Fwd: [IANA #230137] General 
> In the case of candidate-draft evaluation (where CAPWAP 
> appeared to break new ground in terms of candidate protocols 
> all being brand new and introduced as individual submissions 
> - that never before existed in IETF) unlike many other 
> candidate-protocol evaluation exercises in other WGs which by 
> an large pitted existing protocols against each other (PANA, 
> MIDCOM WGs being couple of examples I can relate to) though 
> even in those cases a new candidate protocol may have been 
> just one candidate.
> 
> In that sense - it was somewhat unique (though quite similar) 
> exercise in terms of candidate protocol evaluation and 
> selection for CAPWAP.]
> 
> Current:
> The situation here seems analogous (that almost all 
> technologies that are likely to request WBID allocation are 
> likely to be from SDOs or organizations that have 
> specifications outside IETF and hence, being able to perform 
> allocation by expert review will require access to such 
> I would be interested to know if there are precedences to 
> this situation.
> 
> If there exist precedences - we can use those to see how 
> those experts dealt with it.
> 
> If not, we in CAPWAP seem to have no precedence in this 
> situation as well.
> 
> > for the requester to provide a publicly available 
> specification but  
> > for

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 20 Apr 2009 10:47:06 -0600

Pointing out the potential for more procedural considerations arising,
given the CAPWAP protocols strongly overlap across IETF and (multiple
other consuming SDO) media bindings.

And on the concern about multiple-radio frequency usages specifically;
it should be noted that 802.11 bindings themselves address support for
it (such as 802.11y, 802.11z); and hence should be addressable within
802.11 bindings (or revisions to the binding protocol thereof). I hope
that is true of any extensions ISO introduces (hopefully raitified by
IEEE802.11).

WAPI is a special case. I am wondering if it is not possible for them to
address whatever binding-specs they may come up with for CAPWAP as an
extension to .11 bindings rather than requiring a separate WBID.

It would be useful to request WAPI to show why a separate WBID may be
needed.

-mani
-----Original Message-----
From: Romascanu, Dan (Dan) 
Sent: Monday, April 20, 2009 9:34 AM
To: Mani, Mahalingam (Mani); 'Margaret Wasserman'
Cc: 'capwap'
Subject: RE: [Capwap] Fwd: [IANA #230137] General

Mani,

Dan