Re: Issue 5 : Avi review of I-D Action:draft-ietf-radext-design-13.txt

[Avi Lior <avi@bridgewatersystems.com>]

>> Issue 5:
>> 
>> Section 2.2
>> 
>> The following text does not make sense:
>> 
>> " Vendors therefore SHOULD NOT use multiple
>>   formats for VSAs that are associated with a particular Vendor Id.  A
>>   vendor wishing to use multiple VSA formats SHOULD request one Vendor
>>   Id for each VSA format that they will use."
>> 
>> If a vendor defines two VSAs one of a basic type and another of a non-basic type they should not require a new vendor id.  Please delete this recommendation.
> 
>  It is intended to refer to the "TLV encoding scheme", i.e. RFC 2865
> Section 5.26 encoding of {8-bit type, 8-bit length, data}, versus (e.g.)
> the USR encoding of {32-bit type, data}.
> 
>  I suggest changing the text to clarify this, by saying:
> 
> --
> All VSA encodings that do not follow the [RFC2865] Section 5.26 scheme
> are NOT RECOMMENDED.  Although [RFC2865] does not mandate
> it, implementations commonly assume that the Vendor Id can be used as
> a key to determine the on-the-wire encoding of a VSA.  Vendors
> therefore SHOULD NOT use multiple encodings for VSAs that are
> associated with a particular Vendor Id.  A vendor wishing to use
> multiple VSA encodings SHOULD request one Vendor Id for each VSA
> encoding that they will use.
> ---
> 
>  This uses terminology which is in line with RFC 2865.  I will also
> review the document, and ensure that discussion about TLVs uses
> "encoding", rather than "format", for consistency and clarity.

Okay.  Perhaps giving an example of what is meant by encoding otherwise this may be confused with formatting.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>