Capwap Mailing List: Re: Issue 166: Various IANA Issues

[Pasi.Eronen (Pasi.Eronen]

Pat Calhoun wrote:

> 15.6.  CAPWAP Control Message Type
> 
>    The Type field in the CAPWAP Control Message header (see Section
>    4.6) is used to identify the data being transported.

Section 4.6 doesn't seem to have CAPWAP Control Message header; and
IANA considerations for the CAPWAP Message Type field was already
covered in Section 15.3.

This probably should be "CAPWAP Message Element Type"?

>    The namespace is 32 bits (0-4294967295), where the value of zero
>    (0) is reserved and must not be assigned.

If this is the message element type field, it's only 16 bits.

> The values one (1) through 52 are allocated in this specification,
> and can be found in Section 4.5.1.1.  This namespace is managed by
> IANA and assignments require a Standards Action.

If the intent is to allow bindings documented outside standards
track RFCs (e.g. EPCGlobal), Standards Action probably isn't
the right policy here.

> 15.7.  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.  Due to the limited address space
>    available, a new WBID request requires Standards Action.

Again, Standards Action requires all wireless bindings to be
standards track RFCs, which isn't compatible with EPCGlobal.

<snip>
> 15.10.  AC Information Type
> 
>    The Information Type field in the AC Descriptor message element
> (see Section 4.6.1) is used to represent information about the AC.
> The namespace is 16 bits (0-65535), where the value of zero (0) is
> reserved and must not be assigned.  The values four (4) and five (5)
> are allocated in this specification, and can be found in Section
> 4.6.1.  This namespace is managed by IANA and assignments require a
> Standards Action.  IANA will create the AC Information Type
> registry, whose format is:
> 
>            AC Information Type              Type Value       Reference

Is the intent to have something similar as for CAPWAP Message Types
(IANA manages registry for Enterprise Number 0; other Enterprise
Numbers are not controlled via IANA?)

Or is the AC Information Type independent of the AC Information Vendor
Identifier? (in that case, I'd expect vendors would want to include
vendor-specific information, and Standards Action perhaps isn't the
optimal policy.)

Best regards,
Pasi