[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
review of draft-ietf-radext-management-authorization-00.txt
Hi,
I have read <draft-ietf-radext-management-authorization-00.txt> and in
general I believe this document is in good shape and useful. I have
some issues which I tried to write up in the radiusext WG way...
---
Description: mention NETCONF as framed management protocol
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: 2
Section: 3
Rationale/Explanation of issue:
I think the first paragraph should also mention NETCONF as a Framed
Management protocol.
--
Description: add missing article
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: 2
Section: 4
Rationale/Explanation of issue:
s/containing policy name/containing a policy name/
--
Description: SNMP-Transport-Model vs. SNMP
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 1
Section: 7.1
Rationale/Explanation of issue:
Why is the value 1 associated with "SNMP-Transport-Model"? Should this
not be just "SNMP", perhaps implying SNMPv3? 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. 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.
--
Description: SNMP policy mapping and the reality
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 2
Section: 8
Rationale/Explanation of issue:
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.
--
Description: rules for extending enumerations
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 2
Section: 12
Rationale/Explanation of issue:
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.
--
Description: local or not so local area networks
Submitter name: Juergen Schoenwaelder
Submitter email address: j.schoenwaelder@jacobs-university.de
Date first submitted: Thu Sep 6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E/T
Priority: 2
Section: 13
Rationale/Explanation of issue:
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.
--
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
--
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/>