Subject: Re: [Capwap] Issue 166: Various IANA Issues

From: <[email-masked]>
Date: Fri, 8 Aug 2008 01:32:23 +0300

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 12:27:55 -0700

> This probably should be "CAPWAP Message Element Type"?

Correct.

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

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

Ditto.

> > Standards Action.  IANA will create the AC Information Type
registry, 
> > whose format is:
(IANA manages registry for Enterprise Number 0; other Enterprise Numbers
are not controlled via IANA?)

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

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 12:42:38 +0300

Pat Calhoun wrote:

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

This didn't really answer my question.

Which of the following is meant by this section and Section 4.6.1?

- The AC Descriptor message element MUST always contain exactly one
  Sub-Element with "AC Information Vendor Identifier"=0/"AC Information
  Type"=4, exactly one Sub-Element with Vendor=0/Type=5,
  MAY contain other Sub-Elements.

  (In this case, saying that the contents are "vendor specific"
  is a bit strange, since the message doesn't tell who the
  vendor is. Perhaps "printable UTF-8 string intended for the 
  administator" or something was intended?)

- The AC Descriptor message element MUST always contain exactly
  one Sub-Element with "AC Information Vendor Identifier"=SOMEV/
  "AC Information Type"=4, exactly one Sub-Element with Vendor=SOMEV/
  Type=5, and MAY contain other Sub-Elements.

(BTW -- this same question seems to apply to WTP Board Data message
element as well.)

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 15:34:43 -0700

> > allows the vendor (or SDO) to include their Enterprise Code, and
they 
> > can manage their own message element namespace.
> 
element as well.)

My apologies - I completely misunderstood the original comment. I see
now what you are asking. I have modified the text to:

<modified text>

   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.  This field, combined with the AC
   Information Vendor ID, allows vendors to use a private namespace.
   This specification defines the AC Information Type namespace when the
   AC Information Vendor ID is set to zero (0), for which 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 Expert Review.  IANA will create the AC
   Information Type registry, whose format is:

15.20.  WTP Board Data Type

   The Board Data Type field in the WTP Board Data message element (see
   Section 4.6.39) is used to represent information about the WTP
   hardware.  The namespace is 16 bits (0-65535).  This field, combined
   with the Vendor ID field, allows vendors to use a private namespace.
   This specification defines the WTP Board Data Type namespace when the
   Vendor ID field is set to zero (0), for which the values zero (0)
   through four (4) are allocated in this specification, and can be
   found in Section 4.6.39.  This namespace is managed by IANA and
   assignments require a Expert Review.  IANA will create the WTP Board
   Data Type registry, whose format is:

           WTP Board Data Type              Type Value       Reference
</modified text>

Makes sense?

PatC

---

From: <[email-masked]>
Date: Wed, 20 Aug 2008 15:25:03 +0300

>            AC Information Type              Type Value       Reference

This makes sense. Couple of words should be added to Section 4.6.1 as 
well, explicitly saying that 4/5 are with vendor ID 0.

>            WTP Board Data Type              Type Value       Reference

Again, saying in 4.6.40 that the values 0..4 are with Vendor ID 0
would clarify the situation a lot.

However, there's one difference here: in WTP Board Data, the Vendor
Identifier is listed only once (it's not repeated for every 
WTP Board Data Type field). So if an implementation would send
both (Vendor ID=0, Type=1) and (Vendor ID=123, Type=456), would it 
send two WTP Board Data message elements?

(In this case, Section 4.6.40 should say more than one can be sent,
and Sections 5.1, 5.3, and 6.1 should say "WTP Board Data message
element(s)" instead of just "WTP Board Data").

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 20 Aug 2008 06:17:09 -0700

> This makes sense. Couple of words should be added to Section 4.6.1 as
well, explicitly saying that 4/5 are with vendor > ID 0.

Yes, here is the new text:

<modified text>
4.6.1.  AC Descriptor
[...]
      AC Information Type:   Vendor specific encoding of AC information.
         The following enumerated values are supported.  Both the
         Hardware and Software Version sub-elements MUST be included in
         the AC Descriptor message element.  The values listed below are
         used in conjunction with the AC Information Vendor Identifier
         field, whose value MUST be set to zero (0).

         4 - Hardware Version:   The AC's hardware version number.

         5 - Software Version:   The AC's Software (firmware) version
            number.
</modified text>

Yes, I have made the necessary change. The text now reads:

<modified text>
4.6.40.  WTP Descriptor
[...]
      Descriptor Type:   The Descriptor Type field identifies the data
         being encoded.  The CAPWAP protocol defines the following
         values, and each of these types identify whether their presence
         is mandatory or optional.  The values listed below are used in
         conjunction with the Descriptor Vendor Identifier field, whose
         value MUST be set to zero (0).

         0 - Hardware Version:   The WTP hardware version number MUST be
            present.

         1 - Active Software Version:   The WTP running software version
            number MUST be present.

         2 - Boot Version:   The WTP boot loader version number MUST be
            present.

         3 - Other Software Version:   The WTP non-running software
            (firmware) version number MAY be present.  This type is used
            to communicate alternate software versions that are
            available on the WTP's non-volatile storage.
15.21.  WTP Descriptor Type

   The Descriptor Type field in the WTP Descriptor message element (see
   Section 4.6.40) is used to represent information about the WTP
   software.  The namespace is 16 bits (0-65535).  This field, combined
   with the Descriptor Vendor ID, allows vendors to use a private
   namespace.  This specification defines the WTP Descriptor Type
   namespace when the Descriptor Vendor ID is set to zero (0), for which
   the values zero (0) through three (3) are allocated in this
   specification, and can be found in Section 4.6.40.  This namespace is
   managed by IANA and assignments require a Expert Review.  IANA will
   create the WTP Board Data Type registry, whose format is:
</modified text>

> However, there's one difference here: in WTP Board Data, the Vendor
Identifier is listed only once (it's not repeated 
> for every WTP Board Data Type field). So if an implementation would
send both (Vendor ID=0, Type=1) and (Vendor ID=123, 
> Type=456), would it send two WTP Board Data message elements?
> 
and Sections 5.1, 5.3, and 6.1 should say "WTP 
> Board Data message element(s)" instead of just "WTP Board Data").

I need to apologize profusely. I *just* realized the original intent,
and the reason why the Vendor ID was called out separately. The WTP
Board Data Types are not used in conjunction with the Vendor ID. The
Vendor ID is used to identify the HW manufacturer, while the data types
are used consistently across all implementations. This requires going
back to the original IANA considerations text, but also a small tweak to
the WTP Board Data Vendor ID field descriptor:

<modified text>
4.6.39.  WTP Board Data
[...]
   Vendor Identifier:   A 32-bit value containing the IANA assigned "SMI
      Network Management Private Enterprise Codes", identifying the WTP
      hardware manufacturer.

   The Board Data Type field in the WTP Board Data message element (see
   Section 4.6.39) is used to represent information about the WTP
   hardware.  The namespace is 16 bits (0-65535).  The WTP Board Data
   Type values zero (0) through four (4) are allocated in this
   specification, and can be found in Section 4.6.39.  This namespace is
   managed by IANA and assignments require a Expert Review.  IANA will
   create the WTP Board Data Type registry, whose format is:
</modified text>

PatC