Re: WGLC for draft-ietf-radext-radius-extensions-01

[Alan DeKok <aland@deployingradius.com>]

Leaf yeh wrote:
> I am Not sure that the following words are necessary in section 9,
> 
> ' However, allocation from the "Deprecated" space
>    can still be performed by publication of an IETF specification, where
>    that specification requests allocation from the "Deprecated" space,
>    and gives reasons why use of the Extended Type space is impossible.'
> 
> I can't see any reason why use of the Extended Type space is impossible, when the new allocation intends to use the code from 144 to 191 in the above "Deprecated" space. 

  Neither can I.  But it gives people the ability to use the range
144..191 if they *really* need it.

> I regard the space of 144-191 sounds the equal-right space as the extended space defined in the draft. Am I right?

  No.  The above text says its "Deprecated".  It SHOULD NOT be used.

  It's deprecated because the extended format does more, and has more
attributes available.  We wish to reserve the 144..191 space for future
extensions, or for specifications which can't use the extended space.

  The alternative is to allow allocation from 144..191.  What will
happen is that no one will use the extended space, and the 144..11 space
will quickly be completely allocated.

> 2. Section 2.1 - Length
> 
> ' If a client or server receives an Extended
>       Attribute with a Length of 2 or 3, then that Attribute MUST be
>       deemed to be an "invalid attribute", it SHOULD be silently
>       discarded. If it is not discarded, it MUST NOT be handled in the
>       same manner as a well-formed attribute.
> 
>       Note that an "invalid attribute" does not cause the entire packet
>       to be discarded, or to be treated as a negative acknowledgement.
>       Instead, only the "invalid attribute" is discarded.'
> 
> How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded?

  I have no idea what that means.

> Then how to delimit the next attribute?

  I don't know what that means, either.

> 3. Section 2.3 - TLV-Length
> 
> ' If a client or server
>       receives a TLV with an invalid TLV-Length, then the attribute
>       which encapsulates that TLV MUST be deemed to be an "invalid
>       attribute", it SHOULD be silently discarded. '
> 
> TLV date type sounds a sub-attribute here.

  Yes... it's defined that way in the document.

> Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1?

  We discard the TLV that is invalid.  We don't discard the attribute
which encapsulates it.

> B. Editorials:
> 
> 1. Section 2.2
> 
> ' When the More
>       flag is set (1), ...
>       255; it MUST NOT have a length Field of of value 4; ...'
> 
> Supposed one 'of' should be here.

  Fixed, thanks.

> 2. Section 2.3 (The same case happened in section 2.4.)
> 
> ' We define a new data type in RADIUS, called "tlv".  The "tlv" data
>    type is an encapsulation layer which which permits the "Value" field
>    of an Attribute to contain new sub-Attributes. '
> 
> Supposed one 'which' should be here.

  Fixed, thanks.

> 3. Section 2.3 - TLV-Type
> 
> 'As with Extended-Type above, the TLV-Type is meaningful only
>       within a context defined by "Type" fields of the encapsulating
>       Attributes.'
> 
> Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'.

  It says "Type field*s*".

> 4. Section 2.5
> 
> 'The expected use
>    og this data type is within Accounting-Request packets, but this data
>    type SHOULD be used in any packet where 32-bit integers are expected
>    to be insufficient.'
> 
> Supposed the above 'og' should be 'of'.

  Fixed, thanks.

> 5. Section 3.1 -String (The same case happened in Section 3.2, 3.3, 3.4, 3.5, 3.6)
> 
> 'String
> 
>       The String field is one or more octets...'
> 
> Supposed the above should be 'Value 
> The Value field is one or more octets...'

  Fixed, thanks.

> 6. Section 3.5 (The same case happened in Section 3.6)
> 
> 'Length
> 
>       >= 4'
> 
> Supposed the above should be ' Length >= 5'.

  Fixed, thanks.

  Alan DeKok.

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