Re: Review of Design-01 Strawman

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> Section 2.1.3
> 
> This section makes a recommendation that complex data types SHOULD
> be avoided, and then goes on to say that complex attributes are
> acceptable for authentication mechanisms.  These two recommendations
> seem to be in conflict; my recommendation is that an exception for
> authentication mechanisms be inserted into the first paragraph and
> that the two paragraphs be placed closer together:

  The suggested text looks fine.  I will make the changes.

> Section 2.1.4
> 
>   New specifications SHOULD avoid defining message formats for services
>   inside a RADIUS document.  In addition, the service being provisioned
>   SHOULD NOT be defined in a RADIUS specification...
> 
>   For new services using RADIUS, the service SHOULD be defined
>   elsewhere, and provisioned in RADIUS.
> 
> Could be rephrased to:

  The suggested text looks fine.  I will make the changes.

> Section 2.2
> 
>   The high-order octet of the Vendor-Id field is 0 and the low-order 3
>   octets are the SMI Network Management Private Enterprise Code of the
>   Vendor in network byte order.
> 
> Actually, I believe that the SMI Enterprise code is 4 octets, no?

  Perhaps now.  In RFC 2865, it was the lower 3 octets.

>   Other attribute formats are NOT RECOMMENDED.  Examples of NOT
>   RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
>   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
>   Vendor-Specific contents that are not in Type-Length-Value format.
> 
> Is there a recommendation that RADIUS servers support the 16 bit vendor
> type format?

  Yes:

   In order to be compatible with the above recommendations for
   attribute definitions, it is RECOMMENDED that RADIUS servers support
   attributes using a 16-bit Vendor type field.


> Section 3.1.1
> 
>   Vendors and SDOs are reminded that the standard RADIUS attribute ID
>   space, and the ennumerated
> 
> Recommend changing to:

  The suggested text looks fine.  I will make the changes.

> The following paragraphs are a bit awkward:
...
> Recommend changing to:

  The suggested text looks fine.  I will make the changes.

> Section 3.1.2
> 
>   However, it is RECOMMENDED that Vendors follow the
>   guidelines outlined here, which are intended to enable maximum
>   interoperability with minimal changes to existing systems.
> 
> Recommend changing to:

  OK.

...
> These paragraphs seem like they belong in Section 3.1.1.  Is there a way
> to integrate them there?

  Yes,

> Section 3.1.3
...
> The term PEN is used here, but earlier, the term SMI vendor code is used.
> Can we make the usage consistent?

  Yes.  I'll fix it.

> "  This process means that SDOs do not have to rehost VSAs into the
...
> How about this?

  OK.

> Section 3.1.4
...
> How about this?

  Ok.

> Section 4
> 
>   This document requires no action by IANA.  [RFC4005].
> 
> What is the [RFC4005] reference for?

  Dangling typo.

> Section 5
...
> Can we reference FIPS 140 here?  There is currently a draft FIPS 140-3
> document available from NIST.

  I can add a reference to FIPS.

  I'll submit the updated document today.  Until it's published, it will
be available at:

http://deployingradius.com/ietf/draft-ietf-radext-design-01.txt

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