[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

A. Comments & question:

1. Section 9.

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. 

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

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? Then how to delimit the next attribute?

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. Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1?


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.

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.

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

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

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

6. Section 3.5 (The same case happened in Section 3.6)

'Length

      >= 4'

Supposed the above should be ' Length >= 5'.


Best Regards,
Leaf


-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
Sent: Wednesday, October 26, 2011 3:41 AM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  I've submitted -02 which addresses the concerns below.  All SHOULD /
MAY / MUST / etc. has been removed from the IANA considerations section.

  It repeated text elsewhere in the document, so there is no loss.

  Alan DeKok.


Bernard Aboba wrote:
> Here are my comments:
> 
> The IANA Considerations section needs to be revised.  It is recommended
> that the IANA considerations section be rewritten according to the
> recommendations of RFC 5226, and that this be cited as a normative
> reference.
> 
> Some issues:
> 
> 1. The IANA considerations section does not specify how attributes are
> to be allocated from the extended space, using policy terms defined in
> RFC 5226.
> 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections
> 9.1 and 9.5. 
> 
> The IANA is not a policy making body and therefore is not capable of handling MAY, SHOULD or SHOULD NOT directives. 
> 
> 
>       9.1. Attribute Allocations
> 
> 
> 
>    IANA is requested to move the "Unassigned" numbers in the range
>    144-191 from "Unassigned" to "Deprecated".  This status means that
>    allocations SHOULD NOT be made from this space.  Instead, allocations
>    SHOULD be taken from the Extended Type space, starting with lower
>    numbered attributes.  However, allocation from the "Deprecated" space
>    MAY 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.
> 
> 
> [BA] 
> 
> It seems that the goal is to still allow allocation from the Unassigned range, while preferring allocation from the Extended Type space.
> 
> A more implementable way of accomplishing this might be to say that unless specifically requested to allocate from the Standard RADIUS space,
> IANA should make allocations from the extended type space. 
> 
> 
>       9.5. Extending the RADIUS Attribute Type Space
> 
> 
> 
>    The extended RADIUS Attribute Type space may eventually approach
>    exhaustion.  When necessary, the space SHOULD be extended by
>    publication of a specification which allocates new attributes of
>    either the "Extended Type", or the "Extended Type with flags" format.
> 
> [BA] This material relates to IETF not IANA processing, and so is not
> appropriate for an IANA considerations section.  The IANA cannot handle
> the policy decisions that are implied here. 
> 
> 
>    The specification SHOULD request allocation of a specific number from
>    the "Reserved" RADIUS Attribute type space, such as 247.  The
>    attribute(s) SHOULD be given a name which follows the naming
>    convention used in this document.  The Extended-Type value of 26 MUST
>    be allocated to a "Vendor Specific" attribute, of data type "esv".
>    The Extended-Type values of 241 through 255 MUST be marked as
>    "Reserved".
> 
>    IANA SHOULD allocate the attribute(s) as requested.  For example, if
>    allocation of attribute 247 is requested, the following definitions
>    MUST be made in the specification, and allocated by IANA.
> 
>    * 247.1          Extended-Attribute-7
>    * 247.{1-25}     Unassigned
>    * 247.26         Extended-Vendor-Specific-7
>    * 247.{27-240}   Unassigned
>    * 247.{241-255}  Reserved
> 
>    We note,however, that the above list is an example, and we do not
>    request or perform allocation of attribute 247 in this document.
> 
> 
> 
> 
> 
> 
> 


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

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