Re: [radext] draft-ietf-radext-ip-port-radius-ext

[Paul Aitken <[e-mail]>]

Authors I've been waiting 2 months, yet no reply?

P.


On 08/11/16 17:24, Paul Aitken wrote:
> Dear Authors, some questions came to mind while reviewing section 3.2 
> of your draft:
>
>
> Q1: Why define a new TLV-Type 1..11 simply to encode an IPFIX 
> Information Element?
>
> Since there's a 1:1 mapping between the TLV-Type and IPFIX Element ID, 
> the scheme you propose would be more extensible if the IPFIX Element 
> ID was used instead of the TLV-Type since it would require one less 
> registry. True, one additional byte would be required in the encoding. 
> However, the advantage is that in future anyone could encode a new TLV 
> by using the relevant IPFIX ID, without having to also define a new 
> TLV-Type for it.
>
>
> Q2: In each TLV, the Length field is redundant since it can always be 
> determined from the TLV-Type: it's always 6, with special cases for 
> TLV-Types 5 (Length is 18) and 11 (Length could be determined by a 
> NULL terminator on the string). This suggests that the length is not 
> required in the protocol, so why not remove it entirely?
>
>
> However, many of the descriptions say "contains the data ... right 
> justified, and the unused bits in this field MUST be set to zero. "
>
> Q3: Wouldn't it be better to limit the length of the field to an 
> appropriate size for the data, and encode that size in the Length?
>
>
> For example, the transportType in 3.2.1 is just one octet long 
> (unsigned8) - so there's no reason to encode it in 32 bits. Why not 
> encode it like so:
>
>     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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       TLV-Type = TBAx1        |    Length     | transportType |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> The natEvent in 3.2.8 is also an unsigned8, so it would be encoded 
> similarly - except that the TLV-Type would be 230, which is the IE ID 
> of the IPFIX natEvent.
>
>
> The natTransportLimit in 3.2.2 is an unsigned16 - so there's no need 
> to encode it in 32 bits. Why not encode it like so:
>
>     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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       TLV-Type = TBAx2        |    Length |natTransportLimit ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ...              |
>    +-+-+-+-+-+-+-+-+
>
> 3.2.9 and 3.2.10 would be similar. The encoding of 3.2.3, 3.2.4, and 
> 3.2.5 would all be as shown in the draft, except that the TLV-type 
> would be two octets long and contain the IPFIX IE ID. The 
> sourceTransportPort in 3.2.6 is an unsigned16 - so there's no need to 
> encode it in 32 bits. Why not encode it like so:
>
>     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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | TLV-Type = sourceTransportPort|    Length     | 
> sourceTransportPort ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ...              |
>    +-+-+-+-+-+-+-+-+
>
> The encoding of 3.2.7 would be similar.