RE: Review of Management Authorization -00 document

["David B. Nelson" <dnelson@elbrysnetworks.com>]

I'm on the road currently, so I'll comment only briefly, and follow up later
in the week.

Thank you for the thoughtful and thorough review.

Regards,

Dave

> Section 3
> 
> This seems to imply that SSH would not be an acceptable value for
> Framed-Management-Protocol.  Is that right?

SSH delivers a secure transport service and a remote login (terminal
emulation service).  That does not seem to be the same thing as a specific
management protocol, of which SNMP is the most obvious example.  Should SHH
(alone) be considered a framed management protocol, or should it be
considered a remote form of CLI access?

> Section 7.2
> 
> I am not clear that all combinations of Framed-Management-Protocol
> and Transport-Protocol make sense.

I'll take a look at this in detail and follow up.

> Section 7.3
> 
>    The Management-Policy-Id attribute indicates the name of the
>    management access policy for this user.  Zero or more Management-
>    Policy-Id attributes MAY be sent in an Access-Accept packet.
>    Identifying a policy by name allows the policy to be used on
>    different NASes without regard to implementation details.
> 
> What does it mean if multiple Management-Policy-Id attributes are
> included?
> How are the policies merged?  If this is implementation-specific, isn't
> the result undefined?

This issues was raided by others.  The proposed resolution is to threat it
in the same way as we treat Filter-Id in the Issues & Fixes draft, i.e.
multiple instances are NOT RECOMMENDED and the result is undefined.

> Section 8
> 
> 
>        *  Service-Type (6) = Administrative (6)
>        *  Transport-Protocol (xx) = None (1)
> 
> Is the Transport-Protocol really none??

Hmmm...

> Section 9
>  
> I'm not clear that these statements make sense because there typically is
> no authentication in these AAA exchanges, right?

I'll take a closer look.  Probably wanton application of boilerplate text.
 
> Section 12
> 
>    This document contains placeholders ("TBA") for assigned numbers
>    within the RADIUS Attributes registry, to be assigned by IANA at the
>    time this document should be published as an RFC.  Assignement of
>    additional values for attributes defined in this document are to be
>    processed as described in [RFC3575].
> 
> RFC 3575 specifies "First come, first served", which requires no review.
> Is this really what you want?

Should we tighten up on some of these allocations, above any beyond the
provisions of RFC 3575?  I thought we didn't want to go down that path...



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