Subject: RE: COMMENT: draft-ietf-radext-design

From: <[email-masked]>
Date: Wed, 22 Apr 2009 18:25:44 +0200

Alan T DeKok wrote:

>   The comments are NOT largely editorial.  They are the direct
> result of multiple attempts (I-D's, vendors, etc.) to create complex
> data types where none are necessary.  The result is increased
> complexity in the protocol, the implementations, and decreased
> inter-operability.
> 
>   RADIUS is an authorization protocol that provisions pre-existing
> services.  Defining new services in RADIUS is explicitly out of
> scope of the protocol.

Yes, it's outside the scope of RADIUS, but "scope of RADIUS" is
not the same thing as "scope of some Internet-Draft".

>   Section 2.1.5 says:
> 
> 	New services using RADIUS for
>         provisioning SHOULD be defined elsewhere and referenced in the
>         RADIUS specification.
>
>   So yes, we are mandating two I-D's for provisioning new services
> in RADIUS.  One document to define the service, and another to
> define how RADIUS provisions that service.  This is no different
> than creating MIBs.  One document defines the protocol / service.
> Another one defines the MIBs.

This approach is not always used for MIBs. For example, the IEEE
802.11 specification includes both the protocol/service (802.11) and
the MIB in the same document.

And e.g. draft-ietf-isms-secshell-15 defines the SSH transport model
in the same Internet-Draft as the MIB for managing it.

Best regards,
Pasi
������r��zǧu���Ơz�+iخ��m��z�h�Ȟ��+����^ݺ{.n�+�����"�	^�)�j�azg�����mn�rj�!������� r���+-���v+�{

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Apr 2009 18:42:29 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 
> 802.11 specification includes both the protocol/service 
> (802.11) and the MIB in the same document.
> 

The IEEE 802.11 MIB is not defined in an IETF document. Even in the case
of the IEEE documents that define both the IEEE technology and
management model as part of the same standard, these are separate
sections at precise locations in the IEEE documents. 

Dan

--
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: Wed, 22 Apr 2009 12:45:05 -0400

Hi Pasi,

> not the same thing as "scope of some Internet-Draft".

If you look at my response in this thread, you'll note that I concur with
Alan, but with a slightly different slant.  In my view, this has less to do
with document content, and more to do with separation of concerns.

IF there is an existing (or emerging) service deployed in NASes and IF there
is a need to authorize / provision that service with RADIUS, THEN write an
RADIUS extension draft.

> in the same Internet-Draft as the MIB for managing it.

I agree that the MIB Module example is not the best illustration of the
concept.  One would not expect the protocol being managed to be defined
within the MIB Module.  It's OK to include a MIB Module in the document that
defines the protocols, but not the other way around.  No?

Regards,

Dave

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Apr 2009 23:59:33 -0700

> defines the protocols, but not the other way around.  No?

I'd agree with Pasi in the case where the service is defined (either within the same document or elsewhere).  In such a situation, it should be sufficient for the RADIUS attribute document to either reference the service definition (if it is in another document) or to include it within the same document.  This is an editorial decision outside the scope of the Design Guidelines document. 

The issue that this text was attempting to address was a situation in which there is no definition for the service, either within the document or elsewhere.  In this situation the Design Guidelines document is pointing out that designing management attributes (or MIBs for that matter) for a service that is undefined is not a "best current practice". 

For example, while a "RADIUS Attributes for IPv8" document might meet all the RADIUS Design guidelines, the fact that the document includes no reference for IPv8 is a problem of a non-editorial nature.

Believe it or not, this problem has actually come up in practice (more than once!).

---

From: "Dave Nelson" <[email-masked]>
Date: Thu, 23 Apr 2009 07:25:33 -0400

Bernard Aboba writes...

> For example, while a "RADIUS Attributes for IPv8" document might
> meet all the RADIUS Design guidelines, the fact that the document
> includes no reference for IPv8 is a problem of a non-editorial
> nature.

Right.  That's the most important issue.  Does the service that being
provisioned "exist"?

I think there is also an "ease of finding" issue to be considered.  If the
hypothetical "RADIUS Attributes for IPv8" document *did* indeed contain a
section that defined IPv8, that might not be the first document you'd think
to look at to find a definition of IPv8. :-)