Additional comments on draft-ietf-radext-management-authorization-03.txt

[Bernard Aboba <aboba@internaut.com>]

Section 8.1

"Service-Type of Framed-Management" -> "Service-Type Attribute 
with the value Framed-Management"

"in Access-Request packet" -> "in an Access-Request packet"

"MAY use these hint attributes" -> "may use these attributes as a hint"

"MUST treat the response" -> "MUST treat the Access-Accept"

"http://www.w3.org/TR/html": Please add this to the reference
section, and refer to it in Section 8.1. 

"(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)"
Please add this in the reference section. 

RCP: Can you add a reference?

SCP: Please add a reference (doesn't this also use the services of SSH?)

Section 8.2

   The Management-Transport-Protection Attribute specifies whether a
   secure transport protocol (e.g.  SSH, TLS, DTLS, etc.) is required
   for use with the associated framed or non-framed management access
   session.  The value of this attribute specifies the minimum level of
   protection that is required from the protected transport.  The
   protected transport MAY provide a greater level of protection than is
   called for by the value of Management-Transport-Protection.

[BA] The second sentence is more on target.  How about this? 

   The Management-Transport-Protection Attribute specifies the minimum
   level of protection that is required for a protected transport used
   with the framed or non-framed management access session.  The protected
   transport used by the NAS MAY provide a greater level of protection, 
   but MUST NOT provide a lower level of protection. 

"in Access-Request packet" -> "in an Access-Request packet"
"RADIUS Client" -> "RADIUS clent"
"RADIUS Server" -> "RADIUS server"
"MAY use this hint attribute" -> "may use this attribute as a hint"

Section 8.3

"application to SMNP services" -> "SNMP"
"NAS behavior in such cases is not predictable." -> "The behavior of the 
NAS in this case is undefined."
"a single service provisioning message, such as" -> "an Access-Accept or 
CoA-Request". 

", within a flat namespace of significance to the NAS"

[BA] Are you saying that "." can't be used?  Can this be deleted? 

"Overloading or subdividing this flat name with" ->
"Overloading or subdividing this attribute with"

"If a simple flat policy name" -> "If a simple policy name"
"sufficient to the anticipated use case" -> "sufficient"

Section 12

Within the document, the CoA-Request is mentioned, but the table does not 
describe which attributes can be included in CoA or Disconnect Request, 
ACK or NAK packets.  Is it accurate to assume that none of the attributes
defined in this document can be contained in a CoA or Disconnect packet?

Section 14

   Any of the attributes described in this memo, with the exception of
   Service-Type, may not be understood by the NAS which receives it.  A
   legacy NAS not compliant with this specification may silently discard
   these attributes while permitting the user to access the management
   interface(s) of the NAS.  This can lead to users improperly receiving
   unauthorized management access to the NAS, or access with greater
   levels of access rights than were intended.  RADIUS servers SHOULD
   attempt to ascertain whether or not the NAS supports these attributes
   before sending them in an Access-Accept. 

[BA] This paragraph could be more clear.  There are really two cases. 
When a Service-Type value of Framed-Management is used, I'd assume that a
NAS implementing this specification would be required to behave as 
specified (e.g. treat the Access-Accept as an Access-Reject if the
attribute or value wasn't supported).  

I think that an issue could occur when a legacy Service-Type value
is used though, since then the NAS might ignore the new attributes instead 
of treating the Access-Accept like an Access-Reject.  

I don't think you need to talk about the potential behavior of an 
implementation that claims to conform to the spec, but doesn't do what it 
says.  



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