New ISSUE on RADIUS NAS Management Authorization draft

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

Description of issue
Submitter name: David Harrington
Submitter email address: ietfdbn@comcast.net
Date first submitted: 17-Oct-2007
Reference: https://ops.ietf.org/lists/radiusext/2007/msg00859.html
Document: NAS Management Authorization

Comment type: Technical
Priority: '1' Should fix
Section: 3
Rationale/Explanation of issue:

> > Should netconf be included in the list of framed-protocols?

Requested change:

Comment type: Editorial
Priority: '1' Should fix
Section: 3
Rationale/Explanation of issue:

> > The second paragraph feels a bit rambling.

Comment type: Technical
Priority: '1' Should fix
Section: 4
Rationale/Explanation of issue:

> > "contain the name of a management access rights policy"
> > "containing policy name" can this be more than one policy name?

Comment type: Technical
Priority: '1' Should fix
Section: 5
Rationale/Explanation of issue:

> > Is Transport-Protocol 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.

Comment type: Technical
Priority: '1' Should fix
Section: 7.1
Rationale/Explanation of issue:

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

Comment type: Technical
Priority: '1' Should fix
Section: 7.2
Rationale/Explanation of issue:

> > Should this be named Management-Transport-Protocol to differentiate
> > it from other service-related parameters?

> > While we definitely want this with SSH and TLS, is there a case for
> > having this with SNMPv1/UDP and other non-secure transports?

Comment type: Editorial
Priority: '1' Should fix
Section: 7.2
Rationale/Explanation of issue:

> > /managemetn/management/

Comment type: Technical
Priority: '1' Should fix
Section: 7.3
Rationale/Explanation of issue:

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

Comment type: Editorial
Priority: '1' Should fix
Section: 9
Rationale/Explanation of issue:

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

Comment type: Editorial
Priority: '1' Should fix
Section: 10
Rationale/Explanation of issue:

> > /proxy environments/RADIUS proxy environments/ to differentiate
> > this from SNMP proxy environments.

Comment type: Technical
Priority: '1' Should fix
Section: 13
Rationale/Explanation of issue:

> > "within local area networks" - I'm not sure this can be justified.
> > Many protocols originally designed for use only within local area
> > 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 information to help prevent
> > unauthorized management access.

Comment type: Editorial
Priority: '1' Should fix
Section: (various)
Rationale/Explanation of issue:

> > There are mentions of VACM. These should be couched as examples,
> > since SNMP can theoretically support multiple ACMs.


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