Re: [Rfid] SLRRP Vendor Extensions

[Margaret Wasserman <[e-mail]>]

Hi Peter,

Before deciding to add a vendor extensions mechanism to SLRRP, it 
might be useful to read the IESG document regarding vendor extensions:

http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

This document is not a mandate against all forms of vendor extension, 
but it does make a good case that the use of vendor extensions should 
be extremely limited, as uncontrolled vendor extension mechanisms 
(such as the one you have described) tend to lead to incompatibility 
between different devices that can correctly claim to implement the 
same protocol.

If the group decides that vendor extensions are necessary, then it 
might be preferable to simply set aside a portion of the message type 
and parameter type values for IANA assignment with an appropriate 
level of documentation and/or review (as described in RFC 2434).

Margaret

At 6:43 PM -0400 7/20/05, Peter Spreadborough wrote:
>To facilitate the support of vendor specific extensions, prior to formal
>inclusion into the protocol, the following solution is proposed:
>
>1. The SLRRP message header will be extended to include a thirty two bit
>vendor ID field:
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |x|x|x|x|x| Ver |  Message Type |       Message Length          |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |       Message Seq Num         |x x x x x x x x x x x x x x x x|
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                           Vendor ID                           |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  :                                                               :
>  :                        Message Value                          :
>  :                                                               :
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>2. For SLRRP parameters a bit from the "user" bits will be assigned as
>the Vendor or V bit.
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | A |V|User |  Parameter Type   |       Parameter Length        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  :                                                               :
>  :                       Parameter Value                         :
>  :                                                               :
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>3. A block of unused message types will be reserved for vendor
>extensions.
>4. A block of parameter types will be reserved for vendor extensions.
>
>SLRRP implementations may choose to ignore:
>         - Any message types that fall in to the vendor extension range.
>         - Any parameter types that fall into the vendor extension range.
>         - Any parameters that have the V bit set.
>
>If the V bit is set in a parameter header then the vendor ID used in the
>encapsulating message will apply. The parameter may then be accepted or
>ignored based on the vendor ID. This applies to both defined message
>types and extended message types.
>
>
>
>
>_______________________________________________
>Rfid mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rfid