RE: COMMENT: draft-ietf-radext-design

["Dave Nelson" <d.b.nelson@comcast.net>]

Hi Pasi,

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

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.

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

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



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