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

From: Alan DeKok <[email-masked]>
Date: Tue, 25 Oct 2011 21:41:23 +0200

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Leaf yeh <[email-masked]>
Date: Fri, 28 Oct 2011 11:43:52 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, October 26, 2011 3:41 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 28 Oct 2011 14:40:09 +0200

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

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

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

> Supposed one 'of' should be here.

  Fixed, thanks.

> Supposed one 'which' should be here.

  Fixed, thanks.

> Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'.

  It says "Type field*s*".

> Supposed the above 'og' should be 'of'.

  Fixed, thanks.

> The Value field is one or more octets...'

  Fixed, thanks.

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

  Fixed, thanks.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Sat, 29 Oct 2011 03:37:04 +0000

Alan DeKok - We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. 

Can we suppose the following codes are reserved for the future extension?

192-223 Experimental Use [RFC3575] 
224-240 Implementation Specific [RFC3575] 
247-255 Reserved [RFC3575] 

Note: 241-246 Extended type [Defined in draft-ietf-radext-radius-extensions]

I meant the space of 144-191 doesn't really deserve to be ' Deprecated'.

Alan DeKok - 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.

Understand, but it looks harmless even we expect that happen.

Leaf - > 2. Section 2.1 - Length
>       'If a client or server receives an Extended
Alan DeKok - I have no idea what that means.

I meant ' 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.', then how to do discard this attribute? Does it mean the octets, per the Length of the attribute, eg. 2 or 3, from the 1st octet of 'Type', will be discarded? 

Can we trust all the attributes followed this 'invalid' attribute' in the Radius packet, if the delimitation of these attributes turns to be some kind of suspicious or difficult?

Leaf - > Then how to delimit the next attribute?
Alan DeKok - I don't know what that means, either.

I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'?

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

There exists the same issue described above.

-------------------------------------
One more Editorial 

7.  Section 2.4

'   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Vendor-Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type   |  String ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...

String

      The String field is one or more octets. ...'

Would you mind to change the above 'String's to be 'Value's? 

That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6.

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Friday, October 28, 2011 8:40 PM
To: Leaf yeh
Cc: Bernard Aboba; [email-masked]; [email-masked]; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  Fixed, thanks.

  Fixed, thanks.

  It says "Type field*s*".

  Fixed, thanks.

  Fixed, thanks.

  Fixed, thanks.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 29 Oct 2011 08:49:48 +0200

> Can we suppose the following codes are reserved for the future extension?

  Yes, they are.

> I meant the space of 144-191 doesn't really deserve to be ' Deprecated'.

  I explained my reasons.  Saying they don't "deserver" to be deprecated
isn't a useful response.

> Understand, but it looks harmless even we expect that happen.

  By the same argument, there's no harm in requiring people to use the
extended space.

> I meant ' 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.', then how…

  Your question assumes that the input packet is edited to remove the
attribute.  This is not true.  When the text says "discard the
attribute", it means "ignore it".

> I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'?

  You haven't read the draft, then.  The "invalid attribute" is
correctly formed, so that the entire packet can be correctly decoded.
The text says this explicitly.

  So your question above is based on an incorrect assumption: the
"invalid attribute" means "malformed RADIUS packet".

> There exists the same issue described above.

  The same misunderstanding applies here, too.

> One more Editorial 
..
> That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6.

  Already done.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Sat, 29 Oct 2011 10:45:21 +0000

Alan DeKok - Saying they don't "deserver" to be deprecated isn't a useful response.

It was just my argument, sorry for that. Let's wait for the decision made by the WG or IESG.

Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it".

Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here:

1. ignore the whole packet; then request the 2nd time; or
2. ignore the attributes followed this invalid attribute; or 
3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; 

Does the 3rd one means 'silently discard' in your text?

Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly.

Could you show me the explicit text in your draft mentioned above?

Leaf - >3. Section 2.3 - TLV-Length

But the above text sounds to discard the whole encapsulating attribute.

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Saturday, October 29, 2011 2:50 PM
To: Leaf yeh
Cc: Bernard Aboba; [email-masked]; [email-masked]; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  Yes, they are.

..

  Already done.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 29 Oct 2011 13:26:39 +0200

> Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here:

  No.  The document describes the correct behavior.  There are no
implementation choices.

> Does the 3rd one means 'silently discard' in your text?

  Possibly.  I still don't understand why the text is unclear.  You're
focused on parsing the RADIUS packet.  The text about "invalid
attribute" is talking about the *attribute*, not the *packet*.

> Could you show me the explicit text in your draft mentioned above?

  The text which defines the "invalid attribute" term at the top of the
document.  It says that the Length field is valid, but the *Value* field
is wrong.  Since the Length field is valid, the packet can be parsed
correctly.  So the entire packet is correctly formed.

  Again, the term "invalid attribute" refers to the *Value* field of an
attribute.  It has nothing to do with parsing the packet.

  I really don't know how to make this any clearer.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 01 Nov 2011 06:13:04 +0000

One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here.

'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions '

But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly.

How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference.

----------------------------------------------------------
One more argument on the text in section 9.1

'New allocations are
normally taken from the Extended Type space, starting with lower
numbered attributes.'

But the attributes, including

241.26  Extended-Vendor-Specific-1
242.26  Extended-Vendor-Specific-2
243.26  Extended-Vendor-Specific-3
244.26  Extended-Vendor-Specific-4
245.26  Extended-Vendor-Specific-5
246.26  Extended-Vendor-Specific-6

seem not follow the above words.

Could it let to be decided by IANA?

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Saturday, October 29, 2011 7:27 PM
To: Leaf yeh
Cc: Bernard Aboba; [email-masked]; [email-masked]; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 01 Nov 2011 06:13:04 +0000

'New allocations are

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Saturday, October 29, 2011 7:27 PM
To: Leaf yeh
Cc: Bernard Aboba; [email-masked]; [email-masked]; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

  Alan DeKok.
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext