FW: review of NAS-MManagement-authroization

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

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net]
> Sent: Wednesday, October 17, 2007 1:29 AM
> To: 'David B. Nelson'
> Cc: radext@ietf.org
> Subject: review of NAS-MManagement-authroization
> 
> Hi,
> 
> I'm not sure of the radext ML address. Please forward to radext if it
> isn't radext@ietf.org
> 
> Overall this document looks good. I strongly support its development.
> A few comments:
> 
> section 3.
> Should netconf be included in the list of framed-protocols?
> 
> The second paragraph feels a bit rambling.
> 
> section 4.
> "contain the name of a management access rights policy"
> "containing policy name"
> can this be more than one policy name?
> 
> section 5
> Is Transport-Protocool really only valid for the CLI?
> Should it be named CLI-Transport-Protocol to help make that
> unambiguous?
> The examples in section 8 show it applies to more than just CLI.
> 
> section 7.1
> I have not yet walked through the various combinations of SNMP
> components (message formats vs transports).
> I think SNMP-Transport-Model only covers a small set of possibilities.
> More research is needed on this.
> 
> section 7.2
> Should this be named MManagement-Transport-Protocol to differentiate
> it from other service-related parameters?
> /managemetn/management/
> 
> While we definitely want this with SSH and TLS, is there a case for
> having this with SNMPv1/UDP and other non-secure transports?
> 
> section 7.3
> SNMP does not support sessions, although the transport over which SNMP
> runs may have sessions.
> Does the term session here refer to an SNMP session? If so, that is a
> problem.
> 
> /NAS SHOULD treat the packet/NAS MUST treat the packet/? Under what
> circumstances would it be acceptable to not reject?
> 
> "It is recommended" to use UTF-8. Should UTF-8 support be mandatory to
> implement?
> 
> section 9
> "what this specification says" and "what is said" seem quaint ways of
> describing this. Would it be better to specify the sections where
> things are said, or is this language a common approach for
> RADIUS-Diameter coordination?
> 
> section 10
> /proxy environments/RADIUS proxy environments/ to differentiate this
> from SNMP proxy environments.
> 
> section 13
> "within local area networks" - I'm not sure this can be justified.
> Many protocols originally designed for use only within local araea
> networks actually get used over the Internet. Do we actually have any
> mechanism to prevent this from happening, or is it just recommended
> that it be restricted to use in a LAN?
> 
> I think the last paragraph should include a statement at the end,
> recommending that management protocols should support data access
> controls to prevent the disclosure of inofrmation to help prevent
> unauthorized management access.
> 
> Throughout
> There are mentions of VACM. These should be couched as examples, since
> SNMP can theoretically support multiple ACMs.
> 
> David Harrington
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 



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