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

[Pat Calhoun (pacalhou) (pcalhoun]

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

Correct.

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

Oh right.

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

I'm hoping we can get this discussion going on the thread for issue 158.
So I consider this part of another issue being tracked.

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

Ditto.

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

Currently, any vendor (or SDO) can define their own message elements
through the vendor specific message element. This message element allows
the vendor (or SDO) to include their Enterprise Code, and they can
manage their own message element namespace.


PatC