Subject: Re: IPv6

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 01:01:45 -0700

Alan DeKok said:

"I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less."

[BA] Either the Design Guidelines advice is appropriate or it isn't. 

If it isn't right, then we should fix it, because eventually it will become an RFC and "racing against" it won't work any more. 
If it is right, then we should try to adhere to the guidelines -- that's what they are there for. 

In this particular case, my take is that the Design Guidelines document is saying "don't do precisely what RFC 2868 did".  That is quite sensible.  However, it might also be helpful to say "Here are the problems that were caused by RFC 2868's scheme, and here is some advice to avoid those issues".  That way, until we finish the Extended Attributes document, we'll have some way to address these kind of situations.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Sep 2009 11:17:24 +0200

> [BA] Either the Design Guidelines advice is appropriate or it isn't.

  The comment was an attempt at humor, to counter the vitriol directed
at the design guidelines document.

> In this particular case, my take is that the Design Guidelines document
> is saying "don't do precisely what RFC 2868 did".  That is quite
> sensible.  However, it might also be helpful to say "Here are the
> problems that were caused by RFC 2868's scheme, and here is some advice
> to avoid those issues".  That way, until we finish the Extended
> Attributes document, we'll have some way to address these kind of
> situations.

  Update 2.1.1 Tag Mechanism:

Old text:

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

New text:

   Where these limitations do not apply, new attributes MAY use this
   tagging method, though it is NOT RECOMMENDED.  Where the above
   limitations apply, this tagging method SHOULD NOT be used.

  Alan DeKok.

--
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: "Dave Nelson" <[email-masked]>
Date: Sun, 27 Sep 2009 08:57:24 -0400

Bernard Aboba writes...

> Either the Design Guidelines advice is appropriate or it isn't. 
>
> If it isn't right, then we should fix it, because eventually
> it will become an RFC and "racing against" it won't work any
> more.  If it is right, then we should try to adhere to the
> guidelines -- that's what they are there for.

+1

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 08:46:39 -0700

>    limitations apply, this tagging method SHOULD NOT be used.

Here is the original text of Section 2.1.2:

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values, because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (assuming the tag is optional).

   Other limitations of the tagging mechanism are that when integer
   values are tagged, the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

"

How about this? 

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.
   As stated in [RFC2868] Section 3.3:

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values, because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (e.g. where the first byte of the following
   String field falls in the range of 0x00 through 0x1F). 

   Other limitations of the tagging mechanism are that when integer
   values are tagged, the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
      
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present; 

        * The design make no assumption about the content of the
          data within tagged attributes."