RE: review of draft-ietf-radext-management-authorization-00.txt

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

Juergen Schoenwaelder writes...

> I think the first paragraph should also mention NETCONF as a Framed
> Management protocol.

Others have suggested this as well.  Will do.

> s/containing policy name/containing a policy name/

OK.

> Why is the value 1 associated with "SNMP-Transport-Model"? Should this
> not be just "SNMP", perhaps implying SNMPv3?

Others have made s similar suggestion, so I think something along the lines
of your recommendation is called for.

> This would be more consistent with example #4, no? In fact, the 
> proposed RADIUS attributes do not carry what really counts - the 
> security level, e.g. I might accept SNMP access as long as the 
> actual security level is providing authPriv, regardless how this is
> achieved.

That may indeed be useful...

> Well, since we do not have a defined way to utilize RADIUS from
> SNMPv3/USM, this is probably a mood point. Still, I think calling this 
> enum just SNMP is the better approach.

Yes.

> Example #4 is nice but there is no agreement/specification how this
> would work with SNMPv3 and ISMS is not chartered to figure this out.
> Perhaps this can be addressed by adding a note saying.
> 
>   Note that there is currently no standardized way of implementing
>   this management policy mapping for SNMPv3.

OK.  This is currently something implementation specific.

> The two new attributes Framed-Management-Protocol and
> Transport-Protocol are enumerations that may need to be extended
> (e.g. NETCONF is missing in the first one already). I suggest that
> the IANA section spells out the rules for extending these
> enumerations, e.g. by requiring a specification.

Another reviewer commented in a similar fashion, that this draft should
provide more specific guidance to IANA than simply falling back on RFC 3775.
I'll add some text.

> The first sentence in the security considerations kind of restricts
> RADIUS and DIAMETER to "local area networks". I am not sure why this
> should be useful or what breaks if the network is not a local area
> network (however this is defined). I suggest to simple remove the
> phrase "within local area networks" or if there is a reason for 
> having this restriction, then please add text which spells the 
> reasons out.

No reason.  I'll remove the restriction.

Thanks for the through review.


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